I'm working on a VB.Net program in debug in Visual Studio 2010 (10.0.40219.1) (Windows XP 5.1 2600.xpsp-sp3-gdr.120821-1629), and have noticed that while debugging it runs very slowly. When run as an executable (even the debug executable) it bowls along at a splendid speed.
The cause appears to be that the development environment is generating large numbers of exceptions (appearing in the immediate window).
A first chance exception of type 'System.ArgumentNullException
occurred in Microsoft.VisualBasic.dll
Does anyone know what the cause of this might be? It doesn't appear to have any adverse effect on the running of the program, other than to take a long time to get to the bit I'm trying to find the bug in. The exception doesn't appear to be related to any particular patch of code, and indeed it doesn't happen for most other projects.
I found an answer to a similar question for you:
A first chance exception
I would pay specific attention to the suggestion by Marcus Andren:
If you want to pinpoint where the exceptions are occurring, you can
select the Debug->Exceptions menu item, and in the dialog that
appears, check the first checkbox for "Common Language Runtime
Exceptions". This will make the debugger break as soon as an exception
occurs instead of only breaking on unhandled exceptions.
This is also one reason why it is generally a bad idea to catch
generic exceptions unless you are clearly logging the information
caught.
Related
I'm not sure if I'm missing something here, but it doesn't appear to be possible to debug exceptions in Jetbrains Rider.
I have an incredibly simple piece of code that throws an exception (invalid file name) and there is no way I can find to
a) stop on the exception line in my code raising the exception, and
b) view the value of any variables in my source code that may have contributed to the exception.
I've recorded a sample video here that shows the debug attempt, and why it seems illogically impossible.
Has anyone found a way of debugging this stuff? Is Rider actually broken?
Sample video showing (attempted) debug session
For anyone experiencing the same situation, enable "Any Exception" and disable "Only break on exceptions thrown from user code" in Breakpoint Options.
You can also (as #mu88 mentions) disable debugging of external sources, but that simply reduces the clutter in stack frames.
I have got a minigame.exe which crashes at some point inside the game. It does not show any error message and it just says Not Responding. I am using Win 7. I want to identify the crashing point and try to fix the games problem. I think the problem might be caused due to a specific DLL imported by the executable. However, I have no clue about how to find out that specific assembly line and try to patch the executable with OllyDBG.
With the information given, this answer would need a full tutorial style, which is considered as too broad for this site. But the first step, finding out what type of crash it is and where it occurs can be explained.
I'll use WinDbg as the debugger, since I'm not familiar with OllyDbg. It is is part of the Debugging Tools for Windows and it's freely available. Install the versions, x64 or x86, that matches minigame.exe.
Start WinDbg, use the correct bitness
Run minigame.exe under WinDbg (File/Open executable). It will stop at the initial breakpoint.
Set up the symbols, at least .symfix c:\debug\symbols and .reload. This will download information needed to construct the callstack.
Continue running the application with g
Reproduce the issue / wait until it crashes
When WinDbg stops,
create a crash dump with .dump /ma c:\debug\minigame.dmp so you can analyze it later, e.g. for asking questions here, so that you needn't reproduce the bug again.
get information about the exception with .exr -1
switch to the thread that caused the exception with ~#s
look at the callstack with k
Now you should have a better understanding of the crash, perhaps enough to apply a patch, maybe not. At least it's a better starting point for further exploration.
All of a sudden, I'm seeing floods of first chance exceptions in the VS.NET Output window.
There are 3 of us working on the project. We've all updated our code to the latest in SVN and I'm the only one seeing all the exceptions, so the issue is not our app, but I suspect, some setting that I accidentally triggered in VS.NET.
If I right click the Output window, "Exception Messages" is checked. It always has been and is for my co-workers, so that's not the issue.
I cannot see any options in Tools/Options/Debugging that could be responsible. I suspect I probably just accidentally hit some accelerator key combo that did it. These appear to be perfectly normal first chance exceptions (like setting a property in a dynamic object for the first time causing a RuntimeBindingException). The app seems to operate just fine. But the flood of messages is annoying and makes debug output hard to follow.
By far the most common exception is an ArgumentException with the message, "A property with the name 'UriTemplateMatchResults' already exists."
We use WCF very heavily (but no REST) and have a number of WCF services that our app communicates with, so I'm assuming that's just standard WCF stuff because the calls are all working fine.
Can anyone think of anything I might have done?
I discovered the source of the problem. As I suspected, it was something I had accidentally done, but I'm not sure when or exactly how. Hopefully this solution will help others.
The solution was Tools/Options/Debugging in the General section, I had somehow unchecked Enable Just My Code. I'm not sure how I unchecked it. That fixed the problem.
My program runs for about 10 hours during the night, sometimes I wake up to see that it has crashed (for whatever reason). It is usually a "Program Name" has stopped working, and the only button there is to close the program. I have tried watching and waiting for it to crash but the problem seems very hard to reproduce (and I can't watch it 24/7). I have used try and catch statements in my program in potentially problematic areas and told the program to dump to a text file if it catches an exception. But this isn't good enough it seems.
TLDR: Is it possible to tell my program to run a particular function when an exception has been detected in the program in general (without specifics) so that I can dump the stacktrace to a text file and investigate later?
Is it possible to tell my program to run a particular function when an exception has been detected...
Yes, but the specifics depend on the platform that you are using:
If you have a Console application, put a big Try ... Catch around Sub Main.
If you use WPF, add an event handler to AppDomain's or Dispatcher's UnhandledException event. Specifics can be found in the following question:
WPF global exception handler
In you use WinForms, you can also wrap Sub Main (which might be auto-generated) or attach to AppDomain.UnhandledException, see here for details:
WinForms Global Exception Handling?
For completeness, global exception handling in web applications is done in global.asax's Application_Error method:
How to catch unhandled exceptions in an asp.net application?
It's generally not a good idea to do this. You could, however, look at AppDomain.UnhandledException. This is pretty much restricted to one domain, and you'll also receive (potentially) notifications for all unhandled exceptions unrelated to your program.
This is usually used for class libraries, but I think with a bit of fiddle, you might get it to work.
The only solution I seem to be able to find for testing for exceptions is using SenTestingKit's STAssertThrows and STAssertThrowsSpecific, however in both cases when the exception is thrown the application under test hangs until I manually ask it to continue. Surely the exceptions should be swallowed by the testing framework? And if not, does anyone have a beter suggestion for testing exceptions?
I was going to delete this question, but here is the solution for anyone else who finds themselves in a the same situation:
The reason that the application was breaking was that I had an Exception Breakpoint set up. This breaks as soon as an exception is raised, not when it bubbles up, so it was actually being halted before it had even got as far as my assertion. I just need to toggle off breakpoints (or just the exception breakpoint) when I am running tests.