Problem with using !pool command

Hi All!

I’m debugging a problem with kernel-mode memory corruption on the system running Windows 10 x64 Build 17763.107. I’m using latest Windbg version 10.0.17763.132 AMD64.

I’m executing under Verifier and I’m using Special pool with granularity 0x20

Whenever I’m trying to use !pool command, I’m receiving a message “Failed to read heap key”. For example:

    3: kd> !vm 0x20
    
    ************ NO PAGING FILE *********************
    Physical Memory:          1048284 (    4193136 Kb)
...
    NonPagedPool Usage:             0 (          0 Kb)
    NonPagedPoolNx Usage:        1425 (       5700 Kb)
    NonPagedPool Max:      4294967296 (17179869184 Kb)
    PagedPool  0:                   0 (          0 Kb)
    PagedPool  1:                   0 (          0 Kb)
    PagedPool  2:                   0 (          0 Kb)
    PagedPool  3:                   0 (          0 Kb)
    PagedPool  4:                   0 (          0 Kb)
    PagedPool Usage:                0 (          0 Kb)
    PagedPool Maximum:     4294967296 (17179869184 Kb)
...    
   
    System Region               Base Address    NumberOfBytes
    
    UltraZero             : ffff828000000000     100000000000
...
    PagedPool             : ffffc30000000000     100000000000
...  
    SpecialPoolPaged      : ffffde8000000000       8000000000
    NonPagedPool          : ffffdf0000000000     100000000000
...
    SpecialPoolNonPaged   : fffffd0000000000       8000000000


    3: kd> !pool fffffd0000000000
    Failed to read heap key
    
    3: kd> !pool ffffdf0000000000
    Failed to read heap key

Do I miss something? How else can I enforce verification of the Non-Paged (special) pool at the WinDbg break?

Thank you in advance,

Alex

Me too, for rs5 with the windbg from the RS5 WDK.

RS5 has a new pool implementation and !pool is now broken. It’s been reported but I haven’t heard a timeframe on when it will be fixed.

Is there any information about new pool implementation? I have a driver that works well in any Windows version, but RS5. I’m experiencing random crashes (0x139, 0x13a, 0x70, etc. - typical memory corruption problem), but Driver Verifier shows no problems at all.

Is Driver Verifier is also broken? Any suggestion, how to search for such problem w/o !pool command?

Alex

The only information I have is that it’s now the same “Low Fragmentation Heap” implementation that’s been in user mode for a while. I haven’t done any in depth research on it yet as it’s new to the kernel, but it looks like there’s been a lot of research of the user mode implementation.

I just put in an honest effort to fix !pool myself but the public symbols are missing WAY too much information to make it practical. Lots of the missing structures are in the ntdll symbols, but it was a major rat hole (do a .show_sym_failures /s /t and start trying to fix the errors that pop up…).

What’s the !analyze output? Maybe we can make progress even with the broken commands.

-scott