BSOD when acquiring spinlock with DriverVerifier

Greetings all,
I would appreciate some advice on a BSOD caused when running a heavy IO test with DriverVerifier.
The BSOD happens, when the code tries to acquire a spinlock.

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: c0c05000, memory referenced
Arg2: d0000000, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: 808046d1, address which referenced memory

Debugging Details:

READ_ADDRESS: c0c05000

CURRENT_IRQL: 0

FAULTING_IP:
nt!MiRemoveWorkingSetPages+24a
808046d1 f60101 test byte ptr [ecx],1

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xA

PROCESS_NAME: System

TRAP_FRAME: b79bfa0c – (.trap 0xffffffffb79bfa0c)
ErrCode = 00000000
eax=000013f2 ebx=003ffffc ecx=c0c05000 edx=c0c04ffc esi=c0c00000 edi=c0c05000
eip=808046d1 esp=b79bfa80 ebp=b79bfab4 iopl=0 nv up ei pl zr na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246
nt!MiRemoveWorkingSetPages+0x24a:
808046d1 f60101 test byte ptr [ecx],1 ds:0023:c0c05000=??
Resetting default scope

MISALIGNED_IP:
nt!MiRemoveWorkingSetPages+24a
808046d1 f60101 test byte ptr [ecx],1

LAST_CONTROL_TRANSFER: from 808046d1 to 80836de5

STACK_TEXT:
b79bfa0c 808046d1 badb0d00 c0c04ffc 00000008 nt!KiTrap0E+0x2a7
b79bfab4 8081d89e 808b4160 808b4160 8254ddb0 nt!MiRemoveWorkingSetPages+0x24a
b79bfb58 8087f680 00000005 00000000 00000000 nt!MiEmptyWorkingSet+0x1a6
b79bfb7c 809d727a 00000000 00000000 84ab40f0 nt!MiTrimAllSystemPagableMemory+0x1d9
b79bfb9c 809d8386 00000000 00000000 00000000 nt!ViTrimAllSystemPagableMemory+0x53
b79bfbb0 b738ca47 b738c8f0 84c531d0 84ab40e0 nt!VerifierKfAcquireSpinLock+0x33
b79bfbcc b7574cbd b79bfc04 84c531d0 00000000 SASCSITD!HandleTargetXferComplete+0xc7 [d:\share\work\esm\fctarget\scsitmd.c @ 3349]

SYMBOL_STACK_INDEX: 6

SYMBOL_NAME: SASCSITD!HandleTargetXferComplete+c7

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: hardware

IMAGE_NAME: hardware

DEBUG_FLR_IMAGE_TIMESTAMP: 0

FAILURE_BUCKET_ID: IP_MISALIGNED

BUCKET_ID: IP_MISALIGNED

Followup: MachineOwner

The spinlock (called NewCmdLock) resides in a device extension.
In the dump, the device extension pointer looks fine - device extension fields are OK also.
The code line that causes the BSOD performes:
KeAcquireSpinLock(&DeviceExtension->NewCmdLock, &OldIrql);

The device extension looks like this:
0: kd> ?? DeviceExtension
struct _DEVICE_EXTENSION * 0x84ab40e0
+0x000 NewCmdLIST : _LIST
+0x010 NewCmdLock : 0

That is, the spinlock is the second field in the device extension structure.
The faulting code has been performed many times before - with the same device extension (only 1 device in this case).
Additional strange thing is that WinDbg claims that the fault has been caused by hardware…

Without the DriverVerifier the test seems to run fine…
Any advice would be appreciated.

Thanks,
Alex.

Is SASCSITD!HandleTargetXferComplete marked as a PAGEable routine?

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@storeage.com
Sent: Tuesday, October 09, 2007 12:11 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] BSOD when acquiring spinlock with DriverVerifier

Greetings all,
I would appreciate some advice on a BSOD caused when running a heavy IO test with DriverVerifier.
The BSOD happens, when the code tries to acquire a spinlock.

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: c0c05000, memory referenced
Arg2: d0000000, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: 808046d1, address which referenced memory

Debugging Details:

READ_ADDRESS: c0c05000

CURRENT_IRQL: 0

FAULTING_IP:
nt!MiRemoveWorkingSetPages+24a
808046d1 f60101 test byte ptr [ecx],1

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xA

PROCESS_NAME: System

TRAP_FRAME: b79bfa0c – (.trap 0xffffffffb79bfa0c)
ErrCode = 00000000
eax=000013f2 ebx=003ffffc ecx=c0c05000 edx=c0c04ffc esi=c0c00000 edi=c0c05000
eip=808046d1 esp=b79bfa80 ebp=b79bfab4 iopl=0 nv up ei pl zr na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246
nt!MiRemoveWorkingSetPages+0x24a:
808046d1 f60101 test byte ptr [ecx],1 ds:0023:c0c05000=??
Resetting default scope

MISALIGNED_IP:
nt!MiRemoveWorkingSetPages+24a
808046d1 f60101 test byte ptr [ecx],1

LAST_CONTROL_TRANSFER: from 808046d1 to 80836de5

STACK_TEXT:
b79bfa0c 808046d1 badb0d00 c0c04ffc 00000008 nt!KiTrap0E+0x2a7
b79bfab4 8081d89e 808b4160 808b4160 8254ddb0 nt!MiRemoveWorkingSetPages+0x24a
b79bfb58 8087f680 00000005 00000000 00000000 nt!MiEmptyWorkingSet+0x1a6
b79bfb7c 809d727a 00000000 00000000 84ab40f0 nt!MiTrimAllSystemPagableMemory+0x1d9
b79bfb9c 809d8386 00000000 00000000 00000000 nt!ViTrimAllSystemPagableMemory+0x53
b79bfbb0 b738ca47 b738c8f0 84c531d0 84ab40e0 nt!VerifierKfAcquireSpinLock+0x33
b79bfbcc b7574cbd b79bfc04 84c531d0 00000000 SASCSITD!HandleTargetXferComplete+0xc7 [d:\share\work\esm\fctarget\scsitmd.c @ 3349]

SYMBOL_STACK_INDEX: 6

SYMBOL_NAME: SASCSITD!HandleTargetXferComplete+c7

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: hardware

IMAGE_NAME: hardware

DEBUG_FLR_IMAGE_TIMESTAMP: 0

FAILURE_BUCKET_ID: IP_MISALIGNED

BUCKET_ID: IP_MISALIGNED

Followup: MachineOwner

The spinlock (called NewCmdLock) resides in a device extension.
In the dump, the device extension pointer looks fine - device extension fields are OK also.
The code line that causes the BSOD performes:
KeAcquireSpinLock(&DeviceExtension->NewCmdLock, &OldIrql);

The device extension looks like this:
0: kd> ?? DeviceExtension
struct _DEVICE_EXTENSION * 0x84ab40e0
+0x000 NewCmdLIST : _LIST
+0x010 NewCmdLock : 0

That is, the spinlock is the second field in the device extension structure.
The faulting code has been performed many times before - with the same device extension (only 1 device in this case).
Additional strange thing is that WinDbg claims that the fault has been caused by hardware…

Without the DriverVerifier the test seems to run fine…
Any advice would be appreciated.

Thanks,
Alex.


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Doron,
no all the code is unpageable.
Although, I must add, that this routine is called from another driver, via a function
pointer that it obtained earlier.

Alex.