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:

I see windbg's latest incarnation is even more eager to hang on to pdb files

matt_sykesmatt_sykes Member - All Emails Posts: 298

windbg occasionally locked a pdb file in memory after a sys file on the target got unloaded, making it impossible to do a new build without closing windbg, but on the latest WDKs windbg this haoppens almost every time (and yes, the drivers unload handler got hit, and it is no longer in the lm list)

It used to be possible to clear this with a .reload /u , but this doesnt seem to work, so windb needs to be restarted.

Is there any other way to do this? It is a PITA to have to restart windbg everytime


  • matt_sykesmatt_sykes Member - All Emails Posts: 298

    This is getting really annoying. one hour after starting work I can not build the driver because windbg has the pdb open still.

    So you have to close windbg. Restarting it often results in a crash, or a failure to load symbols when yo try to debug, so yo uend up having to restart everything.

    Productivity down 500%. This sucks. What the hell happened to it? Windbg used to be reasonably usable.

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 9,160

    In which version of WinDbg are you seeing this behavior?

    If you .reload /u everthing this doesn’t free the PDB?


    Peter Viscarola

  • matt_sykesmatt_sykes Member - All Emails Posts: 298

    It used to Peter, not on this version, 10.0.17763.1. As soon as you step through code, the pdb gets locked in memory.

    I downloaded an older version, 10.0.14321.1024, and it works well (I used to have this version, but it got wiped out when I installed the entire WDK to build with VS2017.

    Actually, talking of the WKD and VS2017, because I have my windows on the D drive, and that is where VS and the WDK installed, it failed to build drivers. Errors in finding tracewpp and cl.exe, clearly a hard coded path somewhere, so I had to switch back to the good old and very reliable DDK 7600.

  • Jeffrey_Tippet_[MSFT]Jeffrey_Tippet_[MSFT] Member - All Emails Posts: 577

    I've seen this behavior too -- you're not imagining it. There's something, somewhere in the bowls of the debugger that can leak a file handle. It's annoying when it happens, but I've never been irritated enough to go debug it myself.

    The ".reload /u" command does mostly work, so I don't think the problem is that the debugger never calls CloseHandle. I think there's just some ancillary function that does its own CreateFile on the pdb, and has some codepath that neglects to close the handle.

    The bug has been reported internally a few times. The last I saw (9 September 2018), nobody from the debugger team had yet tracked down a sufficiently solid repro to root cause the leak. If you have a set of steps that deterministically leaks, I think the debugger team would like to know.

  • Mark_RoddyMark_Roddy Member - All Emails Posts: 4,753

    I preserve everything I need for a productive windbg session in the command line/environment when I start windbg. Centuries of tossing shoes at a windbg that will not let go of a pdb file taught me to not depend on keeping the bag open for extended periods of time. I also never point the bag at the built pdbs. That at least allows you to rebuild without trauma.

  • matt_sykesmatt_sykes Member - All Emails Posts: 298

    Yeah, but you then have to change .kdfiles to point to the newly built pdb.

    It is a PITA, and the latest windbg does it every single time, which makes it unusable. Fortunately I kept an old windbg knocking around.

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