PDB remains open after debugging (Windows 10, Visu

Question

Our previous development systems used Windows XP and Windows 7. Debugging C++ DLLs from Visual Studio worked great.

A recent move to Windows 10 has resulted in an annoying problem. We can debug once (using F5), but the 2nd time results in a linker error:

MyProg fatal error LNK1201: error writing to program database 'MyProg.pdb'

Trying to delete the .pdb manually in Explorer while Visual Studio is still open results in the error:

The action can't be completed because the file is open in devenv.exe

It doesn't matter whether you hit a breakpoint or not. Just start debugging once results in the problem. Re-starting Visual Studio resolves the issue (in the sense that you can debug once, but then you get the problem again).

If relevant:

• x86 Visual Studio 2003.NET
• targeting another x86 application
• x64 Windows 10 Pro v1803

Answer 1

In my case it was due to "Process Explorer" program, which was open alongside with my Visual Studio(I used it to check some properties of the exe I've created). After closing it problem solved.

Answer 2

After hunting around for several hours some related, but unanswered, questions were found. Following suggestions in this MSDN article, along with some debugging of my own, this solution works:

• Download FreePDB, a script written by MSDN user Toni76 (thanks Toni!)
• Copy this script to a local folder (say C:\Apps\FreeDPB)
• Download the latest version of SysInternals tool Handle (currently v4.21)
• Copy handle.exe to C:\Apps\FreeDPB
• NB! From the command line, run handle /? once. This is to agree the EULA. The script will not work if you skip this step!
• Open Visual Studio, then Project > Properties > Build Events > Pre-Build Event
• Set Command Line to C:\Apps\FreeDPB\freepdb $(ProjectName)
• Set Description to Delete lock on PDB

...and now you don't need to restart Visual Studio to debug a 2nd time!

From comments, this works with multiple versions of Visual Studio on multiple versions of Windows.

Update

A more radical solution is described here which involves replacing a core Visual Studio DLL (NatDbgDE.dll). This solution only works for Visual Studio 2003 SP1, though.