Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Before Posting...

Please check out the Community Guidelines in the Announcements and Administration Category.

More Info on Driver Writing and Debugging


The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.


Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/


!verifier 80

mark-4mark-4 Member Posts: 77

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

<

address> 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

Comments

  • Scott_Noone_(OSR)Scott_Noone_(OSR) Administrator Posts: 3,679

    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.

    -scott
    OSR

  • Dejan_MaksimovicDejan_Maksimovic Member - All Emails Posts: 636
    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 :(
  • Scott_Noone_(OSR)Scott_Noone_(OSR) Administrator Posts: 3,679

    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.

    -scott
    OSR

  • mark-4mark-4 Member Posts: 77

    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

  • Dejan_MaksimovicDejan_Maksimovic Member - All Emails Posts: 636
    via Email
    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.
  • mark-4mark-4 Member Posts: 77

    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:
    [X] (0x00000000) Automatic Checks
    [X] (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

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. Sign in or register to get started.

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Kernel Debugging 13-17 May 2024 Live, Online
Developing Minifilters 1-5 Apr 2024 Live, Online
Internals & Software Drivers 11-15 Mar 2024 Live, Online
Writing WDF Drivers 20-24 May 2024 Live, Online