BSOD irql not less or equal

speedlever · 14 Sep 2011

When you guys use memtest86, do you set the mobo's BIOS to default settings first? I never considered what effect any custom settings I have could influence the outcome of the test.. 'til now.

speedlever · 16 Sep 2011

A new bsod today... Reference_by_pointer. Never seen that one before.

yowanvista · 17 Sep 2011

STOP 0x00000018: REFERENCE_BY_POINTER

Usual causes: Device driver, kernel, hardware

Either system files are corrupt, old unstable device drivers or defective hardware are the possible causes

SFC /SCANNOW Command - System File Checker
Repair Install

The only old drivers are:

Code:

SiLib.sys        fffff880`04cb2000    fffff880`04cc0000    0x0000e000    0x45c90bb2    07/02/2007 03:13:54                
DSI_SiUSBXp_3_1.sys        fffff880`04ca8000    fffff880`04cb2000    0x0000a000    0x45c90c16    07/02/2007 03:15:34           
lmimirr.sys        fffff880`0f053000    fffff880`0f05a000    0x00007000    0x461c108d    11/04/2007 02:32:45

Any software fro this vendor should be updated This is ANT, the Wireless Sensor Network Solution
Remove LogMeIn for diagnostic purposes

Code:

*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

REFERENCE_BY_POINTER (18)
Arguments:
Arg1: 0000000000000000, Object type of the object whose reference count is being lowered
Arg2: fffffa8009d91060, Object whose reference count is being lowered
Arg3: 0000000000000002, Reserved
Arg4: ff00000000000002, Reserved
    The reference count of an object is illegal for the current state of the object.
    Each time a driver uses a pointer to an object the driver calls a kernel routine
    to increment the reference count of the object. When the driver is done with the
    pointer the driver calls another kernel routine to decrement the reference count.
    Drivers must match calls to the increment and decrement routines. This bugcheck
    can occur because an object's reference count goes to zero while there are still
    open handles to the object, in which case the fourth parameter indicates the number
    of opened handles. It may also occur when the object’s reference count drops below zero
    whether or not there are open handles to the object, and in that case the fourth parameter
    contains the actual value of the pointer references count.

Debugging Details:
------------------


CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

BUGCHECK_STR:  0x18

PROCESS_NAME:  procexp64.exe

CURRENT_IRQL:  0

LAST_CONTROL_TRANSFER:  from fffff80002a68944 to fffff80002ac7c40

STACK_TEXT:  
fffff880`07964678 fffff800`02a68944 : 00000000`00000018 00000000`00000000 fffffa80`09d91060 00000000`00000002 : nt!KeBugCheckEx
fffff880`07964680 fffff800`02d83c9d : fffff880`07964ca0 fffffa80`0616ea10 fffffa80`0616ee30 00000000`0701b780 : nt! ?? ::FNODOBFM::`string'+0x49d71
fffff880`079646e0 fffff800`02dd19f6 : 00000000`07000080 00000000`000226c8 fffff880`07964870 00000000`00000000 : nt!ExpGetProcessInformation+0x4ef
fffff880`07964830 fffff800`02dd2449 : 00000000`07000080 fffff880`07964c30 00000000`00000000 00000000`00000001 : nt!ExpQuerySystemInformation+0xfb4
fffff880`07964be0 fffff800`02ac6ed3 : fffffa80`08701b60 fffff880`07964ca0 00000000`00000400 00000000`00000020 : nt!NtQuerySystemInformation+0x4d
fffff880`07964c20 00000000`7775167a : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
00000000`0557ddb8 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x7775167a


STACK_COMMAND:  kb

FOLLOWUP_IP: 
nt! ?? ::FNODOBFM::`string'+49d71
fffff800`02a68944 cc              int     3

SYMBOL_STACK_INDEX:  1

SYMBOL_NAME:  nt! ?? ::FNODOBFM::`string'+49d71

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: nt

IMAGE_NAME:  ntkrnlmp.exe

DEBUG_FLR_IMAGE_TIMESTAMP:  4e02aaa3

FAILURE_BUCKET_ID:  X64_0x18_nt!_??_::FNODOBFM::_string_+49d71

BUCKET_ID:  X64_0x18_nt!_??_::FNODOBFM::_string_+49d71

Followup: MachineOwner
---------

speedlever · 17 Sep 2011

Thanks for the info.

This system is driving me nuts. Nothing makes sense. memtest86 results are inconclusive. And yet the system just keeps running with just an occasional bsod or lockup. I'm starting to think it's time to replace the mobo, processor, and ram... reinstall win7/64 HP on the SSD and start all over... again.

Edit: I just learned that I may be able to replace the mobo, cpu, and ram without necessarily having to reinstall Win7/64HP. Now the OS re-install is no big deal, but reinstalling and tweaking all my program settings *is* a big deal. That makes this option more palatable, other than for the cost.

speedlever · 20 Sep 2011

I noticed that the computer had a couple of bsods in my absence today. I'll submit another report. Does this serve a purpose at this point? I'm thinking it's past time to dump this mobo, cpu, and ram and build a (basically) new system. Argh.

yowanvista · 21 Sep 2011

speedlever said:

I noticed that the computer had a couple of bsods in my absence today. I'll submit another report. Does this serve a purpose at this point? I'm thinking it's past time to dump this mobo, cpu, and ram and build a (basically) new system. Argh.

This was caused by nvlddmkm.sys, part of the Nvidia Driver
Either the driver is improperly installed or a combination of hardware defects might be causing the crash
I would suggest a reinstall of the Nvidia Driver

Code:

*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high.  This is usually
caused by drivers using improper addresses.
If kernel debugger is available get stack backtrace.
Arguments:
Arg1: fffffa80667ccbb4, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000001, value 0 = read operation, 1 = write operation
Arg4: fffff8800f49c8a6, address which referenced memory

Debugging Details:
------------------


WRITE_ADDRESS: GetPointerFromAddress: unable to read from fffff80002d0f100
 fffffa80667ccbb4 

CURRENT_IRQL:  2

FAULTING_IP: 
nvlddmkm+42f8a6
fffff880`0f49c8a6 4883c468        add     rsp,68h

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

BUGCHECK_STR:  0xD1

PROCESS_NAME:  System

TRAP_FRAME:  fffff80000b9c690 -- (.trap 0xfffff80000b9c690)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000001000000 rbx=0000000000000000 rcx=0000000000000018
rdx=0000000000010000 rsi=0000000000000000 rdi=0000000000000000
rip=fffff8800f49c8a6 rsp=fffff80000b9c820 rbp=0000000000000000
 r8=0000000000000000  r9=0000000000000000 r10=fffffa800614c7b0
r11=fffff80000b9c720 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei pl nz na po nc
nvlddmkm+0x42f8a6:
fffff880`0f49c8a6 4883c468        add     rsp,68h
Resetting default scope

LAST_CONTROL_TRANSFER:  from fffff80002adc1e9 to fffff80002adcc40

STACK_TEXT:  
fffff800`00b9c548 fffff800`02adc1e9 : 00000000`0000000a fffffa80`667ccbb4 00000000`00000002 00000000`00000001 : nt!KeBugCheckEx
fffff800`00b9c550 fffff800`02adae60 : fffffa80`060f9000 fffffa80`060f9000 00000000`00000000 fffffa80`073b62f0 : nt!KiBugCheckDispatch+0x69
fffff800`00b9c690 fffff880`0f49c8a6 : fffffa80`060f9000 00000000`00000000 00000000`00000001 fffffa80`073b6688 : nt!KiPageFault+0x260
fffff800`00b9c820 fffffa80`060f9000 : 00000000`00000000 00000000`00000001 fffffa80`073b6688 00000000`00000000 : nvlddmkm+0x42f8a6
fffff800`00b9c828 00000000`00000000 : 00000000`00000001 fffffa80`073b6688 00000000`00000000 fffff880`0f271820 : 0xfffffa80`060f9000


STACK_COMMAND:  kb

FOLLOWUP_IP: 
nvlddmkm+42f8a6
fffff880`0f49c8a6 4883c468        add     rsp,68h

SYMBOL_STACK_INDEX:  3

SYMBOL_NAME:  nvlddmkm+42f8a6

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: nvlddmkm

IMAGE_NAME:  nvlddmkm.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  4e391010

FAILURE_BUCKET_ID:  X64_0xD1_nvlddmkm+42f8a6

BUCKET_ID:  X64_0xD1_nvlddmkm+42f8a6

Followup: MachineOwner
---------

speedlever · 21 Sep 2011

I'll uninstall and d/l a fresh copy of the Nvidia driver and install it.

The crashes are becoming more frequent. Do you think there's any point in me continuing to send in the bsod zip files for analysis?

yowanvista · 22 Sep 2011

speedlever said:

I'll uninstall and d/l a fresh copy of the Nvidia driver and install it.

The crashes are becoming more frequent. Do you think there's any point in me continuing to send in the bsod zip files for analysis?

All dumps seem to point to a GPU/RAM issue, it might also be failing hardware

speedlever · 22 Sep 2011

It may be worth yanking those 2x1GB ram sticks out of the stand-by computer and running 4x1GB ram for a while and see if I have any more issues with bsods. If I can run for a week or so without a bsod/lockup, it may be worth replacing all the DDR2 ram with a matched set of 4x2GB ram. Otherwise, it sounds like it will be time for a new mobo, cpu, and DDR3 ram.

speedlever · 26 Sep 2011

I have yet to replace the AData 2x2GB ram with the known good sticks of 2x1Gb ram from the standby computer.

Another bsod today, while the computer was sitting unused.

Looking at event viewer, I can't really interpret anything from what I see. The critical events seem to parallel bsods... best I can tell.