I'm trying to design a Silverlight Application that accesses a SQL database through a WCF service. Operations that take place in the web app are fine, but as soon as I try to access data through the database I get this error:
An unhandled exception ('Unhandled Error in Silverlight Application)
Code: 4004
Category: ManagedRuntimeError
Message: System.Reflection.TargetInvocationException: An exception occurred during the operation, making the result invalid.
It then gives me a list of debuggers to choose from, but upon choosing one it tells me its "Unable to attach to the crashing process. A debugger is already attached."
I'm fairly new to this and haven't been able to find much conclusive advise elsewhere. Any input or similar experience to share is appreciated (: Also I'm not sure what else would be helpful to solve this problem, so let me know if there's some other piece of info I should provide.
Thanks!
The message is saying that the code is failing and the exception generated hasn't been handled.
So I recommend that you put in a try catch around the location where you call the webservice for data and simply display a message box with the exception text. And/or put a breakpoint in the location of where the silverlight application calls the webservice. Run the debugger. See what value comes back and how its handled.
Hence I whole-heartedly recommend that you put in try catches in your code and to also handle any future failures and report them appropriately; for this won't be the only exception your code will generate.
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?
I'm getting this error while debugging two background tasks that access an Entity Framework DB. Running just one background task does not seem to trigger the error message. I can't really tell what the issue is because everything is working fine except for the breaking error message that pops up during debug.
It would be great if I can find out why this is happening (the other questions related to this message are unsolved), but the more important thing is turning the error notification off. I am not sure why I am getting the error in the first place because I do not have anything checked in my exception settings. Does anyone know how?
#Tyress, you cannot turn off notifications for unhandled exceptions while debugging. Since unhandled exceptions typically result in application crashes, the debugger will always break when they are encountered.
I'm new to Reactive Extensions. While running my application in Visual Studio, I get the following exception which I cannot reproduce reliably it but always happens given enough time:
System.TimeoutException was unhandled
Message: An unhandled exception of type 'System.TimeoutException' occurred in System.Reactive.PlatformServices.dll
Additional information: The operation has timed out.
The Break Mode tab shows the message:
Your app has entered a break state, but there is no code to show
because all threads were executing external code (typically system or
framework code).
I have no clue as to where to look for the problem, except that it might have to do with Reactive Extensions. Any ideas would be greatly appreciated.
The second message (Break Mode) is something that always gets shown in Visual Studio - that's the definition of "Break Mode" - In any application that you debug with VS you can "break" the app (using the "Pause" button, for example) - This allows you to better debug and understand the state of your parameters, objects and callstacks. The code is not showing up since you're using external code that your have no sources for.
Regarding the first exception, as you said, the platform services have a timeout. After a determined period of time something has not happened, the application will throw this timeout saying that the expected operation didn't complete in the amount of time that was specified for it. I can't tell you really why this is happening on your specific machine, but you should check if the extension requires something to initialize that you might not be providing it.
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.