This page describes an unofficial fix for the PDB handle leak bug that occurs when running Visual C++ 7.1 (2003)
under Windows 7 and up. After debugging a project, the PDB handle is not released, which causes problems when
the project is subsequently built and this file cannot be replaced. Most who have encountered this bug just
restart Visual Studio as a workaround to release the lock, however this gets old in a hurry. You can fix the bug
once and for all by replacing the NatDbgDE.dll in your Visual Studio installation with a version of the patched
NatDbgDE.dll available below:
Since this version of Visual Studio has reached what Microsoft calls, "end of lifetime" more than a decade ago
(with the last of the bugfixes released with Service Pack 1 in 2006), an official fix from Microsoft will never
happen.
The first time you launch Visual Studio 7.1 (2003) on Windows 7 and up, you've probably noticed the initial
message box that informs you the software is incompatible with your version of Windows. Ignoring the
dialog, at least the Visual C++ portion appears to run fine otherwise. It is not until you try and rebuild
your project after a debugging session that the bug appears. Here are some simple steps to reproduce the
bug:
- Debug one of your Visual C++ Win32 projects using the integrated debugger, first setting a breakpoint somewhere such as the main()/WinMain() function.
- After the breakpoint is hit, allow the debugged program to exit.
- Made a simple code change to one of the files in the project.
- Attempt to debug your executable again, allowing the IDE to re-compile and link the changed portions of code.
If you've successfully reproduced the bug, you will hit linker error (LNK1201) when Visual Studio is trying to
replace the project's PDB file. The problem is that the previous debug session still has a handle open to the
PDB file; thus the linker cannot replace it on the subsequent build.
This problem does not occur on Windows XP, which is the last supported operating system for this version of
Visual Studio, but does occur on Windows 7 all the way up through Windows 10.
According to a report, this is only an issue on the 64-bit version of Windows.
A non-patch workaround that ONLY WORKS ON 32-BIT versions of Windows after XP, is to adjust the
"Compatibility" tab of the shortcut properties to the following:
- [X] "Run this program in compatibility for" -> "Windows XP" (or "Windows Vista (Service Pack 2)"
- [X] "Disable visual themes"
- [X] "Run this program as an administrator"
Other workarounds are reported on
StackOverflow
involving running the
SysInternals Handle tool
as a post-build event to forcibly close the handle out from under Visual Studio. The Handle tool is
great (as are most of the SysInternals tools), but I wasn't satisfied with this workaround for multiple reasons:
-
If your project was built on a mapped network-share drive, the .PDB file will still remain "locked"
despite that the handle utility closed the file and subsequently indicated no handles were open.
Obviously portions of the file (or those pertaining to its network mapping) remained in use or were not properly cleaned up.
I found that building my project locally while using the Handle tool does indeed work, but the inability to use a network share wasn't
ideal for my purposes.
-
If you were OK using the "workaround to the workaround" described above (i.e. building your project
locally), you'll still find that executing a "clean" or a "rebuild/clean" on your project fills the output window with
errors related to the .PDB file being locked. Why? These commands happen before the build events can be triggered to forcibly
release the .PDB handle.
-
I prefer not to muck up my project files with ugly OS-specific hacks, especially since I still use
XP on occasion for certain things. I'd still prefer not to have to boot into XP, just to run Visual Studio
7.1.
The ideal way to solve this problem is to have Visual Studio close the handle on its own, within its own
process, even if we have to coerce it to. This should eliminate the side-effects of forcibly closing the handle
in kernel mode, which is what the Handle tool is doing. The nice thing is that the fix described here addresses
the refcounting problem in the most non-invasive way possible, allowing Visual Studio to clean up the handle as
it would just as if it were running under XP without the patch. Not only will the PDB handle get released where
it is supposed to, everything else associated with this object will also get cleaned up.
Questions or Comments?
