PDB files locked by VS2019

Question

I have moved a large project from VS2015 (Win8.1) to VS2019 (Win 10). It is an MFC application.

The product is an EXE that creates and loads DLLs, which are built in another instance of Visual Studio 2019.

The product was first written in VS2008 and was migrated to VS2015 around the year 2016. The product is quite mature now.

When debugging the EXE, and after loading and unloading one of its DLL projects, I am unable to rebuild the DLL (in the other VS2019 instance) because the PDB file has been locked.

I must first shut down the EXE, which unloads it from the VS2019 debugger. Only then can I re-build the DLL from the other VS2019 instance.

This happened in VS2015, and the fix was to Enable Native Compatibility Mode in Tools -> Options -> Debugging -> General, after which all was good and I could debug BOTH the EXE and the DLL it loaded from the same instance of Visual Studio -- this is critically important to be able to do -- step into the EXE, load the DLL, step into the DLL, unload the DLL, watch the unloading process (debug it). There are some bugs that can only be sussed out this way, and then addressed and fixed. Note that I also needed to set the Debugger Type to Native in the Solution Properties.

In VS2019 I can only do this one time.

After I unload the DLL, Visual Studio still keeps the PDB locked and I cannot re-build the DLL project without shutting down the EXE first, so that VS2019 will release the PDB.

I checked the VS2019 Tools -> Options, etc.... and noticed that there is no longer an option to Use Native Compatibility Mode on the Debugging panel. As with the older version, my Solution Properties are still set identically to use Native debugging type (though I have also tried Auto, with the same results).

How can I do this, so that I do not have to shut down the EXE and re-start it each time I need to load/unload the DLL project while debugging new features?

This is extremely frustrating, as I may need to do this dozens of times (or more) when debugging newly developed features. I have pulled out most of my hair, and searched the internet for answers, without luck, so I am trying this forum in hopes that there is a way to do this.

Or, to confirm that Visual Studio 2019 absolutely will not do this, nor be useful to me.

I still have the old version on VS2015 and Win 8.1 and I would really dislike having to do the "Microsoft Downgrade" option (a la Windows Vista) and go back to Win8.1 just to be able to do my job as efficiently as before I upgraded to VS2019.

Note that the DLL itself fully unloads and is not locked. It can be deleted. Only the PDB file is locked, and of course I need that file to be able to step from the EXE into the loaded DLL during debug sessions. I bring this up because some users of the software accidentally do something bad (usually in the DLL constructor) that causes it to not fully unload. When they try to rebuild the DLL, they get a similar message BUT it involved both the DLL being locked and the PDB being locked.

My issue is only with VS2019 holding on to the PDB file.

It would be magically awesome to get an answer here on how to avoid going backwards to Win8.1 and VS2015.

Thanks,

Will

Answer 1

Hi TianyuSun and David

Thanks so much for your replies: I really appreciate your answers. I have tried enable/disabling multiple options in the Tools... General panel with no luck. I also found that I do not even need to step into the DLL - just load it and immediately unload it - to have the problem.

The good news is that this is not a total deal-breaker for me - at least VS keeps running, and there are no BSODs. It just means that my productivity suffers from the problem that I brought upon myself.

I am not sure that I am ready to upgrade yet again to VS2022 - it took VS2019 many, many revisions just to be barely usable, though I still get the "Visual Studio is Not Responding" and resulting white-window on a regular basis (every single time I run it).

Thanks again for your input and taking time to answer my question!

Have a great day.

Will