<-- Articles Index / Visual C++ 7.1 (2003) PDB Handle Leak Bug on Windows 7 and up - Unofficial Fix 
Visual C++ 7.1 (2003) PDB Handle Leak Bug on Windows 7 and up - Unofficial Fix

Date: Jul 4, 2016
Last-Modified: Feb 16, 2018

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.


Download Patch #1 Windows 7 Jul 2016 Technical Details
Download Patch #2 (more aggressive) Windows 7 through Windows 10 Feb 2017 UPDATE Technical Details

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?