BSOD: irql_not_less_or_equal

**Snegithan** · May 15, 2008

Hi Everyone,

I am using a Acer 5920G notebook which was loaded with Vista Home Premium x86. I have format the factory default image/partition and reinstalled Vista Ultimate x64. I am using the drivers which are provided by the notebook manufacturer for 64bit Vista editions. I feel the system is running smooth and stable and I also never notice any errors on the event logs but I have this BSOD (irql_not_less_or_equal) problem which happens 2 times within past 2 weeks. When the first BSOD happens 1 week back I don’t manage to record down the error message or the snap of error BSOD. So I disable the auto restart on BSOD function in advance properties. I encounter the same problem yesterday for second time. I have uploaded the BSOD snap and as well as the minidump. Can someone advise me how I can solve the BSOD problem? Even it’s happen once in a blue moon but I feel uncomfortable with it.

System Specs

===========

Intel C2D T7500 (2.2GHZ)

Nvdia 8600M GT

4GB RAM

250 HDD

BSOD SNAP (http://www.geocities.com/tamilstrike2k/dsc00031.jpg)

BSOD minidump (http://www.geocities.com/tamilstrike2k/Mini051408-01.zip)

Thanks in advance guys

Edited May 15, 2008 by Snegithan

**nitroshift** · May 15, 2008

Please configure your pc for a complete memory dump and insert valid links in your post.

**Snegithan** · May 15, 2008

Please configure your pc for a complete memory dump and insert valid links in your post.

Hi sorry for the typo error. i update the link already. Please check again.

Edited May 15, 2008 by Snegithan

**nitroshift** · May 15, 2008

I`ve read your minidump but an error in ntoskrnl.exe could mean anything... As I said in my previous post, please configure your machine for a COMPLETE memory dump as described here: http://www.msfn.org/board/Creating-memory-dumps-t90244.html When you have the complete dump, compress it and upload it so we can have a look at it. Good luck!

**Snegithan** · May 15, 2008

I`ve read your minidump but an error in ntoskrnl.exe could mean anything... As I said in my previous post, please configure your machine for a COMPLETE memory dump as described here: http://www.msfn.org/board/Creating-memory-dumps-t90244.html When you have the complete dump, compress it and upload it so we can have a look at it. Good luck!

Hi nitroshift,

Thanks for the quick reply. i already check the ink http://www.msfn.org/board/Creating-memory-dumps-t90244.html. BTW, my root contains the c:\windows\memory.dmp file which is 543MB in size. I am not sure your talking about this file? can provide a little more information? Thanks alot

**nitroshift** · May 15, 2008

That is the file I was talking about. Please compress and upload it. Also, having a second look at the minidump with the !analyze -v option it looks that the fault comes from a driver, but cannot pinpoint it until I get my hands on the full dump. Waiting for your link now

**cluberti** · May 15, 2008

Well, the minidump did give something, which was surprising in and of itself. I've got the bugcheck and exception record, and I think maybe this is a driver problem (although getting that full memory.dmp uploaded somewhere to make sure is still prudent). Here's what I see:

1: kd> .bugcheck
Bugcheck code 0000000A
Arguments 00000000`00000008 00000000`0000000c 00000000`00000001 fffff800`01cb7509

// looks like we have (potentially) tried to move the contents of rax into 0x8, which of
// course will fail:
1: kd> .trap 0xfffffa600d812940
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=fffffa800a416618 rbx=fffffa600d812a98 rcx=0000000000000000
rdx=fffffa8005f8f8c0 rsi=fffffa8000000000 rdi=2000000070000000
rip=fffff80001cb7509 rsp=fffffa600d812ad0 rbp=fffffa800a7392a8
 r8=0000000000000000  r9=0000000000000000 r10=fffff9600018d364
r11=fffff900c1fad4f0 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0		 nv up ei pl nz na po nc
nt!KeSetEvent+0x289:
fffff800`01cb7509 48894108		mov	 qword ptr [rcx+8],rax ds:00000000`00000008=????????????????

// we were working with the win32k queue structure, and we were involved in drawing
// something in the window for taskeng.exe (the task manager):
1: kd> k
  *** Stack trace for last set context - .thread/.cxr resets it
Child-SP		  RetAddr		   Call Site
fffffa60`0d812ad0 fffff960`0018b7c6 nt!KeSetEvent+0x289
fffffa60`0d812b40 fffff960`0018d7d9 win32k!SetWakeBit+0xe6
fffffa60`0d812b70 fffff960`0018d5c0 win32k!_PostThreadMessage+0x151
fffffa60`0d812bd0 fffff800`01cb0e33 win32k!NtUserPostThreadMessage+0x25c
fffffa60`0d812c20 00000000`774934ba nt!KiSystemServiceCopyEnd+0x13
00000000`038de378 00000000`00000000 0x774934ba

This could be a malfunctioning device driver (in fact, it almost always is when win32k.sys is involved in the crash), but we'll wait for the full dump to be sure. I've seen overclocked machines do this, I've seen bad RAM cause this, and I've seen hard drives that are dying cause this as well, so I need to be sure before I blame anything software.

**Snegithan** · May 15, 2008

Hello nitroshift/cluberti,

I compressed the file and upload it to mediafire.

LINK: (http://www.mediafire.com/?2hpt4cy3az3)

Thanks for the help

**cluberti** · May 15, 2008

Hello nitroshift/cluberti,
I compressed the file and upload it to mediafire.
LINK: (http://www.mediafire.com/?2hpt4cy3az3)
Thanks for the help

Ouch, hate to say it but this isn't useful...

1: kd> kb
RetAddr		   : Args to Child														   : Call Site
fffff800`01cb112e : 00000000`0000000a 00000000`00000008 00000000`0000000c 00000000`00000001 : nt!KeBugCheckEx
fffff800`01cb000b : 00000000`00000001 fffffa80`0a8cf700 fffffa80`0a8cf700 fffffa80`0a7392a0 : nt!KiBugCheckDispatch+0x6e
fffff800`01cb7509 : 00000000`00395870 00000000`00000000 fffffa80`0a6fcaf0 00000000`00000000 : nt!KiPageFault+0x20b
Page a0125 not present in the dump file. Type ".hh dbgerr004" for details
Page a0125 not present in the dump file. Type ".hh dbgerr004" for details
fffff960`0018b7c6 : fffffa80`0a83ec10 00000000`00000000 fffffa80`0a8cf700 fffff800`01f4c5f1 : nt!KeSetEvent+0x289
Page a0125 not present in the dump file. Type ".hh dbgerr004" for details
Page a0125 not present in the dump file. Type ".hh dbgerr004" for details
Page a0125 not present in the dump file. Type ".hh dbgerr004" for details
Page a0125 not present in the dump file. Type ".hh dbgerr004" for details
Page a0125 not present in the dump file. Type ".hh dbgerr004" for details
fffff960`0018d7d9 : 00000000`0000c046 fffff900`c1fad4f0 fffff900`c1fad860 fffff960`00187468 : win32k!SetWakeBit+0xe6
Page a0125 not present in the dump file. Type ".hh dbgerr004" for details
Page a0125 not present in the dump file. Type ".hh dbgerr004" for details
Page a0125 not present in the dump file. Type ".hh dbgerr004" for details
Page a0125 not present in the dump file. Type ".hh dbgerr004" for details
Page a0125 not present in the dump file. Type ".hh dbgerr004" for details
Page a0125 not present in the dump file. Type ".hh dbgerr004" for details
fffff960`0018d5c0 : 00000000`0000c046 00000000`00000000 fffff900`c1fad860 fffff900`c1fad4f0 : win32k!_PostThreadMessage+0x151
Page a0125 not present in the dump file. Type ".hh dbgerr004" for details
Page a0125 not present in the dump file. Type ".hh dbgerr004" for details
Page a0125 not present in the dump file. Type ".hh dbgerr004" for details
Page a0125 not present in the dump file. Type ".hh dbgerr004" for details
fffff800`01cb0e33 : fffffa80`0a8cf700 fffffa60`0d812ca0 00000000`0041c9c0 00000000`0041c9c0 : win32k!NtUserPostThreadMessage+0x25c
Page a0125 not present in the dump file. Type ".hh dbgerr004" for details
00000000`774934ba : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x774934ba

If you can set your page file size on C: to have both the Min and Max values be 6144, reboot, and try again - this dump is missing a LOT of information, especially about the callstack where the problem occurred (not good).

**Snegithan** · May 16, 2008

Hi,

I checked my advance system properties for the page file settings. currently its on c drive and system managed size. Do i need to change the values to manual as per the previous post? After do the changes do i need to wait for the next BSOD happen b4 i upload the memory dump file? please advise

Thanks

**nitroshift** · May 19, 2008

Hi,
I checked my advance system properties for the page file settings. currently its on c drive and system managed size. Do i need to change the values to manual as per the previous post? After do the changes do i need to wait for the next BSOD happen b4 i upload the memory dump file? please advise
Thanks

Yes to both questions

**Snegithan** · May 19, 2008

Hi Guys,

I already configure my page file settings as per cluberti's post. So far i didn't encounter any BSOD yet. I also tried to use memtest86 v2.01 (memtest.org) tool for check my rams. After perform the checks on my rams around 1hr, the tool prompted that my rams are in good condition. I also do test my rams with Vista built-in Memory Diagnostics Tool and the results are still same as memtest86. I found a post at Windows Vista Blog (http://windowsvistablog.com/blogs/windowsvista/archive/2008/03/18/windows-vista-sp1-released-to-windows-update.aspx) which claims any realtek drivers with version 6.0.1.6242 or earlier is not compatible with Windows vista sp1. Previously i was using the realtek driver 6.0.1.5413 which is provided by Acer. I already downloaded the newer version from realtek website and update my old drivers to figure out if i still getting the BSOD. I just wondering if Microsoft only restrict the computers with certain incompatible drivers from getting the sp1 though windows update but for the users who using integrated versions of the vista sp1 media from msdn network was not prompted with any error messages during the installation of imcomptible drivers. Anyone encounter similar problems? Anyone using modded Nvidia drivers from www.laptopvideo2go.com? I would like to update my Nvidia drivers as well, but I feel not safe to use modded drivers. If anyone here using the modded drivers, pls share with me thx

Edited May 19, 2008 by Snegithan

**Snegithan** · May 25, 2008

Hi Guys,

i got a BSOD yesterday and i got the latest minidump and memory dump uploaded. Please help me to check. This file should be proper one for debug as i already configured my page file settings as per cluberti's post earlier.

http://www.mediafire.com/?b1vgjznxkdc (memory dump)

http://www.mediafire.com/?hzoc2obzexz (mini dump)

Thanks

Edited May 25, 2008 by Snegithan

**Mr Snrub** · May 25, 2008

Unfortunately this leads to a bit of a dead-end, for me at least, as it is a corruption in nonpaged pool, and there's no clear way to see what did the corruption.

For those interested, here is my working...

IRQL_NOT_LESS_OR_EQUAL (a)
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 a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 0000000000000008, memory referenced
Arg2: 000000000000000c, IRQL
Arg3: 0000000000000001, bitfield :
	bit 0 : value 0 = read operation, 1 = write operation
	bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4: fffff80001e6e509, address which referenced memory

TRAP_FRAME:  fffffa600c844940 -- (.trap 0xfffffa600c844940)
NOTE: The trap frame does not contain all registers.

Some register values may be zeroed or incorrect.
rax=fffffa80043851a8 rbx=fffffa600c844a98 rcx=0000000000000000
rdx=fffffa80044e7880 rsi=fffffa8000000000 rdi=2000000070000000
rip=fffff80001e6e509 rsp=fffffa600c844ad0 rbp=fffffa8004389608
 r8=0000000000000000  r9=0000000000000000 r10=fffff960000fd364
r11=fffff900c0811d10 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0		 nv up ei pl nz na pe nc

nt!KeSetEvent+0x289:
fffff800`01e6e509 48894108		mov	 qword ptr [rcx+8],rax ds:00000000`00000008=????????????????

0: kd> .trap 0xfffffa600c844940
0: kd> k
  *** Stack trace for last set context - .thread/.cxr resets it
Child-SP		  RetAddr		   Call Site
fffffa60`0c844ad0 fffff960`000fb7c6 nt!KeSetEvent+0x289
fffffa60`0c844b40 fffff960`000fd7d9 win32k!SetWakeBit+0xe6
fffffa60`0c844b70 fffff960`000fd5c0 win32k!PostThreadMessage+0x151
fffffa60`0c844bd0 fffff800`01e67e33 win32k!NtUserPostThreadMessage+0x25c
fffffa60`0c844c20 00000000`775f34ba nt!KiSystemServiceCopyEnd+0x13
00000000`0253e828 00000000`00000000 0x775f34ba

0: kd> u nt!KeSetEvent+0x289-20
nt!KeSetEvent+0x269:
fffff800`01e6e4e9 44894304		mov	 dword ptr [rbx+4],r8d
fffff800`01e6e4ed 0fb74028		movzx   eax,word ptr [rax+28h]
fffff800`01e6e4f1 498b9788000000  mov	 rdx,qword ptr [r15+88h]
fffff800`01e6e4f8 49098780000000  or	  qword ptr [r15+80h],rax
fffff800`01e6e4ff 488b4208		mov	 rax,qword ptr [rdx+8]
fffff800`01e6e503 488b0a		  mov	 rcx,qword ptr [rdx]
fffff800`01e6e506 488908		  mov	 qword ptr [rax],rcx
fffff800`01e6e509 48894108		mov	 qword ptr [rcx+8],rax

The unassembly at the end is the set of instructions leading up to the bugcheck, which occurs because RCX contains 0, and should be a memory address.

Moving back to the previous instruction, the value in regsiter RCX (0) was placed into the memory address pointed to by RAX (fffffa80043851a8)...

0: kd> dq rax rax+1
fffffa80`043851a8  00000000`00000000

Moving back again, RCX was populated by the memory contents pointed to by RDX (fffffa80044e7880)...

0: kd> dq rdx rdx
fffffa80`044e7880  00000000`00000000

Before that, RAX was populated by the memory contents pointed to by RDX+8...

0: kd> dq rdx+8 rdx+8
fffffa80`044e7888  fffffa80`043851a8

As we are using RDX as a memory pointer and using an offset in another instruction, it seems RDX is pointing to a data structure of some kind, we can check if it was a pool allocation:

0: kd> !pool rdx
Pool page fffffa80044e7880 region is Nonpaged pool
 fffffa80044e7000 size:  130 previous size:	0  (Allocated)  File (Protected)
 fffffa80044e7130 size:   80 previous size:  130  (Allocated)  Muta (Protected)
 fffffa80044e71b0 size:   80 previous size:   80  (Allocated)  MmSd
 fffffa80044e7230 size:  1e0 previous size:   80  (Allocated)  CcSc
 fffffa80044e7410 size:  150 previous size:  1e0  (Allocated)  Mdl 
 fffffa80044e7560 size:  150 previous size:  150  (Allocated)  File (Protected)
 fffffa80044e76b0 size:   10 previous size:  150  (Free)	   Irp 
*fffffa80044e76c0 size:  3a0 previous size:   10  (Allocated) *Wait
		Pooltag Wait : NtWaitForMultipleObjects
 fffffa80044e7a60 size:  1a0 previous size:  3a0  (Allocated)  MmCi
 fffffa80044e7c00 size:   30 previous size:  1a0  (Allocated)  MmSi
...

The pool allocation starts at fffffa80044e76c0 and the next one starts at fffffa80044e7a60, so let's take a look at the data in between:

0: kd> dq fffffa80044e76c0 fffffa80044e7a60-1
fffffa80`044e76c0  74696157`023a0001 fffff800`01fa6548

fffffa80`044e76d0  fffffa80`0438e048 fffffa80`0438e048
fffffa80`044e76e0  fffffa80`0438fbb0 fffffa80`0438e040
fffffa80`044e76f0  fffffa80`044e7700 00000000`00010000

fffffa80`044e7700  fffffa80`04366738 fffffa80`04366738
fffffa80`044e7710  fffffa80`0438fbb0 fffffa80`04366730
fffffa80`044e7720  fffffa80`044e7730 00000000`00010001

fffffa80`044e7730  fffffa80`04385b58 fffffa80`04385b58
fffffa80`044e7740  fffffa80`0438fbb0 fffffa80`04385b50
fffffa80`044e7750  fffffa80`044e7760 fffff800`02010002

fffffa80`044e7760  fffffa80`043932b8 fffffa80`043932b8
fffffa80`044e7770  fffffa80`0438fbb0 fffffa80`043932b0
fffffa80`044e7780  fffffa80`044e7790 00000000`00010003

fffffa80`044e7790  fffffa80`0ad4deb8 fffffa80`0ad4deb8
fffffa80`044e77a0  fffffa80`0438fbb0 fffffa80`0ad4deb0
fffffa80`044e77b0  fffffa80`044e77c0 00000000`00010004

fffffa80`044e77c0  fffffa80`0ad4ddd8 fffffa80`0ad4ddd8
fffffa80`044e77d0  fffffa80`0438fbb0 fffffa80`0ad4ddd0
fffffa80`044e77e0  fffffa80`044e77f0 00000000`00010005

fffffa80`044e77f0  fffffa80`0ad4dcf8 fffffa80`0ad4dcf8
fffffa80`044e7800  fffffa80`0438fbb0 fffffa80`0ad4dcf0
fffffa80`044e7810  fffffa80`044e7820 00000000`00010006

fffffa80`044e7820  fffffa80`04385368 fffffa80`04385368
fffffa80`044e7830  fffffa80`0438fbb0 fffffa80`04385360
fffffa80`044e7840  fffffa80`044e7850 00000000`00010007

fffffa80`044e7850  fffffa80`04385288 fffffa80`04385288
fffffa80`044e7860  fffffa80`0438fbb0 fffffa80`04385280
fffffa80`044e7870  fffffa80`044e7880 00000000`00000000

fffffa80`044e7880  00000000`00000000 fffffa80`043851a8
fffffa80`044e7890  fffffa80`0438fbb0 fffffa80`043851a0
fffffa80`044e78a0  fffffa80`044e78b0 fffffa60`04010009

fffffa80`044e78b0  fffffa80`04375368 fffffa80`04375368
fffffa80`044e78c0  fffffa80`0438fbb0 fffffa80`04375360
fffffa80`044e78d0  fffffa80`044e78e0 00000000`0001000a

fffffa80`044e78e0  fffffa80`04375288 fffffa80`04375288
fffffa80`044e78f0  fffffa80`0438fbb0 fffffa80`04375280
fffffa80`044e7900  fffffa80`044e7910 00000000`0001000b

fffffa80`044e7910  fffffa80`043751a8 fffffa80`043751a8
fffffa80`044e7920  fffffa80`0438fbb0 fffffa80`043751a0
fffffa80`044e7930  fffffa80`044e7940 00000000`0001000c

fffffa80`044e7940  fffffa80`0ad4eab8 fffffa80`0ad4eab8
fffffa80`044e7950  fffffa80`0438fbb0 fffffa80`0ad4eab0
fffffa80`044e7960  fffffa80`044e7970 00000000`0001000d

fffffa80`044e7970  fffffa80`0ad4e9d8 fffffa80`0ad4e9d8
fffffa80`044e7980  fffffa80`0438fbb0 fffffa80`0ad4e9d0
fffffa80`044e7990  fffffa80`044e79a0 00000000`0001000e

fffffa80`044e79a0  fffffa80`0ad4e8f8 fffffa80`0ad4e8f8
fffffa80`044e79b0  fffffa80`0438fbb0 fffffa80`0ad4e8f0
fffffa80`044e79c0  fffffa80`044e79d0 00000000`0001000f

fffffa80`044e79d0  fffffa80`0a521e18 fffffa80`0a521e18
fffffa80`044e79e0  fffffa80`0438fbb0 fffffa80`0a521e10
fffffa80`044e79f0  fffffa80`044e7a00 00000000`00010010

fffffa80`044e7a00  fffffa80`0438ccd8 fffffa80`0438ccd8
fffffa80`044e7a10  fffffa80`0438fbb0 fffffa80`0438ccd0
fffffa80`044e7a20  fffffa80`044e7a30 00000000`00010011

fffffa80`044e7a30  fffffa80`04389608 fffffa80`04389608
fffffa80`044e7a40  fffffa80`0438fbb0 fffffa80`04389600
fffffa80`044e7a50  fffffa80`044e76d0 fffffa60`04010012

I reformatted the output for readability - it may not appear so, but there is a nice clear pattern here... it looks like a header of 16 bytes...

0: kd> db fffffa80044e76c0 fffffa80044e76c0+f
fffffa80`044e76c0  01 00 3a 02 57 61 69 74-48 65 fa 01 00 f8 ff ff  ..:.WaitHe......

...followed by 13 blocks of 48 bytes, forming a list - the last item pointing back to the first:

0: kd> dq /c6 fffffa80044e76c0+10 fffffa80044e7a60-1
fffffa80`044e76d0  fffffa80`0438e048 fffffa80`0438e048 fffffa80`0438fbb0 fffffa80`0438e040 fffffa80`044e7700 00000000`00010000
fffffa80`044e7700  fffffa80`04366738 fffffa80`04366738 fffffa80`0438fbb0 fffffa80`04366730 fffffa80`044e7730 00000000`00010001
fffffa80`044e7730  fffffa80`04385b58 fffffa80`04385b58 fffffa80`0438fbb0 fffffa80`04385b50 fffffa80`044e7760 fffff800`02010002
fffffa80`044e7760  fffffa80`043932b8 fffffa80`043932b8 fffffa80`0438fbb0 fffffa80`043932b0 fffffa80`044e7790 00000000`00010003
fffffa80`044e7790  fffffa80`0ad4deb8 fffffa80`0ad4deb8 fffffa80`0438fbb0 fffffa80`0ad4deb0 fffffa80`044e77c0 00000000`00010004
fffffa80`044e77c0  fffffa80`0ad4ddd8 fffffa80`0ad4ddd8 fffffa80`0438fbb0 fffffa80`0ad4ddd0 fffffa80`044e77f0 00000000`00010005
fffffa80`044e77f0  fffffa80`0ad4dcf8 fffffa80`0ad4dcf8 fffffa80`0438fbb0 fffffa80`0ad4dcf0 fffffa80`044e7820 00000000`00010006
fffffa80`044e7820  fffffa80`04385368 fffffa80`04385368 fffffa80`0438fbb0 fffffa80`04385360 fffffa80`044e7850 00000000`00010007
fffffa80`044e7850  fffffa80`04385288 fffffa80`04385288 fffffa80`0438fbb0 fffffa80`04385280 fffffa80`044e7880 00000000`00000000
fffffa80`044e7880  00000000`00000000 fffffa80`043851a8 fffffa80`0438fbb0 fffffa80`043851a0 fffffa80`044e78b0 fffffa60`04010009
fffffa80`044e78b0  fffffa80`04375368 fffffa80`04375368 fffffa80`0438fbb0 fffffa80`04375360 fffffa80`044e78e0 00000000`0001000a
fffffa80`044e78e0  fffffa80`04375288 fffffa80`04375288 fffffa80`0438fbb0 fffffa80`04375280 fffffa80`044e7910 00000000`0001000b
fffffa80`044e7910  fffffa80`043751a8 fffffa80`043751a8 fffffa80`0438fbb0 fffffa80`043751a0 fffffa80`044e7940 00000000`0001000c
fffffa80`044e7940  fffffa80`0ad4eab8 fffffa80`0ad4eab8 fffffa80`0438fbb0 fffffa80`0ad4eab0 fffffa80`044e7970 00000000`0001000d
fffffa80`044e7970  fffffa80`0ad4e9d8 fffffa80`0ad4e9d8 fffffa80`0438fbb0 fffffa80`0ad4e9d0 fffffa80`044e79a0 00000000`0001000e
fffffa80`044e79a0  fffffa80`0ad4e8f8 fffffa80`0ad4e8f8 fffffa80`0438fbb0 fffffa80`0ad4e8f0 fffffa80`044e79d0 00000000`0001000f
fffffa80`044e79d0  fffffa80`0a521e18 fffffa80`0a521e18 fffffa80`0438fbb0 fffffa80`0a521e10 fffffa80`044e7a00 00000000`00010010
fffffa80`044e7a00  fffffa80`0438ccd8 fffffa80`0438ccd8 fffffa80`0438fbb0 fffffa80`0438ccd0 fffffa80`044e7a30 00000000`00010011
fffffa80`044e7a30  fffffa80`04389608 fffffa80`04389608 fffffa80`0438fbb0 fffffa80`04389600 fffffa80`044e76d0 fffffa60`04010012

2 quadwords at virtual address fffffa80'044e7878 are zeroed - this is the root of the bugcheck, the memory corruption.

Looking at the surrounding data, we can guess what should have been here (take a look at the far right column to spot the pattern):

00000000`00010008 fffffa80`043851a8

So, this leads us to the conclusion I posted at the top - "something" corrupted this 16-byte block of data by filling it with 0's, and when the data structure was accessed it caused the bugcheck, and what we see in the stack trace is the victim of the corruption.

As to how to nail it down to a particular driver that is causing the corruption, I can only suggest to start with the basics:

- is there something in common with the scenario of each bugcheck?

- remove VMWare (it has plenty of kernel drivers on the host)

- check for an update for the Broadcom NIC driver, it is dated Feb 2007

- remove unnecessary kernel drivers (I see wireless, Connexant modem, touchpad, Dritek keyboard drivers)

**nitroshift** · May 26, 2008

Back to what cluberti said earlier in post #9... Your dump is still missing a lot of information

Sign In

BSOD: irql_not_less_or_equal

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Create an account or sign in to comment

Create an account

Sign in

Recently Browsing 0 members