I'm having some problems getting the Diagnostic Tools in Visual Studio 2015 (with Update 3) to start. I build and launch a project in Debug Mode, the Diagnostic Tools window pops up with the text
Starting Diagnostic Tools...
and after around ten minutes this text disappears but the Diagnostic Tools window remains (with nothing on it). There is no output in the Diagnostics Hub, either. This happens on both x86 and x64 platforms, running VS as administrator doesn't help either.
VShub.exe an the Visual Studio Standard Collector Service are both running.
EDIT: It now fails sooner and the Diagnostic Tools window gives thhe following message:
The diagnostic tools failed unexpectedly. The Diagnostics Hub output in the Output window may contain additional information.
And now the Diagnostics Hub window has the following message:
VsHub failed to locate/start service.
This is an environmental problem, software that is running on the machine is interfering with the proper operation of VSHub.exe. Underlying issue is that it operates a lot like malware does, attaching itself to another process (the program you are trying to debug) and then using a named pipe to talk to another process (the IDE). The "failed to locate/start service" is the diagnostic message for not being able to connect the named pipe.
This behavior is enough to raise the hackles or trigger a bug in the kind of software that tries to stop malware from doing this. Products like Avast, AVG, Sophos, ESET, McAfee have been identified before for being especially unfriendly on a developer's machine. Avast in particular needs to be singled-out as a product that has never stopped causing trouble.
The test is simple, just de-activate the product and check that the delay is now gone. You might limp along by adding specific exclusions for vshub.exe and devenv.exe, but choosing a product more compatible with what a programmer does every day is wise. I've seen, and personally experienced, very few problems with the antimalware solution included with Windows.
Related
Today my CPU Usage Performance profiler in Visual Studio stopped working. I start it, it seems like it's working, you can see the graph of the CPU going up and down but when it finishes I get no data with the message:
"There is no data in the current set of filters."
I have tried every combination of categories and filters with no luck. I restarted Visual Studio, I rebooted the workstation, I tried against a new hello world project. Other performance tools seem to work (e.g. the .NET Object Allocation Tracking tool works). To (try) to rule out that it was something specific in my project I was able to successfully run it on a 2nd workstation against the same set of code. I have also run VS without extensions and also in regular mode after disabling everything I've added in (like ReSharper).
Edit: Additionally I just found this in the Windows Event Viewer.
System.Runtime.InteropServices.COMException: The method or operation is not implemented., System.Object get_Value()
at EnvDTE.Property.get_Value()
at Microsoft.VisualStudio.PerformanceTools.ProjectTarget.LoadBinaryProject(IVsHierarchy hier)
at Microsoft.VisualStudio.PerformanceTools.ProjectTarget.LoadProjInfo()
This also just popped up in the Event Viewer under "Windows Error Reporting" that referenced a Watson VSTelem.Out error:
Fault bucket 125730739576, type 5
Event Name: PerfWatsonVS12Data
Response: Not available
Another oddity is, I just ran a profile session for maybe 20 seconds, however when it's done VS says "Diagnostic session: 127:47 minutes" which would be the about the time I first time I tried it this morning if it never stopped. I did a repair of Visual Studio from the installer and the profile worked for 1 session after, the 2nd session then reverted to the aforementioned behavior again.
I'm currently using:
Visual Studio 16.8.5 16.9.1 16.9.2 16.9.3 16.9.4 16.11.2
.NET Core SDK: 5.0.201
Windows 10 Version 2004 Build 19041.867
Any thoughts on fixes?
Edit: According to the following link, it might be related to a Windows Update and a bug in my NVidia driver:
https://developercommunity.visualstudio.com/t/no-data-in-cpu-usage-tool-windows-update-related/1384519
Microsoft confirmed the problem, as soon as a solution or workaround is found - report it. Follow the forum https://developercommunity.visualstudio.com/t/profiling-cpu-still-states-no-user-code-was-runnin/607535?from=email&viewtype=all#T-ND1373491
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'm looking for tips for those who to develop for Windows XP embedded in Visual Studio2013, then debug in Visual Studio 2010.
The reasons for this are discussed in this Stack Overflow Link on the topic.
Essentially the remote debug protocol changed after VS2010, and the new msvsmon.exe which uses the new VS2013 protocol doesn't support XP embedded debugging. So we are forced into a TWO IDE solution, one for builds, another for debug. VS2013 is used for builds, and VS2010 is used to launch remote debug sessions.
There is some misinformation about the requirement to purchase both VS2013 and VS2010. It appears from the previously mentioned link, that it's possible to obtain the VS2010 debug environment for free. I was able to verify the free download of the components, but haven't had time to validate that the debug environment works. The environment I use consists of a licensed copy of VS2013 and a licensed copy of VS2010.
Here are two initial problems which I haven't seen doing remote debug in the former VS6 msvsmon.exe environment:
1) With VS2013 build projects, VS2010 does not want to open the *.sln file. If I open the VS6 .dsp/.dsw we ported from VS2010 does a "ONE TIME CONVERSION" which destroys my painstakenly built VS2013 build project.
It seems I will have to build TWO different solution spaces, one named SOLUTION_NAME_VS2013 and another SOLUTION_NAME_VS2010. I'm interested to know if there is a more elegant solution to manage 1 set of BUILD files with two different "Highlander" (there can be only one) IDE's.
2) When starting up the project remotely, if it crashes I get one of those annoying "Your program has crashed" dialogs on the Win2012 debug host (running VS2010), which is trapping the crash signal from the debugger. About 30% of the time, it detects the running instance of VS2010, 70% of the time it doesn't.
3) msvmon times out (needs restarting) and requires extra time/mouse clicks to setup over the old vs6 msvcmon.exe
I'm wondering if other Windows Embedded developers have discovered elegant solutions for these issues. I'll post what I find here if I find any more tips moving forward.
For Issue #1: Unable to read VS2013 *.sln file in VS2010.
The problem was that the VERSION of Visual Studio 2010 must be at least SERVICE PACK1. Earlier versions of Visual Studio 2010 cannot read the VS2012/VS2013/VS2015 solution files.
For Issue #2: Your program has crashed dialog preventing signals from reaching debugger.
This Stack Overflow link was helpful. There are multiple ways to suppress the "Your program has crashed" dialog. In my case, users may need to debug new applications on a production system, so changing the setting globally is not ideal.
I choose the solution from this Raymond Chen link it allows me to disable the dialog box on an application by application basis. Since I typically have access to source code I'm debugging this was the best solution for me.
DWORD dwMode = SetErrorMode(SEM_NOGPFAULTERRORBOX);
SetErrorMode(dwMode | SEM_NOGPFAULTERRORBOX);
I still see an issue occasionally with the Windows runtime not seeing the running debugger instance on a crash and wanting to initiate a new one. This seems to happen ~30% of the time. When I figure out what is causing that I will update it here.
Finally, the new remote debug client changed to msvmon.exe which has improved security. To save the extra mouse clicks, the following command is usefull to run on the remote Windows Embedded XP client:
"Path\to\msvsmon.exe" /anyuser /noauth /nosecuritywarn /timeout:2147483646
The /noauth and /anyuser require /nosecuritywarn. /timeout max value keeps the debugger client from terminating after ~ hour of idle time. If your workday is to be spent debugging you don't want it timing out after a coffee/rebuild all break.
I recently installed VS2010 Ultimate on my Windows 7 Ultimate 64-bit Edition computer and I receive "An unhandled exception of type 'System.ExecutionEngineException' occurred in mscorlib.dll" randomly (or so it seems) when starting the IDE. If I reboot the computer then about 50% of the time the IDE will start normally. If not, I have to keep rebooting until it finally behaves normally.
I've looked around on various sites and this seems like an error that comes from many different problems ... any idea on why I might be receiving it, or something I should be checking for?
Thanks for any help or advice you care to offer.
Have you checked the system event log? There might be some clues there. You can also try a couple of the VS command line parameters such as Log, SafeMode, ResetSettings.
Another approach which is more advanced and not for the faint of heart is to use Debugging Tools for Windows to start devenv.exe from WinDbg to see what causes the crash by looking at what threads are doing (stack trace, etc.).
When trying to execute from within Visual Studio 2008 your application and you get the (uninformative) message "The operation could not be completed".
The solution to this is to turn off the "Visual Studio Hosting Process".
The problem with turning off this "hosting process" is that all the "run and rewrite" functionality is no longer available. OK, so this isn't a big deal, but I'm always getting this message no matter what machine I use (and it might be nice once in a while to use the rewrite and execute functionality).
Am I doing something wrong? How come this "feature" within VS seems to complain so readily? Do other people have success with enabling the hosting process and making use of it?
The problem with turning off this "hosting process" is that all the "run and rewrite" functionality is no longer available.
The Visual Studio Hosting Process is not needed to allow Edit and Continue. It is used for "Design time expression Evalutation" in the case where the project is a dll rather than an EXE. It is also used to provide debugging for partial trust scenarios. See the documentation for everything it does.
It is highly unlikely it does anything you need, so don't feel bad turning it off.
Is your project output folder set to a network share?
If so, try changing it to a local folder and see what happens. It appears that VS is not always able to terminate the process if the host exe is running from a share.
The other possibility is that the project is open and running in debug mode on another instance of Visual Studio - although I suspect you will allready have ensured this is not the case.
I honestly have never seen this message and I work with Visual Studio for at least 8 hours a day. Is this reproducible on other machines? If so is there anything weird or abnormal in your code that could cause this to crash?
I use 4 different machines and have got this situation on all of them. I understand what is causing the problem - it is that the VS hosting process isn't terminating after the first debug session ends, which means that the next time that you try to compile the exe the hosting process is locking the exe and preventing compilation. Another solution therefore is to use Task Manager to kill the VS hosting process and compile and debug as normal but thats even more of a hassle!
I can't think that its anything in my code that would be causing this - its probably a VS issue itself isn't it?
Here's the anwser: disable "Enable he Visual Studio hosting process" in he debug tab of your projects properties.
I found it here:
http://social.msdn.microsoft.com/Forums/en-US/vbide/thread/40d2d241-a0c0-4137-9da9-e40611972c0e/
There are several causes and workarounds regarding to this problem and you might try the following ones that are useful most of the time:
Delete the "Your_Solution_FileName.suo" file and restart Visual Studio.
or
Right click on the project and select Unload Project and then click Reload Project by right clicking on the project again might also fix it.