When using Visual Studio I often encounter situations when the IDE freezes while performing some operation. For instance, this frequently happens when I move next statement pointer (yellow arrow) during the debug session, when I unintentionally press F1, step into some low-level function that has multiple instantiations in the binary code etc.
In these situations Visual Studio notification balloon shows up in the tray with the following text:
Microsoft Visual Studio is Busy
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.
Often the delay is so long that it is faster to kill the Visual Studio process, start it over again, restart debugging session (or whatever else I was doing) and avoid doing an operation that has caused such a delay. However, this still takes too much time. I would like to have a way to stop/cancel the operation that is taking so much time. For instance, in Total Commander this is possible by pressing Esc during such an operation.
Is something like this possible with Visual Studio? Any plugins that allow doing it? Any other way to circumvent the problem?
P.S. Sorry for the lenghty description, but I wanted to explain the actual problem (not ask if certain solution is possible), so that people can think of ways to solve the problem.
P.P.S. Both 2008 and 2010 suffer from this problem.
If you're debugging, try hitting SHIFT-F5. This should stop the debugger, though probably not immediately, faster than what you've described. The program will process the keyboard a lot faster than trying to click menus with the mouse.
If you're building, try hitting CTRL-Break. Again, it may take a few seconds, but it usually comes around.
I've had the problem you mentioned a few years ago, but I can't remember what I ultimately did to fix it.
There may be many different causes of this issue, but for me apparently what was slowing it down was trying to load symbols from symbol servers. I unchecked the Symbol file (.pdb) locations in the Debugging\Symbols options and the problem went away entirely.
run iisreset may solve your problemstart >> iisreset.exe
Related
When placing the curser on a closing bracket in c# for instance, there is a small annoying delay before the opening bracket gets highlighted, and you have to sit and wait before you can use shortcuts such as (ctrl + shift + up/down). It feels like it is intended behaviour for reasons beyond me, so i don't think it is a bug or because my computer is slow (it's not), but it's driving me crazy.
I'm on a freshly installed PC, so i have only testet it in a few programming languages / file formats, and the behaviour only occours in some of them.
The delayed highligh behaviour occurs in .cs (c#), and .css files, but not in .js and .html files, here the code gets highlighed instantaneously exactly like i want it to in .cs files aswell.
I'm using Visual Studio 2015 Community Edition.
I have had this problem as well, since first installing. I can confirm that Update 1 CTP addresses this issue, and the delay is almost gone (maybe 1/8 second now.)
This UI delay was actually called out as a bugfix that was included with the update:
https://support.microsoft.com/en-us/kb/3025135
To the problem that there is a delay highlighting the brackets: In my opinion that has nothing to do with a bug. I think it takes a little while because your code needs to be parsed every time you change something in order to highlight the brackets. When you have many lines of code in one file it is obvious that it takes a little more time than normal.
Here are some tips that may help you:
Click the bracket and press STRG + ´ this will bring you directly to the other bracket. Or you press ALT + ´ and it will mark all your code in between your current brackets. You can look up the shortcuts of Visual Studio in Tools -> Options -> Environment -> Keyboard:
I'd recommend everybody programming in Visual Studio is to change the highlight color of the matching bracket. Have a look at this:
Here you can change all the colors and forms used for specific searchterms. I personally use Visual Assist 2015 to highlight my code (that's why I didn't change anything here). It is way more faster than VS itself and comes with a lot more functions like bracket guidelines who will show you the indent level of your brackets. Have a look, maybe you like it:
Its about 500ms in a newly created console project
500 msec is a magic number in .NET. You can get some insight from the source code for the C# Language Service, accidentally (?) exposed by a Microsoft programmer on github. Most relevant file is probably this one:
internal interface IBraceMatchingService
{
Task<BraceMatchingResult?> GetMatchingBracesAsync(Document document,
int position, CancellationToken cancellationToken = default(CancellationToken));
}
Or in other words, the brace matching service runs as a background task. Such tasks normally run on a thread-pool thread and are subject to scheduling by the threadpool manager. That's where the magic 500 ms number comes into play. The manager attempts to keep the number of executing tp threads down to the number of processor cores available on the machine, the most efficient way to run threads. However, if the existing tp threads take too long to finish their job then the manager assumes that they are bogged down by I/O and allows an extra one to run. It does this once every 500 msec.
So first-order estimate of your problem is that VS has too many active thread-pool threads and they don't complete in a timely manner. Causing the brace matching task to run too late.
Finding out exactly what specific tasks bog it down is technically possible. I can't guarantee success with the Community edition and you'd need a fair amount of insight in how to read thread call stacks to get ahead. Startup another instance of Visual Studio and use Debug > Attach to Process. Pick "devenv.exe" from the list. Let it trundle while it is attempting to find PDB files, then use Debug > Break All.
First place to look is Debug > Windows > Tasks. Pretty unlikely you'll see anything there however, normal is to see none. Next one is Debug > Windows > Threads. You ought to see about 15 active threads back in that window. Hover over their Location column to take a peek at their callstack. Making sense of what you see isn't that simple unfortunately, it will help a lot if you can compare what you see with another machine that does not have this problem.
Since you have this problem on more than one machine, another approach is to look for an environmental factor that they have in common. Things to look for are aggressive anti-malware, a network connection that is too slow or too unreliable, a poorly performing add-in that you like but runs poorly on a VS version it wasn't tested on.
And consider that VS2015 isn't exactly ready for prime-time. Of all the recent VS versions released in the past 18 years, it is probably the least stable. It has a lot of heavy internal changes and there were an unprecedented number of alpha and beta versions with critical bug fixes implemented just a few months ago. Try it again after Update 1 is released.
Seems like this will be fixed in a future Visual Studio update: https://github.com/dotnet/roslyn/issues/1906#issuecomment-145874647
I have not found a definitive solution for your problem.
This was a known bug in the VS2015 review edition.
This links discusses the delay (this link refers to c# btw, not c):
https://connect.microsoft.com/VisualStudio/feedback/details/1033540/braces-are-not-highlighted-correctly-in-c
And there are still similar problems for some VS2015 Community Edition users.
http://www.developerteacher.com/msdn/bracket-matching-highlights-not-working-like-i-had-in-2013-express-4227
Personally, I think you are stuck with a bug and if I were you I'd try the following:
Make sure I had unistalled all previous editions of VS.
Try a repair.
Completely uninstall and reinstall VS2015 if running repair doesn't work
Go back to VS2013 if it drives you cannot stand it, and wait until VS2015 is a bit more ripe on the vine.
One thing I have found with VS, is when it plays up it's painful, it takes so long to install and the worst case was when I ended up uninstalling and downloading everything that was associated with the install. It now works fine. (this was after previewing 2015 and then going back to 2013). You can also try this for VS2015 and also try a new download.
I sometimes will have a look at some previews, but after jumping in with haste too many times with the latest software releases and then repenting with leisure. I am now happy to wait for new releases to be out for a while before upgrading.
Another FYI for you to browse.
This is a link to Visual Studio 2015 RC fixed bugs and known issues. There are quite a few issues and hacks suggested. (not specific to your problem, but still there a few months ago.).
I am assuming you know how to play around with the settings. I've added the obvious, in case it's been overlooked.
I have added this screen shot from VS2013 settings.
Make sure you have automatic delimeter highlighting checked.
Sorry I could not be of more help.
I have been suffering from the all too common 'Waiting for a background operation to complete...' message in Visual Studio 2012 (Professional) for a while now but it has been fairly sporadic.
Lately though, I am really struggling to use Visual Studio as pretty much whenever i try and do anything with any Razor views (mostly clicking to move the cursor) visual studio hangs and the above message appears for about a minute at a time.
(If when its finished doing stuff i then click in the view again, the process repeats, and repeats, and repeats.....)
I have searched high and low, and read loads of articles regarding this and peoples suggestions and tried changing indentation settings, resetting settings, etc but none have worked.
Has anyone come across something else that may work as this is seriously impeding my ability to use visual studio and sadly provoking much cursing.
I also had the same issue with VS2012 and unfortunately I had to format my pc after trying all the following solutions:
Move/clean the symbols cache
Reset VS preferences
Install Upgrade 2
Uninstall/Reinstall VS
After formatting and reinstalling VS2012, it started working like a charm again (obviously).
Sorry for that.
I know I asked this question a while back, but I thought best to put up my findings as they may help others.
The exact reason for the Waiting dialog is still unknown, but I have since moved my project to a local disk and implemented Team Foundation server to perform the hosting and backup of the main project files.
Since moving to local disk and using TFS, I have not experienced any more of the VS Waiting dialog.
Check if IIS or another process (BizTalk maybe) is locking your DLLs/references
Kill/stop IIS if it is
I recently watched a bit of Notch's Ludum Dare live stream. He uses Eclipse's hotswap feature extensively while he works on his game. (here is a video of what I am referring to http://www.twitch.tv/notch/b/302823358?t=86m30s)
I would like to do the same with C# and XNA. Fortunately, Visual Studio has an Edit and Continue feature. However, I would like to edit my rendering code while it is running instead of pausing it.
Is it possible for me to setup Visual Studio to do the same? I noticed that there is a checkbox for Break all processes when one process breaks. Is it maybe possible to set up my rendering loop in another thread so that the game keeps rendering while I make a change?
Update: This answer is now available as a video.
I've been struggling to find a way to do this. I know this doesn't answer your exact question. But really what you are looking for is a workflow where you can make code changes with zero (or near-zero) delay, and I think I've figured out the closest you can get with just Visual Studio. (And therefore avoiding a huge engineering effort and dealing with "abnormal" projects).
The way to achieve this workflow is actually astonishingly simple, once you think of it:
Use shortcut keys!
The first way I came up with is to just use the normal edit-and-continue method of setting a breakpoint. Only by using the keyboard you can do this considerably faster. This only works with code being called in a loop (eg: draw/update). Click the code you want to modify, add a breakpoint (F9), the breakpoint will almost immediately be hit, modify your code, remove the breakoint (F9), and then run the code again (F5).
This is pretty good. You don't have to use the mouse to hit the relatively small "Add breakpoint" target in the left hand column. But it does move the input focus to the beginning of the line, so you generally have to use the mouse again to fix that before you can start editing.
I want something faster. So I came up with a better solution:
Again, using the keyboard: Press Ctrl + Alt + Break to "Break All". This enters the debugger almost instantly, without having to worry about setting a breakpoint or if the code you want to modify is running in a loop. This will change the editor window and caret focus to the document where execution break, but you can then immediately fix it by pressing Ctrl + - for "Navigate Backwards".
Then you can make your edits and simply press F5 to see them in action. You only have to use the mouse once (or not at all) to initially pick where you want to start typing - just as you would expect.
Admittedly Ctrl + Alt + Break and Ctrl + - are horrible key combinations for something you want to be able to do extremely quickly. And it would be better if there was just one key to press.
If you have the full Visual Studio, you could probably turn it into a macro or add-in. Express doesn't have those - so the best you can do is modify your key bindings (Tools, Customise, Keyboard...) and bind it to two keys that are adjacent, that you can press in quick succession. Or use an external macro utility.
Personally I have set up the two key combinations to be pressed in succession (you don't seem to need a delay between the two) by a macro set to a spare button on my mouse. Which works reasonably well - as I'm usually selecting text at the same time. I might add a keyboard macro later too.
So far I've identified two minor pitfalls of this method:
When you run the app again, Visual Studio gives it focus. It would be nice if it kept focus. Adding a left mouse click to my macro is a partial solution to quickly re-editing code.
"Navigate Backwards" does not retain the text selection, only the caret position.
i can tell you how, but you arn't going to like it:
1) run your game executable in a visual studio instance (game.exe --> vsInstanceA)
2) code your modifiable code in a seperate dll, using a seperate visual studio instance (modifiable.dll --> vsInstanceB)
*note that doing this lets you compile your modifiable.dll, thus doing compile time error checking, etc.*
... and now is where it get's tricky ...
3a) game.exe needs to reference the modifiable.dll. NOT the .vcproj, the actual dll
3b) when you hit a "magic key" (have game.exe look for a key-press), have game.exe unload the modifiable.dll, and reload it. You can easily do this via the Assembly and AppDomain classes provided in mscorlib. Of course this means you need to unload any dependant systems in game.exe.
note, there's a lot of hand-waving in this 3b) section, it's quite a lot of work but pretty straight forward (example google search: https://www.google.com/search?q=dynamic+load+dll+.net)
... and after that, you are good to go ...
3-alt) some other choices if 3b) doesn't suit you:
you can invoke msbuild.exe to rebuild modifiable.dll when you press
"magic key"
you can use the CSharp compiler dll's to dynamically
recompile each class instead of the entire modifiable.dll
but unfortunatly, in my 10+ years of .net development, this is the only way, unless someone has created a 3rd party product to do it (IE: they do what i mentioned, for you)
This may not be exactly what you're looking for but it's what I've been doing. Just throw in a break point while your game is running. Once it's stopped, you can edit things, remove the break point, and then hit F5 to continue.
For the most part, this allows you to edit things while the game is running and continue running the game afterwards but it doesn't work for everything. You can't add or remove class level things and also can't add/remove entire functions or the parameters. Mostly, I do this to test out different numbers and equations for smaller things that get hit every update.
To answer the original question "in Visual Studio 2010 without pausing execution?"
No. For Java there is JRebel which allows this.
I can quickly imagine why Microsoft haven't done this - if you have some sort of committee or group of people designing things - it's easy for even one person to come up with good arguments where this "dynamic software updating"/hotswap will break. It's just too easy to shoot down. Or if they proceed with it, it will be through some entirely new "enterprise framework" that requires lot of steps, work and understanding to get anywhere, because they want to use it for complicated online scenarios.
I'd prefer there was some simple way to do this - I'll take the risks, and put up a lot of disclaimers that if you want hotswap services that talk to external systems then you need to use that complicated framework or whatever.
The most typical scenario where this could safely be used with low risk is prototyping and tweaking some sort of engine with either high startup cost or more likely, to study behaviour if something running in the engine (like rules) is buggy and to exhibit the bug, a lot of things has to happen and it's possible you don't encounter the bug always. That is the case where having this could save weeks of debugging time, atleast would have in my case.
I'm used to work in Java using IntelliJ Idea + DCEVM (Dynamic code evolution VM).
Unfortunately i haven't found anything getting closer to that configuration at Microsoft C# platform. It really sucks and you can't do much about it. You can use some user defined macros, but you can't still do much in Edit and Continue mode without restarting Debug session).
However if you can, try to use newest .NET Core which offers much better productivity using Dotnet Watch. Still not so fast as DCEVM but much better than traditional VS + .NET hot reload experience. Details here.
I keep having intermittent issues with visual studio 2010: I'm working on a rather large solution (200+ projects), so the whole solution takes a long time to build even with a little change.
I often need to debug processes on remote machines.
What I noticed is that visual studio would often appear hung on detach or terminate remote process. On closer examination, it appears that immediately after debugger disconnects, VS will start to build solution, and it is not possible to cancel the build by pressing Ctrl+Break, in fact no menus work at all until the build finishes or fails, and with large solution it takes a long time. One way I found which would fix this issue is killing the MSBuild.exe processes, spawned by VS, which would fail the build.
Have anyone seen this behavior? Is there any fix? Very annoying
EDIT: This is how the process explorer looks after disconnect from debugger: http://vvcap.net/db/oz1NMoyXnWWlQp8mWaRY.htp
This would happen when you edit code while a breakpoint is active. After the debugging session ends, VS automatically rebuilds the solution to incorporate the changes into the binaries, not just in memory. This does tend to make VS a bit catatonic, I think it tries to prevent you from doing anything that would interrupt that operation. This normally doesn't take more than a couple of seconds but I have no idea what might happen in such a large solution. Disabling E+C is probably not one of the workarounds you'd contemplate if you are used to being able to edit code while debugging.
Having solutions with 200 projects does tend to test the limits of endurance. Do try to whittle it down to a core set of projects, chucking out the ones that shouldn't change because doing so would break too much code in higher layers. Or just create another solution and include only the projects you want to test. It doesn't otherwise affect the debugging session, you can still debug code from such projects as normal. Without E+C of course.
Such amount of projects in a solution file can take a LOT of time to build. I can't (myself) imagine) the worries before pressing ctrl+b (know that takes 30 seconds of my working hours).
I would tell my boss that we are in badly need of insert a 40 hour delay because of refactoring the projects into maintanable & compilable parts (sharing same dll into each library per purpose/layer). If the delays is about pure project redefining or just splitting out the solution into several projects fully depends on your work. At least the parts where I am expecting problems and are about to change,
I'm using VS2008, in a normal mid-size solution.
Sometimes, debug stepping becomes very slow. A padlock gets rendered on the every file tab for every "step" (F10/F11), and it can take up to two seconds for every step. That makes debugging very annoying and slow. Has anyone seen this problem?
I've noticed in VS 2008 that if you have the 'Show Threads in Source' button selected in the debug toolbar that stepping can be at least 10 times slower.
I've also noticed that if your application takes a long time to start in debug mode that this can be resolved if you simply 'Delete All Breakpoints' under the Debug menu. This solved an annoying problem for me even though I only had a handful of breakpoints set at the time.
Silas
Try turning off the "Enable property evaluation…” setting in Debugger options, it should make debugging much faster (read more: Fix: Make Debugging Faster with Visual Studio):
(source: flickr.com)
Disable Show Threads in Source in Visual Studio. and Close Call Stack Trace Window.
In addition to all issues mentioned above.
A "Disassembly" tab (opened in a background) slows down the debugging by 1-2 sec per step.
(Not sure if it always happens like this).
I had the same issue, especially when debugging apps with many threads.
It was caused by the feature "Show threads in source".
See the following link for details:
Code Project: Show threads in source
Visual Studio Single Step Performance Fixes
After disabling this feature, problem has been fixed.
There are many things that can cause Visual Studio to be slow. Excessive breakpoints and Show Threads in Source are probably the two most common, but you don't care what is most common, you care what is making Visual Studio slow for *you*.
So, if deleting breakpoints and turning off Show Threads in Source doesn't work then you need to profile Visual Studio. That lets you find performance problems that are unique to your situation. An explanation of how to do this (which resolved two separate Visual Studio performance problems) can be found here:
http://randomascii.wordpress.com/2013/03/03/visual-studio-single-step-performance-fixes/
More investigations of performance problems in other people's code are detailed here:
http://randomascii.wordpress.com/category/investigative-reporting/
Accepted answer is hardly relevant or helpful!
These are some possible issues that could make debugging extremely slow:
"Show threads in source" (see screensht). If you have a heavily mutithreaded app you won't be able to debug with this option enabled. What this options does is it tries to show in the same file execution position of other threads if they also execute the same code. So, if you have many threads debugger needs to check for all threads where they are located. If you have many threads this might make each step with debugger extremely slow.
Many conditional or even regular breakpoints. Especially if these are in some inline functions of some header file.
"Show external code" enabled in call stack also makes it slower.
Disable “Show Threads in Source” if it is enabled, and also close the Parallel Stacks Threads, Tasks, and GPU threads windows if it they are open. Those cause the debugger to walk the call stack for every thread in the process.
Yes, Visual Studio is extremely slow at debugging at times. There are a number of additional steps (in addition to turning off the Enable property evaluation" setting) you can take to speed up the process. Essentially, it requires massive amounts of RAM, so performing a few things to free that up will help.
Go into the preferences of Visual Studio. Look for all the options relating to animating menus and so forth. These have a tendency to be intensive at times, while not specific to debugging as you usually aren't opening up menus, it does seem to help.
On the computer itself, if you right-click on my computer. Go to the advanced tab and under performance. If you adjust your computer for best performance it'll speed things up. It gets rid of any nice styles on your computer, but it'll free up some of the memory you are wanting.
Close any unnecessary programs. The more memory you can give Visual Studio the better it is going to behave.
Here's a link to some guidance on Mike Stahl's MSDN blog, with respect to resolving debugger slowdowns
I ran across this because conditional breakpoints in my app's hotspot killed my debug performance. Personal BKM: resolve potential performance issues before you leave for the night, for you may not remember them in the morning.
Another cause of single step slowness is use of Intellitrace (available only in Ultimate). To turn it off, Tools | Options | IntelliTrace. Uncheck Enable IntelliTrace.
The "Show Threads in Source" suggestion did not help.
But I fixed it by enabling Tools:Options:Debugging:General - > "Require source files to exactly match the original version".
Mine was unchecked initially, but after changing it stepping through code in VS2008 is now back to normal speed.
What helped me was disabling Diagnostic Tools.
Tools / Options / Debugging / General / Enable Diagnostic Tools
Visual Studio 2015 (Version 14)
I experienced this problem after enabling ".NET Framework source stepping". Stepping got a lot faster after turning this off. In particular, turning back on "Enable Just My Code" (Options > Debugging > General) removed about half the lag I was experiencing.
The other half was caused by loading more Symbols than I needed (Options > Debugging > Symbols). At one point I needed Symbol locations defined, but I didn't anymore, so I was able to uncheck them all and click "Empty Symbol Cache". If you have _NT_SYMBOL_PATH listed it means you have this environment setting defined, and Visual Studio won't let you uncheck it. You'll need to remove the setting. More about Symbol settings (https://blogs.msdn.microsoft.com/visualstudioalm/2015/01/05/understanding-symbol-files-and-visual-studios-symbol-settings/)
I had the same problem, I deleted all my variable watches and it helped a lot! Because each step during debug, it reloads all watches and it takes time...
Solution : From the Debug menu, choose Windows, then Watch, and click on Watch1, Watch2, Watch3, or Watch4. The menu will appear and right click on them to clear them all.
If you have a virus scanner (with realtime scans enabled), check if C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Remote Debugger\x64\msvsmon.exe* is excluded from the scan.
In my case, debugging became very slow after the companywide rollout of new virus scanner. After a while, we found out that the realtime scan of msvsmon.exe was the culprit.
*modify path as per your installation folder
clear all entries in the watch window.