IRQL = 1b

NTFSD
2

Ken,

0x1B is IRQL SYNCH_LEVEL on the x86 - this just means that the dispatcher
database lock is held (which makes sense in KeWaitForSingleObject.) My
guess is that the dispatcher object passed in here is invalid or has been
damaged in some way.

Regards,

Tony

Tony Mason

Consulting Partner

OSR Open Systems Resources, Inc.

http://www.osr.com http:

-----Original Message-----
From: Ken Galipeau [mailto:xxxxx@legato.com]
Sent: Wednesday, February 05, 2003 1:09 PM
To: File Systems Developers
Subject: [ntfsd] IRQL = 1b

I got a verify bug while referencing an event. Seems the IRQL is 0x1B!

Prior to the WaitForSingleObject was a:
ExQueueWorkItem(&pCreatePacket->WorkQueueItem, CriticalWorkQueue);

That work queue item calls “IoCreateDevice”.

This code was inside a FSControl resulting from a Mount Volume Request.

I was running iostress on the 2 cpu system, running Server 2003 build 3718
(.Net).

That stack trace is below.

Any ideas how this could happen?

Thanks,

Ken

0: kd> !analyze -v

************************************************************************



Bugcheck Analysis

*

*************************************************************************

IRQL_NOT_LESS_OR_EQUAL (a)

An attempt was made to access a pagable (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: 83ddadc8, memory referenced

Arg2: 0000001b, IRQL

Arg3: 00000000, value 0 = read operation, 1 = write operation

Arg4: 804eb7b8, address which referenced memory

Debugging Details:

------------------

READ_ADDRESS: 83ddadc8 Special pool

CURRENT_IRQL: 1b

FAULTING_IP:

nt!KeWaitForSingleObject+db

804eb7b8 803b02 cmp byte ptr [ebx],0x2

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xA

LAST_CONTROL_TRANSFER: from 80540128 to 804e338c

STACK_TEXT:

f82c832c 80540128 00000003 83ddadc8 00000000
nt!RtlpBreakWithStatusInstruction

f82c8378 80540cd4 00000003 83ddadc8 804eb7b8 nt!KiBugCheckDebugBreak+0x19

f82c86e0 80541150 0000000a 83ddadc8 0000001b nt!KeBugCheck2+0x4a8

f82c8700 804e2b74 0000000a 83ddadc8 0000001b nt!KeBugCheckEx+0x19

f82c8700 804eb7b8 0000000a 83ddadc8 0000001b nt!KiTrap0E+0x224

f82c87bc 8067f36d 83ddadc8 00000006 00000000 nt!KeWaitForSingleObject+0xdb

f82c87e4 f81e4e0e 83ddadc8 00000006 00000000
nt!VerifierKeWaitForSingleObject+0x45

f82c881c f81e6cde 82cce2e8 f82c8848 f82c883c Driver!MakeNewDevice+0x17e
[c:\dev\src\kernel\devices.c @ 512]

f82c8858 f81e78e0 82cce2e8 00000045 00000000 Driver!MakeNewDeviceForId+0xee
[c:\dev\src\kernel\devices.c @ 1135]

f82c88dc f81e95ba 8116b248 fa059540 814415b0
Driver!ReattachDriveDevices+0x5a0 [c:\dev\src\kernel\devices.c @ 1431]

f82c8948 f81fd1a2 8116b248 8352ee48 80713e30 Driver!FileSystemControl+0x29a
[c:\dev\src\kernel\fsctrl.c @ 388]

f82c89a8 8067e4aa 8116b248 8352ee48 8352ee48 Driver!IrpDispatch+0x472
[c:\dev\src\kernel\passthru.c @ 382]

f82c89d8 80528caa 805b2cab 805b2cab 814415b0 nt!IovCallDriver+0x110

f82c89dc 805b2cab 805b2cab 814415b0 80714420 nt!IofCallDriver+0xe

f82c8a38 805161c9 8116b248 fa178200 00000000 nt!IopMountVolume+0x1d3

f82c8a64 8057ac1d fa178218 81441500 f82c8bb0 nt!IopCheckVpbMounted+0x5a

f82c8b6c 80577669 814415b0 00000000 81236440 nt!IopParseDevice+0x3f0

f82c8be8 80577956 00000000 f82c8c28 00000042 nt!ObpLookupObjectName+0x544

f82c8c3c 8057b1b2 00000000 00000000 00000101 nt!ObOpenObjectByName+0xe8

f82c8cb8 8057b349 0006f6cc 00100020 0006f660 nt!IopCreateFile+0x413

f82c8d04 805883a2 0006f6cc 00100020 0006f660 nt!IoCreateFile+0x3d

f82c8d44 804dfc4d 0006f6cc 00100020 0006f660 nt!NtOpenFile+0x25

f82c8d44 7ffe0304 0006f6cc 00100020 0006f660 nt!KiSystemService+0xd0

0006f630 77f50c7a 77f8172d 0006f6cc 00100020
SharedUserData!SystemCallStub+0x4

WARNING: Stack unwind information not available. Following frames may be
wrong.

0006f6ec 77f550e3 00020024 0006f868 00020024 ntdll+0x10c7a

0006f71c 77f542ab 00020024 00000080 0006f984 ntdll+0x150e3

0006f7bc 77f5b734 0006f998 00000080 0006f87c ntdll+0x142ab

0006f820 77f5ca1f 0006f998 0006f958 0006f984 ntdll+0x1b734

0006f860 77f5c7d9 00000005 0006f984 00000001 ntdll+0x1ca1f

0006f94c 000133b8 00000000 00800000 0006f87c ntdll+0x1c7d9

00000001 00000000 00000000 00000000 00000000 0x133b8

FOLLOWUP_IP:

Driver!MakeNewDevice+17e

f81e4e0e 8945ec mov [ebp-0x14],eax

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: Driver!MakeNewDevice+17e

MODULE_NAME: Driver

IMAGE_NAME: Driver.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 3e3eb2d1

STACK_COMMAND: kb

BUCKET_ID: 0xA_Driver!MakeNewDevice+17e

Followup: MachineOwner

---------

—
You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com</http:>

3

Tony,
Your right! If I do a !poolval on the address I get:
0: kd> !poolval 83ddadc8
Pool page 83ddadc8 region is Special pool

Validating Pool headers for pool page: 83ddadc8

Pool page [83dda000] is INVALID.

Analyzing linked list…
[83dda000]: invalid previous size [0x44] should be [0x0]
[83dda000 –> 83dda010 (size = 0x10 bytes)]: Corrupt region

Scanning for single bit errors…

None found

The Kevent looks like this:
0: kd> dd 83ddadc8
83ddadc8 db04db00 00000000 83ddadd0 83ddadd0
83ddadd8 810f9d88 02080028 83ddadf4 00000000
83ddade8 00000878 00000008

So not only is the Kevent messed up but the pool block it is in.

I had just done this:

KeInitializeEvent(&pCreatePacket->Event, NotificationEvent, FALSE);
ExInitializeWorkItem(&pCreatePacket->WorkQueueItem, CreateNewDevice,
pCreatePacket);
ExQueueWorkItem(&pCreatePacket->WorkQueueItem, CriticalWorkQueue);
status = KeWaitForSingleObject(&pCreatePacket->Event, UserRequest,

(KPROCESSOR_MODE)KernelMode, FALSE, NULL);

The work item does an IoCreateDevice and then sets the event.

Any idea what could cause this kind of corruption?

Thanks,
Ken

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tony Mason
Sent: Wednesday, February 05, 2003 7:10 PM
To: File Systems Developers
Subject: [ntfsd] RE: IRQL = 1b

Ken,

0x1B is IRQL SYNCH_LEVEL on the x86 - this just means that the dispatcher
database lock is held (which makes sense in KeWaitForSingleObject.) My
guess is that the dispatcher object passed in here is invalid or has been
damaged in some way.

Regards,

Tony

Tony Mason

Consulting Partner

OSR Open Systems Resources, Inc.

http://www.osr.com http:

-----Original Message-----
From: Ken Galipeau [mailto:xxxxx@legato.com]
Sent: Wednesday, February 05, 2003 1:09 PM
To: File Systems Developers
Subject: [ntfsd] IRQL = 1b

I got a verify bug while referencing an event. Seems the IRQL is 0x1B!

Prior to the WaitForSingleObject was a:
ExQueueWorkItem(&pCreatePacket->WorkQueueItem, CriticalWorkQueue);

That work queue item calls “IoCreateDevice”.

This code was inside a FSControl resulting from a Mount Volume Request.

I was running iostress on the 2 cpu system, running Server 2003 build 3718
(.Net).

That stack trace is below.

Any ideas how this could happen?

Thanks,

Ken

0: kd> !analyze -v

************************************************************************



Bugcheck Analysis

*

*************************************************************************

IRQL_NOT_LESS_OR_EQUAL (a)

An attempt was made to access a pagable (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: 83ddadc8, memory referenced

Arg2: 0000001b, IRQL

Arg3: 00000000, value 0 = read operation, 1 = write operation

Arg4: 804eb7b8, address which referenced memory

Debugging Details:

------------------

READ_ADDRESS: 83ddadc8 Special pool

CURRENT_IRQL: 1b

FAULTING_IP:

nt!KeWaitForSingleObject+db

804eb7b8 803b02 cmp byte ptr [ebx],0x2

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xA

LAST_CONTROL_TRANSFER: from 80540128 to 804e338c

STACK_TEXT:

f82c832c 80540128 00000003 83ddadc8 00000000
nt!RtlpBreakWithStatusInstruction

f82c8378 80540cd4 00000003 83ddadc8 804eb7b8 nt!KiBugCheckDebugBreak+0x19

f82c86e0 80541150 0000000a 83ddadc8 0000001b nt!KeBugCheck2+0x4a8

f82c8700 804e2b74 0000000a 83ddadc8 0000001b nt!KeBugCheckEx+0x19

f82c8700 804eb7b8 0000000a 83ddadc8 0000001b nt!KiTrap0E+0x224

f82c87bc 8067f36d 83ddadc8 00000006 00000000 nt!KeWaitForSingleObject+0xdb

f82c87e4 f81e4e0e 83ddadc8 00000006 00000000
nt!VerifierKeWaitForSingleObject+0x45

f82c881c f81e6cde 82cce2e8 f82c8848 f82c883c Driver!MakeNewDevice+0x17e
[c:\dev\src\kernel\devices.c @ 512]

f82c8858 f81e78e0 82cce2e8 00000045 00000000 Driver!MakeNewDeviceForId+0xee
[c:\dev\src\kernel\devices.c @ 1135]

f82c88dc f81e95ba 8116b248 fa059540 814415b0
Driver!ReattachDriveDevices+0x5a0 [c:\dev\src\kernel\devices.c @ 1431]

f82c8948 f81fd1a2 8116b248 8352ee48 80713e30 Driver!FileSystemControl+0x29a
[c:\dev\src\kernel\fsctrl.c @ 388]

f82c89a8 8067e4aa 8116b248 8352ee48 8352ee48 Driver!IrpDispatch+0x472
[c:\dev\src\kernel\passthru.c @ 382]

f82c89d8 80528caa 805b2cab 805b2cab 814415b0 nt!IovCallDriver+0x110

f82c89dc 805b2cab 805b2cab 814415b0 80714420 nt!IofCallDriver+0xe

f82c8a38 805161c9 8116b248 fa178200 00000000 nt!IopMountVolume+0x1d3

f82c8a64 8057ac1d fa178218 81441500 f82c8bb0 nt!IopCheckVpbMounted+0x5a

f82c8b6c 80577669 814415b0 00000000 81236440 nt!IopParseDevice+0x3f0

f82c8be8 80577956 00000000 f82c8c28 00000042 nt!ObpLookupObjectName+0x544

f82c8c3c 8057b1b2 00000000 00000000 00000101 nt!ObOpenObjectByName+0xe8

f82c8cb8 8057b349 0006f6cc 00100020 0006f660 nt!IopCreateFile+0x413

f82c8d04 805883a2 0006f6cc 00100020 0006f660 nt!IoCreateFile+0x3d

f82c8d44 804dfc4d 0006f6cc 00100020 0006f660 nt!NtOpenFile+0x25

f82c8d44 7ffe0304 0006f6cc 00100020 0006f660 nt!KiSystemService+0xd0

0006f630 77f50c7a 77f8172d 0006f6cc 00100020
SharedUserData!SystemCallStub+0x4

WARNING: Stack unwind information not available. Following frames may be
wrong.

0006f6ec 77f550e3 00020024 0006f868 00020024 ntdll+0x10c7a

0006f71c 77f542ab 00020024 00000080 0006f984 ntdll+0x150e3

0006f7bc 77f5b734 0006f998 00000080 0006f87c ntdll+0x142ab

0006f820 77f5ca1f 0006f998 0006f958 0006f984 ntdll+0x1b734

0006f860 77f5c7d9 00000005 0006f984 00000001 ntdll+0x1ca1f

0006f94c 000133b8 00000000 00800000 0006f87c ntdll+0x1c7d9

00000001 00000000 00000000 00000000 00000000 0x133b8

FOLLOWUP_IP:

Driver!MakeNewDevice+17e

f81e4e0e 8945ec mov [ebp-0x14],eax

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: Driver!MakeNewDevice+17e

MODULE_NAME: Driver

IMAGE_NAME: Driver.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 3e3eb2d1

STACK_COMMAND: kb

BUCKET_ID: 0xA_Driver!MakeNewDevice+17e

Followup: MachineOwner

---------

—
You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

—
You are currently subscribed to ntfsd as: xxxxx@legato.com
To unsubscribe send a blank email to xxxxx@lists.osr.com</http:>

4

Ken,

Sounds like something is trashing the beginning of the pool block - and I
see you are using special pool, so finding the guilty culprit is not going
to be a simple exercise (otherwise you’d have caught it already.)

Check to make sure your data structure is defined properly (I can’t see that
in the code snippet and I don’t really expect that is the problem, but
there’s not much I can see at this stage.)

One thing to do that might help is to enable buffer underrun checking in
your special pool settings (use gflags.exe to change it from “Verify End” to
“Verify Start”) because that should catch how/if the block is being
modified.

Sorry I can’t give more insight.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

-----Original Message-----
From: Ken Galipeau [mailto:xxxxx@legato.com]
Sent: Thursday, February 06, 2003 10:57 PM
To: File Systems Developers
Subject: [ntfsd] RE: IRQL = 1b

Tony,
Your right! If I do a !poolval on the address I get:
0: kd> !poolval 83ddadc8
Pool page 83ddadc8 region is Special pool

Validating Pool headers for pool page: 83ddadc8

Pool page [83dda000] is INVALID.

Analyzing linked list…
[83dda000]: invalid previous size [0x44] should be [0x0]
[83dda000 –> 83dda010 (size = 0x10 bytes)]: Corrupt region

Scanning for single bit errors…

None found

The Kevent looks like this:
0: kd> dd 83ddadc8
83ddadc8 db04db00 00000000 83ddadd0 83ddadd0
83ddadd8 810f9d88 02080028 83ddadf4 00000000
83ddade8 00000878 00000008

So not only is the Kevent messed up but the pool block it is in.

I had just done this:

KeInitializeEvent(&pCreatePacket->Event, NotificationEvent, FALSE);
ExInitializeWorkItem(&pCreatePacket->WorkQueueItem, CreateNewDevice,
pCreatePacket);
ExQueueWorkItem(&pCreatePacket->WorkQueueItem, CriticalWorkQueue);
status = KeWaitForSingleObject(&pCreatePacket->Event, UserRequest,

(KPROCESSOR_MODE)KernelMode, FALSE, NULL);

The work item does an IoCreateDevice and then sets the event.

Any idea what could cause this kind of corruption?

Thanks,
Ken

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tony Mason
Sent: Wednesday, February 05, 2003 7:10 PM
To: File Systems Developers
Subject: [ntfsd] RE: IRQL = 1b

Ken,

0x1B is IRQL SYNCH_LEVEL on the x86 - this just means that the dispatcher
database lock is held (which makes sense in KeWaitForSingleObject.) My
guess is that the dispatcher object passed in here is invalid or has been
damaged in some way.

Regards,

Tony

Tony Mason

Consulting Partner

OSR Open Systems Resources, Inc.

http://www.osr.com http:

-----Original Message-----
From: Ken Galipeau [mailto:xxxxx@legato.com]
Sent: Wednesday, February 05, 2003 1:09 PM
To: File Systems Developers
Subject: [ntfsd] IRQL = 1b

I got a verify bug while referencing an event. Seems the IRQL is 0x1B!

Prior to the WaitForSingleObject was a:
ExQueueWorkItem(&pCreatePacket->WorkQueueItem, CriticalWorkQueue);

That work queue item calls “IoCreateDevice”.

This code was inside a FSControl resulting from a Mount Volume Request.

I was running iostress on the 2 cpu system, running Server 2003 build 3718
(.Net).

That stack trace is below.

Any ideas how this could happen?

Thanks,

Ken

0: kd> !analyze -v

************************************************************************



Bugcheck Analysis

*

*************************************************************************

IRQL_NOT_LESS_OR_EQUAL (a)

An attempt was made to access a pagable (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: 83ddadc8, memory referenced

Arg2: 0000001b, IRQL

Arg3: 00000000, value 0 = read operation, 1 = write operation

Arg4: 804eb7b8, address which referenced memory

Debugging Details:

------------------

READ_ADDRESS: 83ddadc8 Special pool

CURRENT_IRQL: 1b

FAULTING_IP:

nt!KeWaitForSingleObject+db

804eb7b8 803b02 cmp byte ptr [ebx],0x2

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xA

LAST_CONTROL_TRANSFER: from 80540128 to 804e338c

STACK_TEXT:

f82c832c 80540128 00000003 83ddadc8 00000000
nt!RtlpBreakWithStatusInstruction

f82c8378 80540cd4 00000003 83ddadc8 804eb7b8 nt!KiBugCheckDebugBreak+0x19

f82c86e0 80541150 0000000a 83ddadc8 0000001b nt!KeBugCheck2+0x4a8

f82c8700 804e2b74 0000000a 83ddadc8 0000001b nt!KeBugCheckEx+0x19

f82c8700 804eb7b8 0000000a 83ddadc8 0000001b nt!KiTrap0E+0x224

f82c87bc 8067f36d 83ddadc8 00000006 00000000 nt!KeWaitForSingleObject+0xdb

f82c87e4 f81e4e0e 83ddadc8 00000006 00000000
nt!VerifierKeWaitForSingleObject+0x45

f82c881c f81e6cde 82cce2e8 f82c8848 f82c883c Driver!MakeNewDevice+0x17e
[c:\dev\src\kernel\devices.c @ 512]

f82c8858 f81e78e0 82cce2e8 00000045 00000000 Driver!MakeNewDeviceForId+0xee
[c:\dev\src\kernel\devices.c @ 1135]

f82c88dc f81e95ba 8116b248 fa059540 814415b0
Driver!ReattachDriveDevices+0x5a0 [c:\dev\src\kernel\devices.c @ 1431]

f82c8948 f81fd1a2 8116b248 8352ee48 80713e30 Driver!FileSystemControl+0x29a
[c:\dev\src\kernel\fsctrl.c @ 388]

f82c89a8 8067e4aa 8116b248 8352ee48 8352ee48 Driver!IrpDispatch+0x472
[c:\dev\src\kernel\passthru.c @ 382]

f82c89d8 80528caa 805b2cab 805b2cab 814415b0 nt!IovCallDriver+0x110

f82c89dc 805b2cab 805b2cab 814415b0 80714420 nt!IofCallDriver+0xe

f82c8a38 805161c9 8116b248 fa178200 00000000 nt!IopMountVolume+0x1d3

f82c8a64 8057ac1d fa178218 81441500 f82c8bb0 nt!IopCheckVpbMounted+0x5a

f82c8b6c 80577669 814415b0 00000000 81236440 nt!IopParseDevice+0x3f0

f82c8be8 80577956 00000000 f82c8c28 00000042 nt!ObpLookupObjectName+0x544

f82c8c3c 8057b1b2 00000000 00000000 00000101 nt!ObOpenObjectByName+0xe8

f82c8cb8 8057b349 0006f6cc 00100020 0006f660 nt!IopCreateFile+0x413

f82c8d04 805883a2 0006f6cc 00100020 0006f660 nt!IoCreateFile+0x3d

f82c8d44 804dfc4d 0006f6cc 00100020 0006f660 nt!NtOpenFile+0x25

f82c8d44 7ffe0304 0006f6cc 00100020 0006f660 nt!KiSystemService+0xd0

0006f630 77f50c7a 77f8172d 0006f6cc 00100020
SharedUserData!SystemCallStub+0x4

WARNING: Stack unwind information not available. Following frames may be
wrong.

0006f6ec 77f550e3 00020024 0006f868 00020024 ntdll+0x10c7a

0006f71c 77f542ab 00020024 00000080 0006f984 ntdll+0x150e3

0006f7bc 77f5b734 0006f998 00000080 0006f87c ntdll+0x142ab

0006f820 77f5ca1f 0006f998 0006f958 0006f984 ntdll+0x1b734

0006f860 77f5c7d9 00000005 0006f984 00000001 ntdll+0x1ca1f

0006f94c 000133b8 00000000 00800000 0006f87c ntdll+0x1c7d9

00000001 00000000 00000000 00000000 00000000 0x133b8

FOLLOWUP_IP:

Driver!MakeNewDevice+17e

f81e4e0e 8945ec mov [ebp-0x14],eax

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: Driver!MakeNewDevice+17e

MODULE_NAME: Driver

IMAGE_NAME: Driver.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 3e3eb2d1

STACK_COMMAND: kb

BUCKET_ID: 0xA_Driver!MakeNewDevice+17e

Followup: MachineOwner

---------

—
You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

—
You are currently subscribed to ntfsd as: xxxxx@legato.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

—
You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com</http:>

5

Thanks!

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tony Mason
Sent: Friday, February 07, 2003 5:11 AM
To: File Systems Developers
Subject: [ntfsd] RE: IRQL = 1b

Ken,

Sounds like something is trashing the beginning of the pool block - and I
see you are using special pool, so finding the guilty culprit is not going
to be a simple exercise (otherwise you’d have caught it already.)

Check to make sure your data structure is defined properly (I can’t see that
in the code snippet and I don’t really expect that is the problem, but
there’s not much I can see at this stage.)

One thing to do that might help is to enable buffer underrun checking in
your special pool settings (use gflags.exe to change it from “Verify End” to
“Verify Start”) because that should catch how/if the block is being
modified.

Sorry I can’t give more insight.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

-----Original Message-----
From: Ken Galipeau [mailto:xxxxx@legato.com]
Sent: Thursday, February 06, 2003 10:57 PM
To: File Systems Developers
Subject: [ntfsd] RE: IRQL = 1b

Tony,
Your right! If I do a !poolval on the address I get:
0: kd> !poolval 83ddadc8
Pool page 83ddadc8 region is Special pool

Validating Pool headers for pool page: 83ddadc8

Pool page [83dda000] is INVALID.

Analyzing linked list…
[83dda000]: invalid previous size [0x44] should be [0x0]
[83dda000 –> 83dda010 (size = 0x10 bytes)]: Corrupt region

Scanning for single bit errors…

None found

The Kevent looks like this:
0: kd> dd 83ddadc8
83ddadc8 db04db00 00000000 83ddadd0 83ddadd0
83ddadd8 810f9d88 02080028 83ddadf4 00000000
83ddade8 00000878 00000008

So not only is the Kevent messed up but the pool block it is in.

I had just done this:

KeInitializeEvent(&pCreatePacket->Event, NotificationEvent, FALSE);
ExInitializeWorkItem(&pCreatePacket->WorkQueueItem, CreateNewDevice,
pCreatePacket);
ExQueueWorkItem(&pCreatePacket->WorkQueueItem, CriticalWorkQueue);
status = KeWaitForSingleObject(&pCreatePacket->Event, UserRequest,

(KPROCESSOR_MODE)KernelMode, FALSE, NULL);

The work item does an IoCreateDevice and then sets the event.

Any idea what could cause this kind of corruption?

Thanks,
Ken

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tony Mason
Sent: Wednesday, February 05, 2003 7:10 PM
To: File Systems Developers
Subject: [ntfsd] RE: IRQL = 1b

Ken,

0x1B is IRQL SYNCH_LEVEL on the x86 - this just means that the dispatcher
database lock is held (which makes sense in KeWaitForSingleObject.) My
guess is that the dispatcher object passed in here is invalid or has been
damaged in some way.

Regards,

Tony

Tony Mason

Consulting Partner

OSR Open Systems Resources, Inc.

http://www.osr.com http:

-----Original Message-----
From: Ken Galipeau [mailto:xxxxx@legato.com]
Sent: Wednesday, February 05, 2003 1:09 PM
To: File Systems Developers
Subject: [ntfsd] IRQL = 1b

I got a verify bug while referencing an event. Seems the IRQL is 0x1B!

Prior to the WaitForSingleObject was a:
ExQueueWorkItem(&pCreatePacket->WorkQueueItem, CriticalWorkQueue);

That work queue item calls “IoCreateDevice”.

This code was inside a FSControl resulting from a Mount Volume Request.

I was running iostress on the 2 cpu system, running Server 2003 build 3718
(.Net).

That stack trace is below.

Any ideas how this could happen?

Thanks,

Ken

0: kd> !analyze -v

************************************************************************



Bugcheck Analysis

*

*************************************************************************

IRQL_NOT_LESS_OR_EQUAL (a)

An attempt was made to access a pagable (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: 83ddadc8, memory referenced

Arg2: 0000001b, IRQL

Arg3: 00000000, value 0 = read operation, 1 = write operation

Arg4: 804eb7b8, address which referenced memory

Debugging Details:

------------------

READ_ADDRESS: 83ddadc8 Special pool

CURRENT_IRQL: 1b

FAULTING_IP:

nt!KeWaitForSingleObject+db

804eb7b8 803b02 cmp byte ptr [ebx],0x2

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xA

LAST_CONTROL_TRANSFER: from 80540128 to 804e338c

STACK_TEXT:

f82c832c 80540128 00000003 83ddadc8 00000000
nt!RtlpBreakWithStatusInstruction

f82c8378 80540cd4 00000003 83ddadc8 804eb7b8 nt!KiBugCheckDebugBreak+0x19

f82c86e0 80541150 0000000a 83ddadc8 0000001b nt!KeBugCheck2+0x4a8

f82c8700 804e2b74 0000000a 83ddadc8 0000001b nt!KeBugCheckEx+0x19

f82c8700 804eb7b8 0000000a 83ddadc8 0000001b nt!KiTrap0E+0x224

f82c87bc 8067f36d 83ddadc8 00000006 00000000 nt!KeWaitForSingleObject+0xdb

f82c87e4 f81e4e0e 83ddadc8 00000006 00000000
nt!VerifierKeWaitForSingleObject+0x45

f82c881c f81e6cde 82cce2e8 f82c8848 f82c883c Driver!MakeNewDevice+0x17e
[c:\dev\src\kernel\devices.c @ 512]

f82c8858 f81e78e0 82cce2e8 00000045 00000000 Driver!MakeNewDeviceForId+0xee
[c:\dev\src\kernel\devices.c @ 1135]

f82c88dc f81e95ba 8116b248 fa059540 814415b0
Driver!ReattachDriveDevices+0x5a0 [c:\dev\src\kernel\devices.c @ 1431]

f82c8948 f81fd1a2 8116b248 8352ee48 80713e30 Driver!FileSystemControl+0x29a
[c:\dev\src\kernel\fsctrl.c @ 388]

f82c89a8 8067e4aa 8116b248 8352ee48 8352ee48 Driver!IrpDispatch+0x472
[c:\dev\src\kernel\passthru.c @ 382]

f82c89d8 80528caa 805b2cab 805b2cab 814415b0 nt!IovCallDriver+0x110

f82c89dc 805b2cab 805b2cab 814415b0 80714420 nt!IofCallDriver+0xe

f82c8a38 805161c9 8116b248 fa178200 00000000 nt!IopMountVolume+0x1d3

f82c8a64 8057ac1d fa178218 81441500 f82c8bb0 nt!IopCheckVpbMounted+0x5a

f82c8b6c 80577669 814415b0 00000000 81236440 nt!IopParseDevice+0x3f0

f82c8be8 80577956 00000000 f82c8c28 00000042 nt!ObpLookupObjectName+0x544

f82c8c3c 8057b1b2 00000000 00000000 00000101 nt!ObOpenObjectByName+0xe8

f82c8cb8 8057b349 0006f6cc 00100020 0006f660 nt!IopCreateFile+0x413

f82c8d04 805883a2 0006f6cc 00100020 0006f660 nt!IoCreateFile+0x3d

f82c8d44 804dfc4d 0006f6cc 00100020 0006f660 nt!NtOpenFile+0x25

f82c8d44 7ffe0304 0006f6cc 00100020 0006f660 nt!KiSystemService+0xd0

0006f630 77f50c7a 77f8172d 0006f6cc 00100020
SharedUserData!SystemCallStub+0x4

WARNING: Stack unwind information not available. Following frames may be
wrong.

0006f6ec 77f550e3 00020024 0006f868 00020024 ntdll+0x10c7a

0006f71c 77f542ab 00020024 00000080 0006f984 ntdll+0x150e3

0006f7bc 77f5b734 0006f998 00000080 0006f87c ntdll+0x142ab

0006f820 77f5ca1f 0006f998 0006f958 0006f984 ntdll+0x1b734

0006f860 77f5c7d9 00000005 0006f984 00000001 ntdll+0x1ca1f

0006f94c 000133b8 00000000 00800000 0006f87c ntdll+0x1c7d9

00000001 00000000 00000000 00000000 00000000 0x133b8

FOLLOWUP_IP:

Driver!MakeNewDevice+17e

f81e4e0e 8945ec mov [ebp-0x14],eax

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: Driver!MakeNewDevice+17e

MODULE_NAME: Driver

IMAGE_NAME: Driver.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 3e3eb2d1

STACK_COMMAND: kb

BUCKET_ID: 0xA_Driver!MakeNewDevice+17e

Followup: MachineOwner

---------

—
You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

—
You are currently subscribed to ntfsd as: xxxxx@legato.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

—
You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

—
You are currently subscribed to ntfsd as: xxxxx@legato.com
To unsubscribe send a blank email to xxxxx@lists.osr.com</http:>