Acquiring Lock

NTDEV
1

Hi, I am writing a storport miniport driver.

In Build Io function , I am trying to acquire lock by calling StorPortAcquireSpinLock(pDevExt, StartIoLock, NULL, pLockHandle). But i get BSOD.

I am unable to find the reason why is it resulting in BSOD? Below is the dump.

3: kd> !analyze -v
*******************************************************************************
* *
* 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: 00000000, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000001, value 0 = read operation, 1 = write operation
Arg4: 8fd0d631, address which referenced memory

Debugging Details:

WRITE_ADDRESS: 00000000

CURRENT_IRQL: 2

FAULTING_IP:
storport!StorAcquireSpinLock+14
8fd0d631 8906 mov dword ptr [esi],eax

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0xD1

PROCESS_NAME: System

TRAP_FRAME: 8cf87370 – (.trap 0xffffffff8cf87370)
ErrCode = 00000002
eax=00000002 ebx=862bd9d8 ecx=862bd9d8 edx=00000002 esi=00000000 edi=84fd8004
eip=8fd0d631 esp=8cf873e4 ebp=8cf873e8 iopl=0 nv up ei pl zr na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00210246
storport!StorAcquireSpinLock+0x14:
8fd0d631 8906 mov dword ptr [esi],eax ds:0023:00000000=???
Resetting default scope

LOCK_ADDRESS: 82b6ef60 – (!locks 82b6ef60)

Resource @ nt!PiEngineLock (0x82b6ef60) Exclusively owned
Contention Count = 1
NumberOfExclusiveWaiters = 1
Threads: 84fc3d48-01<*>
Threads Waiting On Exclusive Access:
84ffba70

1 total locks, 1 locks currently held

PNP_TRIAGE:
Lock address : 0x82b6ef60
Thread Count : 1
Thread address: 0x84fc3d48
Thread wait : 0x4ad

LAST_CONTROL_TRANSFER: from 82ae5e71 to 82a74394

STACK_TEXT:
8cf86f3c 82ae5e71 00000003 062e824e 00000065 nt!RtlpBreakWithStatusInstruction
8cf86f8c 82ae696d 00000003 00000000 8fd0d631 nt!KiBugCheckDebugBreak+0x1c
8cf87350 82a4f7eb 0000000a 00000000 00000002 nt!KeBugCheck2+0x68b
8cf87350 8fd0d631 0000000a 00000000 00000002 nt!KiTrap0E+0x2cf
8cf873e8 8fd0511c 84fd8004 00000002 00000000 storport!StorAcquireSpinLock+0x14
8cf87410 8fcfa73f 00001003 84fd8004 00000002 storport!StorPortNotification+0x30d
8cf8742c 8fcfa41b 84fd8004 00000002 00000000 My_Driver!StorPortAcquireSpinLock+0x1f [c:\winddk\7600.16385.0\inc\ddk\storport.h @ 6060]
8cf87460 8fcfbdf0 84fd8004 8638d218 8cf8748c My_Driver!FindSlot+0xab [e:\driver\interface.c @ 263]
8cf874d4 8fd05614 84fd8004 8638d218 8cf8750c My_Driver!BuildIo+0x340 [e:\driver\io.c @ 221]
8cf874e4 8fd07000 862bda78 8638d218 865dc008 storport!RaCallMiniportBuildIo+0x24
8cf8750c 8fd0727f 862bd9d8 86390da8 85fe9800 storport!RaidAdapterPostScatterGatherExecute+0x5e
8cf87524 82e1da2e 862bd920 00000000 865dc05c storport!RaidpAdapterContinueScatterGather+0x3f
8cf87550 8fd0ae19 865dc05c 862bd920 85fe97e0 hal!HalBuildScatterGatherList+0x1ba
8cf87580 8fd0731b 862bdb84 862bd920 85fe97e0 storport!RaidDmaBuildScatterGatherList+0x2c
8cf875c0 8fd0736b 862bdb84 00000010 8cf875f0 storport!RaidAdapterScatterGatherExecute+0x65
8cf875d0 8fd14b30 862bd9d8 865dc008 85ff3238 storport!RaidAdapterExecuteXrb+0x24
8cf875f0 8fd0c3e9 00000000 85ff3238 8cf87610 storport!RaUnitStartIo+0xbf
8cf87630 8fd1282c 00390d30 85ff3238 00000006 storport!RaidStartIoPacket+0x100
8cf87650 8fd15262 86390d30 85ff3238 85ff3238 storport!RaidUnitSubmitRequest+0x4e
8cf87670 8fd0b511 86390d30 85ff3238 8638d258 storport!RaUnitScsiIrp+0x114
8cf8768c 82a454bc 86390c78 85ff3238 00000000 storport!RaDriverScsiIrp+0x60
8cf876a4 8fd11177 8cf87728 85040001 00000000 nt!IofCallDriver+0x63
8cf876c0 8fd09e7d 86390c78 85ff3238 8cf87920 storport!RaSendIrpSynchronous+0x3b
8cf8772c 8fd0a60e 8cf87920 8cf8779c 8638d218 storport!RaidBusEnumeratorIssueSynchronousRequest+0x6c
8cf87750 8fd0a763 8638d218 00000000 8cf8779c storport!RaidBusEnumeratorIssueReportLuns+0x3d
8cf87778 8fd0a9b4 8cf87920 00000000 8cf8779c storport!RaidBusEnumeratorGetLunListFromTarget+0x72
8cf877c8 8fd0743a 8cf87920 00000000 8cf87804 storport!RaidBusEnumeratorGetLunList+0x43
8cf87908 8fd07504 862bd9d8 8fd0aa30 8cf87920 storport!RaidAdapterEnumerateBus+0xbd
8cf87964 8fd3b165 862bd9d8 86018a90 00000007 storport!RaidAdapterRescanBus+0x49
8cf87988 8fd3b82d 862bd9d8 00000000 8fd19000 storport!RaidAdapterQueryDeviceRelationsIrp+0x90
8cf879a4 8fd3bd7c 00000007 01018a90 86018b48 storport!RaidAdapterPnpIrp+0x94
8cf879c0 82a454bc 862bd920 86018a90 8cf87a38 storport!RaDriverPnpIrp+0x71
8cf879d8 82bb1d60 00000000 84f73b60 863a1bf8 nt!IofCallDriver+0x63
8cf879f4 82bb1c97 8cf87a14 82a1cb64 863a1bf8 nt!PnpAsynchronousCall+0x92
8cf87a54 82bb1a19 00000000 82a1cb64 863a1bf8 nt!PnpQueryDeviceRelations+0xc5
8cf87a98 82bb0a45 863a1bf8 0000003e 00000000 nt!PipEnumerateDevice+0xf9
8cf87c94 82b94a2a 84fdbc20 85fa75c0 8cf87cc8 nt!PipProcessDevNodeTree+0x32c
8cf87cd4 82a1cf99 85fa75c0 82b6ce80 84fc3d48 nt!PiProcessStartSystemDevices+0x6d
8cf87d00 82a76f2b 00000000 00000000 84fc3d48 nt!PnpDeviceActionWorker+0x241
8cf87d50 82c1766d 00000001 062e9052 00000000 nt!ExpWorkerThread+0x10d
8cf87d90 82ac90d9 82a76e1e 00000001 00000000 nt!PspSystemThreadStartup+0x9e
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x19

STACK_COMMAND: kb

FOLLOWUP_IP:
storport!StorAcquireSpinLock+14
8fd0d631 8906 mov dword ptr [esi],eax

SYMBOL_STACK_INDEX: 4

SYMBOL_NAME: storport!StorAcquireSpinLock+14

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: storport

IMAGE_NAME: storport.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4a5bc736

FAILURE_BUCKET_ID: 0xD1_storport!StorAcquireSpinLock+14

BUCKET_ID: 0xD1_storport!StorAcquireSpinLock+14

Followup: MachineOwner

Thanks,
Amogha

2

You have a null pointer that you are writing to. In particular it looks
like you pass a NULL pointer as the spin lock.

Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

“xxxxx@gmail.com” wrote in message
news:xxxxx@ntdev:

> Hi, I am writing a storport miniport driver.
>
> In Build Io function , I am trying to acquire lock by calling StorPortAcquireSpinLock(pDevExt, StartIoLock, NULL, pLockHandle). But i get BSOD.
>
> I am unable to find the reason why is it resulting in BSOD? Below is the dump.
>
> 3: kd> !analyze -v
> **
> *
> * 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: 00000000, memory referenced
> Arg2: 00000002, IRQL
> Arg3: 00000001, value 0 = read operation, 1 = write operation
> Arg4: 8fd0d631, address which referenced memory
>
> Debugging Details:
> ------------------
>
>
> WRITE_ADDRESS: 00000000
>
> CURRENT_IRQL: 2
>
> FAULTING_IP:
> storport!StorAcquireSpinLock+14
> 8fd0d631 8906 mov dword ptr [esi],eax
>
> DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
>
> BUGCHECK_STR: 0xD1
>
> PROCESS_NAME: System
>
> TRAP_FRAME: 8cf87370 – (.trap 0xffffffff8cf87370)
> ErrCode = 00000002
> eax=00000002 ebx=862bd9d8 ecx=862bd9d8 edx=00000002 esi=00000000 edi=84fd8004
> eip=8fd0d631 esp=8cf873e4 ebp=8cf873e8 iopl=0 nv up ei pl zr na pe nc
> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00210246
> storport!StorAcquireSpinLock+0x14:
> 8fd0d631 8906 mov dword ptr [esi],eax ds:0023:00000000=???
> Resetting default scope
>
> LOCK_ADDRESS: 82b6ef60 – (!locks 82b6ef60)
>
> Resource @ nt!PiEngineLock (0x82b6ef60) Exclusively owned
> Contention Count = 1
> NumberOfExclusiveWaiters = 1
> Threads: 84fc3d48-01<>
> Threads Waiting On Exclusive Access:
> 84ffba70
>
> 1 total locks, 1 locks currently held
>
> PNP_TRIAGE:
> Lock address : 0x82b6ef60
> Thread Count : 1
> Thread address: 0x84fc3d48
> Thread wait : 0x4ad
>
> LAST_CONTROL_TRANSFER: from 82ae5e71 to 82a74394
>
> STACK_TEXT:
> 8cf86f3c 82ae5e71 00000003 062e824e 00000065 nt!RtlpBreakWithStatusInstruction
> 8cf86f8c 82ae696d 00000003 00000000 8fd0d631 nt!KiBugCheckDebugBreak+0x1c
> 8cf87350 82a4f7eb 0000000a 00000000 00000002 nt!KeBugCheck2+0x68b
> 8cf87350 8fd0d631 0000000a 00000000 00000002 nt!KiTrap0E+0x2cf
> 8cf873e8 8fd0511c 84fd8004 00000002 00000000 storport!StorAcquireSpinLock+0x14
> 8cf87410 8fcfa73f 00001003 84fd8004 00000002 storport!StorPortNotification+0x30d
> 8cf8742c 8fcfa41b 84fd8004 00000002 00000000 My_Driver!StorPortAcquireSpinLock+0x1f [c:\winddk\7600.16385.0\inc\ddk\storport.h @ 6060]
> 8cf87460 8fcfbdf0 84fd8004 8638d218 8cf8748c My_Driver!FindSlot+0xab [e:\driver\interface.c @ 263]
> 8cf874d4 8fd05614 84fd8004 8638d218 8cf8750c My_Driver!BuildIo+0x340 [e:\driver\io.c @ 221]
> 8cf874e4 8fd07000 862bda78 8638d218 865dc008 storport!RaCallMiniportBuildIo+0x24
> 8cf8750c 8fd0727f 862bd9d8 86390da8 85fe9800 storport!RaidAdapterPostScatterGatherExecute+0x5e
> 8cf87524 82e1da2e 862bd920 00000000 865dc05c storport!RaidpAdapterContinueScatterGather+0x3f
> 8cf87550 8fd0ae19 865dc05c 862bd920 85fe97e0 hal!HalBuildScatterGatherList+0x1ba
> 8cf87580 8fd0731b 862bdb84 862bd920 85fe97e0 storport!RaidDmaBuildScatterGatherList+0x2c
> 8cf875c0 8fd0736b 862bdb84 00000010 8cf875f0 storport!RaidAdapterScatterGatherExecute+0x65
> 8cf875d0 8fd14b30 862bd9d8 865dc008 85ff3238 storport!RaidAdapterExecuteXrb+0x24
> 8cf875f0 8fd0c3e9 00000000 85ff3238 8cf87610 storport!RaUnitStartIo+0xbf
> 8cf87630 8fd1282c 00390d30 85ff3238 00000006 storport!RaidStartIoPacket+0x100
> 8cf87650 8fd15262 86390d30 85ff3238 85ff3238 storport!RaidUnitSubmitRequest+0x4e
> 8cf87670 8fd0b511 86390d30 85ff3238 8638d258 storport!RaUnitScsiIrp+0x114
> 8cf8768c 82a454bc 86390c78 85ff3238 00000000 storport!RaDriverScsiIrp+0x60
> 8cf876a4 8fd11177 8cf87728 85040001 00000000 nt!IofCallDriver+0x63
> 8cf876c0 8fd09e7d 86390c78 85ff3238 8cf87920 storport!RaSendIrpSynchronous+0x3b
> 8cf8772c 8fd0a60e 8cf87920 8cf8779c 8638d218 storport!RaidBusEnumeratorIssueSynchronousRequest+0x6c
> 8cf87750 8fd0a763 8638d218 00000000 8cf8779c storport!RaidBusEnumeratorIssueReportLuns+0x3d
> 8cf87778 8fd0a9b4 8cf87920 00000000 8cf8779c storport!RaidBusEnumeratorGetLunListFromTarget+0x72
> 8cf877c8 8fd0743a 8cf87920 00000000 8cf87804 storport!RaidBusEnumeratorGetLunList+0x43
> 8cf87908 8fd07504 862bd9d8 8fd0aa30 8cf87920 storport!RaidAdapterEnumerateBus+0xbd
> 8cf87964 8fd3b165 862bd9d8 86018a90 00000007 storport!RaidAdapterRescanBus+0x49
> 8cf87988 8fd3b82d 862bd9d8 00000000 8fd19000 storport!RaidAdapterQueryDeviceRelationsIrp+0x90
> 8cf879a4 8fd3bd7c 00000007 01018a90 86018b48 storport!RaidAdapterPnpIrp+0x94
> 8cf879c0 82a454bc 862bd920 86018a90 8cf87a38 storport!RaDriverPnpIrp+0x71
> 8cf879d8 82bb1d60 00000000 84f73b60 863a1bf8 nt!IofCallDriver+0x63
> 8cf879f4 82bb1c97 8cf87a14 82a1cb64 863a1bf8 nt!PnpAsynchronousCall+0x92
> 8cf87a54 82bb1a19 00000000 82a1cb64 863a1bf8 nt!PnpQueryDeviceRelations+0xc5
> 8cf87a98 82bb0a45 863a1bf8 0000003e 00000000 nt!PipEnumerateDevice+0xf9
> 8cf87c94 82b94a2a 84fdbc20 85fa75c0 8cf87cc8 nt!PipProcessDevNodeTree+0x32c
> 8cf87cd4 82a1cf99 85fa75c0 82b6ce80 84fc3d48 nt!PiProcessStartSystemDevices+0x6d
> 8cf87d00 82a76f2b 00000000 00000000 84fc3d48 nt!PnpDeviceActionWorker+0x241
> 8cf87d50 82c1766d 00000001 062e9052 00000000 nt!ExpWorkerThread+0x10d
> 8cf87d90 82ac90d9 82a76e1e 00000001 00000000 nt!PspSystemThreadStartup+0x9e
> 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x19
>
>
> STACK_COMMAND: kb
>
> FOLLOWUP_IP:
> storport!StorAcquireSpinLock+14
> 8fd0d631 8906 mov dword ptr [esi],eax
>
> SYMBOL_STACK_INDEX: 4
>
> SYMBOL_NAME: storport!StorAcquireSpinLock+14
>
> FOLLOWUP_NAME: MachineOwner
>
> MODULE_NAME: storport
>
> IMAGE_NAME: storport.sys
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 4a5bc736
>
> FAILURE_BUCKET_ID: 0xD1_storport!StorAcquireSpinLock+14
>
> BUCKET_ID: 0xD1_storport!StorAcquireSpinLock+14
>
> Followup: MachineOwner
> ---------
>
> Thanks,
> Amogha

3

> Hi, I am writing a storport miniport driver.

In Build Io function , I am trying to acquire lock by calling
StorPortAcquireSpinLock(pDevExt, StartIoLock, NULL, pLockHandle). But
i get
BSOD.

I am unable to find the reason why is it resulting in BSOD? Below is
the dump.

What is pLockHandle? I bet you have defined it as:

PSTOR_LOCK_HANDLE pLockHandle;
…
StorPortAcquireSpinLock(pDevExt, StartIoLock, NULL, pLockHandle);

But you really want:

STOR_LOCK_HANDLE lockHandle;
…
StorPortAcquireSpinLock(pDevExt, StartIoLock, NULL, &lockHandle);

James

4

Hi James,

Thanks for the input. I changed the code as you suggested and it worked.

But what is the difference in both of the declaration and usage?
1.
PSTOR_LOCK_HANDLE pLockHandle;
StorPortAcquireSpinLock(pDevExt, StartIoLock, NULL, pLockHandle);

STOR_LOCK_HANDLE lockHandle;
StorPortAcquireSpinLock(pDevExt, StartIoLock, NULL, &lockHandle);

Thanks,
Amogha

5

Ehh … If you don’t know the difference, don’t write drivers! This is basic C!

6

I mean to say in WDK documentation, it says

VOID
StorPortAcquireSpinLock (
IN PVOID DeviceExtension,
IN STOR_SPINLOCK SpinLock,
IN PVOID LockContext,
IN PSTOR_LOCK_HANDLE LockHandle
);

So how to know that which one to use.

I know the difference between them.

Thanks,
Amogha

7

PSTOR_LOCK_HANDLE is typedef of STOR_LOCK_HANDLE *

8

Thanks Volodymyr

9

Hello!

PSTOR_LOCK_HANDLE pLockHandle;

You have a pointer to a STOR_LOCK_HANDLE on the stack, which may be NULL (in DEBUG or “fresh” stack-region), or any other random value.

StorPortAcquireSpinLock(pDevExt, StartIoLock, NULL, pLockHandle);

You are passing the Pointer - which points to “nowhere” - to the function => BSOD.

STOR_LOCK_HANDLE lockHandle;

You allocate an instance of STOR_LOCK_HANDLE on the stack.

StorPortAcquireSpinLock(pDevExt, StartIoLock, NULL, &lockHandle);

You pass a pointer to that instance to the function => OK.

As others have already mentioned: You will not get far in Driver-Land if you don’t know about the basics of C. Search Samples, read docs, …

GP

10

xxxxx@gmail.com wrote:

I mean to say in WDK documentation, it says

VOID
StorPortAcquireSpinLock (
IN PVOID DeviceExtension,
IN STOR_SPINLOCK SpinLock,
IN PVOID LockContext,
IN PSTOR_LOCK_HANDLE LockHandle
);

So how to know that which one to use.

LockHandle is an INPUT parameter here. It is expecting you to hand it a
valid address. What you handed it was uninitialized memory, which
apparently contained zero. The documentation says:

LockHandle [in, out] A pointer to a buffer that, on return, will
contain a lock handle.

It expects the valid address of a place where it can store the handle.
You aren’t giving it a valid address.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

11

>

Hi James,

Thanks for the input. I changed the code as you suggested and it
worked.

But what is the difference in both of the declaration and usage?
1.
PSTOR_LOCK_HANDLE pLockHandle;
StorPortAcquireSpinLock(pDevExt, StartIoLock, NULL, pLockHandle);

In this case you declared a pointer but haven’t ‘pointed it’ at
anything. PSTOR_LOCK_HANDLE is the same as *STOR_LOCK_HANDLE.

STOR_LOCK_HANDLE lockHandle;
StorPortAcquireSpinLock(pDevExt, StartIoLock, NULL, &lockHandle);

Here you are allocating a STOR_LOCK_HANDLE structure (which is probably
actually a typedef PVOID) and passing in the pointer to it. This would
also work:

STOR_LOCK_HANDLE lockHandle;
PSTOR_LOCK_HANDLE pLockHandle;
pLockHandle = &lockHandle;
StorPortAcquireSpinLock(pDevExt, StartIoLock, NULL, pLockHandle);

James

12

>

Ehh … If you don’t know the difference, don’t write drivers! This is
basic
C!

I suspect maybe he was confused about the meaning of the P prefix
indicating a pointer. The first time I sat down and looked at the WDK
docs I spent a few minutes pondering this too. I was looking at some
sample code that declared a variable of type PMDL but there was no
reference to PMDL in the WDK docs. Looking at wdm.h made everything
clear.

James

13

“Tim Roberts” wrote in message news:xxxxx@ntdev…
> xxxxx@gmail.com wrote:
>> I mean to say in WDK documentation, it says
>>
>> VOID
>> StorPortAcquireSpinLock (
>> IN PVOID DeviceExtension,
>> IN STOR_SPINLOCK SpinLock,
>> IN PVOID LockContext,
>> IN PSTOR_LOCK_HANDLE LockHandle
>> );

In the online MSDN the last parameter is __inout.
It is IN in an older releases of WDK .chm

When a function returns something thru a pointer parameter, the parameter is
output - even though the pointer itself is input to the function.
That’s the ole good C.

–pa

>>
>> So how to know that which one to use.
>
> LockHandle is an INPUT parameter here. It is expecting you to hand it a
> valid address. What you handed it was uninitialized memory, which
> apparently contained zero. The documentation says:
>
> LockHandle [in, out] A pointer to a buffer that, on return, will
> contain a lock handle.
>
> It expects the valid address of a place where it can store the handle.
> You aren’t giving it a valid address.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.