Debugger hangs VS for a long time when coming out of debug mode - by CoolDadTx

Status : 

  Fixed<br /><br />
		This item has been fixed in the current or upcoming version of this product.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 504538 Comments
Status Closed Workarounds
Type Bug Repros 59
Opened 10/27/2009 10:35:37 AM
Duplicates 524683 Access Restriction Public


The debugger is frequently (read: once an hour or more) hanging VS for a long period of time (read: over a minute) when debugging stops.  Unfortunately it is not related to any particular action that I can see.  I've noticed it a lot when interacting with the Output window while debugging but I can replicate it without the Output window as well.  Unfortunately it is proving to be very difficult to narrow down.  I'm reporting this in hopes that it is a known issue or that there is a suggestion on how to diagnose what is going on so it can be corrected.
Sign in to post a comment.
Posted by Phil Burlison on 7/26/2012 at 5:46 PM
As someone else recommended, I was able to eliminate the problem in Visual Studio 2008 by opening the solution directly in Explorer instead of clicking on the Project Name in Visual Studio Start page. What the connection could possibly be escapes me.

Posted by Eytan Tzakoni on 2/15/2012 at 1:32 AM
apparently it's solved with KB2106584
Posted by Eytan Tzakoni on 2/15/2012 at 1:08 AM
I have also this problem when i start debug with vs2010 and when i stop debug. what I have to do?

Posted by Bernardo Salazar on 9/30/2011 at 2:43 PM
The thing is only getting worse. Now disabled intellitrace, installed KB2106584 and nothing. HELP!
Posted by Bernardo Salazar on 9/30/2011 at 2:24 PM
I think that i solved the problem in my VS2010 installation. I removed RTFTOHTML utility (used to copy a selected text in IDE, and paste the code in MSDN forums) and VS debug return to normal behavior. If persist the problem i write again.
Posted by Tristan2 on 2/15/2011 at 11:40 AM
Installed hotfix KB2106584. VS still hangs after exiting debugger. Task manager does not list VS as 'Not Responding'; however, VS no longer redraws itself.
Posted by Andrew [MSFT] on 10/11/2010 at 10:38 AM

This bug is for some reason showing as "Active" on this connect site even though it has been closed for over 10 months.

If you are encountering this issue, please try installing a recently released hotfix from the debugger team from

If that does not address the hang issue, please email with the details of your issue and someone will follow up with you to get more information about your problem and try to help diagnose the cause.

Best Regards,
Visual Studio Debugger
Posted by Pat Piccolo on 9/15/2010 at 8:42 AM
I started seeing this problem after installing some of the axTools into Visual Studio (CodeMap, CodeSmart, etc). Check to see if you have these tools installed (Tools/Extension Manager). If so, try deleting all .vs10x files (so far as I can tell, these are settings files, much like VS's own SUO files). Once I removed the .vs10x files, and reloaded my solution, my debugging delay went away. The axTools will recreate the .vs10x files.
Posted by Jon Theriault on 9/2/2010 at 6:15 AM
I've tried disabling IntelliTrace but that doesn't resolve the issue. Disabling the Visual Studio Hosting Process for the project does the debugger stop in the normal amount of time but the delay for the debugger to start up is now just as long as the delay was with the vshost enabled.

I'm running XP SP3. Please let me know if there's anything I can do or try that would help.
Posted by Jon Theriault on 9/1/2010 at 4:03 AM
I'm also getting the hang. I tried running the Performance Diagnostic tool but I just get a "Starting Xperf profiling. Please wait..." message in the status bar and the progress bar keeps spinning. After ten minutes I give up. I've tried it a few times.
Posted by Raul Herrero on 8/10/2010 at 11:31 AM
I have encountered this problem in past versions of the product and just now got it with VS2010 Version 10.0.30319.1 RTM.
I am working on a standard ASP.Net application and am just now experiencing the problem whenever I jump into the source view of an aspx page that I just applied a large CSS file to.
I think what is happening is that I have the source view as the current page when I start debugging. So when I am done, the page becomes active and the IDE just hangs for minutes. (It seems to be running through some kind of process of verifying the CSS and/or applying the styles to the layout or who knows what it’s doing?)
Posted by Jacob Page on 7/13/2010 at 5:52 PM
This happens all the time for me in my Silverlight 4 application. When watching VS in task manager, I see it ballooning to over a gigabyte in memory usage as this occurs. This incidentally frequently crashes VS for me if it takes up too much memory (I'm forced to run this under Windows XP, 32-bit). I think this has to do with the XAML designer since opening XAML in the designer causes tons of memory to get allocated, and I've only seen the coming-out-of-debug thing happen when I have XAML files open, even when they're not opened in designer mode.
Posted by Dave Rathbone on 6/16/2010 at 5:52 AM
I have the same bug in VS2008 and on VS2010. My program runs ok but after clicking debug hangs for 10 to 12 mins. My thought is that I have envoked multi threads that have not finished running, when my VB code exits during debug break. I made my code tidy up all threads I started via my own exit command and this works 9 times out of 10.
Q? Does VS clean up the thread pool after a debug exit to the state before the user ran his application?

Its making me feel that multi threading is still handled by Ronnie McDonald with Intel doing the hardware sales!
Posted by Jason Lavigne on 6/9/2010 at 9:43 AM
Any suggestions for this yet? I am getting the same thing in Version 10.0.30319.1 RTMRel, the interface stops responding to the mouse. The odd part is not everything stops responding to the mouse click, for example I can edit a .cs file just fine and the mouse works, but when I switch to editing a .aspx file, no mouse. A restart of VS does solve it, for a while, but then it does return. Another example is some buttons stop responding but other parts of the interface is ok. Could this be a WPF issue??
Posted by cslater on 5/24/2010 at 2:38 PM
Still happens with the GM version.

I can't believe you guys at MSFT have so much trouble reproducing this issue. Almost everyone I know using VS2010 has run into this issue.

I hope disabling the hosting app helps work around the issue
Posted by Ray Dyce on 5/10/2010 at 1:20 AM
This hunk of crap still has the problem... should have stayed with the only EVER use SP1 approach..

Posted by Andrew [MSFT] on 4/19/2010 at 6:07 PM

Could you please follow the instructions above for collecting a performance trace? (repeated here):
Download and install the Visual Studio 2010 Diagnostic tool located at: Once you have installed the tool:
-    Open your project in Visual Studio (do not begin debugging yet)
-    Open the “PerformanceDiagnostics” application that was just installed
-    On the ETW/Xperf tab, select ‘Default’, click ‘Start Profiler’
-    Reproduce the hang
-    Click ‘End Profiler’, wait
-    Click ‘View Profiles’; the newest .etl file is the file that we are interested in

and upload it to the following workspace:
Password: fwBud@xV{S

Thank you,
Visual Studio Debugger
Posted by mharen on 4/17/2010 at 11:59 AM
I'm seeing this on VS2010 Pro RTM, just installed a few days ago
Posted by Andrew [MSFT] on 1/6/2010 at 5:44 PM

We believe that we have determined the cause of this hang and fixed the issue. We have created a pre-Release Candidate build that we would like to provide to anyone experiencing this issue to be sure that we have fully fixed the problem. Note: In order to obtain this build you will be required to sign a Microsoft Non-Disclosure Agreement (NDA).

If you are interested in obtaining and evaluating the build with the fix for this issue, please contact me at and I will provide further details.

Best Regards,
Andrew Hall
Visual Studio Debugger
Posted by Andrew [MSFT] on 12/4/2009 at 10:50 AM
One clarification, the performance tool will install to:
"C:\Program Files\Microsoft\PerformanceDiagnostics"

or for a 64 bit version of Windows:
"C:\Program Files (x86)\Microsoft\PerformanceDiagnostics"
Posted by Andrew [MSFT] on 12/3/2009 at 5:30 PM

It is a top priority for the IntelliTrace team to address this. Unfortunately we are not able to reproduce this issue in our internal labs. Therefore we need the help of customers experiencing this issue to help us determine the exact cause(s), and verify that we fix it appropriately for the RTM release of Visual Studio 2010. Our ask from customers who are willing to assist us, is that you collect ETW traces using the Visual Studio 2010 Diagnostic tool located at: Once you have installed the tool:
-    Open your project in Visual Studio (do not begin debugging yet)
-    Open the “PerformanceDiagnostics” application that was just installed
-    On the ETW/Xperf tab, select ‘Default’, click ‘Start Profiler’
-    Reproduce the hang
-    Click ‘End Profiler’, wait
-    Click ‘View Profiles’; the newest .etl file is the file that we are interested in

Then, please open the Windows Event Viewer (on Vista and above typing “Event Viewer” into the Start Menu search bar will bring this up), and under Windows Logs -> Application see if any of the recent events are for the VSTraceLog.exe process.

Once you have checked the Event Viewer, and collected the traces, please email me at with the Windows Event Viewer information, and to let me know you have traces. I will then provide you with a secure workspace to upload the traces to.

Thank you very much for your assistance on this issue,
Andrew Hall
Program Manager
Visual Studio Debugger
Posted by Sebastien Bach on 12/3/2009 at 2:34 AM
i'm tired with this bug... please help us
Posted by Andrew [MSFT] on 12/1/2009 at 5:32 PM

Thank you all very much for your engagement on this issue. The hang reported in this bug is the result of IntelliTrace hanging for up to 2 minutes when debugging is stopped. To answer one of the questions previously posted, the feedback item 498240 ( is not the same issue that is reported here. 498240 is an IDE/Project System issue which causes the “Visual Studio is waiting for an internal operation to complete” message.

Unfortunately releasing a QFE for a Beta release is not possible at this time, however there is a simple workaround which is to disable IntelliTrace. To disable IntelliTrace, navigate to Tools->Options->IntelliTrace, and uncheck “Enable IntelliTrace”. Due to the difficult nature of diagnosing the exact cause of hangs, we are interested in working with anyone who appears to be experiencing this issue to verify that this problem has indeed been addressed for the final release of Visual Studio 2010.

Please contact me at if you have any further questions about this issue or want to provide additional feedback.

Best Regards,
Andrew Hall
Program Manager
Visual Studio Debugger
Posted by dotScience on 11/24/2009 at 7:24 PM
I can now reliably confirm the amount VS 2010 beta 2 spends "frozen" has increased dramatically after installing the Office Pro 2010 beta, and the Visio Pro 2010 beta.

I estimate it is now unusable more than 60% of the time. And having two different dialogs pop-up (sometimes), one in a silvery grey coming up from the taskbar area, and another larger one with an option to "Continue Waiting" do not help at all.
Posted by Ralph57Cbk on 11/22/2009 at 2:17 AM
I agree wit UNT1TLED. We seriously need a Patch or Hot fix otherwise VS2010 Beta 2 is history!
Posted by dotScience on 11/21/2009 at 9:20 PM
After installing the Office 2010 Pro beta, and the Visio 2010 beta, and all their associated updates, it seems like VS 2010 beta two hangs even more frequently (of course, I don't have hard statistics); my perception is VS 2010 beta two is now unavailable more than 50% of the time.
Posted by Jarem on 11/20/2009 at 3:46 PM
Oh you fixed it? That's great. I'm happy for you. Can we get a patch or something so we can continue to find more bugs?
Posted by CoolDadTx on 11/20/2009 at 6:30 AM
I'd definitely like to see a QFE for this so we can confirm the fix. Given that it was so hard for MS to duplicate we want to make sure that it is the problem that was fixed. If this issue gets into RTM then MS is going to have to release a QFE shortly after release before the backlash gets intolerable. It is truly a showstopping bug.
Posted by dotScience on 11/19/2009 at 11:14 PM
"Thank you for your feedback. We have resolved this issue and the RTM build should be fixed. "

How about a hot-fix for those of us for whom VS 2010 beta 2 is unusable for at least twenty minutes per hour.

thanks, Bill
Posted by JGTM on 11/19/2009 at 10:21 PM
Glad to know that the issue is reproduced and fixed, finally.

Could you please further confirm that the issue reported in FeedbackID=498240 is the same as (or highly relevant to) this one? IMHO, these bugs are really the killer issues for preventing people for evaluating the beta 2 and even final product (if they're still there). Considering the next release drop (maybe the one RC or directly RTM) will be hold for nearly three to four months, and there are stilll many things for us to explore for issues, this hanging bug really hurt our productivity heavily. Is there possible to give us a QFE to address the issue locally?

Posted by Justin [MSFT] on 11/19/2009 at 6:01 PM
Thank you for your feedback. We have resolved this issue and the RTM build should be fixed.
Posted by JGTM on 11/16/2009 at 7:14 PM
I think this bug is the same one as this:

Maybe you guys could possibly merge there two issues and pay more attention to this real show stopper.
Posted by Asbjørn on 11/15/2009 at 5:45 AM
Sorry for the extra post, but I wanted to add that for me it seems to be linked to the XAML editor. If have a XAML file in the foreground and have made edits, VS will freeze when debugging.
Posted by Asbjørn on 11/15/2009 at 5:35 AM
I can reproduce this consistently with or without the hosting process enabled. I'm running Windows 7 RTM x64. I have a project that does this all the time. I can send it along if needed. Just let me know.
Posted by Ralph57Cbk on 11/14/2009 at 6:30 AM
I too am expieriencing this problem. The IDE hangs perioically (not always), when closing Windows Forms applications which were started with debugging (F5).
Posted by Wokket on 11/10/2009 at 6:18 PM
I'm also seeing this, with a very simple WPF application.

Running Win7 RTM 32bit under a Native boot VHD.

Breaking into the process from another VS instance is generally showing threads locked up with tracing/logging related call stacks.

[In a sleep, wait, or join]    
mscorlib.dll!System.Threading.WaitHandle.InternalWaitOne(System.Runtime.InteropServices.SafeHandle waitableSafeHandle, long millisecondsTimeout, bool hasThreadAffinity, bool exitContext) + 0x2b bytes    
mscorlib.dll!System.Threading.WaitHandle.WaitOne(int millisecondsTimeout, bool exitContext) + 0x2d bytes    
Microsoft.VisualStudio.TraceLog.dll!Microsoft.VisualStudio.Diagnostics.Logging.QueuedIpcPipeClient.WaitForConnect() + 0x4b bytes    
Microsoft.VisualStudio.TraceLog.dll!Microsoft.VisualStudio.Diagnostics.Logging.QueuedIpcPipeClient.Add(byte* data = 0x2d16f4f0, int msgLen = 258) + 0x3d bytes    
Microsoft.VisualStudio.TraceDebugger.dll!Microsoft.VisualStudio.TraceDebugger.DebuggerEventRecorder.HandleModuleLoad(Microsoft.VisualStudio.TraceDebugger.ModuleLoadNotifyEvent moduleLoadNotifyEvent) + 0x119 bytes    
Microsoft.VisualStudio.TraceDebugger.dll!Microsoft.VisualStudio.TraceDebugger.ModuleLoadNotifyEvent.HandleNotifyEvent(Microsoft.VisualStudio.TraceDebugger.Debuggee debuggee) + 0x1c bytes    
Microsoft.VisualStudio.TraceDebugger.dll!Microsoft.VisualStudio.TraceDebugger.EngineNotifyHandler._NotifyHandleEvents(uint dwEventTicket = 32) + 0x121 bytes    
Microsoft.VisualStudio.TraceDebugger.dll!Microsoft.VisualStudio.TraceDebugger.EngineNotifyHandler.NotifyHandleEvents.AnonymousMethod__21() + 0xd bytes    
Microsoft.VisualStudio.TraceLog.dll!Microsoft.VisualStudio.Diagnostics.Common.ILExceptionFilter.Invoke(Microsoft.VisualStudio.Diagnostics.Common.ILExceptionFilter.InvocationTarget target, Microsoft.VisualStudio.Diagnostics.Common.ILExceptionFilter.FilterFunction predicate = {Method = Cannot evaluate expression because the current thread is in a sleep, wait, or join}, Microsoft.VisualStudio.Diagnostics.Common.ILExceptionFilter.HandlerFunction catchBlock = {Method = Cannot evaluate expression because the current thread is in a sleep, wait, or join}) + 0x29 bytes    
Microsoft.VisualStudio.TraceLog.dll!Microsoft.VisualStudio.Diagnostics.Common.ExceptionHelper.Invoke(Microsoft.VisualStudio.Diagnostics.Common.ILExceptionFilter.InvocationTarget target) + 0x56 bytes    

Disabling the VS Hosting process has certainly improved matters. I'll report back if I can repro with the hosting process disabled.
Posted by CoolDadTx on 11/10/2009 at 10:10 AM
It's taken a while but I've finally seen VS lock up again when going into debug even when the host process is disabled. I'm attaching the output window contents from debugging VS directly. As before, VS sits there for a while and periodically generates first chance exceptions. It eventually generates a few exceptions and recovers.

Out of curiosity I set the debugger to break when the exception 0xe0434352 was thrown because that is where VS seems to be sitting for a while. It was being thrown by the trace log infrastructure. I'm attaching the callstack from one such exception.
Posted by Jarem on 11/9/2009 at 7:54 AM
Having this problem as well. Win7 x64.
Posted by Ryan Mrachek on 11/8/2009 at 5:41 AM
This problem happens almost everytime for me. I'm running Win7 64 fairly clean with just the beat bits installed. I've made a process dump or two please let me know if you're interested.

btw- This problem is a road block for seriously using 2010.
Posted by CoolDadTx on 11/5/2009 at 8:18 PM
I've posted all the scenarios I see it in. It is reproducible by quite a few people and the debugger logs show exceptions and what appears to be timeouts in COM calls. Assuming your fixes involve those areas then it might be resolved but there is no real way to tell. I've seen it with VB and C# apps whether they were WinForms or WPF. They can be new or existing projects. The key seems to be continually stopping and restarting the debugger over time. It does seem to be related to the vshost process.

What can we do to better provide you the debugging information and/or verify that your solution solves the problem? I've sent the call stack and debugger output for the scenarios I've seen so hopefully they've helped you out some. Nevertheless this problem is not isolated to one person and it is a breaking issue that will prevent folks from upgrading. We need to make sure it is fixed before the final release. So whatever we can do to help we'll try.
Posted by Microsoft on 11/5/2009 at 3:36 PM

We are currenly unable to reproduce this issue. We've made a few performance optimizations since Beta 2 and this may have solved your problem. Is there a specific solution that you see this with and would like for us to test out?

Visual Studio Debugger Team
Posted by CoolDadTx on 11/5/2009 at 6:55 AM
I've been running a day with the host disabled and haven't had any more lock ups. However I have experienced two other (potentially unrelated) issues.

Firstly I created a brand new C# WPF app. Before the designer even finished initializing to show me the main window VS hung. The host process had already been started. I hadn't seen it hang outside the debugger until this point.

Today I created a brand new VB WPF app and started into debug mode. The build succeeded and VS hung. What makes this a little different is that VS had created two host processes and two VSTraceLog processes whereas it normally only creates one when you first open/create the project.
Posted by David131 on 11/4/2009 at 11:15 AM
I disabled the hosting process and it does see to have an impact on the frequency of this problem. Once I did that though it now hangs sometimes when trying to start the debug process.
Posted by CoolDadTx on 11/4/2009 at 6:18 AM
Sorry for the delay. I've been in unmanaged land for a few days (which doesn't seem to exhibit the problem). I ran with the host enabled until the problem replicated. Then I disabled the host and continued running. It seemed to help although VS still had a noticeable delay. I'm going to run without the host for a day and see if the problem occurs again.
Posted by steveloft on 11/3/2009 at 12:59 PM
I get this problem too. VS 2010 hangs after debugging - mine is a WPF application. I have to use task manager to kill Visual Studio. Disabling the hosting process does make the problem go away.

Posted by Izzy [MSFT] on 11/1/2009 at 10:50 PM
Hi -

Thanks for reporting this issue. We have not been able to reproduce this issue internally, so we will need to do some further investigation to see what is going on. As a starting point in the investigation, can you see if this issue also reproduces when you disable the Visual Studio Hosting Process? To disable this, go to Project Properties for the project you're debugging, go to the Debug tab, and all the way at the bottom you'll see a checkbox "Enable the Visual Studio hosting process." Can you uncheck this and see if the problem goes away? Let us know.

-- Izzy

Izzy Gryko
Lead Software Design Engineer
Microsoft Visual Studio Platform Development
Posted by Vector Hawk on 10/30/2009 at 8:29 AM
I also have this issue. My application uses a unbound DataGrid and several Drop Downs. After it freezes, I have to use Task Manager to terminate VS 2010.
Posted by David131 on 10/30/2009 at 7:49 AM
I am also experiencing this problem in VS2010 with a new WinForms application. It is happening several times an hour and usually requires terminating the VS2010 task and restarting the application. I have not been able to regain control of VS2010 after stopping the debug process.
Posted by Microsoft on 10/29/2009 at 12:36 AM
Thanks for your feedback.

We are rerouting this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.

Thank you