So I've been struggling with visual studio debugger timeout out on large entity framework queries for a while now. Basically sometimes when stepping over a entity framework linq query it would give me this error.
Evaluating the function
'System.Data.Entity.Infrastructure.DbQuery.ToString' timed
out and needed to be aborted in an unsafe way. This may have corrupted
the target process.
If the problem happens regularly, consider disabling the
Tools->Options setting "Debugging->General->Enable property evaluation
and other implicit function calls" or change the code to disable
evaluation of this method. See help for information on doing this.
Once i had the error i would need to restart the debugger to fix it. After a tone of research and hair pulling i came across a suggestion to enable "Use Managed Compatibility Mode". Amazingly this worked and i also noticed a significant increase in the speed that i could step through my code.
The documentation says that this is a legacy debugger and enabling it may disable some debug features.
So what exactly is the feature difference and why does using "Managed Compatibility Mode" improve step speed so much?
What I know that it is a new option from VS2013
https://blogs.msdn.microsoft.com/visualstudioalm/2013/10/16/switching-to-managed-compatibility-mode-in-visual-studio-2013/
In old VS version, C# and VB projects do not have a way to turn off managed debugging.
The option "Managed Compatibility Mode" was used to managed and mixed debugging but not to native-only debugging.
You could get much more detailed information from Hans Passant's suggestion here:
`Use managed compatibility mode` or `Enable native code debugging`?
Related
I'm currently migranting an VBA powerpoint add-in to VSTO.
For weeks I've been struggling with Visual studio degug for COM objescts. AS you can see on the image below, the object types show {system._ComObject} and object inspection becomes a challenge since one must use the dynamic view, which is quite inconvenient in my opinion.
Looking around I've found a recommendation to activate the option "use managed code compatibility mode" in the general debugging settings, as you can see on Debugging setting
I also followed another the recommendation to set the property "Embed interop Types" on all my office related references to false.
After applying these changes. Voilà! The inspection began do work just as I wished to and as you can see here: Debug working properly
I was almost in heaven. My ecstasy lasted till I tried to change some code during debug and was informed by visual studio that
"managed compatibility mode does not support edit and continue".
Now I'm back in hell. With edit and continue I miss a decent COM object inspection. With COM inspection I cannot change code during debug.
This situation looks awkward and I would expect more from VS 2017.
Does anybody know how can I get decent COM inspection and edit and continue at the same time?
Does anybody know how can I get decent COM inspection and edit and
continue at the same time?
I am afraid that you cannnot get what you want.
Since you just debug a com object which is more like optimized, mixed, or SQL Server common language runtime (CLR) integration code(use ), as the official document said, Edit and Continue function does not support it.
Usually, to debug those mixed codes in VS, you should enable Use Managed Compatibility Mode or enable native code debugging, but those options cannot work well with Edit and Continue as the official document said.
You can check this document to know unsupported changes or supported changes to code.
So for your issue, there is no such option to use both of them.
As a suggestion, you should break the debugging process first, make some changes to your code. Then start Debugging to debug the new changes.
Besides, if you still want this feature, you could suggest a feature on our User Voice Forum. The Team will check your request carefully and hope they will give you a satisfactory reply.
I've spent the last few days searching google, blogs and MSDN looking for any small scrap of info on how "interop" or "mixed mode" debugging is implemented in Visual Studio.
I'm attempting to implement my own debugger for a custom VM (actually, it gets JIT-ed to native code, which means I'll have to rebuild callstacks for the normal native debugger whenever it enter's the JIT-ed code), but I can't find any info on how you can actually interact with VS's native debugger and do the fancy "native/managed" like transitions that VS's mixed mode debugging pulls off.
So far I've found a few things that provide useful tidbits, but not enough to actually interact with the debugger. The best, most useful articles I've found are:
Mike Stall's various blog posts (mainly these two) while providing useful info and glimpses at the inner workings, they seem to be very heavily tied to .Net debugging.
MSDN's Creating a Basic Debugger gives a nice overview of how MS implements it's debuggers and how you can implement one on the same tech stack. Unfortunately, this doesn't really provide any real info on how to pass data off to VS's native debugger. (Combined with Mike Stall's blogs, it seems like both debuggers would be waiting for the same events, so how do you actually splice the results together in a meaningful way?)
The Debugger Engine API (aka DbgEng) documentation. I found this by running Dependency Walker on VS's native debug engine (NatDbgDE.dll, it seems to export the DebugCreate function which I could only find in this documentation, so it could be related). Unfortunately I've had very little success in even doing any debugging through this and it seems to be poorly documented, although the documentation does seem to indicate this is what I'll probably want to deal with in the end. It also doesn't really say how I can work cooperatively with another debugger and makes no mention of VS's debugger, so I could be going down the wrong path entirely with this anyway.
How can I get started with writing a debugger that will work cooperatively with VS's native debugger?
Thanks!
I'm afraid there's not much documentation on this subject. The resources you mention are all pretty old at this point. My suggestion is to integrate with Visual Studio's newer debug engine (Concord). Concord is used as the debug engine for native debugging from Visual Studio 2012 forward and for all debugging in Visual Studio 2013 forward. One of the design goals of Concord was to simplify mixed mode debugging. It is also designed to be easily extensible.
I created some Concord extensibility documentation that may be of help. It is mainly focused on expression evaluators, but it has some good information for getting started with Concord. Another resource that may be of use is the source code for the Concord-based debugger in Python Tools for Visual Studio. This is a full implementation of a mixed mode debugger that integrates with Concord and allows mixed mode debugging with Python.
I'm using Visual Studio 2013 with ReSharper 9 on a quite strong computer (16GB RAM, Core i7 CPU, SSD, etc.). Still I experience heavy delays and laggings during typing for example in a C# or Razor source file.
I've noticed that every time I hit a key, the processing immediately starts, and context actions, offering rename refactorings, autocompetion immediatley shows up in the editor. It would make sense to delay these stuff for example so that all of this processing would start only when I finish typing and have some amount of quite milliseconds.
I've browsed through the settings for the third time now, but could not find anything related. Is there anything like this? If yes, where? If no, what else could I do to overcome this lagging? It's really annoying and I don't quite understand it. I can't beleive that such a computer is still not enough.
Disable Bing Developer Assistant extension if you have it by going to 'Tools -> Extension And Updates'.
Disable the Microsoft Git Provider Plugin by going to 'Tools -> Source Control -> Then setting the Plug-In ComboBox to NONE.'
The above has helped me and has improved performance on my PC. Hopefully it will help you too.
You shouldn't be seeing a lag while typing. I'd suggest disabling other extensions to see if there's a clash - something that ReSharper doesn't like being installed at the same time. Alternatively (or better yet, as well) you can profile Visual Studio to see what's going wrong. Go to ReSharper → Help → Profile Visual Studio, and ReSharper will download the profiler, attach to Visual Studio and start to gather info. Once you've demonstrated the problem, click "Get snapshot", and ReSharper will save the snapshot and add it to the dialog as an attachment. You can then describe what you were doing and submit the snapshot and description to the dev team.
I'd also suggest downloading the latest build - the 9.2 EAP has just started, and contains a number of fixes that might help performance under certain circumstances.
Also, what are you typing in - what language, what size file?
I've got a relatively small project written in ASP.NET MVC3. After working a while, Visual Studio 2010 becomes very slow in Razor views (other file types work fine). With "slow" I mean "every keystroke takes around 1 second to register". It doesn't matter what that keystroke was - typing a single letter is as slow as pasting a screenful of markup. During this slowdown VS2010 consumes 1 CPU core to 100%. After I restart VS2010, everything goes smoothly again for a small while. This happens in any and all Razor views.
My PC isn't the best, but it should be enough: Core 2 Duo 6700, 4GB of RAM (currently only 75% filled with VS2010 being slow and all, so it's not a RAM shortage), Windows 7 x64.
The project is close to an end, and I remember that for most time there were no problems. This has started only recently, although I cannot imagine what could have caused it.
Does anyone have any ideas about what could be wrong and what could be done to fix it?
It is plugins - TFS/AnkvSVN and ReSharper have all caused problems for me.
Turn them off one by one, to discern which one (if only one) is causing you grief.
When you find the culprit, make sure you keep up on any patches with it.
In extreme cases, turn if off if you have a long development session and don't need it the whole time (SVN for instance could be turned on when you are ready to do commits and check ins, etc.)
The issue is resolved for me, by installing the Mvc Html5 Templates.
After the installation, I picked XHTML5 and then back HTML5 from the "Target schema" combo box. After that, the paste was instant!
Edit: I uninstalled "Mvc Html5 Templates" and the issue didn't reappear. Perhaps it has something to do with the "HTML 5 Intellisense"
Have you installed sp 1 it fixed some performance related issues when loading IntelliSense for markup
Run the Resource Monitor (CTRL+SHIFT+ESC, click Performance tab then Resource Monitor button at the bottom). Pay special attention to disk I/O and perhaps CPU usage.
Sort disk I/O by Total B/Sec descending. As you type, see if it can identify a process which is causing the issue. Hopefully it's a virus scanner or some other famous performance destroyer and not the Visual Studio process itself, which wouldn't be very helpful.
Have you tried opening the same project on a different machine? This will give you an idea whether issue is in the project or VS install. Quite obvious, but is there anything in the event viewer. Are you connected to a domain while this is happening?
Well, for me the problem has turned out to be anti virus - we use (or are made to suffer) Sunbelt Vipre on our workstations and as soon as I switch off active protection (so that's basically disabling AV completely) all of a sudden all the performance issues in all windows are gone.
Sorry for adding another answer, but there seem to be lots of different causes, so - lets list all possible fixes here.
I tried disabling ReSharper and other addons - did not work. What did work - is reapplying the SP1 again.
PS. Weird, I know. Don't ask, no idea... My guess is - VS was "repairing" itself silently at some point and restored some non-SP1 components.
PPS. You might also want to try disabling "Productivity Power Tools" addon. If you have ReSharper installed - almost all the PPT features are already there, in ReSharper.
PPPS. I have a blog post with several performance tips for Visual Studio & ReSharper, might come handy..
Have you tried Cleaning the solution?
In my case, high CPU usage started out of nowhere (WPF project). Restarts of Visual Studio didn't help, neither disabling/uninstalling addons. But Cleaning the solution did help!
I was experiencing a very similar issue on a large cshtml file in VS 2015 and was solved for me by turning off all of the automatic formatting options in Options > Text Editor > C# > Formatting > General:
I then use the "Control+K,D" key combination to format the page once I have finished making the necessary code changes.
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.