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

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

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.

In which version of WinDbg are you seeing this behavior?

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

P

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.

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.

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.

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.