Hello. I’m trying to view the allocation history for a specific address in a Windows 10 crash dump with verifier and special pool enabled.
If I run !verifier 80 I can see a bunch of allocations for that address but no frees. I haven’t looked at this for a while but I’m sure that it used to show the frees too. Is this no longer supported or is there an additional argument for this?
Also am I correct in assuming that the allocation at the top of the list is the most current one?
Cheers
Mark
You should see the frees as well. Any chance the allocation is freed by another module?
And, yes, the top is the most current one.
There is a good chance it just didn’t get captured due to the log limits? I never find a leaked allocation in verifier 0x80 myself 
Good point! The log isn’t infinite and, obviously, if you have a leak there aren’t going to be any frees. !verifier 1 should give you info about how man allocations you have active if you suspect a leak.
Thanks both. It’s not a leak as such: I’m looking at a BSOD in a different driver (bridge.sys) which only occurs when our driver is also running. The crash occurs while walking the NBL context list because the context is invalid
0: kd> db ffffbe05a0176fd0 ffffbe05a0176fd0 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???
ffffbe05a0176fe0 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? ffffbe05a0176ff0 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???
ffffbe05a0177000 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? ffffbe05a0177010 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???
ffffbe05a0177020 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? ffffbe05a0177030 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???
ffffbe05`a0177040 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???
0: kd> !pool ffffbe05`a0176fd0 2
Pool page ffffbe05a0176fd0 region is Special pool
ffffbe05a0176000: Unable to get contents of special pool block
Verifier indicates that this was allocated on the following stack (there don’t appear to be any public symbols for bridge.sys)
!verifier 80 ffffbe05`a0176fd0
Pool block ffffbe05a0176fd0, Size 0000000000000030, Thread fffff8047553fa00
fffff804751f8fe5 nt!VfAllocPoolNotification+0x31
fffff804751ed89f nt!VeAllocatePoolWithTagPriority+0x2cf
fffff804751ee06c nt!VerifierExAllocatePoolWithTag+0x8c
fffff8047789c983 ndis!NdisAllocateNetBufferListContext+0x133
fffff8050e317d10 bridge+0x7d10
fffff8050e314a18 bridge+0x4a18
fffff804777f7ef1 ndis!ndisCallReceiveHandler+0x61
fffff8047782df58 ndis!ndisInvokeNextReceiveHandler+0x148
fffff804777f4a94 ndis!NdisMIndicateReceiveNetBufferLists+0x104
fffff8050e2500f6 NdisImPlatform!implatTryToIndicateReceiveNBLs+0x1c2
fffff8050e24faf0 NdisImPlatform!implatReceiveNetBufferLists+0x1b0
fffff804777f1eb1 ndis!ndisMIndicateNetBufferListsToOpen+0x141
fffff80477830b84 ndis!ndisMTopReceiveNetBufferLists+0x3f0e4
I was wondering whether this has been prematurely freed but don’t see any frees at all in the log.
Thanks anyway for the suggestions.Much appreciated.
Cheers
Mark
Did you have SP and PT or just SP enabled?
What was the crash anyway?
Log may not have the free, even if it happened.
Hi Dejan
I think you just answered my question. I checked and only had special pool enabled
0: kd> !verifier
Verify Flags Level 0x00100001
STANDARD FLAGS:
(0x00000000) Automatic Checks
(0x00000001) Special pool
(0x00000002) Force IRQL checking
(0x00000008) Pool tracking
(0x00000010) I/O verification
(0x00000020) Deadlock detection
(0x00000080) DMA checking
(0x00000100) Security checks
(0x00000800) Miscellaneous checks
(0x00020000) DDI compliance checking
I just tried enabling pool tracking and on my test environment at least I am now seeing frees. Many thanks for the steer 
The crash occurs in bridge.sys when it attempts to derference a NBL context
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: ffffbe05a0176ff0, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000000, value 0 = read operation, 1 = write operation
Arg4: fffff8050e3180b9, address which referenced memory
…
bridge+0x80b9:
fffff8050e3180b9 4b8b4c3420 mov rcx,qword ptr [r12+r14+20h] ds:0000000000000020=???
The NBL looks valid
0: kd> !ndiskd.nbl ffffbe05`9e902dd0
NBL ffffbe059e902dd0 Next NBL NULL
First NB ffffbe059e902f50 Source ffffbe05a95e51a0 - Realtek USB GbE Family Controller
Pool ffffbe05a496e680 -
Status Unknown value 0x00000105
Flags INDICATED, RETURNED, NBL_ALLOCATED, PROTOCOL_020_0,
PROTOCOL_200_0, PROTOCOL_800_0
Walk the NBL chain Dump data payload
Show out-of-band information Show in Microsoft Network Monitor
But at the time of the crash the context was NULL
: kd> dt _net_buffer_list ffffbe059e902dd0 ndis!_NET_BUFFER_LIST +0x000 Next : (null) +0x008 FirstNetBuffer : 0xffffbe059e902f50 _NET_BUFFER
+0x000 Link : _SLIST_HEADER
+0x000 NetBufferListHeader : _NET_BUFFER_LIST_HEADER
+0x010 Context : (null)
+0x018 ParentNetBufferList : (null)
+0x020 NdisPoolHandle : 0xffffbe05a496e680 Void +0x030 NdisReserved : [2] (null) +0x040 ProtocolReserved : [4] (null) +0x060 MiniportReserved : [2] 0xffffbe05a8a4d870 Void
+0x070 Scratch : (null)
+0x078 SourceHandle : 0xffffbe05a95e51a0 Void +0x080 NblFlags : 0 +0x084 ChildRefCount : 0n0 +0x088 Flags : 0xa200010c +0x08c Status : 0n261 +0x08c NdisReserved2 : 0x105 +0x090 NetBufferListInfo : [29] 0x0000000000000028 Void
However with a little disassembly and grubbing of the stack I was able to find the context value in r14 was extracted from the NBL and set to ffffbe05`a0176fd0,
R12 was set to zero hence the invalid address reported in the stop code of ffffbe05a0176ff0 for the following instruction
fffff8050e3180b9 4b8b4c3420 mov rcx,qword ptr [r12+r14+20h] ds:0000000000000020=???
The customer reported that the crash occurs when they plug their laptop into the docking station. At this point the bridge is established so I’m thinking that the miniport for the NIC is being halted when the bridge is created and I’m wondering whether the NBL allocated by the Realtek driver is being torn down during this process hence the null context value in the NBL. I see that the context value was allocated on the following stack but for the reasons you mentioned did not see a free for it.
; !verifier 80 ffffbe05`a0176fd0
;
Pool block ffffbe05a0176fd0, Size 0000000000000030, Thread fffff8047553fa00
fffff804751f8fe5 nt!VfAllocPoolNotification+0x31
fffff804751ed89f nt!VeAllocatePoolWithTagPriority+0x2cf
fffff804751ee06c nt!VerifierExAllocatePoolWithTag+0x8c
fffff8047789c983 ndis!NdisAllocateNetBufferListContext+0x133
fffff8050e317d10 bridge+0x7d10
fffff8050e314a18 bridge+0x4a18
fffff804777f7ef1 ndis!ndisCallReceiveHandler+0x61
fffff8047782df58 ndis!ndisInvokeNextReceiveHandler+0x148
fffff804777f4a94 ndis!NdisMIndicateReceiveNetBufferLists+0x104
fffff8050e2500f6 NdisImPlatform!implatTryToIndicateReceiveNBLs+0x1c2
fffff8050e24faf0 NdisImPlatform!implatReceiveNetBufferLists+0x1b0
fffff804777f1eb1 ndis!ndisMIndicateNetBufferListsToOpen+0x141
fffff80477830b84 ndis!ndisMTopReceiveNetBufferLists+0x3f0e4
But the context memory is certainly no longer valid
0: kd> !pool ffffbe05a0176fd0 2 Pool page ffffbe05a0176fd0 region is Special pool ffffbe05a0176000: Unable to get contents of special pool block 0: kd> db ffffbe05a0176fd0
ffffbe05a0176fd0 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? ffffbe05a0176fe0 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???
ffffbe05a0176ff0 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? ffffbe05a0177000 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???
ffffbe05a0177010 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? ffffbe05a0177020 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???
ffffbe05a0177030 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? ffffbe05a0177040 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???
I’ll let you know once I’ve figured out what’s happening. Hopetully the pool tracking option should help.
Thanks again for your valuable input.
Cheers
Mark