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.
Related
I have a problem when using the method AssertConfigurationIsValid(). The expected result should display a exception containing the details of mapping, instead it throws this error:
I expect to see a well detailed error at this point but instead throw this.
Did I missed something when install AutoMapper extension?
This isn't a matter of getting the wrong result, you're looking the wrong place.
You're showing us a notification that an unhandled exception occurred. It only mentions that "an exception of type X" occurred, it doesn't show you the content of that exception, which is where you want to be looking.
Either change your IDE debug settings to not raise this notification (I generally don't like it), or handle your exception (i.e. catch it) and inspect it at debug time.
Note also that AssertConfigurationIsValid should generally be used in a test suite, where all exceptions (inside tests) are automatically handled and reported as a test result.
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?
i am searching for that output error recently, but every answer here only explaining why that output happened on a specific case and solved a chunk of code.
like here and here
i hope there's anyone who can give a well elaborated answer, generally explaining what this output is actually mean and how to (elegantly) avoid this error.
note : im working on a project using .NET framework on windows store apps
An ArgumentExeption means that there was an error with an argument that was passed to a function. Normally the exception should contain the name of the offending parameter.
A more specialised exception is the ArgumentNullException which means that an Argument was null where it must not be null.
Or the ArgumentOutOfRangeException which means that an argument requires a specific range (e.g. 1-100) and an invalid value was passed (e.g. 101).
See MSDN for more Information: https://msdn.microsoft.com/de-de/library/system.argumentexception(v=vs.110).aspx?f=255&MSPPError=-2147217396
"A first chance exception" means you've set up your debugger to let you know whenever exceptions get thrown, regardless of whether there's code to handle those exceptions properly. They can even appear inside .NET Framework source code, if you've also set up your debugger to debug all IL code rather than just that of your project.
Unless there's an actual problem, don't worry about first-chance exceptions, just turn off the notifications: in the Exception Settings window, uncheck the "Break When Thrown" checkbox. You'll still be alerted whenever an exception isn't handled.
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:
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.