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.
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 have a C# program that I'm using with VS2017. When I run the app I get a simple message box, twice, with the exact message:
"Exception has been thrown by a target of an invocation error in C# program and VS2017?"
The error is happening in one of the referenced PCL projects (Portable Class Library). I don't know which one because the message box has absolutely no other information other than the sentence above. I am not getting the Exception dialog that has the rich error information like the one you see when an exception occurs in your main code. Therefore, I can't look for the innerException for the actual cause, which is the main solution to diagnosing the underlying exception that is recommended in all the other Stack Overflow posts related to this problem that I found. I can't use the try/catch method of trapping the error because it is occurring in during the initialization phase of the other referenced libraries and outside the scope of my code. I know this because I put a break point on the very first line of code in my app and those two "dumb" exception message boxes pop up before I hit my breakpoint.
How can I find out which of the referenced libraries are causing the error?
NOTE ADDED AFTER SOLUTION: An AccessViolationException was being thrown inside the method called by reflection. This was the reason the TargetInvocationException couldn't be caught.
NOTE: This is OUTSIDE of the IDE. The referenced question is NOT the same.
TL;DR
Can't get a stack trace
Can't get inner exceptions
Can't use debugger (copy protection scheme of a third party library gets in the way)
Any changes to the code prevent the exception from occurring - means I can't add logging to find out where the exception occurrs
How can I get the exception to be caught or get the needed information some other way?
Long description:
I am having a problem with an exception that occurs in a method that gets called by reflection. The exception itself actually occurs in the called method, but since the method is called by reflection, the real exception gets wrapped in a System.Reflection.TargetInvocationException. No problem, just catch it and get the internal exception - except the System.Reflection.TargetInvocationException doesn't get caught. My program crashes, and I get a dump along with an entry in the Windows event log.
The Windows event log doesn't contain the internal exceptions, and neither does the dump.
I can't attach a debugger to the program because then an external library (which is needed to get to the reflection call) won't run - copy protection, don't you know.
If I put a try/catch into the offending method, the exception doesn't occur - which is bad. The cause isn't fixed, it just doesn't happen any more.
The same effect happens if I put logging into the offending method - the exception doesn't occur any more.
I can't use logging, I can't use a debugger, and in the one place where I could catch the exception and log it the exception doesn't get caught.
I'm using Visual Studio 2010 and dotnet 4.0.
To make it clear: The try/catch doesn't work when the program is run outside of Visual Studio, and I can't run it inside of Visual Studio in the debugger because then the program can't reach the point where the exception occurs. This is NOT within the IDE.
Eliminating the reflection isn't an option (I've tried it for just the one case, and the exception goes away.)
The method being called does a lot of stuff, but breaking it down into smaller methods doesn't help - the exception just goes away.
The exception doesn't occur all the time, only when I do a certain sequence of steps - and when it occurs then it is always on the second time through the whole sequence.
In the sequence I am using, the method gets called by two threads almost simultaneously - a particular bunch of data gets entered, which causes a copy of a report and another document to be printed on two separate printers - one report and document to each printer. Since generating the reports and printing the document can take a while, they are done on threads in the background so the user can continue working.
I suspect that the threads are stepping on each others toes (lots of file and database manipulations going on) but without knowing what is really happening I can't fix it.
The code below shows a simplified version of the call by reflection.
Does any one have a suggestion as to what may be causing the System.Reflection.TargetInvocationException to not be caught, or maybe an alternative way to catch the inner exception?
Try
Dim methode As System.Reflection.MethodInfo
methode = GetType(AParticularClass).GetMethod("OneOfManyMethods", Reflection.BindingFlags.NonPublic Or Reflection.BindingFlags.Static)
Dim resultobject As Object = methode.Invoke(Nothing, Reflection.BindingFlags.InvokeMethod Or Reflection.BindingFlags.NonPublic Or Reflection.BindingFlags.Static, Nothing, New Object() {SomeBooleanVariable, SomeStringVariable}, Nothing)
result = DirectCast(resultobject, DataSet)
Catch ex As Exception
'Log the error here.
End Try
Found the reason why I couldn't catch the exception:
The actual exception was an AccessViolationException, which can't be caught in dotnet 4.0 without taking special steps (How to handle AccessViolationException.)
To make things more fun, when AccessViolationException gets thrown in a method called by reflection, only a TargetInvocationException gets logged in the Windows event log, and only the TargetInvocationException is available in the dump.
Once I managed to get the real exception, I found that that it was a call to Application.DoEvents() from a non-GUI thread that caused the AccessViolation. DoEvents() can cause enough fun when called on the GUI-Thread (Use of Application.DoEvents()), let alone when called from a background thread.
Once that was fixed, I found that our third party library (the one with the copy protection) doesn't like being called simultaneously in separate instances. Fixing that was a matter of a synclock in the right place.
The code causing all of this fun was at one time all in the GUI-Thread, and was originally written back in the days of dotnet 1.1 - this explains the call to DoEvents. The code has been converted piece-wise to run in parallel in background threads through several different stages, with no one single developer having a complete overview of the process.
I am not sure I can replicate your issue, but this is how we get it and it work's just fine...
Try
'YOUR CODE'
Catch ex As Exception
'This is where we grab it from... It needs to be in this block to work...
System.Reflection.MethodInfo.GetCurrentMethod.ToString
End Try
Let me know how it work's out for you?
I'm debugging and enhancing a C#/XAML program that repeatedly generates an exception while running which I can see looking at the Output window.
A first chance exception of type 'System.ObjectDisposedException' occurred in System.dll
A first chance exception of type 'System.ObjectDisposedException' occurred in System.dll
(for some reason they seem to happen in pairs) The program itself keeps running after the exceptions occur.
The program consists of some XAML/C# code-behind which forms a front-end and test harness for a library of calls in a .Net DLL, which is also part of our C# code.
The total code-base (front end and DLL) is about 100K lines of C# source code code spread among about 25 files. It mostly runs in one thread except for code which runs in socket-data handlers which get called by the system when data arrives from outside hardware devices (this program runs a factory manufacturing process).
How do I narrow-down/track-down where or what in my code is triggering these exceptions?
In Visual Studio you can break execution when an exception is thrown. Go to debug menu -> exceptions -> Common Language Runtime Exceptions -> System -> System.ObjectDisposedException and check the checkbox for "Thrown".
This exception indicates an attempt to access an object after it has been .Dispose()-ed. The reason the program continues to run is that the exception is handled. a First-Chance exception is always generated when an exception is thrown, even if it is handled with a catch statement.
In general, many first chance exceptions like this are not something to worry about. If you want to track them down, you will need to attach a first chance exception handler, and then use the StackTrace Property to find them. Assuming your Main function is in Program, the following code should work
static Program()
{
AppDomain.CurrentDomain.FirstChanceException += (sender, e) =>
{ // Breakpoint here
};
}
This will give you access to the exception via the e.Exception
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: