BSOD: irql_not_less_or_equal

**Snegithan** · May 26, 2008

Hi Guys,

I just notice the following information from my event log, does this one got something to do with the BSOD?

Intel RAID Controller: Unknown Controller

Number of Serial ATA ports: 3

RAID Option ROM Version: Unknown

Driver Version: 7.0.0.1020

RAID Plug-In Version: 7.0.0.1020

Language Resource Version of the RAID Plug-In: File not found

Create Volume Wizard Version: 7.0.0.1020

Language Resource Version of the Create Volume Wizard: File not found

Create Volume from Existing Hard Drive Wizard Version: 7.0.0.1020

Language Resource Version of the Create Volume from Existing Hard Drive Wizard: File not found

Modify Volume Wizard Version: 7.0.0.1020

Language Resource Version of the Modify Volume Wizard: File not found

Delete Volume Wizard Version: 7.0.0.1020

Language Resource Version of the Delete Volume Wizard: File not found

ISDI Library Version: 7.0.0.1020

Event Monitor User Notification Tool Version: 7.0.0.1020

Language Resource Version of the Event Monitor User Notification Tool: File not found

Event Monitor Version: 7.0.0.1020

Hard Drive 0

Usage: Unknown hard drive usage

Status: Normal

Device Port: 0

Device Port Location: Internal

Current Serial ATA Transfer Mode: Generation 1

Model: WDC WD2500BEVS-22UST0

Serial Number: WD-WXEZ07W90248

Firmware: 01.01A01

Native Command Queuing Support: Yes

System Hard Drive: Yes

Size: 232.8 GB

Unused Port 0

Device Port: 1

Device Port Location: Internal

Unused Port 1

Device Port: 2

Device Port Location: Internal

**Snegithan** · May 26, 2008

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

nitroshift, i really don’t have any clue what else to change in the configuration i already set the page file size as per cluberti earlier post.

**cluberti** · May 27, 2008

Back to what cluberti said earlier in post #9... Your dump is still missing a lot of information
nitroshift, i really don’t have any clue what else to change in the configuration i already set the page file size as per cluberti earlier post.

There's probably not anything you can do to fix that, unfortunately, but we do know that we fail when using functions in win32k.sys, we've zeroed out a nonpaged pool region, and we crash when attempting to use that region. Since the memory manager itself doesn't zero out pool blocks (it only modifies the flink and blink on alloc/dealloc and coalescing), we know a driver did this. You could enable special pool and driver verifier, but that will increase pool usage in kernel (strongly suggest you uninstall any antivirus and non-Microsoft firewall software during this test to reduce the load on nonpaged pool during the test).

You could also try to make sure all drivers (especially the nvidia driver for your video card) is up-to-date, and also make sure your Vista box is fully patched (including SP1), just to be safe.

**Snegithan** · May 31, 2008

Hey all,

i got one more bsod today "Multiple_IRP_Complete_Request". Does this one related to the earlier case?

i have uploaded the minidump and memory dump. Assist me to check the files thx

http://www.mediafire.com/?jmnxtzsmtmp (minidump)

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

Thanks guys!

**Mr Snrub** · May 31, 2008

You're still looking at memory corruption I think.

STOP 0x44 is typically caused by bad drivers.

You still have VMWare installed.

MULTIPLE_IRP_COMPLETE_REQUESTS (44)
A driver has requested that an IRP be completed (IoCompleteRequest()), but the packet has already been completed.
This is a tough bug to find because the easiest case, a driver actually attempted to complete its own packet twice, is generally not what happened.
Rather, two separate drivers each believe that they own the packet, and each attempts to complete it.
The first actually works, and the second fails.
Tracking down which drivers in the system actually did this is difficult, generally because the trails of the first driver have been covered by the second.
However, the driver stack for the current request can be found by examining the DeviceObject fields in each of the stack locations.

Arguments:
Arg1: fffffa800b9d2810, Address of the IRP
Arg2: 0000000000001d00
Arg3: 0000000000000000
Arg4: 0000000000000000

1: kd> k 50
Child-SP		  RetAddr		   Call Site
fffffa60`0cf99f38 fffff800`01e6193e nt!KeBugCheckEx
fffffa60`0cf99f40 fffffa60`00b3f0c4 nt! ?? ::FNODOBFM::`string'+0x2185b
fffffa60`0cf99f80 fffffa60`00b5a644 fltmgr!FltpFreeIrpCtrl+0x174
fffffa60`0cf99fb0 fffffa60`071e87af fltmgr!FltQueryDirectoryFile+0xb4
fffffa60`0cf99ff0 fffffa60`00b5bb92 luafv!LuafvNormalizeNameComponentEx+0x13f
fffffa60`0cf9a0f0 fffffa60`00b5b711 fltmgr!FltpCallNormalizeNameComponentHandler+0x82
fffffa60`0cf9a150 fffffa60`00b5b587 fltmgr!FltpExpandShortNames+0x151
fffffa60`0cf9a1b0 fffffa60`00b5b3c9 fltmgr!FltpGetNormalizedFileNameWorker+0xb7
fffffa60`0cf9a1e0 fffffa60`00b5ba5f fltmgr!FltpGetNormalizedFileName+0x59
fffffa60`0cf9a220 fffffa60`00b4a0e9 fltmgr!FltpCreateFileNameInformation+0xaf
fffffa60`0cf9a250 fffffa60`00b432fb fltmgr!HandleStreamListNotSupported+0x159
fffffa60`0cf9a290 fffffa60`00b4b094 fltmgr! ?? ::FNODOBFM::`string'+0x2a87
fffffa60`0cf9a330 fffffa60`0452ee1f fltmgr!FltGetFileNameInformation+0x174
fffffa60`0cf9a3c0 fffffa60`0452ef00 klif+0x17e1f
fffffa60`0cf9a420 fffffa60`045460d6 klif+0x17f00
fffffa60`0cf9a4b0 fffffa60`00b3e05a klif+0x2f0d6
fffffa60`0cf9a540 fffffa60`00b3d32c fltmgr!FltpPerformPreCallbacks+0x28a
fffffa60`0cf9a620 fffffa60`00b59256 fltmgr!FltpPassThroughInternal+0x3c
fffffa60`0cf9a650 fffff800`02138cc3 fltmgr!FltpCreate+0x247
fffffa60`0cf9a700 fffff800`02132999 nt!IopParseDevice+0x5e3
fffffa60`0cf9a8a0 fffff800`02136884 nt!ObpLookupObjectName+0x5eb
fffffa60`0cf9a9b0 fffff800`02142e30 nt!ObOpenObjectByName+0x2f4
fffffa60`0cf9aa80 fffff800`02143968 nt!IopCreateFile+0x290
fffffa60`0cf9ab20 fffff800`01eb0e33 nt!NtCreateFile+0x78
fffffa60`0cf9abb0 00000000`779b5fca nt!KiSystemServiceCopyEnd+0x13
00000000`04c5e778 00000000`00000000 0x779b5fca

IRP = I/O Request Packet.

First hint of memory corruption - we were handling an IRP, but the debugger doesn't believe that looks like one:

1: kd> !irp fffffa80`0b9d2810
IRP signature does not match, probably not an IRP

What about the pool description of that "IRP"...

1: kd> !pool fffffa80`0b9d2810 
Pool page fffffa800b9d2810 region is Unknown
 fffffa800b9d2000 size:  4b0 previous size:	0  (Allocated)  Thre (Protected)
 fffffa800b9d24b0 size:   20 previous size:  4b0  (Free)	   ....
 fffffa800b9d24d0 size:   80 previous size:   20  (Allocated)  Ntfr
 fffffa800b9d2550 size:   80 previous size:   80  (Allocated)  Ntfr
 fffffa800b9d25d0 size:  130 previous size:   80  (Allocated)  File (Protected)
 fffffa800b9d2700 size:   10 previous size:  130  (Free)	   FMng
 fffffa800b9d2710 size:   f0 previous size:   10  (Allocated)  MmCa
*fffffa800b9d2800 size:  400 previous size:   f0  (Free ) *Irp 
		Pooltag Irp  : Io, IRP packets
 fffffa800b9d2c00 size:   70 previous size:  400  (Allocated)  Vad 
 fffffa800b9d2c70 size:   10 previous size:   70  (Free)	   SeTd
 fffffa800b9d2c80 size:   70 previous size:   10  (Allocated)  Vad 
 fffffa800b9d2cf0 size:  1e0 previous size:   70  (Allocated)  ALPC (Protected)
 fffffa800b9d2ed0 size:  130 previous size:  1e0  (Allocated)  Irp  Process: fffffa8006b98040

So it was tagged as an IRP, is now marked as free, but the pool allocation does not make the debugger believe it has the structure of an IRP...

There is another IRP in the pool which hasn't completed yet, and the debugger says belongs to process fffffa8006b98040 so let's have a look at the memory contents of the good one...

1: kd> dq fffffa800b9d2ed0 fffffa800b9d2ed0+130-1
fffffa80`0b9d2ed0  20707249`0a13001e fffffa80`06b98040
fffffa80`0b9d2ee0  00000000`01180006 00000000`00000000
fffffa80`0b9d2ef0  00000000`00062900 00000000`00000000
fffffa80`0b9d2f00  fffffa80`06beca40 fffffa80`06beca40
fffffa80`0b9d2f10  00000000`00000000 00000000`00000000
fffffa80`0b9d2f20  01000000`01010001 00000000`02f03db0
fffffa80`0b9d2f30  00000000`00000000 fffffa80`06b98042
fffffa80`0b9d2f40  00000000`02f03db0 fffffa60`0457e008
fffffa80`0b9d2f50  00000000`003ad370 00000000`00000000
fffffa80`0b9d2f60  00000000`00000000 fffff880`07643e60
fffffa80`0b9d2f70  fffffa80`0b3896b0 fffffa80`0b9c4060
fffffa80`0b9d2f80  00000000`00000000 00000000`00000000
fffffa80`0b9d2f90  00000000`00000000 fffffa80`0b9d2fb0
fffffa80`0b9d2fa0  fffffa80`06bec980 00000000`00000000
fffffa80`0b9d2fb0  00000000`01000003 00000000`00000400
fffffa80`0b9d2fc0  00000000`00000000 00000000`00000000
fffffa80`0b9d2fd0  00000000`00000000 fffffa80`081bddf0
fffffa80`0b9d2fe0  fffffa80`06bec980 00000000`00000000
fffffa80`0b9d2ff0  00000000`00000000 00000000`00000000

We can see that the !irp command should work for an IRP object:

1: kd> !irp fffffa800b9d2ed0+10
Irp is active with 1 stacks 1 is current (= 0xfffffa800b9d2fb0)
 No Mdl: No System Buffer: Thread fffffa800b9c4060:  Irp stack trace.  
	 cmd  flg cl Device   File	 Completion-Context
>[  3, 0]   0  1 fffffa80081bddf0 fffffa8006bec980 00000000-00000000	pending
		   \FileSystem\Npfs
			Args: 00000400 00000000 00000000 00000000

(We add +10 because the header of the pool allocation is 16 (0x10) bytes - previous allocation size, current allocation size and owning PID - the real IRP data structure starts immediately after the header.)

The owning process ID is the second quadword in the pool structure, which we can verify by checking the pool allocation:

1: kd> !pool fffffa80`06b98040
Pool page fffffa8006b98040 region is Nonpaged pool
*fffffa8006b98000 size:  430 previous size:	0  (Allocated) *Proc (Protected)
		Pooltag Proc : Process objects, Binary : nt!ps

So to check what process does our bad IRP belong to, we need to look at the second quadword from address fffffa800b9d2800:

1: kd> dq fffffa800b9d2800+8 fffffa800b9d2800+f
fffffa80`0b9d2808  fffffa80`06bea600

Checking the pool allocation of this alleged process to ensure it is what we think:

1: kd> !pool fffffa80`06bea600
Pool page fffffa8006bea600 region is Nonpaged pool
...
*fffffa8006bea5c0 size:  430 previous size:   40  (Allocated) *Proc (Protected)
		Pooltag Proc : Process objects, Binary : nt!ps

Looks good so far - so what process is this?

1: kd> !process fffffa80`06bea600 1
PROCESS fffffa8006bea600
	SessionId: 0  Cid: 04fc	Peb: 7efdf000  ParentCid: 0290
	DirBase: 1284f4000  ObjectTable: fffff88007825170  HandleCount: 588.
	Image: avp.exe
	VadRoot fffffa8006bfa560 Vads 554 Clone 0 Private 12762. Modified 1092. Locked 0.
	DeviceMap fffff88000007310
	Token							 fffff88007965520
	ElapsedTime					   00:01:03.553
	UserTime						  00:00:00.764
	KernelTime						00:00:00.655
	QuotaPoolUsage[PagedPool]		 145776
	QuotaPoolUsage[NonPagedPool]	  438928
	Working Set Sizes (now,min,max)  (16420, 50, 345) (65680KB, 200KB, 1380KB)
	PeakWorkingSetSize				16516
	VirtualSize					   191 Mb
	PeakVirtualSize				   194 Mb
	PageFaultCount					22900
	MemoryPriority					BACKGROUND
	BasePriority					  8
	CommitCharge					  13216

So, avp.exe owns an IRP which it wants to complete, but upon checking the packet the system believes it has already been completed and BOOM - bugcheck (by design).

The IRP structure is in pool memory, starting at fffffa800b9d2800 for 0x400 bytes, unfortunately we can't get any clues as to what specific area of the allocation is corrupted like before, just 'something' in this range has been blitzed by 'something':

1: kd> dq /c4 fffffa800b9d2800 fffffa800b9d2c00-1
fffffa80`0b9d2800  20707249`0440000f fffffa80`06bea600 fffffa80`04286c10 00000000`00000000
fffffa80`0b9d2820  00000000`00060000 00000000`00000000 fffffa80`0b9d2830 fffffa80`0b9d2830
fffffa80`0b9d2840  00000000`00000000 00000000`0000001c 00000000`0d0b0000 00000000`00000000
fffffa80`0b9d2860  00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000
fffffa80`0b9d2880  fffff880`08f01a10 00000000`00580012 fffffa80`04289060 fffffa80`042890a8
fffffa80`0b9d28a0  fffffa80`042890a8 fffff800`01ed94f0 fffff800`021fd700 00000000`00000000
fffffa80`0b9d28c0  00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000
fffffa80`0b9d28e0  00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000
fffffa80`0b9d2900  00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000
fffffa80`0b9d2920  00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000
fffffa80`0b9d2940  00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000
fffffa80`0b9d2960  00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000
fffffa80`0b9d2980  00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000
fffffa80`0b9d29a0  00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000
fffffa80`0b9d29c0  00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000
fffffa80`0b9d29e0  00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000
fffffa80`0b9d2a00  00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000
fffffa80`0b9d2a20  00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000
fffffa80`0b9d2a40  00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000
fffffa80`0b9d2a60  00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000
fffffa80`0b9d2a80  00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000
fffffa80`0b9d2aa0  00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000
fffffa80`0b9d2ac0  00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000
fffffa80`0b9d2ae0  00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000
fffffa80`0b9d2b00  00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000
fffffa80`0b9d2b20  00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000
fffffa80`0b9d2b40  00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000
fffffa80`0b9d2b60  00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000
fffffa80`0b9d2b80  00000000`00000000 00000000`00000000 fffffa80`04d5c030 00000000`00000000
fffffa80`0b9d2ba0  fffffa60`00b3f0f0 fffffa80`04d3f010 00000000`0000000c 00000000`00000000
fffffa80`0b9d2bc0  00000000`00000000 00000000`00000000 00000000`00000000 fffffa80`0688d900
fffffa80`0b9d2be0  00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000

Another apparent case of random memory locations being zeroed?

I think avp.exe is Kaspersky AV, which has yet more kernel filter drivers that could be the root, or may be having a conflict with something like VMWare's filter driver.

If it was dodgy RAM, I would expect very random memory corruption, leading to application crashes as much as bugchecks, all random.

I would still say test uninstalling VMWare and run for a period of time to observe stability.

"Not using VMWare" is not enough btw - the kernel filter drivers are still loaded and will be involved in I/O.

**Snegithan** · May 31, 2008

Hello Mr Snrub,

Thanks for the quick reply

So i should uninstall VMware only? or both Kaspersky and VMware?

**Mr Snrub** · May 31, 2008

One at a time, or you won't know which solved the problem, if it goes away.

**Snegithan** · June 15, 2008

Hi Mr Snrub,

I was using an older version of VMware WorkStation 6 and I found a newer version of the software on the VMware site which is certified for Windows Vista SP1. After the VMware workstation upgrade I didn't get any BSOD. I have tested it for past 2 weeks and it seems everything work perfectly.

Thanks for the help Guys! All the replies were very helpful to solve my problem

Sign In

BSOD: irql_not_less_or_equal

Recommended Posts

Snegithan

Link to comment

Share on other sites

Snegithan

Link to comment

Share on other sites

cluberti

Link to comment

Share on other sites

Snegithan

Link to comment

Share on other sites

Mr Snrub

Link to comment

Share on other sites

Snegithan

Link to comment

Share on other sites

Mr Snrub

Link to comment

Share on other sites

Snegithan

Link to comment

Share on other sites

Create an account or sign in to comment

Create an account

Sign in

Recently Browsing 0 members

Activity

Browse