Using Visual C# 2010 Express, when I throw an exception it takes about minute and a half for the debugger to break on a user unhandled exception. During this time the application I'm debugging and visual studio are completely unresponsive and VCSExpress.exe processor usage jumps to 12-14%. The rest of the computer (mouse, other applications, etc.) remains responsive.
Visual studio isn't completely unusable but it is definitely slowing my application down when running from the debugger. I haven't been able to find the real source of the slowdown yet. This happens right at startup and isn't a problem that gets worse over time.
I have disabled my antivirus (eset nod32 v7) and do not have any extensions installed. My CPU is an Intel Core i7 740QM # 1.73GHz (quad-core hyperthreaded). OS is Windows 7 Professional. I've updated Visual C# 2010 Express to SP1 (Version 10.0.40219.1 SP1Rel). My hard disk shows no warning signs via S.M.A.R.T.
I have two extremely simple test scenarios written in WPF. In the first scneario I simply throw an exception when the button is clicked:
private void button1_Click(object sender, RoutedEventArgs e)
{
throw new InvalidOperationException();
}
I manually measured the time between when I click the button and when Visual Studio displays the thrown/user unhandled exception dialogue box (and thus becomes responsive again). I tested the timing for breaking on thrown versus user-unhandled exceptions when, with and without antivirus (AV), and with and without the Visual Studio Hosting Process (VS):
Debug, Unhandled, AV on -- 1:35.3, 1:38.0
Debug, Thrown, AV on -- 0:10.4, 0:11.5, 0:11.1
Debug, Thrown, AV off -- 0:10.7
Release, Thrown, AV off -- 0:9.1, 0:10.0
Release, Unhandled, AV off -- 1:34.5
Release, Thrown, AV off, No VS Hosting -- 0:8.9, 0:9.1
Release, Unhandled, AV off, No VS Hosting -- 1:19.6, 1:20.9
When breaking on unhandled exceptions, it takes 1:30 (1 minute, 30 seconds) to recover. Antivirus makes no difference. Taking away VS Hosting saves around 15 seconds. Release mode saves about 1 second. Switching to breaking on thrown exceptions has significant savings (10 seconds to recover), though this still is not acceptable.
My second test scenario is for timing a caught exception inside and outside of Visual Studio:
private void button2_Click(object sender, RoutedEventArgs e)
{
System.Diagnostics.Stopwatch sw = new Stopwatch();
sw.Start();
try
{
throw new InvalidOperationException();
}
catch { }
sw.Stop();
label1.Content = string.Format("{0:0.000} seconds", sw.ElapsedMilliseconds / 1000.0);
}
For this scenario, I set VS to break only on unhandled exceptions so I could get timing data for simple caught exceptions. I ran this in VS and outside of VS as the stand-alone EXE:
Release, Unhandled, AV off, No VS Hosting -- 0:1.965, 0:1.812, 0:1.985
Debug, Unhandled, AV off, No VS Hosting -- 0:2.333, 0:2.136, 0:2.305
Release EXE, AV off -- 0:0.002, 0:0.000, 0:0.000
Debug EXE, AV off -- 0:0.002, 0:0.000, 0:0.000
Outside of VS there is no slowdown. Inside of VS this takes about 2 seconds, which still seems pretty excessive for a quad core hyperthreaded CPU and a tiny try/catch block.
I'm pursuing some of the leads in the linked questions (system environment settings, etc.) and monitoring the file system/disk activity to see if I can get any leads. Any additional help is much appreciated!
btw, I'd prefer not to re-install Visual Studio or my OS
Thanks!
Update
I've installed VS 2012 Express, and the numbers are:
Test 1:
Debug, Unhandled, AV off -- 0:01.6
Debug, Thrown, AV off -- 0:01.1
Test 2:
Debug, VS Hosting -- 0:1.202
Debug, No VS Hosting -- 0:1.191
Release, VS Hosting -- 0:1.220
The numbers in VS2012 are much better. Clearly one solution to my problem is upgrading to VS2012, which is what I'm planning on doing. But I'd still like a resolution to this problem if anyone has any ideas.
Related
i have a C# project that i'm working on and i'm trying to debug an issue that cause an unhandled exception. The problem is that whenever i place a breakpoint and it gets hit if i press "Step Into" it simply resumes execution instead of stepping to the next instruction. Does anyone know how to step C# instructions 1 by 1 instead of resuming execution?
I'm using Visual Studio 2019 on Windows 10 to do the debugging. The project is a solution with multiple projects where the main project is written in C# with others written in C++ and C. I am able to load the symbols successfully for the C# project.
Here is the github repository.
Edit:
The project i'm working on is an NES emulator called Mesen and the issue i'm trying to debug is an unhandled exception during online play. The exception triggers apparently randomly and i've tried multiple actions to try and trigger it but it still only happened on its own.
private void StartEmuThread()
{
if(_emuThread == null) {
_emuThread = new Thread(() => {
try {
InteropEmu.Run();
_emuThread = null;
} catch(Exception ex) {
MesenMsgBox.Show("UnexpectedError", MessageBoxButtons.OK, MessageBoxIcon.Error, ex.ToString());
_emuThread = null;
}
});
_emuThread.Start();
}
UpdateMenus();
}
I'm trying to put a breakpoint on InteropEmu.Run() and single step from there but every time i hit step into it just resumes the program.
Here is a screenshot from visual studio during when i hit the breakpoint on InteropEmu.Run()
And here it resumes after i press step into at the top in the debugging toolbar.
Here is the exception that i'm trying to troubleshoot
Thanks
I've tried out some different build options and it turns out single stepping is disabled for Release builds but not for Debug builds. I tried a debug build and this time it worked.
I try to deploy a Click Once Installer but run into a very strange issue:
The installer runs fine but as soon as the application is supposed to start it crashes with the following message
[MyApp] has encountered a problem and needs to close. We are sorry for
the inconvenience.
and no useful information about the cause. As soon as I install Visual Studio Professional 2012 on the same machine, the application starts fine but sometimes behaves very strange (e.g. I have to click to red close button twice to close the application). Funny enough, the problem not always appears, I suspect it has something to do with the order in which I install the .Net Framework/Visual Studio/the Click Once installer.
I am pretty much lost here .....
Btw: The framework targetVersion and supportedRuntime of the Click-Once installer are 4.0 and 4.0.30319 respectively.
Add an UnhandledException handler to your app. This will allow you to see the exception that is causing the crash.
AppDomain.CurrentDomain.UnhandledException += new UnhandledExceptionEventHandler(MyHandler);
static void MyHandler(object sender, UnhandledExceptionEventArgs e)
{
Exception ex = (Exception)e.ExceptionObject;
MessageBox.Show("Unhandled domain exception:\n\n" + ex.Message);
}
Note that the use of MessageBox is only for debugging. A logging system should be used for your release version.
I found that one of my tests that passes in VS2013 is failing in VS2015, the test calls a service that includes among other things a call to Console.Clear();
to find out whats going on I made a simple unit test
[TestMethod]
public void ExampleTest()
{
Console.Clear();
}
This test passes in visual studio 2013 but in 2015 I get the following error:
Test Name: ExampleTest
Test FullName: solution.Common.Test.CacheManagerTest.ExampleTest
Test Source: C:\solution.Common.Test\CacheManagerTest.cs : line 34
Test Outcome: Failed
Test Duration: 0:00:00.3015003
Result StackTrace: at System.IO.__Error.WinIOError(Int32 errorCode,
String maybeFullPath) at System.Console.GetBufferInfo(Boolean
throwOnNoConsole, Boolean& succeeded) at System.Console.Clear()
at sol.Common.Test.CacheManagerTest.ExampleTest() in
C:\solution.Common.Test\CacheManagerTest.cs:line 35 Result Message:
Test method Alexandria.Common.Test.CacheManagerTest.ExampleTest threw
exception: System.IO.IOException: The handle is invalid.
I do understand that it is bad design for my service to fail if it is not called by a console. The reason I am asking this question is to understand why this is failing in the new version of Visual Studio. Is this the intended behavior? What changed?
I did not see anything obvious in the change log that would seem related to this.
Edit: I am calling the Console.clear from the following dll
Microsoft\Framework.NETFramework\v4.5.1\mscorlib.dll
Edit 2:
picture of testproject properties in both visual studios
The changes in VS2015 are pretty visible, use the Test > Debug > All Tests to get insight. You can see that it now has a new test host process, its name is TE.ProcessHost.Managed.exe, stored in the C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\CommonExtensions\Microsoft\TestWindow directory.
Previous versions of VS used a different host, vstest.executionengine.exe. One notable change in the new test host is that it is no longer a console mode program. Something you can see by running Dumpbin.exe /headers on the exe.
Another way to see the underlying problem is with Task Manager. Note how running a test in an older VS version causes a conhost.exe process to get added. This is the process that owns the console window for a console mode app. A problem I've seen before is that this process tends to leak, not terminating when the test completes. Adding ever more conhost.exe instances, at one point researching this problem I had 12 of them running. Presumably the changes in VS2015 were meant to address that problem.
Technically you can configure the unit test with a .runsettings file and use the <ForcedLegacyMode> element to force the old test host process to be used. This however has no effect on the outcome of this test, looks like they addressed this in multiple ways.
That's a fair amount of guessing, I recommend you use connect.microsoft.com to file a feedback report. You can quote this Q+A for reference.
Meanwhile, you can consider a workaround. Do note that Console.Clear() is in general a trouble-maker, it will also fail in normal usage when the output of a console mode app is redirected. Very easy to do from a command line prompt with the > operator. Which is the ultimate reason it fails in a unit test. You'll want to make the code resilient so it can work properly both in production and in a unit test. Like this:
if (!Console.IsOutputRedirected) Console.Clear();
Which requires targeting .NET 4.5 or higher. You can use the code in this SO post if you need to target earlier versions.
Few lines program perfectly works if running with ctrl+F5 (not debugging) but throws exception when running with F5 (debugging):
private static void Main(string[] args)
{
IWebDriver driver = new ChromeDriver(#"C:\Program Files (x86)\ChromeDriver");
This statement throws "No connection could be made because the target machine actively refused it" exception with no inner exception.
Again, it works perfectly with ctrl-f5
Windows 7 x64
VS 2012
Using Selenium WebDriver NuGet Packcge 2.35 (latest)
Using ChromeDriver.exe (v2.4.226107) (latest)
All firewalls and antivrus etc was killed.
Running VS as admin and UAC turned off
Why is this difference between debugging and running without debugging?
(I know that debugger has a host process please do not explain that)
How can I run this simple program in debug mode?
Any ideas?
Thx in advance
Thanks for all who spent time with reading and thinking about this question.
I've solved it. Well, it's a stupid thing but I am pretty sure that similar questions here complaining Selenium WebDriver and
"No connection could be made because the target machine actively refused it" exception
has this resolution, and other answers there missed the correlation between the issued solved and taken actions. Most of them suggest use other version of ChromeDriver.exe and talking about version incompatibility and ChromeDriver.exe bugs.
I think (at least my case) these resolutions are false.
The "error" comes from the WebDriver assembly and not about ChromeDriver.exe. I've examined the source of WebDriver, here it is:
while (!processStarted && DateTime.Now < timeout)
{
try
{
request.GetResponse();
processStarted = true;
}
catch (WebException)
{
}
When the DriverService class starts the ChromeDriver.exe immediately starts polling it with requests. Because it takes time the process to start, the port is not open for the first few dozen try... (at least a Sleep(10) or Sleep(50) would be nice here, but anyway)
Now the point: If you are so unlucky, you not checked the VS 2012 Options/Debug/General 'Enable Just My Code' and you checked the Debug/Exceptions/Thrown then debugger will break by this exception, but of course you will not see the source, the exception line will be your line
IWebDriver driver = new ChromeDriver(#"C:\Program Files (x86)\ChromeDriver");
Depending on timing (process start), you can get couple repeated time, and you will think your port, firewall, ChromeDriver.exe version, etc has to do with the exception.
I had this error at one point as well..and after hours of debugging..finally got the real error to show...my view for the I.E. browser was set at 125%...and when I changed it back to 100%...it worked. :)
As the title says, VS2008 keeps crashing on me whenever I debug a project when a certain form is open. I attached another VS2008 instance to it and found the following exception to be the culprit:
System.Runtime.InteropServices.COMException occurred
Message="Catastrophic failure (Exception from HRESULT: 0x8000FFFF (E_UNEXPECTED))"
Source="mscorlib"
ErrorCode=-2147418113
StackTrace:
at System.Runtime.InteropServices.Marshal.ThrowExceptionForHRInternal(Int32 errorCode, IntPtr errorInfo)
at Microsoft.VisualStudio.NativeMethods.ThrowOnFailure(Int32 hr, Int32[] expectedHRFailure)
InnerException:
The problem I'm having is that I have no idea why this would happen. We use a few COM components (this is an old version of software I'm updating), but they don't cause any exceptions when the program is actually running, or when viewing design view normally. Only when I debug when the form is open. The program itself runs fine when debugging after VS's crash, but Visual Studio itself is hosed.
I know the simplest answer is to "make sure that form is closed!" but it takes forever to load and it's a much smoother workflow to keep it open (plus, I don't always remember to close it!)
So, has anyone run into this? Does anyone have any ideas why this might be happening?
You could try to 'refresh' you IDE istallation by command line:
devenv.exe /setup
/setup - Forces Visual Studio to merge resource metadata that describes menus, toolbars, and command groups, from all VSPackages available.
or run it with detailed logging to see what's happened:
devenv.exe /log
/log - Starts Visual Studio and logs all activity to the log file.
See MSDN: Devenv Command Line Switches for the rest of supported Visual Studio IDE switches