Home Dashboard Directory Help
Search

Microsoft Visual studio is waiting for an internal operation to complete. by HariDD


Status: 

Active


107
0
Sign in
to vote
Type: Bug
ID: 498240
Opened: 10/17/2009 12:39:06 AM
Access Restriction: Public
12
Workaround(s)
view
62
User(s) can reproduce this bug

Description

I get this message more often then I think I should "Microsoft Visual studio is waiting for an internal operation to complete. If you regularly encounter this delay during normal usage, please report this problem to Microsoft."

The whole IDE seems to hang after this and although if becomes responsive again after some time (5-10 minutes) its really annoying.
Details
Sign in to post a comment.
Posted by Robin Ainscough on 1/29/2014 at 8:13 AM
I can duplicate this problem also:

1. VS 2012 Ultimate with TFS source control
2. SL5 & Web Project & .NET 4.0 framework
3. Debug, inspect an object that has at least 4 hierarchical levels to it, the 4th drop down just freeze.

Note: does NOT trigger a "NOT RESPONDING" message, appears to be stuck in some recursive loop of object evaluation.
Posted by SamCPP on 1/8/2014 at 9:56 PM
I still receive this issue in VS2012. Currently using VS2013 more actively. Will keep an eye on it and will post if the issue happens a lot there too.

In VS2012, I've noticed the issue occurs on simple C# WinForms code editing operations. Simple things like using code completion/intellisense then hitting enter to confirm a property or even creating a closing brace for a statement of some description (e.g. using/if/while/for/foreach).
Posted by Microsoft on 6/14/2012 at 4:14 PM
Hi folks,

This feedback really represents a suite of performance items, as the title is a fairly generic message we send when VS hangs. We have received a ton of feedback on performance, and have invested heavily in improving it, fixing a number of issues. Visual Studio 2012 RC is available here: http://msdn.microsoft.com/en-US/vstudio/ and has many of those fixes incorporated.

These types of issues are very hard to reproduce, and we want to get to the root of the issue. So we've created the Visual Studio Feedback Tool, which grabs a trace, and helps us find what is really going on. If you can use that tool: https://login.live.com/login.srf?wa=wsignin1.0&wtrealm=visualstudiogallery.msdn.microsoft.com&wreply=https%3a%2f%2fvisualstudiogallery.msdn.microsoft.com%2ff8a5aac8-0418-4f88-9d34-bdbe2c4cfe72%3fstoAI%3d10&wp=MBI_FED_SSL&wlcxt=microsoft%24microsoft%24microsoft it will greatly help us in finding out what is causing the hang. It will file a bug on your behalf, with data that helps us reproduce the issue.

Also, we've had a few hiccups with Connect, and we have made several changes that help us better reproduce issues, and respond in a more timely fashion. The issues have been with the system, and routing of bugs. My apologies for the extended time in addressing issues, and hopefully you will find better experiences using Connect now.

thanks,
Doug Turnure
Visual Studio PM
Posted by CK79 on 5/31/2012 at 12:40 AM
I get this message regularly.
Usually Visual Studio 2010 crashes two or three times a day, which is pretty annoying.
Is there any known fix for this problem? It would be nice if Visual Studio 2010 were much more stable.
Posted by Matt Fricker on 3/21/2012 at 7:47 AM
I am running Visual Studio 2010 in Windows 7 Professional 64-Bit in VMware 4.1.1 running on 2 processors and roughly 2GB of ram. On debugging a simple application Visual Studio seems to hang/unresponsive. I then get a bubble message informing me that "Visual Studio is busy waiting for an internal operation to complete". After a few minutes I then receive the following prompt:

"A fatal error has occurred and debugging needs to be terminated. For more details, please see the Microsoft Help and Support web site. HRESULT=0x80131c08. ErrorCode=0x0.. HRESULT=0x80131c08. ErrorCode=0x0."

Saw on another forum that this may have something to do with memory or something so upped the VM to 4GB and still have the same problem. Have noticed this happens in Visual Studio 11 Beta too...any update/fix or config change that I need to make?
Posted by wimk on 3/21/2012 at 3:49 AM
this happens often, somewhere VS (of the NetFramework) stacks/takes/stays in memory. It looks like the memory uses only increases and never (or less) decreases...After a reset it's gone!
Posted by old_geek on 1/27/2012 at 6:42 AM
Had it happen yesterday, VS 2010 sp1, i5 3.6 GHz. Had to kill VS and reboot computer to clean things up. It is definitely an issue with multithreading in VS. Guess micro$soft expects us all to buy supercomputers...still think they would produce dogware.

BTW, two instances of MsBuild.exe ALWAYS persist even when VS is closed.
Posted by BrownSwagger on 1/18/2012 at 9:55 AM
For us it is sometimes Perforce integration. Sometimes its intellisense parsing. Sometimes its Visual Assist parsing. Sometimes its unclear what the UI thread is blocked on but if you wait long enough it usually comes back. For me, I can't waste time waiting for my IDE to come back so it gets nuked, everyday at least once, usually more like 3 or 4 times a day.

I completely agree with:

"Please -Please -Please -Please -Please -Please -Please -Please -Please -
Do a design review on your thread scheduling and synchronization!"
Posted by Frank Heimes on 8/10/2011 at 5:20 AM
BTW.: The IDE is frozen for 15 minutes now. I'll shoot it with the Process Explorer - as so often.
- Sigh -
Posted by Frank Heimes on 8/10/2011 at 5:18 AM
On my host, when I save a file, a thread in module "vcpkg.dll" chokes one of my cores at 100% CPU load while executing symbol_at_cursor.

As the name is suggesting, it's trying hard to resolve a symbol - obviously scanning the entire internet on the fly!

I don't care if it does - I have three other cores to do work. HOWEVER: The big issue here is that this dreaded background thread is holding a resource while doing this and the main thread is waiting for that resource. That's what makes the IDE freeze.

Please -Please -Please -Please -Please -Please -Please -Please -Please -
Do a design review on your thread scheduling and synchronization!
Posted by Eduardo H. Marques on 6/9/2011 at 4:56 AM
I have the same issue. When i will go debug my project, This message appears and it does not return.
In my case: For Each Item As DataRow In tableschema.Rows
Whenever I see information For Each Item As DataRow In tableschema.Rows
, I move the cursor over the item and I will see tableschema hangs there. I've given up doing so because crashes every time, I've tested on 3 computers and same thing.
Posted by John Boncek on 5/26/2011 at 12:19 PM
Still happening frequently in Visual Studio 2010, Service Pack 1, on Windows XP Pro, Service Pack 3.
Posted by Luna_0609 on 4/6/2011 at 1:20 AM
I have the same issue. When typing text (no matter what), Visual Studio blocks. Sometimes it suddenly shows strange things like, the Configuration Manager, switches to Full Screen-mode etc. I have this issue almost every 5 minutes, very frustrating..
When I kill the process and restart Visual Studio, no question is asked to recover files. So I lost my recent changes to the code.
I'm using Visual Studio 2010 Pro on Windows XP
Any help would be appreciated..
Posted by Bob990099 on 2/16/2011 at 9:56 PM
I have also experienced this problem. Am using the Academic version, have ReSharper 5.1 installed. Working on an ASP.Net MVC2 application. Generally, happens about once a week for me, doing just the usual thing. Can't reproduce on a consistent basis, and usually have to hard-reboot my system to shut-down and start-up again. Extremely annoying. Haven't tried any of the workarounds (yet) -- hopefully they work so that I don't have to do a system shutdown.
Posted by Rishchand on 12/28/2010 at 8:01 PM
I had the similar issue. I was not able create a new windows forms application. Visual studio goes busy on an internal process and never came back.

I restarted the machine and it worked.
Posted by Radek Tetík on 12/21/2010 at 7:35 AM
I'm using C++ and MFC. Opening a method form the class view is slow, looking up symbol definitions too, often symbols are not found etc. Very often I get the busy message. Terrible. I have been looking forward to VS 2010 after the experience with VS 2008. Sadly it's even worse.
Posted by Andy Lite on 8/5/2010 at 12:18 AM
I suspect that this problem may be about too many GDI objects in devenv.exe process. Actually I had to raise the limit from default 10000 to avoid out of memory crashes, but I am not sure how well system deals with too many of them.
Posted by Thomas.H on 7/22/2010 at 11:25 PM
Same with VS 2010 RTM. Absolutely unusable. It's annoying, we waited two years to get a faster VS 2010 after switching to VS 2008 and now everything is slower(C++, using MFC).
We will make some dumps if you want to investigate this somewhat deeper.
Posted by AWBauman on 7/8/2010 at 6:29 AM
I am getting this message roughly once a day and it is really getting frustrating. A lot of times I am doing nothing more than working in a ASP.NET code-behind like today. Other days it can be while debugging or working in a aspx/ascx page.

When I do get the message it requires a restart of Visual Studio.

Any solution in the works for this yet?
Posted by AkkiOrama on 2/11/2010 at 6:24 PM
I'm experiencing the same and really getting frustrated with it. This message appears in my case especially when I try to switch between source and design or source to split mode. It works fine in XP between problem is occurring in WIN 7. So solutions guys?
Posted by Nic Martel on 12/13/2009 at 3:36 PM
.
Update... I am 'quoting' the previous post so that all the info can be found in 1 post.
---- PREVIOUS POST (1) ---------------------------------------------------------------------------------------------
Posted by Nic Martel on 12/13/2009 at 11:48 AM
.
I seem to get that when I *disable breakpoints* while in a debugging sequence/session.
I will monitor this issue and edit or post again.

When the dialog pops up it has 3 options, *Switch*, *Continue*, *Cancel* <-- Cancel is disabled!!!
I have never waited 5 or 10 minutes to see if recovers on its own...

Killing the *vshost* is of no use to me since it no longer shows in the *task manager*... in *WINDOWS 7*...
That is what I used to do on my XP Pro... and it did not work 100%. I had to kill several *vshost* instances...

So far all I know to do is to kill *devenv*... short of freakin REBOOTING!
Is *taskhost.exe* the *vshost* equivalent on *WIN 7*?

---- NEW POST (2) ---------------------------------------------------------------------------------------------
I tried to get it to break repeatedly by enabling/disabling breakpoints... was unsuccessful.
...thus disregard previous post statement that refers to breakpoints. All the rest in previous post still stands.

But while in a debugging session, I can cause the problem by changing the RegExp string in my
javascript validation function, in the Immediate Window (reason: adding/testing new features)
or by simply stepping thru the code (for loop that sweeps thru all text objects on form) and eventually
it fails on one of them, not always the same one. ( that already let’s me know it is DEBUGGER BUG)
so...
regex is set into variable
LINE 1: var regexString = "^[A-Z-a-z0-9_ ]{0,50}$"; (verified regex string that works.)
LINE 2: var thismask = RegExp(regexString); // Debugger's next statement is on this line at breakpoint
LINE 3: return thismask.test(textPhrase);

I bring up the Immediate window and execute:
regexString = "^[A-Z-a-z0-9 ]{0,50}$"; //note that I took the _ out, after the 9
or I set the regexString in the WATCH window and modify its value in the right-pane.
When I click on the VS window… it is already in its dead-loop.
I can tell before I even click on it that it is hung… and I get the dreadful dialog to hell.

If I run it outside of VS… (Duh!, no debugger)… it validates without any problems
…works fine!!!
.
The DEBUGGER, first fails for some reason,
then it does not allow recovery from an exception that throws it into a loop.
…seems it should always have a BIG RED button to stop the ROBOT before it takes over the entire planet

I hope this helps... I am sure there are more scenarios.
.
Posted by Nic Martel on 12/13/2009 at 11:48 AM
.
I seem to get that when I *disable breakpoints* while in a debugging sequence/session.
I will monitor this issue and edit or post again.

When the dialog pops up it has 3 options, *Switch*, *Continue*, *Cancel* <-- Cancel is disabled!!!
I have never waited 5 or 10 minutes to see if recovers on its own...

Killing the *vshost* is of no use to me since it no longer shows in the *task manager*... in *WINDOWS 7*...
That is what I used to do on my XP Pro... and it did not work 100%. I had to kill several *vshost* instances...

So far all I know to do is to kill *devenv*... short of freakin REBOOTING!
Is *taskhost.exe* the *vshost* equivalent on *WIN 7*?
.
Posted by Boyd_Rice on 12/5/2009 at 12:02 PM
"Alternatively, you can create the dump file with Task Manager."

Sending you archive with 3 files

devenv1.dmp and VSTraceLog.dmp were created after getting freeze after stopping debug of my app. After some time VS unfreezed and I started debug again - debugging application didn't start and VS freezed again. Then I made one more dump - devenv2.dmp

Enjoy :)

Posted by Boyd_Rice on 12/5/2009 at 11:43 AM
I have MSO 2010 beta installed too, but I don't think it is a reason :)

And I noticed this bug happens only when stopping debugging with closing a main window of your app, when stopping debugging with special button in VS toolbar - there is no hangs. But I'm too lazy to click this button every time :))
Guys, please, repair it!
Posted by nSanche on 12/4/2009 at 3:36 PM
I've been having the same problem today. It happens when the process I am debugging exits. The IDE looks like it's restoring its layout back to the non-debug layout, but then it just puts up a Wait cursor and does nothing. The workaround of killing the vshost process does not work for me.

I'm on Win7 64, writing a very simple WPF app with a button on the form. IDE hangs about once in 3 debug sessions when closing the debugged application with window chrome close button.

I dumped the process and zipped it, but it's 250MB. Download it from http://nsdev.org/~neal/devenv.zip if you can.

-Neal
Posted by NETmorsels on 12/3/2009 at 11:05 AM
I am having the same issue today. I don' t think MS has a solution yet and I am not even using the Beta. I am using the original VS2008 edition.
One workaround that seems to work is stepping into the debug area when you know a particular function is going to take long. In my case this was a DB call. The error doesn't occur when I step-into the process.
Posted by Sebastien Bach on 12/3/2009 at 2:32 AM
I agree, i got the same issue and it's definitly a bug. Please solve this as quick as you can cause it's really anoying and quite impossible to work whith that. good luck
Posted by GMagana on 11/26/2009 at 9:11 AM
Microsoft, we DONT NEED A PROGRESS BAR!! This is a freeze in the IDE that has no reason (ie, while editing a file). jIf we go back and take the same steps the freeze does not happen. THIS IS A BUG, NOT A MISSING PROGRESS BAR dammit, I wonder how MS stays in business with these people on board.
Posted by dotScience on 11/24/2009 at 7:23 PM
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 50% 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 Greg Bachraty on 11/21/2009 at 9:01 AM
"We have investigated the issue and in order to improve the user experience and prevent the appearance of a hang, we have added appropriate progress dialogs whenever such an operation takes a long time"
I really hope you mean that you have found and fixed the issue *and* have added a progress dialog that makes it easier to pinpoint the culprit in case another hangup bug surfaces. Most of theese operations should complete in mere seconds, there's no point in making a dialog for that.
Posted by hamanu on 11/17/2009 at 11:54 PM
My VS2010 Beta 2 hangs too often when i edit xaml file (as code), i noticed in particular it stops responding when i scroll xaml code with mouse wheel just after opening. It seems that hangs even if i have xaml file(s) opened for editing and doing something else (building/running etc.).

Beta 1 did not have this problems.
Beta 2 is absolutely unusable :(
Posted by JGTM on 11/16/2009 at 7:13 PM
I think this bug is the same one as this: http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=504538.

Maybe you guys could possibly merge there two issues and pay more attention to this real show stopper.
Posted by André Obelink - MVP on 11/15/2009 at 5:11 AM
Same here... Forr me it's a real showstopper, it's too time consuming.. Just want to make a comment on the latest post of Microsoft..

"We have investigated the issue and in order to improve the user experience and prevent the appearance of a hang, we have added appropriate progress dialogs whenever such an operation takes a long time."

In my case the software really stops working... waiting for 2 minutes or more is not acceptable.. Okay, I know I have to wait :-) , but the software really hangs on my machine (Win7 - 32 bit, WIndows Forms app - 3.5 Framework - mostly when debugging.)


Posted by Microsoft on 11/13/2009 at 11:30 AM
Hello,

Thank you for all the feedback. We have investigated the issue and in order to improve the user experience and prevent the appearance of a hang, we have added appropriate progress dialogs whenever such an operation takes a long time.

Thank you
Visual C++ Team
Posted by Greg Bachraty on 11/10/2009 at 10:26 AM
I'm also experiencing this issue in various scenarios, most often during build, when starting/stopping debugging (especially if I use the stop button on the toolbar) or when editing xaml, but it happened during editing plain C# source code or just leaving the IDE for a couple of minutes. The occurence of this issue is consistent with observations above (a few to a dozen times an hour). Sometimes I get the "Visual Studio is waiting for an internal operation...", sometimes I don't. In the overwhelming majority of cases the IDE does not become responsive again, although I have observed a very few cases when it does after several minutes. (Might be a different issue). Devenv never goes into the "not responding" state and never reports any crash.
Debug dump from the latest freeze uploading right now to the workspace above.
Posted by JGTM2008 on 11/8/2009 at 1:58 PM
I'd already uploaded a (huge, near 300M) devenv process's dump file captured while it's freezing to the amentioned workplace (https://sftus.one.microsoft.com/choosetransfer.aspx?key=c5798c9a-ae9f-45e1-aa2e-14a9ea39fb80) several days ago. If you guys cannot see it, please let me know. The upload progress took me near an hour but it is worth the time if you could fix the bug which bothers a lot of developers' valuable time every single hour while they evaluate the Beta 2.

A hint to the problem I found just now (yes, the freeze bug actually gives me some spare time to write this comment to you guys), when the freeze happens, the entire UI is not responde but there won't be an "(not responding)" prompt hanging in the window's title, but if you click here and there for several times, it's really getting "not responding" in the title bar and the balloon pops up to say that the Visual Studio is busying waiting some internal progress to finish or something like that, the most interesting thing I just noticed is, that while it's freezing, if you click the VS2010's icon in the taskbar (I'm using Windows 7 RTM), it plays the "ding" system sound each time you click. It's rather fun (read, boring!) to click to hear the ding while it's preventing me from working with my stuffs.

Okay, now it's unfreezed by some mystery power and I'm going back to work. See you guys...fix the bug. :)
Posted by Microsoft on 11/3/2009 at 2:58 PM
Hello,

If you could provide us with a dump of the process when it hangs, it will make investgation a lot easier. As of now, we are unable to reproduce it. Please feel free to write directly to me:
rasharm at microsoft dot com

Thanks
Visual C++ Team
Posted by David131 on 11/1/2009 at 6:40 AM
I used BETA 1 for months with no issues. I then reformatted my PC and installed a fresh Windows 7 64-bit. I then installed VS2010 BETA 2 and started a new Windows Forms project. This hang occurs 5 to 10 times per hours now making VS2010 very unproductive for me. Most of the hangs occur when coming out of debug mode. I cannot believe that this cannot be reproduced as I can reproduce it within 5 minutes of using the IDE.
Posted by Mythox on 10/31/2009 at 12:56 PM
I have the same problem, Visual Stuio is unusable for me too.

I format complete pc and test in Windows Seven x64 Beta 1, Windows Seven x64 RTM, Windows XP Profesional SP3, All systems clean new installation and the same problem in all systems.

I think that this a big problem in Bet2 of Visual Studio 2010, Beta1 not have this problem in my machine.

Thanks.

Posted by Microsoft on 10/30/2009 at 10:47 AM
Hello,

Thanks for reporting this issue. Your feedback is important to us and in every product cycle we try to make sure we incorporate customer suggestions. However, after multiple attempts we have not been able to reproduce this particular issue.

Best Regards,
Visual C++ Team
Posted by David Elliott on 10/29/2009 at 6:28 PM
I am experiencing exactly the same problem. Unfortunately this beta is completely unusable until this is resolved!

VS2010 Beta2 worked fine for a few hours. But since then, the VS IDE hangs every time I attempt to being debugging (e.g. F10). It will finally come clear after maybe 10 minutes.

Interestingly, the same hang results when changing the Platform Target on the Build properties page.

I have discovered that killing the hosting process causes the IDE to come clear.
Posted by JGTM on 10/29/2009 at 3:36 PM
This is just annoying and really a showstopper for anyone who want to have a taste of this next generation of dev tool. I am uploading a dump to you guy (and yes, I'd second that we can capture as many dumps as you want) for deeply inspecting the problem.

I hope you can quickly provide some workaround or even hotfix right after the issue is understood so that we technical evanglists don't feel guilty to persuade people around to adapt to this sexy guy.

Urgent. Indeed.
Posted by David131 on 10/29/2009 at 12:01 PM
I am writing a Windows Forms application using Window 7 and VS2010 Beta 2. I get this problem 4 to 5 times per hours. Usually I have to terminate the VS2010 task and restart the application. I usually see this when I run the application in debug mode and exit the application being debugged. VS2010 goes to an hour class and never returns.

I have been able to capture a dump and I can capture as many as necessary because it happens a lot.
Posted by dotScience on 10/25/2009 at 2:41 PM
Kylin.Ming wrote : "Alternatively, you can create the dump file with Task Manager. Once the IDE hangs, start Task Manager, and then switch to Processes Tab. Right-click the devenv.exe and then click "Create Dump File" context menuitem."

When VS 2010 beta 2 goes into this "internally busy" state, and I follow your directions above : I get an error message after selecting "Create Dump File" from right-clicking devenv.exe : "The Operation could not be completed. The system could not read from the specified device."

This message will occur even if VS 2010 beta 2 is NOT in the "internally busy" state where it will not respond to mouse or keyboard input.

On average Vs Studio Beta 2 is going into these "internally busy" states about four to six times per hour resulting in at least fifteen minutes when no work can be done.

I call that a critical bug.

I have tried things like killing the VSTraceLog.exe process in the Task Manager, and I am already compiling without the option for the Visual Studiio Hosting Process. Neither of those two factors seem to make any difference in the behavior of VS Studio Beta 2.

Bill Woodruff
dotScience
Chiang Mai, Thailand
Posted by Microsoft on 10/22/2009 at 2:34 AM
any update?

Thanks,
Kylin
Posted by Microsoft on 10/19/2009 at 11:17 PM
Alternatively, you can create the dump file with Task Manager. Once the IDE hangs, start Task Manager, and then switch to Processes Tab. Right-click the devenv.exe and then click "Create Dump File" context menuitem. Please upload zipped dump file to the following worksapce:
https://sftus.one.microsoft.com/choosetransfer.aspx?key=c5798c9a-ae9f-45e1-aa2e-14a9ea39fb80
Password:^DJs5zLk3e

Thanks,
Kylin.Ming
Posted by Microsoft on 10/19/2009 at 11:14 PM
Thanks for reporting this issue.
We could investigate this problem if you give us a minidump. This will let us know the state of Visual Studio at the time of the hang. Here are some instructions for getting a minidump:
[1] Install Debugging Tools for Windows. These tools can be downloaded from Microsoft free of charge from http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx (assuming you're running on an x86 machine; other platforms are also supported).
[2] Open a command prompt.
[3] Change to the directory where you installed Debugging Tools for Windows (a typical product installation will place the software in C:\Program Files\Debugging Tools for Windows).
[4] Type in the following command:
windbg -g -G <full_path_to_devenv.exe> (in double-quotes if necessary -- omit the angle brackets)
If your issue requires using command line arguments, you can insert them after the full path to the executable, e.g.:
    windbg -G -c "$<C:\dump.scr" "C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\vbexpress.exe" /build
This will run Visual Studio under WinDbg, which is a low-level debugger that can be easily used to gather a minidump at the point of the application hang. This minidump will help us diagnose the cause of the hang as well as provide you with a possible workaround.    
[4] When Visual Studio starts, run through the scenario that makes the problem happen.
[5] When Visual Studio stops responding (make sure to wait a minute or more to make sure that VS is really hung), switch to WinDbg and:
[a] Hit Ctrl-Break.
[b] There should be a “Command” window -- ensure that focus is in this window.
[c] At the bottom of the “Command” window, you will see a single-line textbox; this is used for entering debugging commands. Type in the following command into the textbox exactly as shown below (in particular, do not forget to include the leading dot before “dump”), and press Enter:
    .dump C:\dump.dmp
After the command finishes (you’ll see a “Dump successfully written” message in the “Command” window), you can exit WinDbg. This will close both WinDbg as well as Visual Studio. The dump will have been written on your disk to C:\dump_xxxx.dmp, where xxxx is a unique date/time string automatically generated by WinDbg.

Please upload zipped dump file to the feedback.

Thanks,
Kylin.Ming
Posted by Microsoft on 10/19/2009 at 3:40 AM
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)
Sign in to post a workaround.
Posted by BizHS on 5/19/2014 at 4:05 PM
Terminating TFSComProvider.exe resolved the issue.
Posted by Derrick S on 4/11/2012 at 11:51 AM
Running Windows8 CP + VS11 beta + VisualSVN Version 3.0.0-alpha7

Terminating: "VisualSVN host process for Visual Studio" in task manager recovered VS11
Posted by ckozl on 2/2/2012 at 12:20 PM
Terminating The Roslyn CTP "InteractiveHost.exe *32" seemed to wake the process back up. I am not sure if this is because the terminated process was in the middle of doing something or because it triggered some other event in Visual Studio that coincidentally woke it back up. But it did work and allow me to cancel the build and then restart Visual Studio 2010 SP1 without having to terminate it while it was possibly doing something...
Posted by John of York on 12/20/2011 at 6:59 AM
I am having this problem with a windows form application.

The work around for me was (similiar to what was already suggested) to step into the code with a break point ONCE at the forms load event. Seems that as long as I do that, I don't have any more trouble....well, at least with this anyway. ;)
Posted by Rishchand on 12/28/2010 at 8:01 PM
I had the similar issue. I was not able create a new windows forms application. Visual studio goes busy on an internal process and never came back.

I restarted the machine and it worked.
Posted by Alan Waiss on 8/26/2010 at 9:13 AM
I'm not sure if this was the same problem, but after I installed Office 2010, Visual Studio 2008 was frequently becoming non-responsive when using the html source designer and switching to editing a .js file or vice-versa - it would act as if a modal dialog was open and make the "ding" sound.

I found the solution at http://mattfrear.com/2010/03/09/visual-studio-2008-sp1-locks-up-after-installing-office-2010-rc/ - It was spawning a SETUP.EXE that never ended. I went to C:\Program Files (x86)\Common Files\microsoft shared\OFFICE12\Office Setup Controller and ran setup.exe, choosing the Repair option. It hasn't locked up since.
Posted by TriSys Business Software on 5/4/2010 at 3:01 AM
Look for the licence compiler in task list: LC.EXE
If this exists, kill it and VS will complete but finish with an error about the license compiler.
This is probably an error with the 3rd part components not being registered correctly.
Seek vendor help.
Posted by dotScience on 2/4/2010 at 3:14 PM
It seems like I have fewer failures in WinForms programming if, when I start a new Project/Solution, I immediately :

1. Go to 'Solution Explorer' : right click on the #nameApplication : select Properties : in the Application tab : set the Build target to the FrameWork 4.0, not the FrameWork 4.0 Client Profile

2. In the 'Debug tab of the same Application configuration panel : uncheck the VS Hosting process, as reported here.

Whether step #1 above is the equivalent of throwing salt over my left shoulder : no idea.

With WPF, however, crashes remain so frequent, doing the simplest things, that it is, effectively, unusable.
Posted by NETmorsels on 12/3/2009 at 11:27 AM
I just noticed the killing the vshost process alone seems to work. The application can still remain open and we don;t need to restart.
Posted by NETmorsels on 12/3/2009 at 11:05 AM
I am having the same issue today. I don' t think MS has a solution yet and I am not even using the Beta. I am using the original VS2008 edition.
One workaround that seems to work is stepping into the debug area when you know a particular function is going to take long. In my case this was a DB call. The error doesn't occur when I step-into the process.
Posted by JGTM2008 on 11/8/2009 at 2:00 PM
The previous workaround is simply not revalant to this problem. Verified.

Anybody out there to remove it from misleading people having this problem? Thanks.
Posted by Rajesh R Subramanian on 10/25/2009 at 7:01 AM
Restarting the entire web server seems to work most of the time.

Try this: Start->Run->iisreset

Credits to Vivitor: http://geekswithblogs.net/sevenfortytwo/archive/2006/11/23/97947.aspx