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:00000000
00000020=???
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 : 0xffffbe05
9e902f50 _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] 0xffffbe05
a8a4d870 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] 0x00000000
00000028 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:00000000
00000020=???
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 ffffbe05
a0176fd0
ffffbe05a0176fd0 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? ffffbe05
a0176fe0 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???
ffffbe05a0176ff0 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? ffffbe05
a0177000 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???
ffffbe05a0177010 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? ffffbe05
a0177020 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???
ffffbe05a0177030 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? ffffbe05
a0177040 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???
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