I’m trying to get the Diagnostics Tools in Visual studio 2019 to work while having multiple instances of Visual studio running.
One is fine two works. Three or four, there is where the trouble starts.
Then I get
The diagnostic tool failed unexpectedly.
And in the output window.
Failed to enable provider {E13C0D23-CCBC-4E12-931B-D9CC2EEE27E4}: Insufficient system resources exist to complete the requested service.
My main question is, what system resources?
Is it not memory, I have 16Gb free. Not cpu, it is mainly ideling, and there is plenty of disk.
It does no matter if the other Visual studios are running a debug. Even if I just opened the solution and did nothing after that, they still seem to take up the “system resource”.
Does anyone have an idea of what system resource to get more of? Or is it some limitation / bug in the Diagnostic tools that cause this?
UPDATE
I gave up. Almost a year later and several updates of visual studio, the problem is still present and I have not found the source and have no clue why this keeps happening.
I have visual studio 2015 enterprise edition, update 1.
When idle, the visual studio process is using around 10-15% cpu constantly.
I tried the solutions provided here with no success.
The solution includes 11 c# projects.
The issue seems to appear only after the first compilation after the solution.
In my case a few *.mdb files had been added to the solution which triggered a constant cpu usage of 30-35%.
So generally the content of a solution triggers background tasks which can lead to high cpu usage. If that usage occurs suddenly, it's worth to get maybe an older source version to check, if the problem is related to added files.
In my scenario the visual studio process remained active using cpu even after closing visual studio. Using process explorer I identified two threads using the cpu indicating following start addresses:
clr.dll!CreateApplicationContext
devenv.exe!IsAssertEtwEnabled
After a lot of attempts and tests to fix this issue, I finally discovered the source of it.
I had a Code Map dgml file in the solution.
Removing the file fixed the issue, and now the devenv process cpu consumption returned to normal.
UPDATE:
After some time working, it seems that just removing the Code Map dgml didn't entirely solve the problem. The solution at last was to remove the reference to the "Modeling Project" containing it(along with other documents such as Sequence Diagrams...).
I'm currently evaluating Visual Studio 2015 RC. I've noticed when running the IDE, The Visual Studio 2015 process is constantly at around 25% CPU usage. Even without a project loaded and without the welcome page it is gobbling up 25% CPU usage at a constant rate. No other applications running other than background services. All other running processes use around an additional 2 to 4 percent CPU overall.
This behavior has also been noticed in Visual Studio 2013.
Is anyone else seeing this behavior? Is this normal? Any suggestions?
Had this same problem. Processor constantly at 45-50% even when the IDE is completely idle.
Turns out the problem is the Microsoft Git Source Code provider.
I turned that off and processor dropped to 0 and the IDE became much more usable.
In my case disabling Telerik ASP.NET MVC Extension solved high CPU issue.
High CPU load started on solution load and didn't drop (40% with one, 80% with two solutions) until VS was closed or even sometimes after (had to kill the process).
Tools->Extensions and Updates->Installed, find the extension and click 'Disable'.
In my case all reference counts tried to update every time when I edit code.
I have just turned them off. You can do it this way.
It’s not to be expected that Visual Studio should chew up continuous CPU time.
I am running Visual Studio 2015 Community RTM right now with a medium sized project open, and am not seeing any ongoing CPU usage (according to Process Hacker 2, which shows usage as small as 0.01 percent). It’s just blank, which means not even 0.01% CPU usage is registering.
Keep in mind that IntelliSense scans your project files in the background to build the database for popping up its suggestions, etc.
Choosing Project > Rescan Solution from the menus will result in that process being done over, which will cause the CPU to be used for a time. But it should ultimately go quiet.
Seemingly forever, there have been times when deleting the Intellisense Database files and doing a full rescan solves “odd behavior” type problems. I don’t know if it’s the “prescribed” method, but if I suspect an IntelliSense problem I just delete the .sdf file in the project folder if I want to make sure Visual Studio starts with a clean slate. This isn’t necessary very often.
I also had this problem, constant 20-40% CPU when idling (Visual Studio 2015 update 1). I noticed that other local repositories of the same code did not have this problem.
I deleted the problematic local repository and took a new checkout, this solved the issue for me. Why this worked, I unfortunately cannot explain...
I run resharper, turned that off and turned off the Microsoft Git provider and still had high CPU issues, devenv.exe would also run after close... until recently.
It appears VS 2015 Update 2 has resolved these issues!
https://www.visualstudio.com/en-us/news/vs2015-update2-vs.aspx
In my case; "Visual Studio 2015 Update 1" gone crazy editing JS files regarless of the length of the source. It used high CPU and the editor is even freezed. I fixed the issue by disabling the 3rd party add-ons by one-by-to detect the buggy one causing VS 2015 malfunctioning.
Hope it works.
In my case, the culprit was Node.js tools for Visual Studio. I had v1.1.2 installed and the cpu was constantly around 25-40%.
A switch to Node.js Tools v1.2 RC resolved the problem completely after an initial high load that went away in a couple of minutes.
In my case it was either the Roaming Extention Manager or most probably the azure worker role project in my solution. If you have one of these try unloading it and restart visual studio. I can reproduce it but I don't know why it happens.
I've noticed also that when running and stopping a debug episode on the local server, if the page is still open in the browser, VS will continue to run at high CPU. Closing the browser page stops this.
I want to share my experience,
In my case I had to diable all extensions and updates and code analysis c#.
1-For extensions and updates :
Tools => Extensions and updates
2-For the code analysis
Solution explorer => right click on the project => Properties =>Click on the tab "Code analysis" => click on the "Open" bouton => Uncheck the checkbox "Microsoft.CodeAnalysis.CSharp" => save and exit.
Cpu usage descended to 1 %.
In my case, The .suo file in Visual Studio was the culprit. Deleting it fixed my issue.
Refer below link for more details.
https://shemeerns.com/2014/04/04/the-solution-user-options-suo-file-in-visual-studio/
Visual Studio Ultimate 2013 has been a nightmare. There seems to be a long delay between when I press a key and when it appears in the code editor window. When I scroll, either in the code editor or in the navigation pane, it takes many seconds. I've had similar problems with VS 2010 and VS 2012 (see Visual Studio 2012 Ultimate slow while editing C# code). Another person had a similar problem, none of their solutions helped me with mine (Visual Studio 2012 Ultimate slow while editing C# code).
My machine is running Windows 8.1, has an Intel i7 and 16GB of RAM, and a Samsung SSD. It's pretty fast.
What I've experienced:
Visual Studio absolutely hammers the registry per Process Monitor
HKLM\SOFTWARE\Wow6432Node\Microsoft\CTF\KnownClasses
HKLM\SOFTWARE\Wow6432Node\Microsoft\Cryptography\Defaults\Provider Types\Type 001 HKLM\SOFTWARE\Microsoft\Cryptography
HKLM\SOFTWARE\Wow6432Node\Microsoft\Cryptography\Defaults\Provider
Types\Type 001\Name HKLM\SOFTWARE\Microsoft\Cryptography\MachineGuid
HKCR\Drive\shellex\FolderExtensions, HKCU\Software\Classes
HKLM\Software\Wow6432Node\Microsoft\Cryptography\DESHashSessionKeyBackward
HKLM\SOFTWARE\Wow6432Node\Microsoft\Cryptography\Defaults\Provider\Microsoft
Enhanced Cryptographic Provider v1.0\Image Path
Processor Monitor also shows that, when I attempt to interact with the code in any way, VS literally kicks off about 85,000 events, all containing access to files in the project and the registry keys listed above. There are also a lot of 'NotifyChangeDirectory' events to my user home directory and a lot of 'Thread Create' and 'Thread Exit' events.
What I've tried:
deleting files/folders in the AppData temp directory unchecked
hardware graphics acceleration (Tools > Options > Environment)
disabled source control plugin (Tools > Options > Source Control)
disabled synchronized settings (Tools > Options > Environment)
disabled auto recover (Tools > Options > Auto Recover) reinstalling
SQL server compact edition 4.0 deleting the .SUO file disabled
codelens rebooting (too many times)
This behavior also happens when I start Visual Studio in safe mode.
Per Task Manager, Visual Studio isn't consuming a lot of CPU/RAM (up to 3% CPU, 150MB of RAM). Additionally, not using BitLocker, disk is unencrypted, and no add-ins are installed in Visual Studio.
This is really, really bad. It's become practically unusable. If anyone has any idea how to fix this, I will be in your debt.
This did it.
I really hope this keeps someone from jumping off the bridge.
NoGit is a great extension, but ultimately it came down to removing the registry entries for the Git source control provider.
http://blog.markrendle.net/disable-the-git-source-control-add-in-in-vs2013-permanently/
Is it somehow possible to measure the CPU and/or IO requirements for all installed Visual Studio Addins / Extensions (VS 2012 / 2013)?
Concrete Problem: I have quite a lot of Extensions and Addins for Visual Studio 2013 installed and in general it runs smooth, just sometimes i experience ~5-10 sec spikes where VS just freezes. (Without any Addins or Extensions it doesn't happen).
Any idea how to find the problem?
If it reproduces often enough, you can just attach a debugger to Visual Studio and break in when something is going bad. Conveniently, Visual Studio is a debugger, so if you launch two instances in and in one go Debug > Attach to process, you can just attach to the other. When you hit the issue, break in (quickly) in the other and look at the main thread (it's labled in the threads window.) Look at the stack to see if there are any obvious offenders...
When VS freezes you can run ProcDump and then analyze the stack for an offending extension. Alternatively Process Explorer has a nice real time threads and stack monitor.