I'm getting exceptions thrown from somewhere, but all I get from the compiler is "A first chance exception of type 'System.ArgumentOutOfRangeException' occurred in mscorlib.dll". This is fairly useless to me, as that's not my code (pretty sure it's default library). I'd like to see a stack-trace or something so I know where in my code things went wrong. It's a fairly large codebase (much of which is not mine), and there's a lot of multi-threading and other stuff going on, so it's nearly impossible to try and step through the code without some idea of where to start looking. Is there some setting somewhere to make ALL exceptions trigger a break so I can see the call-stack when they occur, rather than just having them silently fail with a completely useless error message in the output?
You have a couple of options. First, like Greg said, you can cause VS to break when any exception occurs:
Make sure these are checked, then click OK:
That will cause Visual Studio to break wherever the exception occurs.
Another approach is to catch the exception and either write just the stack trace, or write the exception (using ToString()) to the output window:
Then check your output window:
Related
Visual Studio 2019 .NET Core C# Windows Forms development.
SqlDependency.Start is causing a SqlException. But it happens after .Start completes with return code True. So catch does not catch it. Happens periodically. Can see it in VS Output:
Exception thrown: 'System.Data.SqlClient.SqlException' in System.Data.SqlClient.dll
Checking SSMS log file:
Service Broker needs to access the master key in the DB. Error 32.
But I see this once. Whereas VS Output shows SqlException in groups of 5 separated by tens of seconds.
In general how can one setup a way to monitor all SqlException that happen outside of a response to a call. Say a time out exception perhaps not that I know if it happens.
In particular suggestions for resolving this are appreciated. I tried setting TRUSTWORTHY to YES but it did not help.
Not sure if SqlException and the log message are related.
Thanks!
That an exception is thrown is not necessarily an issue. It's quite normal for exceptions to be thrown. The VS debugger will show you every exception that is thrown but the vast majority of those are being thrown, caught and dealt with in system code and are most likely of no concern to you.
That said, you can configure VS to break whenever a particular type of exception is thrown, rather than the default of when it goes uncaught. While debugging, open the Exception Settings window, find the exception of interest and check the corresponding box to break whenever that exception gets thrown. It seems that you want the System.Data.SqlClient.SqlException under the Common Language Runtime Exceptions node.
I'm receiving this weird InvalidCastException that does not break at the line where it actually occurs in Debug Mode and does not even tell me what line it is breaking at.
I'm assuming it can't tell me the line because it occurred in the presentation framework. I've compared previous code that worked with my current set and there is nothing that stands out so I'm assuming my designer did some spiffy XAML that is incorrect.
Is there any way to locate the exception without going through hundreds of thousands of lines of markup?
Easiest way to see where these exceptions are coming from is set the debugger to stop on that particular type of exception. In the top menu: Debug->Exceptions. Then find the InvalidCastException and check the box.
Run you program again and it will stop and show you the exception box. Make sure you dive into the exception to the inner most exception that was thrown to know what the root cause is.
I have a strange error after catch the error "A generic error occurred in GDI+."
when i try to open an excel file trought the instruction :
Workbook workbook = new Workbook();
workbook.LoadFromFile(FileName);
but few minute after catching this exception my application craches (NullReferenceException )without specifying the location of the error !!
knowing that it happens when i try to scan an excel file, but it work for others excel files !!!
I can't locate where the exception with the message "Object reference not set to an instance of an object" is thrown . Visual Studio show that it can't locate it !!!
So even if i try to handle exceptions in my code i'll have nothing.
Could someone help me in this topic ?
The TL:DR; version is:
Something went wrong when the "Generic Error in GDI+" exception was thrown, which you didn't fix in your exception handler (probably because there was no way for you to do so).
Some time later, something else went wrong as a consequence of the earlier thing.
Long version
You can only handle exceptions which you know how to handle.
To handle an exception, as opposed to merely clean up the local variables and re-throw it, you need to fully understand the following:
Exactly what went wrong
What all the consequences are
Exactly what needs to be done to put everything - all the consequences - right
If you do not know all of those things then you cannot handle the exception correctly.
In your case you have caught an exception (Generic Error in GDI+). However you do not know what caused it, nor how to make sure you have taken care of all the adverse consequences it may have caused.
Once you have had an exception you do not fully understand, it is possible that the internal data structures of the application are no longer consistent. For example things might be missing which are otherwise assumed to be present.
If that's the case, it is to be expected that further problems will arise later on, as they have in your case.
Therefore you shouldn't have caught it, or at least should have re-thrown it. It is time for the process to exit, and page the sysadmin to find out what went wrong. Or at least, to start again with a clean slate.
I have a Windows Forms application. It loads assemblies with the extension .Plugin.dll with Assembly.LoadFile. One of these "plugins" calls into another assembly dll. That dll eventually throws a ValidationException exception. The method that throws the exception is in a class that inherits from IDataErrorInfo. This class is a class that is contained in a Linq to SQL class (.dbml). In the "plugin" I call DataContext.SubmitChanges. This is wrapped in a try/catch block. This causes my business logic to validate the data before submitting to the database in the OnValidate override. The result that I see is that after the ValidationExeption is thrown, the debugger stops at the bottom of the OnValidate method indicating that an unhandled exception has occured. If I continue to run the app my catch block is executed. That is what I wanted in the first place, but why am i getting an unhandled exception when it truly is handled?
I am 99% sure your "real" exception causing this is indeed unhandled -this is what the Debugger tells you at first place, and he is generally right.
When you continue to run the App in VS after that, it is not actually what would happen when you will execute your exe out of the debugger. In fact, the debugger notifies you first of the unhandled exception, and then continues some pending logic if any (that's why you see you ValidationException error). But the unhandled exception is still there. I don't exactly know the details and causes of this behavior, but I noticed this many times.
You have to catch the precise error at the precise place where the unhandledexception is thrown after you identify it.
Maybe posting your code sample would help.
Firstly, is the plugin in the same AppDomain?
Secondly, it sounds to be like you have your debugger to "Break when exception is thrown" rather than "Break when exception is user-unhandled".
In VS.NET, go to Debug --> Exceptions...
Expand the "Common Language Runtime Exceptions" node and see if any are ticked.
I have a windows service run as a server. However, the server sometime stops immediately by an error which is un-handled. Please help me how to handle global exception. Thanks.
It sounds to me like you're trying to solve the problem the wrong way around...
When your program (or service) crashes because of an unhandled error, the solution is not to figure out where and how to "handle" all unhandled errors so that you can ignore them and continue execution. I've hashed out that view more clearly in this answer, but the short version is that when you encounter an unhandled exception, the correct thing to do is to crash. As quoted in the original answer:
The fact that an unhandled exception occurred means that the server was in an unexpected state. By catching the exception and saying, "Don't worry, it's all good," you end up leaving a corrupted server running.
[ . . . ]
Catching all exceptions and letting the process continue running assumes that a server can recover from an unexpected failure. But this is absurd. You already know that the server is unrecoverably toast: It crashed!
Much better is to let the server crash so that the crash dump can be captured at the point of the failure. Now you have a fighting chance of figuring out what's going on.
So in fact, the real solution involves figuring out the root cause of the unhandled exception and modifying your code to prevent that error from occurring in the first place.
There's no way that we can help you to do that unless you post the exact exception message that you're getting, and preferably a full stack trace. But you definitely want to preserve the debugging information that you're getting, rather than come up with a way to ignore it entirely—that's the only way to actually solve the problem.
If you still insist on ignoring all well-meaning advice to the contrary, you'll find the "stick your head in the sand and ignore it" approach detailed here.
You could try using the AppDomain.CurrentDomain.UnhandledException event, although I'm not sure if it will catch every single unhandled exception.