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

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

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

matt_sykesmatt_sykes Member - All Emails Posts: 270

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

Comments

  • matt_sykesmatt_sykes Member - All Emails Posts: 270

    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: 7,211

    In which version of WinDbg are you seeing this behavior?

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

    P

    Peter Viscarola
    OSR
    @OSRDrivers

  • matt_sykesmatt_sykes Member - All Emails Posts: 270

    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: 513

    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,305

    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: 270

    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. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
Developing Minifilters 29 July 2019 OSR Seminar Space
Writing WDF Drivers 23 Sept 2019 OSR Seminar Space
Kernel Debugging 21 Oct 2019 OSR Seminar Space
Internals & Software Drivers 18 Nov 2019 Dulles, VA