Home Dashboard Directory Help

VS2010 Locks static library after debug session by jschroedl



Sign in
to vote
Type: Bug
ID: 551819
Opened: 4/16/2010 7:35:10 AM
Access Restriction: Public
User(s) can reproduce this bug


VS2010 is keeping a file lock on a static library in our solution after a debugging session. This prevents us from compiling changes to the library and forces us to close and re-start VS to unlock the file.

This is an issue preventing us from moving to VS2010.
Sign in to post a comment.
Posted by iXquisite on 8/6/2012 at 5:50 PM
Even more interesting: After closing the solution, the DLL is still being locked by devenv.exe. Other than building a debug version, I am not actually debugging but devenv.exe is grabbing a permanent handle on the DLL.

When the solution is open and after running a build, devenv.exe actually holds 3 handles to the DLL at various path locations.

Handle v3.46
Copyright (C) 1997-2011 Mark Russinovich
Sysinternals - www.sysinternals.com
devenv.exe         pid: 18916 type: File         2C34: C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\root\51143815\b4970e60\assembly\dl3\159e93cf\2891807c_1a74cd01\<Project>.DLL
devenv.exe         pid: 18916 type: File         2C38: C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\root51143815\b4970e60\assembly\dl3\159e93cf\2891807c_1a74cd01\<Project>.DLL
devenv.exe         pid: 18916 type: File         51D8: C:\Development\Projects\<Solution>\TRUNK\<Project>\Web\Bin\<Project>.dll

So why would VisualStudio still want to hold a handle on the last DLL even after closing the Solution file?

Seems as if a ton load of time is wasted and Microsoft is not doing anything about it despite making Millions of $$$ revenue on MSDN Subcription licenses. Looks like MS won't care yet again until it loses a fair share of revenue.
Posted by Nico Rieck on 5/30/2012 at 3:20 PM
That this issue is still open after two years is extremely embarassing. Especially because the bug is said to be fixed already. What happened?

Anyway, I posted a new workaround that goes beyond trying to rename the afflicted file. Has been working like a charm for me.
Posted by FleeceDesign on 2/18/2012 at 5:04 PM
Due to this bug people are losing valuable time. I have the same problems and the .NET Framework source stepping is disabled. Please provide a workaround, because it the bug costs money everyday!
Posted by echoDreamz on 1/22/2012 at 4:57 PM
Yes, this is pushing me away from doing Windows development. I am so damn tired of having to close VS wait a few minutes for the file to delete before I can compile again. The workarounds do not work, this is just ridiculous. Maybe I need to start looking at xCode and Mac OS.

There is no excuse for this shit Microsoft, no excuse at all other than you guys simply do not give a crap about VS 2010 anymore, it is "old news" since Windows 8 and the latest VS are all the hype.

Personally I wont be upgrading to this new version, and I will be moving my projects to different development systems such as Delphi, there is no reason I should have to do this, but I am tired of paying money for 3rd rate products.
Posted by Grobbel on 1/20/2012 at 3:21 AM
Over here the problem comes and goes, sometimes deleting/renaming the lib still works, at other times Visual Studio has to be closed. vs2010 ultimate sp1 on windows 7 enterprise, all updates installed.
Posted by echoDreamz on 12/27/2011 at 3:51 PM
Jesus Christ this is extremely annoying! Is there not a fix yet? Come on Microsoft...
Posted by Jan-Patrick on 8/2/2011 at 2:07 AM
Was a fix released in the meantime? I still have this problem, even when .NET Framework source stepping is disabled...
Posted by DonRiesbeck on 5/31/2011 at 7:42 AM
I am experiencing this issue with VS2010 on Windows XP as well.
Posted by russgreen on 4/30/2011 at 12:38 AM
this issue has just started quite randomly on a project which used to be fine. now I have to restart my IDE after every rebuild. VS2010 on Win 7
Posted by Soren Dreijer on 4/28/2011 at 12:20 PM
I'm experiencing this with SP1 as well. I'm able to run the application once at which time devenv.exe acquires locks on all my .lib files. When I close the application the locks are still held by Visual Studio and a restart of the IDE is required.

Turning off "Enable .NET Framework source stepping" fixes the issue, but leaves me having to keep enabling/disabling it whenever I wish to debug into the .NET source.

This corresponds well with the response from Microsoft earlier in this thread that the fault is with SrcSrv.dll. As far as I've been able to tell, SrcSrv.dll is a part of Debugging Tools For Windows:

There ought to exist a fixed srcsrv.dll for this by now, right?
Posted by Frank Heimes on 4/18/2011 at 3:38 AM
The problem still occurs occasionally(!) in VS2010, Service Pack 1.
Most of the time, I can build, debug and build again without file locking problems.
Posted by jschroedl on 3/30/2011 at 10:04 PM
Agreed Trevor. I attached a repro app to the original report and MS agrees it's a bug in Windows. That means it'll take a Windows update to fix.
Posted by Trevor Robinson on 2/5/2011 at 4:36 PM
This occurs for me intermittently but regularly with C++ native code static libs. The issue is present in both the RTM and SP1 beta releases. Unfortunately, I'm not sure how to reproduce it directly.
Posted by jschroedl on 11/30/2010 at 1:46 PM
Any update on when we can expect a fix to be pushed into the OS? This is still a dialy problem for many of us.
Posted by Roger Lipscombe on 11/16/2010 at 7:55 AM
I'm having the same problem with a C++ project, although there are some .NET projects in the solution. I'm a little unclear about why .NET Framework source stepping would affect a C++ project, but I've (just) turned it off anyway. I'll see how I get on.

Any update on when the fix might be available? If turning this setting didn't work for Rob, it might not work for me. Moreover, I'm _not_ disabling symbol servers; I do a _lot_ of post-mortem debugging.
Posted by megaboich on 10/15/2010 at 8:43 AM
Looks like I'm having the same problem in my small open-source project.
I have " .NET framework source stepping" option off, but still after debug i cant build project and have message:

Unable to copy file "obj\Debug\JsParserCore.dll" to "bin\Debug\JsParserCore.dll". The process cannot access the file 'bin\Debug\JsParserCore.dll' because it is being used by another process.

It is WinForms application i migrated from VS2008, i never experienced this issue on VS2008.

Environment: Windows7 with all patches and updates and VS2010 pro.
Posted by Microsoft on 7/30/2010 at 2:30 PM
Hi Rob,

What type of application are you debugging? Also, do you have any symbol servers enabled (if yes, that is the problem, .NET source stepping causes the problem because it enables source servers).

Best Regards,
Visual Studio Debugger
Posted by Rob McKay on 7/30/2010 at 6:39 AM
I'm having this problem even with .NET source stepping turned off.
Posted by Microsoft on 7/24/2010 at 10:47 PM

The file handle leak that results in this behavior is occuring in srcsrv.dll which is a component produced by the Windows team. Windows has currently fixed this issue internally to the Windows team, and we are currently coordinating with them regarding how and when a fix will be available for public release.

Best Regards,
visual Studio Debugger
Posted by jschroedl on 7/16/2010 at 10:36 AM
Any news of progress on this one? This bites me every day. Turning off .NET source stepping is not an option for us.
Posted by jschroedl on 4/30/2010 at 6:07 AM
Thank you for the follow-up.

Yes, indeed, turning off "Enable .NET Framework source stepping" prevents the static library from being locked after the debug.

Posted by Microsoft on 4/29/2010 at 7:04 PM
Thank you for taking the time to report this. While we evaluate a fix for this issue, our initial investigation showed that there is a workaround. If you disable .NET source stepping (under Tools -> Options -> Debugging | uncheck "Enable .NET Framework source stepping") this should prevent the static library from being locked. Could please verify if this workaround prevents the issue from occuring?

Best Regards,
Visual Studio Debugger
Posted by JRosenbaum on 4/22/2010 at 9:23 AM
I also have experienced this locking issue on the compiled executable in the debug folder
Posted by Microsoft on 4/18/2010 at 9:57 PM

Thank you for your feedback, We are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)
Posted by Craig Gemmill on 4/17/2010 at 7:29 PM
I've had this persist even after closing the IDE.
Sign in to post a workaround.
Posted by HelgeKlein on 6/26/2012 at 2:13 PM
This worked for me:

Disable "Enable .NET Framework source stepping".

Source: http://stackoverflow.com/questions/3906404/link-fatal-error-lnk1104-cannot-open-file-d-myproj-exe
Posted by Nico Rieck on 5/30/2012 at 3:17 PM
Renaming the lib file did not work for me (unable to rename). What did work was forcefully closing the hande in the Visual Studio process. See https://github.com/gix/KillHandle for a tool that automates this as a pre-build step.
Posted by echoDreamz on 1/22/2012 at 5:00 PM
Move to a new development tool or IDE. It is obvious there will not be a fix for this. It has almost been 2 years.
Posted by mjeson on 10/1/2011 at 9:21 PM
A workaround is posted in StackOverflow. It is by making a simple console utility to delete the locked file, if fails it renames it. Run this utility as a pre-build event.


File Name Submitted By Submitted On File Size  
DebugLocksLibrary.zip (restricted) 4/16/2010 -