I have a strange issue with VS2010 in which the grid-views within the IDE sometimes mis-behave, they go into a state of constant re-painting very very slowly, which then causes the all other windows in the OS to re-paint, this gets stuck in an endless loop and causes the OS UI to pretty-much lockup, the only way to fix is to close VS2010 or minimize it.
Here is a detailed explaination (this just mentions Team Explorer but I've had the issue with a connection string dialog too):
http://social.msdn.microsoft.com/Forums/en/tfsworkitemtracking/thread/57ceb594-10ac-482c-bb3d-9a294a538d6c
My gut feeling is that maybe there's an issue just on my laptop (maybe graphics card issue?) that only affects VS2010. It's SP1 by the way.
Any ideas?
UPDATE: I just tried to do some diagnosis when this issue occurs, so I opened up task manager, and that actually sorted the issue out, even after I've closed task manager, the re-painting stopped and everything worked as normal.
I haven't found the solution to this, but Ctrl+Alt+Delete, then clicking Cancel seems to cause VS2010 to 'snap out of it'.
Related
I'm running in to an issue where my solution freezes when debugging. If I place a breakpoint at the beginning of the solution, it wont freeze and will allow me to either continue or step through just fine. With this solution however, I need it to start from a specific point in the code. When I try to start it from that specific point, it'll freeze, and the output and locals box will have a popup in each saying "Busy..". It did not have this issue a few days ago, but just started yesterday.
It only occurs to this specific solution (I can debug other solutions just fine). Using C#/.NET mostly.
Remedies I've tried: Clean/Rebuild, repair on installer, uninstall just app, uninstall app and associated files, running Release, code cleanup, upgrading/downgrading vos, placing breakpoint at beginning then jumping to next breakpoint at specified point, removing antivirus software temporarily
Running latest version of Visual Studios 19 Community at the moment.
I didn't find the solution necessarily, but deemed it to be an issue with the "Locals" box that displays all your local variables and values. If I close out of this, I can continue with debugging. From further research, it seems that tool has been known to be pretty buggy.
I've been fighting this little problem for a while now, so I'm really hoping I can get some help. I've been looking for a solution to this, and I found this SO question: Debugging doesn't start.
My issue is somewhat similar to the issue discussed here, except that my issue is a two-parter.
Part 1: Similar to the issue discussed on the other question. (Debug Window Doesn't show up)
When I attempt to launch my Windows 32 console application project (The simple kind that opens in the windows CLI). The CLI (or CMD) window doesn't open, and windows idles giving me a spinning cursor wheel. Visual Studio IDE (I'm using VS 2013 Community) becomes unresponsive and I cannot access any menus, or use any hotkey to "Stop Debugging". One difference from the provided SO question though, is that when I try to launch "MyProject.exe" from my project's "Debug" folder I get the same result as attempting to debug in the IDE.
Part 2: Unkillable Process
When I try to close my debug application in the windows task manager, it is not listed as an ongoing process. However, whenever I try to manipulate, delete, or otherwise modify my Project.exe application (in my Project's "Debug" folder), windows informs me that the application is in use. Confused by this, I downloaded two applications. The first was Process explorer, which showed me that I did in fact have 2 instances of "MyProject.exe" running. The second was Process Hacker, which also showed me 2 instances of "MyProject.exe". However, neither of these programs were able to terminate either of the "MyProject.exe" processes.
I am capable of terminating the processes for visual studio and restarting the IDE, however, because the "MyProject.exe" processes are still running. Building always fails with the error
"Error 1 error LNK1168: cannot open C:\Users\Brandon\Desktop\MyProject\Debug\MyProject.exe for writing"
Whenever I restart my computer, the lock files (as expected) are removed, and the "MyProject.exe" processes disappear. I can restart VS and everything works, but if I try to Debug (pressing "Start Debugging" or F5) the same issue occurs.
A process of my program is started ("MyProject.exe"), but the CLI window where my program's text should appear doesn't show up. Visual studio locks up, and "MyProject.exe" persists until the next restart because "MyProcess.exe" cannot be terminated.
My solution configuration is set to "Debug", Solution Platforms = Win32.
I have tried creating a new blank console project in VS 2013 and I get the same result: code builds fine, but I have the same debugging issue. I get an identical result with a quickly assembled "Hello World" project.
Sorry for being a noob, but honestly. I really don't know what's going on, so any help is greatly appreciated.
(Note: Running Windows 10 with VS2013)
EDIT (UPDATE):
So, I'm having the same problem with several programs in Windows 10 (most notably Allegorithmic's Substance Painter). So it looks like this may actually be an OS problem. Several of my programs whenever I try to launch them do the same thing...the program acts like it's going to launch, but then no usable window appears. Looking at my processes I can see that the process has been started, but it is once again unkillable. For reference, I am using Windows 10 Version 1511 (OS Build 10586.17).
I believe your problem might be Avast, if you are running it. I had exactly the same issues until I uninstalled it. Had upgraded to Win10 and VS2013 just froze, same as you described.
Cheers.
I have brand new Win7 64bit machine. Visual Studio 2008 is newly installed, but has started responding more and more slowly, eventually hanging completely and occupying one (virtual) core of the machine completely. After an hour or so of increasingly slow response I close it and start again, whereupon it runs fine at first before gradually slowing down again.
Using Process Explorer I have found that the responsible devenv.exe thread always has a stack which looks something like this when it is pegging the processor:
ntoskrnl.exe!KeWaitForMultipleObjects+0xc0a
ntoskrnl.exe!KeAcquireSpinLockAtDpcLevel+0x732
ntoskrnl.exe!KeWaitForMutexObject+0x19f
ntoskrnl.exe!__misaligned_access+0xba4
msenv.dll!DllCanUnloadNow+0x49b31
with one or more ntoskrnl.exe!__misaligned_access and msenv.dll!DllCanUnloadNow lines; can anyone give me an idea of what might be going wrong? Thanks!
UPDATE:
Having started VS via the command line switch /SafeMode (thanks 0xA3), I find that without Resharper the problem seems to go away... So it looks likely to be a Resharper bug :(
did you check all other threads in the process? (both managed and un-managed) to see if any thread is busy or waiting in non-trivial place with stacks unlike others? Main thread is obviously waiting, most likely on another thread of the same process - I'm curious to know what other callstacks are out there.
I have a complex C# project that I ported over from C++ and now I'm in the middle of debugging. Things are working great most of the time but more often than not I have huge problems with Visual Studio and debugger attached to WP7 emulator. For some strange reasons, my debug session is often abruptly terminated while stepping through the code without any indication from VS or any trace left in the Output window.
There are even some cases when a breakpoint is hit and then when I hover over a particular variable, VS simply exits the current debugging session. If I refrain from inspecting the variable contents, nothing happens and VS waits happily forever.
As the app is a memory hog by definition, I am wondering whether I am hitting any debugger / WP7 / emulator limits of any kind. Why would a mouse over variable terminate debugging session? Most of all, why is there no trace of what happened? I am left to wonder whether this is a VS issue or an emulator issue or even an app issue.
What are your computer specs?
I have seen similar problems on computers with low specs, especially computers with low memory.
Try clearing out memory hogs from your PC (CCleaner is a good tool) and running Visual Studio in administrator mode.
I have found this post which has helped me immensely. It appears that having ToString() overrides can sometimes crash the debugging session. I have implemented mine for the sole purpose of having customized value representation of variables/values in the debugger.
After removing all the ToString() overrides I am able to debug normally again. The thing that still puzzles me is the fact that no exceptions are leaked from my ToString() overrides so I wonder why debugger behaves the way it does but at least the problem is solved for now.
I hope this helps someone.
I noticed that at installation time of a VS package product (like http://www.continuoustests.com/ ) devenv.exe is started
and I notice that sometime my VS addin is loaded (its OnConnection() method is called), and this could provoke a crash.
The problem is about sometime, since I cannot repro the conditions where my VS addin gets loaded.
From my crash log, I know it happens rarely, only with VS2010 devenv.exe, and I know as well it is independent from the machine architecture x86 / x64.
I tried installing/deinstalling extra addins having no VS instance running, or having VS instances running, VS2008 or VS2010.
Does anyone have a clue about how to reproduce the problem when my VS addin gets loaded?
Btw, I am pretty sure to have a fix for the problem, since in OnConnection() I already have code like that...
switch (connectMode) {
case ext_ConnectMode.ext_cm_External: // This setting is no longer used by Visual Studio. (http://msdn.microsoft.com/en-us/library/extensibility.ext_connectmode%28v=vs.80%29.aspx)
case ext_ConnectMode.ext_cm_CommandLine:// The add-in was loaded from the command line, don't support it so far
case ext_ConnectMode.ext_cm_UISetup: // addin loaded for the first time, we don't need it (http://msmvps.com/blogs/carlosq/archive/2008/10/13/the-onconnection-method-and-ext-connectmode-ext-cm-uisetup-of-visual-studio-add-ins.aspx)
return;
case ext_ConnectMode.ext_cm_AfterStartup:
case ext_ConnectMode.ext_cm_Startup:
case ext_ConnectMode.ext_cm_Solution:
break;
}
... but once OnStartupComplete() is called back, I forgot to check the connectMode value I got in OnConnection(), hence the crash.
Anyway being able to reproduce the bug would comfort me in the fix.
Update: 10 October 2011
After more testing and feedback from users that repro the problem, it appears that my theory was wrong: connectMode is actually in the range [ext_cm_AfterStartup, ext_cm_Startup, ext_cm_Solution].
The problem only occurs with VS2010 and comes from the fact the addin has no UI element, provoking something like dte.MainWindow, or HwndSource.FromHwnd(new IntPtr(mainWindow.HWnd)).RootVisual to be null.
I talked with Carlos Quintero http://msmvps.com/blogs/carlosq/, the world expert in VS addin, that has never observed this case. VS2010 shouldn't load any addin in the VS extension install/uninstall scenario, and it seems to occur randomly, or more likely, under unknown and rare conditions.
I'll put yet another try/catch to circumvent yet another VS2010 addin bug :(