The PLOOKASIDE_LIST_EX typed parameter of ExInitializeLookasideListEx must be 16 bytes aligned on x64 according to MSDN.
If the structure is a member of a larger structure than you may need a C_ASSERT check.
The PLOOKASIDE_LIST_EX typed parameter of ExInitializeLookasideListEx must be 16 bytes aligned on x64 according to MSDN.
If the structure is a member of a larger structure than you may need a C_ASSERT check.
Thanks!
Got it working. That was the problem. Found your reference in MSDN.
Sometimes it was aligned (most of the time, but sometimes it was not).
On Fri, May 5, 2017 at 4:49 PM wrote:
> Thanks!
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: <
> http://www.osronline.com/showlists.cfm?list=ntdev>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer>
></http:>
Unless you screwed with default structure alignment, LOOKASIDE_LIST_EX natural alignment will be 16 bytes.
On x64, pools are always 16 bytes aligned.
J. S.
I did not screw with anything. I simply put the structure in in my device extension. Now, I put a pointer to the structure in the extension, and allocate the memory from ExAllocatePool() which is 16 byte aligned on x64. Solved my problem.
The offset of a member of a structure is constant for the lifetime of the structure. I’m afraid you have a bug because if a member is properly aligned once, it should always be properly aligned.
C_ASSERT((FIELD_OFFSET(DEVICE_EXT,LookAsideListEx) & 0xF) == 0)
If you can compile then the member is properly aligned. Than you need to check that the device extension is properly aligned as well.
J. S.
Initializing the lookaside is one of the first things I do when setting up
the device. Not much else can go wrong before that. I’ll add the assert
check just to be safe. I haven’t spent much time tracking it down. Maybe
I’ll dig in a little closer today. Allocating the structure surely solves
the BSOD. I’ll post more information if I discover some root cause that I
am not seeing right now.
The bug is rare, and does not happen on all machines. If it does not happen
on a machine, it appears to never happen on that machine. If I find a
machine where it does happen, it happens frequently.
On Sat, May 6, 2017 at 2:38 PM xxxxx@outlook.com <
xxxxx@outlook.com> wrote:
The offset of a member of a structure is constant for the lifetime of the
structure. I’m afraid you have a bug because if a member is properly
aligned once, it should always be properly aligned.C_ASSERT((FIELD_OFFSET(DEVICE_EXT,LookAsideListEx) & 0xF) == 0)
If you can compile then the member is properly aligned. Than you need to
check that the device extension is properly aligned as well.J. S.
NTDEV is sponsored by OSR
Visit the list online at: <
http://www.osronline.com/showlists.cfm?list=ntdev\>MONTHLY seminars on crash dump analysis, WDF, Windows internals and
software drivers!
Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer>
></http:>
> The bug is rare, and does not happen on all machines. If it does not happen
on a machine, it appears to never happen on that machine.
A lookaside list can be garbage-collected by the kernel whenever it decides so. Maybe those machines become low on memory and you have a dangling pointer to a reclaimed item. Or, there’s some synchronization problem (a lookaside list has some lock to sync between allocations, frees and garbage collection…). When you repro this again, post a call stack …
– pa
@Mr Kirby:
I hope you haven’t forgotten to call ExDeleteLookasideListEx before IoDeleteDevice?
It is a Storport miniport, but yes, I do delete the list where appropriate.
On Sat, May 6, 2017 at 9:11 PM wrote:
> @Mr Kirby:
>
> I hope you haven’t forgotten to call ExDeleteLookasideListEx before
> IoDeleteDevice?
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: <
> http://www.osronline.com/showlists.cfm?list=ntdev>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer>
></http:>
Def pool corruption.
fffff8800496bb88 fffff800
027866d2 : 0000000000000003 fffffa80
021e2a60
0000000000000065 fffff800
026cf314 : nt!RtlpBreakWithStatusInstruction
fffff8800496bb90 fffff800
027874be : 0000000000000003 00000000
00000000
fffff800026cbee0 00000000
00000019 : nt!KiBugCheckDebugBreak+0x12
fffff8800496bbf0 fffff800
02691004 : fffff8800496c500 00000000
00000000
0000000000000000 fffffa80
01904320 : nt!KeBugCheck2+0x71e
fffff8800496c2c0 fffff800
027c2d6f : 0000000000000019 00000000
00000003
fffff8000281ea80 00000000
0007e73a : nt!KeBugCheckEx+0x104
fffff8800496c300 fffff800
028fc89e : 0000000000000000 fffffa80
01af5b60
fffffa8072724d46 00000000
00000000 : nt!ExFreePool+0x536
fffff8800496c3f0 fffff880
01097310 : fffff8800496c4f0 00000000
00000005
fffffa80019d6be0 fffffa80
0199a730 :
nt!ExAllocateCacheAwareRundownProtection+0xe6
fffff8800496c420 fffff880
010990e1 : fffff8a005e4d3a0 ffffffff
80000914
fffffa8000000005 00000000
000007ff : fltmgr!FltpInitInstance+0x130
fffff8800496c490 fffff880
010978bb : fffff8a001c334e0 00000000
00000000
0000000000000050 00000000
00000018 :
fltmgr!FltpCreateInstanceFromName+0x1d1
fffff8800496c560 fffff880
010980bc : fffffa80019d6bf0 fffffa80
019bf010
fffffa80019d6bf0 00000000
00000020 :
fltmgr!FltpEnumerateRegistryInstances+0x15b
fffff8800496c600 fffff880
010933f0 : fffffa8001d97800 fffffa80
00000000
fffffa80019d6bf0 fffffa80
019bf010 :
fltmgr!FltpDoFilterNotificationForNewVolume+0xec
fffff8800496c670 fffff800
02991477 : 0000000000000025 fffff800
02990ed0
fffffa8002c27b10 00000000
00000000 : fltmgr!FltpCreate+0x3e0
fffff8800496c720 fffff800
02987764 : fffffa8001f09060 00000000
00000000
fffffa8001d7db10 00000000
00000001 : nt!IopParseDevice+0x5a7
fffff8800496c8b0 fffff800
0298c876 : fffffa8001d7db10 fffff880
0496ca30
0000000000000040 fffffa80
018ba750 : nt!ObpLookupObjectName+0x585
fffff8800496c9b0 fffff800
02993587 : fffffa80018ba750 00000000
00000001
00000000746c6601 fffff880
0496cac0 : nt!ObOpenObjectByName+0x306
fffff8800496ca80 fffff800
0299d198 : 0000000001d5e338 fffff800
80100080
0000000000000000 00000000
01d5e348 : nt!IopCreateFile+0x2b7
fffff8800496cb20 fffff800
02690153 : ffffffffffffffff 00000000
01d5e348
0000000001d5e360 00000000
00000004 : nt!NtCreateFile+0x78
fffff8800496cbb0 00000000
778f040a : 000007fefdb24d76 00000000
00000000
0000000080000000 ffffffff
ffffffff : nt!KiSystemServiceCopyEnd+0x13
0000000001d5e2b8 000007fe
fdb24d76 : 0000000000000000 00000000
80000000
ffffffffffffffff 00000000
00000018 : ntdll!NtCreateFile+0xa
0000000001d5e2c0 00000000
77792aad : 0000000080000000 00000000
80000000
0000000000000003 00000000
01d5e778 : KERNELBASE!CreateFileW+0x2cd
0000000001d5e420 000007fe
ed39b2be : 000000000048c190 00000000
01d5e778
0000000000000000 00000000
0048c190 :
kernel32!CreateFileWImplementation+0x7d
0000000001d5e480 000007fe
ed0e39e0 : 000000000048c190 00000000
00489820
000007feed0ca0d8 00000000
0048c190 : vdsutil!OpenDevice+0xfe
0000000001d5e740 00000000
fff5b970 : 0000000000000000 00000000
00000001
0000000001d5e800 00000000
00457b00 : vdsbas!CBasicDisk::GetProperties+0x398
0000000001d5e7d0 000007fe
ff40c7f5 : 0000000000000002 00000000
01d5ebf0
000007feed33e6e0 000007fe
ff78f17d : vds!CVdsDiskLun::GetProperties+0x98
0000000001d5e820 000007fe
ff4bb62e : 0000000000000002 00000000
00487c80
000007feed33d3d0 00000000
00496760 : RPCRT4!Invoke+0x65
0000000001d5e870 000007fe
ff40f1f6 : 0000000000000000 00000000
00000000
0000000000000000 00000000
00000000 : RPCRT4!Ndr64StubWorker+0x61b
0000000001d5ee30 000007fe
ff78f223 : 0000000000000000 00000000
00000000
000007feed33f460 00000000
0043d960 : RPCRT4!NdrStubCall3+0xb5
0000000001d5ee90 000007fe
ff78fc0d : 0000000000000001 00000000
00000000
0000000000000000 00000000
00000000 : ole32!CStdStubBuffer_Invoke+0x5b
[d:\w7rtm\com\rpc\ndrole\stub.cxx @ 1586]
0000000001d5eec0 000007fe
ff78fb83 : 0000000000496760 00000000
00484c04
000000000044bc20 00000000
fff04ca0 : ole32!SyncStubInvoke+0x5d
[d:\w7rtm\com\ole32\com\dcomrem\channelb.cxx @ 1187]
0000000001d5ef30 000007fe
ff62fd60 : 0000000000496760 00000000
0044fa20
0000000000496760 00000000
00000000 : ole32!StubInvoke+0xdb
[d:\w7rtm\com\ole32\com\dcomrem\channelb.cxx @ 1396]
0000000001d5efe0 000007fe
ff78fa22 : 0000000000000000 00000000
00000010
0000000000499f10 00000000
0043d960 :
ole32!CCtxComChnl::ContextInvoke+0x190
[d:\w7rtm\com\ole32\com\dcomrem\ctxchnl.cxx @ 1262]
0000000001d5f170 000007fe
ff78f76b : 00000000d0908070 00000000
0044fa20
00000000004496b0 00000000
00487c80 : ole32!AppInvoke+0xc2
[d:\w7rtm\com\ole32\com\dcomrem\channelb.cxx @ 1086]
0000000001d5f1e0 000007fe
ff78ed6d : 000000000044fa20 00000000
0044fa20
000000000043d960 00000000
00070005 : ole32!ComInvokeWithLockAndIPID+0x52b
[d:\w7rtm\com\ole32\com\dcomrem\channelb.cxx @ 1727]
0000000001d5f370 000007fe
ff409c24 : 000007feff7f7930 00000000
00000000
0000000000452960 000007fe
ff402d97 : ole32!ThreadInvoke+0x30d
[d:\w7rtm\com\ole32\com\dcomrem\channelb.cxx @ 4751]
0000000001d5f410 000007fe
ff409d86 : 000007feff79fab0 00000000
00000001
0000000001d5f680 000007fe
ff629910 : RPCRT4!DispatchToStubInCNoAvrf+0x14
0000000001d5f440 000007fe
ff40c44b : 0000000000484be0 00000000
00000000
0000000001d5f764 00000000
00484be0 :
RPCRT4!RPC_INTERFACE::DispatchToStubWorker+0x146
0000000001d5f560 000007fe
ff40c38b : 0000000000000000 00000000
01d5f680
0000000001d5f680 00000000
00452960 :
RPCRT4!RPC_INTERFACE::DispatchToStub+0x9b
0000000001d5f5a0 000007fe
ff40c322 : 0000000000484be0 00000000
00484be0
0000000000484be0 000007fe
ff40ac00 :
RPCRT4!RPC_INTERFACE::DispatchToStubWithObject+0x5b
0000000001d5f620 000007fe
ff40a11d : 0000000000000001 00000000
00000000
000007feff3e0000 00000000
00484be0 :
RPCRT4!LRPC_SCALL::DispatchRequest+0x422
0000000001d5f700 000007fe
ff417ddf : 0000000000010000 00000000
00000000
0000000000000000 00000000
00000001 : RPCRT4!LRPC_SCALL::HandleRequest+0x20d
0000000001d5f830 000007fe
ff417995 : 0000000000000000 00000000
00000000
000000000043a5d0 00000000
00000000 : RPCRT4!LRPC_ADDRESS::ProcessIO+0x3bf
0000000001d5f970 00000000
778bb43b : 0000000000000000 00000000
00000000
0000000000000000 00000000
00000000 : RPCRT4!LrpcIoComplete+0xa5
0000000001d5fa00 00000000
778b923f : 0000000000000000 00000000
00000000
000000000000ffff 00000000
00000000 : ntdll!TppAlpcpExecuteCallback+0x26b
0000000001d5fa90 00000000
7779f56d : 0000000000000000 00000000
00000000
0000000000000000 00000000
00000000 : ntdll!TppWorkerThread+0x3f8
0000000001d5fd90 00000000
778d3281 : 0000000000000000 00000000
00000000
0000000000000000 00000000
00000000 : kernel32!BaseThreadInitThunk+0xd
0000000001d5fdc0 00000000
00000000 : 0000000000000000 00000000
00000000
0000000000000000 00000000
00000000 : ntdll!RtlUserThreadStart+0x1d
On Sat, May 6, 2017 at 10:26 PM Jamey Kirby wrote:
> It is a Storport miniport, but yes, I do delete the list where appropriate.
>
> On Sat, May 6, 2017 at 9:11 PM wrote:
>
>> @Mr Kirby:
>>
>> I hope you haven’t forgotten to call ExDeleteLookasideListEx before
>> IoDeleteDevice?
>>
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> Visit the list online at: <
>> http://www.osronline.com/showlists.cfm?list=ntdev>
>>
>> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
>> software drivers!
>> Details at http:
>>
>> To unsubscribe, visit the List Server section of OSR Online at <
>> http://www.osronline.com/page.cfm?name=ListServer>
>>
></http:>
My driver is not in the call stack.
On Sat, May 6, 2017 at 10:27 PM Jamey Kirby wrote:
> Def pool corruption.
>
> fffff8800496bb88 fffff800
027866d2 : 0000000000000003 fffffa80
021e2a60
> 0000000000000065 fffff800
026cf314 : nt!RtlpBreakWithStatusInstruction
> fffff8800496bb90 fffff800
027874be : 0000000000000003 00000000
00000000
> fffff800026cbee0 00000000
00000019 : nt!KiBugCheckDebugBreak+0x12
> fffff8800496bbf0 fffff800
02691004 : fffff8800496c500 00000000
00000000
> 0000000000000000 fffffa80
01904320 : nt!KeBugCheck2+0x71e
> fffff8800496c2c0 fffff800
027c2d6f : 0000000000000019 00000000
00000003
> fffff8000281ea80 00000000
0007e73a : nt!KeBugCheckEx+0x104
> fffff8800496c300 fffff800
028fc89e : 0000000000000000 fffffa80
01af5b60
> fffffa8072724d46 00000000
00000000 : nt!ExFreePool+0x536
> fffff8800496c3f0 fffff880
01097310 : fffff8800496c4f0 00000000
00000005
> fffffa80019d6be0 fffffa80
0199a730 :
> nt!ExAllocateCacheAwareRundownProtection+0xe6
> fffff8800496c420 fffff880
010990e1 : fffff8a005e4d3a0 ffffffff
80000914
> fffffa8000000005 00000000
000007ff : fltmgr!FltpInitInstance+0x130
> fffff8800496c490 fffff880
010978bb : fffff8a001c334e0 00000000
00000000
> 0000000000000050 00000000
00000018 :
> fltmgr!FltpCreateInstanceFromName+0x1d1
> fffff8800496c560 fffff880
010980bc : fffffa80019d6bf0 fffffa80
019bf010
> fffffa80019d6bf0 00000000
00000020 :
> fltmgr!FltpEnumerateRegistryInstances+0x15b
> fffff8800496c600 fffff880
010933f0 : fffffa8001d97800 fffffa80
00000000
> fffffa80019d6bf0 fffffa80
019bf010 :
> fltmgr!FltpDoFilterNotificationForNewVolume+0xec
> fffff8800496c670 fffff800
02991477 : 0000000000000025 fffff800
02990ed0
> fffffa8002c27b10 00000000
00000000 : fltmgr!FltpCreate+0x3e0
> fffff8800496c720 fffff800
02987764 : fffffa8001f09060 00000000
00000000
> fffffa8001d7db10 00000000
00000001 : nt!IopParseDevice+0x5a7
> fffff8800496c8b0 fffff800
0298c876 : fffffa8001d7db10 fffff880
0496ca30
> 0000000000000040 fffffa80
018ba750 : nt!ObpLookupObjectName+0x585
> fffff8800496c9b0 fffff800
02993587 : fffffa80018ba750 00000000
00000001
> 00000000746c6601 fffff880
0496cac0 : nt!ObOpenObjectByName+0x306
> fffff8800496ca80 fffff800
0299d198 : 0000000001d5e338 fffff800
80100080
> 0000000000000000 00000000
01d5e348 : nt!IopCreateFile+0x2b7
> fffff8800496cb20 fffff800
02690153 : ffffffffffffffff 00000000
01d5e348
> 0000000001d5e360 00000000
00000004 : nt!NtCreateFile+0x78
> fffff8800496cbb0 00000000
778f040a : 000007fefdb24d76 00000000
00000000
> 0000000080000000 ffffffff
ffffffff : nt!KiSystemServiceCopyEnd+0x13
> 0000000001d5e2b8 000007fe
fdb24d76 : 0000000000000000 00000000
80000000
> ffffffffffffffff 00000000
00000018 : ntdll!NtCreateFile+0xa
> 0000000001d5e2c0 00000000
77792aad : 0000000080000000 00000000
80000000
> 0000000000000003 00000000
01d5e778 : KERNELBASE!CreateFileW+0x2cd
> 0000000001d5e420 000007fe
ed39b2be : 000000000048c190 00000000
01d5e778
> 0000000000000000 00000000
0048c190 :
> kernel32!CreateFileWImplementation+0x7d
> 0000000001d5e480 000007fe
ed0e39e0 : 000000000048c190 00000000
00489820
> 000007feed0ca0d8 00000000
0048c190 : vdsutil!OpenDevice+0xfe
> 0000000001d5e740 00000000
fff5b970 : 0000000000000000 00000000
00000001
> 0000000001d5e800 00000000
00457b00 : vdsbas!CBasicDisk::GetProperties+0x398
> 0000000001d5e7d0 000007fe
ff40c7f5 : 0000000000000002 00000000
01d5ebf0
> 000007feed33e6e0 000007fe
ff78f17d : vds!CVdsDiskLun::GetProperties+0x98
> 0000000001d5e820 000007fe
ff4bb62e : 0000000000000002 00000000
00487c80
> 000007feed33d3d0 00000000
00496760 : RPCRT4!Invoke+0x65
> 0000000001d5e870 000007fe
ff40f1f6 : 0000000000000000 00000000
00000000
> 0000000000000000 00000000
00000000 : RPCRT4!Ndr64StubWorker+0x61b
> 0000000001d5ee30 000007fe
ff78f223 : 0000000000000000 00000000
00000000
> 000007feed33f460 00000000
0043d960 : RPCRT4!NdrStubCall3+0xb5
> 0000000001d5ee90 000007fe
ff78fc0d : 0000000000000001 00000000
00000000
> 0000000000000000 00000000
00000000 : ole32!CStdStubBuffer_Invoke+0x5b
> [d:\w7rtm\com\rpc\ndrole\stub.cxx @ 1586]
> 0000000001d5eec0 000007fe
ff78fb83 : 0000000000496760 00000000
00484c04
> 000000000044bc20 00000000
fff04ca0 : ole32!SyncStubInvoke+0x5d
> [d:\w7rtm\com\ole32\com\dcomrem\channelb.cxx @ 1187]
> 0000000001d5ef30 000007fe
ff62fd60 : 0000000000496760 00000000
0044fa20
> 0000000000496760 00000000
00000000 : ole32!StubInvoke+0xdb
> [d:\w7rtm\com\ole32\com\dcomrem\channelb.cxx @ 1396]
> 0000000001d5efe0 000007fe
ff78fa22 : 0000000000000000 00000000
00000010
> 0000000000499f10 00000000
0043d960 :
> ole32!CCtxComChnl::ContextInvoke+0x190
> [d:\w7rtm\com\ole32\com\dcomrem\ctxchnl.cxx @ 1262]
> 0000000001d5f170 000007fe
ff78f76b : 00000000d0908070 00000000
0044fa20
> 00000000004496b0 00000000
00487c80 : ole32!AppInvoke+0xc2
> [d:\w7rtm\com\ole32\com\dcomrem\channelb.cxx @ 1086]
> 0000000001d5f1e0 000007fe
ff78ed6d : 000000000044fa20 00000000
0044fa20
> 000000000043d960 00000000
00070005 : ole32!ComInvokeWithLockAndIPID+0x52b
> [d:\w7rtm\com\ole32\com\dcomrem\channelb.cxx @ 1727]
> 0000000001d5f370 000007fe
ff409c24 : 000007feff7f7930 00000000
00000000
> 0000000000452960 000007fe
ff402d97 : ole32!ThreadInvoke+0x30d
> [d:\w7rtm\com\ole32\com\dcomrem\channelb.cxx @ 4751]
> 0000000001d5f410 000007fe
ff409d86 : 000007feff79fab0 00000000
00000001
> 0000000001d5f680 000007fe
ff629910 : RPCRT4!DispatchToStubInCNoAvrf+0x14
> 0000000001d5f440 000007fe
ff40c44b : 0000000000484be0 00000000
00000000
> 0000000001d5f764 00000000
00484be0 :
> RPCRT4!RPC_INTERFACE::DispatchToStubWorker+0x146
> 0000000001d5f560 000007fe
ff40c38b : 0000000000000000 00000000
01d5f680
> 0000000001d5f680 00000000
00452960 :
> RPCRT4!RPC_INTERFACE::DispatchToStub+0x9b
> 0000000001d5f5a0 000007fe
ff40c322 : 0000000000484be0 00000000
00484be0
> 0000000000484be0 000007fe
ff40ac00 :
> RPCRT4!RPC_INTERFACE::DispatchToStubWithObject+0x5b
> 0000000001d5f620 000007fe
ff40a11d : 0000000000000001 00000000
00000000
> 000007feff3e0000 00000000
00484be0 :
> RPCRT4!LRPC_SCALL::DispatchRequest+0x422
> 0000000001d5f700 000007fe
ff417ddf : 0000000000010000 00000000
00000000
> 0000000000000000 00000000
00000001 : RPCRT4!LRPC_SCALL::HandleRequest+0x20d
> 0000000001d5f830 000007fe
ff417995 : 0000000000000000 00000000
00000000
> 000000000043a5d0 00000000
00000000 : RPCRT4!LRPC_ADDRESS::ProcessIO+0x3bf
> 0000000001d5f970 00000000
778bb43b : 0000000000000000 00000000
00000000
> 0000000000000000 00000000
00000000 : RPCRT4!LrpcIoComplete+0xa5
> 0000000001d5fa00 00000000
778b923f : 0000000000000000 00000000
00000000
> 000000000000ffff 00000000
00000000 : ntdll!TppAlpcpExecuteCallback+0x26b
> 0000000001d5fa90 00000000
7779f56d : 0000000000000000 00000000
00000000
> 0000000000000000 00000000
00000000 : ntdll!TppWorkerThread+0x3f8
> 0000000001d5fd90 00000000
778d3281 : 0000000000000000 00000000
00000000
> 0000000000000000 00000000
00000000 : kernel32!BaseThreadInitThunk+0xd
> 0000000001d5fdc0 00000000
00000000 : 0000000000000000 00000000
00000000
> 0000000000000000 00000000
00000000 : ntdll!RtlUserThreadStart+0x1d
>
>
> On Sat, May 6, 2017 at 10:26 PM Jamey Kirby wrote:
>
>> It is a Storport miniport, but yes, I do delete the list where
>> appropriate.
>>
>> On Sat, May 6, 2017 at 9:11 PM wrote:
>>
>>> @Mr Kirby:
>>>
>>> I hope you haven’t forgotten to call ExDeleteLookasideListEx before
>>> IoDeleteDevice?
>>>
>>>
>>> —
>>> NTDEV is sponsored by OSR
>>>
>>> Visit the list online at: <
>>> http://www.osronline.com/showlists.cfm?list=ntdev>
>>>
>>> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
>>> software drivers!
>>> Details at http:
>>>
>>> To unsubscribe, visit the List Server section of OSR Online at <
>>> http://www.osronline.com/page.cfm?name=ListServer>
>>>
>></http:>
>It is a Storport miniport, but yes, I do delete the list where appropriate.
In which callback do you delete the list? Have you verified it’s actually been called when the miniport is unloaded?
I am a long way from deleting or unloading anything. When it occurs, it is
after system boot when my virtual adapter is initializing. Really, not very
much has happened at that point (I delay initialization via
StorPortEnablePassiveInitialization()). Although a virtual storport
initialization should occur at PASSIVE_LEVEL, I figured using
StorPortEnablePassiveInitialization() makes it clear that it MUST be done
at PASSIVE_LEVEL:
BOOLEAN VirtualHwInitializePassive(In PVHBA_EXT vhba_ext) {
KeInitializeSpinLock(&vhba_ext->request_lock);
InitializeListHead(&vhba_ext->request_head);
KeInitializeEvent(&vhba_ext->thread_ready_event, SynchronizationEvent,
FALSE);
KeInitializeEvent(&vhba_ext->stop_thread_event, SynchronizationEvent,
FALSE);
KeInitializeEvent(&vhba_ext->request_queued_event, SynchronizationEvent,
FALSE);
// Initialize our lookaside list for requests.
// Fix BSOD by allocating lookaside header.
vhba_ext->node_pool = ExAllocatePoolWithTag(NonPagedPool,
sizeof(LOOKASIDE_LIST_EX), 0xBEEF);
NTSTATUS status = ExInitializeLookasideListEx(vhba_ext->node_pool, NULL,
NULL, NonPagedPool, 0, sizeof (SRB_IO_NODE), 0xBEEF, 0);
if (!NT_SUCCESS(status)) {
return FALSE;
}
…
}
BOOLEAN VirtualHwInitialize(In PVHBA_EXT vhba_ext) {
// WDK indicates that this callback should called at PASSIVE_LEVEL
// To be safe, let’s tell storport to complete initialization
at PASSIVE_LEVEL
// anyway.
return StorPortEnablePassiveInitialization(vhba_ext,
VirtualHwInitializePassive);
}
Nothing out of the ordinary, unless I am returning something incorrect from
the find adapter callback:
ULONG VirtualHwFindAdapter(In PVHBA_EXT vhba_ext, In PVOID vhw_context,
In PVOID bus_info, In PVOID lower_device, In PCHAR arg_string,
Inout PPORT_CONFIGURATION_INFORMATION config_info, Out PBOOLEAN again) {
UNREFERENCED_PARAMETER(vhw_context);
UNREFERENCED_PARAMETER(bus_info);
UNREFERENCED_PARAMETER(arg_string);
UNREFERENCED_PARAMETER(again);
#if NTDDI_VERSION >= NTDDI_WIN8
UNREFERENCED_PARAMETER(lower_device);
UNREFERENCED_PARAMETER(vhba_ext);
#endif
config_info->VirtualDevice = TRUE;
config_info->WmiDataProvider = FALSE;
config_info->MaximumTransferLength = VIRTUAL_MAX_IO_SIZE;
config_info->AlignmentMask = 0x3;
config_info->CachesData = FALSE;
config_info->MaximumNumberOfTargets = SCSI_MAXIMUM_TARGETS;
config_info->NumberOfBuses = SCSI_MAXIMUM_BUSES;
config_info->SynchronizationModel = StorSynchronizeFullDuplex;
config_info->ScatterGather = TRUE;
config_info->MultipleRequestPerLu = FALSE;
return SP_RETURN_FOUND;
}
At the time I get the BSOD, I’ve not done much.
Here is the top of the device extension:
typedef struct _VHBA_EXT {
LIST_ENTRY request_head;
KSPIN_LOCK request_lock;
// Changed to pointer, and allocated to fix BSOD.
PLOOKASIDE_LIST_EX node_pool;
KEVENT thread_ready_event;
KEVENT request_queued_event;
KEVENT stop_thread_event;
…
} VHBA_EXT, *PVHBA_EXT;
I’ll add the C_ASSERT next to verify things are aligned as they shoudl be.
I haven’t look at it much over the weekend.
On Sun, May 7, 2017 at 8:17 AM wrote:
> >It is a Storport miniport, but yes, I do delete the list where
> appropriate.
>
> In which callback do you delete the list? Have you verified it’s actually
> been called when the miniport is unloaded?
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: <
> http://www.osronline.com/showlists.cfm?list=ntdev>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer>
></http:>
C_ASSERT is not needed now that you use a pointer.
Why don’t you check that the returned value of ExAllocatePoolWithTag is not null before calling ExInitializeLookAsideListEx ?
I don’t think that 0xBEEF is a useful pool tag for pool tracking. According to MSDN a pool tag is made of ASCII characters in the range 0x20 (space) to 0x126 (tilde).
Use driver verifier with pool tracking.
https://docs.microsoft.com/en-us/windows-hardware/drivers/devtest/pool-tracking
J. S.
Once the struct is allocated, fill it with zeros.
Wai. N.
Johns, the original problem was when I was not allocating it. Once I
started allocating it, the BSOD went away. My confusion is why there was a
BSOD when I was not allocating it.
On Sun, May 7, 2017 at 6:25 PM xxxxx@outlook.com
wrote:
> Once the struct is allocated, fill it with zeros.
>
>
>
> Wai. N.
>
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: <
> http://www.osronline.com/showlists.cfm?list=ntdev>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer>
></http:>
Check if vhba_ext is aligned.
That’s what I will check now. If it is not, I would consider this to be a
bug in the StorPort stack. I assume the extension is allocated via
ExAllocatePool(), and on 64 bit systems, this should be 16 byte aligned.
But, I will check.
On Sun, May 7, 2017 at 10:03 PM wrote:
> Check if vhba_ext is aligned.
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: <
> http://www.osronline.com/showlists.cfm?list=ntdev>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer>
></http:>