Visual Studio keeps locking the pdb file even after the dll is released using FreeLibrary - by Starmind Technologies

Status : 

  Won't Fix<br /><br />
		Due to several factors the product team decided to focus its efforts on other items.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.


2
0
Sign in
to vote
ID 1026184 Comments
Status Closed Workarounds
Type Bug Repros 2
Opened 11/10/2014 2:19:41 AM
Access Restriction Public

Description

We run a stand alone application (developed in MFC Visual Studio 2013 Professional Edition) in debugger and load a dll using the function "LoadLibrary". The loaded dll is then released using "FreeLibrary". Now without terminating the debugger if we compile the dll project (in vc++) in a different instance of Visual Studio then at the end of compilation it reports error MSB3073. We find the dll's pdb still remains locked by Visual Studio debugger and thus cannot be overwritten by the fresh compilation. Earlier in Visual Studio 2008 the same feature used to work correctly because the dll's pdb used to get released immediately after "FreeLibrary" was called.

We even tried installing Visual Studio 2013 Update 3 but the issue remains unsolved. Please help ASAP.
Sign in to post a comment.
Posted by Rory Driscoll on 9/24/2015 at 9:43 AM
This no longer works in Visual Studio 2015. Native Edit and Continue is enabled by default, but the debugger still keeps a lock on the PDB after a call to FreeLibrary. Is there any other workaround to this problem?
Posted by Marc [MSFT] on 11/25/2014 at 3:05 PM
Unfortunately, it does not appear that we currently expose that option publically through DTE at this time so there is no programmatic way to control that option. We do have a registry key we read on VS startup but you'd have to restart VS each time.

I'm sorry I don't have a better answer here. We'll look into exposing this and other options publically in a future release.
Posted by Starmind Technologies on 11/25/2014 at 1:21 AM
Can we access "Enable native edit and continue" programmatically and control it as required? if so how? We have accessed all the properties programmatically under Debugging->EnableEditAndContinue but we find that "Enable native edit and continue" cannot be controlled (enabled/ disabled).

Please highlight.

Posted by Andrew [MSFT] on 11/19/2014 at 9:42 AM
Hello,

Visual Studio 2013 by default uses a significantly newer debug engine than Visual Studio 2008 did. I should have been clear that the current implementation has never supported this functionality. If this is a blocker for you, you can fall back to the previous engine by enabling native edit and continue under Tools -> Options -> Debugging -> Edit and Continue (note you will lose any new functionality added to native debugging such as natvis support).

My previous comment to file a suggestion on User Voice is still applicable, as at this time we do not have the resources to add this capability in either Visual Studio 2013 or 2015, so would like to understand how much need/interest there is in the debugger community for this functionality.

Best Regards,
Andrew Hall
Visual Studio Debugger
Posted by Starmind Technologies on 11/18/2014 at 10:34 PM
We did not encounter any pdb locking issue while compiling in Visual Studio 2008. The issue arose when we migrated to Visual Studio 2013. Attached Demo-VS2008.zip and Demo-VS2013.zip in support of our observation. Please follow these steps for both the zip files in order to reproduce the issue:

1. Extract both Demo-VS2013/08.Zip. There are two projects inside
    a. SampleMFCDLL: A standard MFC Dll Project
    b. Try: A Standard MFC application project that loads and unloads SampleMFCDLL.dll

2. Open both the projects in two different instances of Visual Studio 2008/2013

3. Rebuild SampleMFCDLL Project. This will copy SampleMFCDLL.dll and SampleMFCDLL.pdb inside the Demo folder
through post build event

4. Build Try project and press F5 to start debugging.

5. On the Try dialog there is a button "Press once to Load and Unload SampleMFCDLL.dll". Pressing that button
will load Demo\SampleMFCDLL.dll using the function "LoadLibrary" and therafter will release it using the library "FreeLibrary".

6. In the output window of the Try project you will find that SampleMFCDLL.dll is loaded and then released.

7. Now Without stopping the debugger in Try Project Rebuild SampleMFCDLL project.

8. There will be build failure while copying SampleMFCDLL.dll in case of VS 2013 build only. SampleMFCDLL.dll gets compiled successfully in VS2008.

Please peruse the projects and suggest.
Posted by Andrew [MSFT] on 11/18/2014 at 12:10 PM
Thank you for taking the time to report this issue. Unfortunately the Visual Studio debugger has never supported unloading a pdb when the binary is unloaded from the process, it has always required that debugging be stopped. As such, this is not a feature that we are able to implement at this time. However please create a suggestion on Visual Studio's User Voice site (http://visualstudio.uservoice.com/), as that allows us to understand the overall interest from the community, and prioritize this request against other feature requests in the debugger.

Best Regards,
Andrew Hall
Visual Studio Debugger
Posted by Starmind Technologies on 11/11/2014 at 4:00 AM
Added Demo.zip with the attachments. Please follow these steps in order to reproduce the issue:

1. Extract Demo.Zip. There are two projects inside
    a. SampleMFCDLL: A standard MFC Dll Project
    b. Try: A Standard MFC application project that loads and unloads SampleMFCDLL.dll

2. Open both the projects in two different instances of Visual Studio 2013

3. Rebuild SampleMFCDLL Project. This will copy SampleMFCDLL.dll and SampleMFCDLL.pdb inside the Demo folder
through post build event

4. Build Try project and press F5 to start debugging.

5. On the Try dialog there is a button "Press once to Load and Unload SampleMFCDLL.dll". Pressing that button
will load Demo\SampleMFCDLL.dll using the function "LoadLibrary" and therafter will release it using the library "FreeLibrary".

6. In the output window of the Try project you will find that SampleMFCDLL.dll is loaded and then released.

7. Now Without stopping the debugger in Try Project Rebuild SampleMFCDLL project.

8. There will be build failure while copying SampleMFCDLL.dll.

9. Stop the debugger in the Try project and again try to rebuild SampleMFCDLL. This time the build will be successful
Posted by Microsoft on 11/10/2014 at 10:35 PM
Thank you for submitting feedback on Visual Studio and .NET Framework.

In order to efficiently investigate and reproduce this issue, we are requesting additional information outlined below.

Could you please give us a demo project so that we can conduct further research?

Please submit this information to us within 4 business days. We look forward to hearing from you with this information. If you require immediate assistance with this issue, please contact product support at <http://support.microsoft.com/ph/1117>.
Posted by Microsoft on 11/10/2014 at 3:10 AM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If you require immediate assistance with this issue, please contact product support at http://support.microsoft.com/ph/1117.