How to eliminate Unhandled Exception dialog produced by 3rd party application - c#

I'm working with a 3rd party executable that I can't recompile (vendor is no longer available). It was originally written under .Net 1.1 but seems to work fine under later versions as well. I launch it using Process.Start from my own application (I've tried p/invoke CreateProcess as well with the same results so that's not relevant)
Unfortunately this 3rd party app now throws an unhandled exception as it exits. The Microsoft dialog box has a title like "Exception thrown from v2.0 ... Broadcast Window" with the version number relating to the version of .Net it's running under (I can use a .exe.config file to target different .Net versions, doesn't help).
The unhandled exception dialog box on exit doesn't cause any real problems, but is troubling to my users who have to click OK to dismiss it every time. Is there any way (a config file option perhaps) to disable this dialog from showing for an app I don't have the source code to? I've considered loading it in a new AppDomain which would give me access to the UnhandledException event but there's no indication I could change the appearence of the dialog. Maybe someone knows what causes the exception and I can fix this some other way?

You could write a wrapper application that calls the 3rd party application directly and launch your application using Process.Start.
Then in your wrapper application trap the exception so the users won't see the error message.

If it hasn't been obfuscated you may be able to decompile it? This is of course illegal etc. but if the company has actually gone bankrupt then no one is there to pursue it. It is reasonable for you to support the code if you have no other choice.
Reflector might give you a clue as to why the code crashes as well, perhaps you need to do something or call it with a parameter to stop it from doing so?

Next time don't try to use something without source code :)
A workaround is to follow Chris' suggestion. A wrapper application can make use of such code,
http://blog.jtbworld.com/2007/06/windows-live-writer-spell-checking.html
Find the old application executable.
Execute it in an AppDomain object created in the wrapper application.
Bind your application unhandled exception handler to this AppDomain object's UnhandledException event.
http://msdn.microsoft.com/en-us/library/system.appdomain.unhandledexception.aspx

Related

How can I catch a Side-By-Side (SxS) manifest load error without crashing on startup?

I have a C++ application which uses controls contained in a managed (C#) library.
The controls are activated using Registry-Free COM Interop (SxS activation).
If the managed library is missing, the application shuts down immediately with a generic and unhelpful dialog:
("Unable to start program X", "This Application has failed to start... blah...blah")
What I would like to do, is catch the error and present the user with my own (hopefully more helpful) message. Better yet, I would like to allow the application to continue loading and just disable the few dialogs that actually use the managed library and its controls (only a tiny fraction of the main application uses this library).
Unfortunately, the error from the SxS loader seems to happen before any of my code gets a crack at handling it.
Can I catch and handle these errors? If so, how?
Thanks!

How can I monitor an application crash from a separate process

I have a certain .net application that occasionally crashes with one of the following windows errors:
[application name] has encountered a problem and needs to close. We are sorry for the inconvenience.
or
[application name] has stopped working
I want to monitor this app from another .net process, prevent showing the default windows error report dialog, and do my own error processing.
Is there a way I can detect that the other app has crashed?
And can I prevent or hide the default error dialog?
Some background information: I do have the code for the crashing app, and I can change it if necessary. However the crash is caused by a third party unmanaged assembly, which overwrites some memory and leaves the app in an unrecoverable state. A simply try-catch block is not enough to prevent the crash. This is why I want to monitor and handle the error from a separate process.
If the app writes to the windows event log, your other program could check there for errors
Can AppDomain.UnhandledException help?
The dialog box is a function of Windows Error Reporting (WER).
Is there a way I can detect that the other app has crashed?
There are plenty of options, from a service that requires some kind of heartbeat message from the process, to enabling catching of corrupted state exceptions, to enabling a corporate WER server. (link below)
[C]an I prevent or hide the default error dialog?
The WER configuration documentation has information about excluding a process from the automatic dialog.
Specifically the registry key:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\
Windows Error Reporting\ExcludedApplications\[Application Name]
(HKCU has a similar key)
Unfortunately, if it's an access violation, you're pretty well hosed. By the time that the exception has made it to WER the entire stack is blown, and the memory is already corrupt.
Disabling the built in error reporting for your application, will also prevent the automated creation of minidumps, which may be helpful, if not in solving the direct issue, providing ammunition for use convincing the vendor to fix their dll.
If the vendor is unwilling or unable to fix the problem, you could copy the way Explorer handles shell extensions, and host the component in a separate process. That way, when it crashes, it only trashes the memory of the other process. You'd have to write a wrapper to allow you to communicate with it.

How do I find the reason EETypeLoadException was thrown?

I have a Windows 8.1 WinRT (modern/metro) application that is partly native C++ and partly .net (C#)
At some point the C++ part is calling a delegate that is set to a C# method, when this delegate is called an EETypeLoderException is thrown and the method isn't called, I want to find out what is the reason for this failure.
The method the delegate is pointing to is in a .net assembly that is already loaded, code from this assembly - and the same class that has the to-be-called method - has already ran (and possibly is running in another thread at the time the exception is thrown)
The EETypeLoadException is a native unmanaged exception, it is thrown by unmanaged code (in msvcr120_clr0400.dll), I can only use the unmanaged debugger to look at it and that debugger can't show me data from the exception because it doesn't know about the EETypeLoadException class.
I can't catch the exception and extract data from it in code because I don't have the header files for it or any of its super classes.
The fusion log viewer (FUSLOGVW) isn't showing anything useful, no bind errors, successful bindings don't look related.
Procmon doesn't show any attempt to access a missing dll
Making the code run on the UI thread or a background task doesn't change anything.
I even tries looking at the memory dump of the exception object and following anything that looks like a pointer, couldn't find an error message.
This happens both on the local machine and in the simulator
I'm using Visual Studio 2013 update 3 on a Windows 8.1 machine
It looks like EETypeLoadException thrown by native code in WinRT (that is, not the .net CLR) does not carry any additional information and it's not possible to get the information about what exactly has failed

Microsoft Visual C++ Runtime Library - Runtime Error - How to suppress the error

It looks like a duplicate, but believe I checked other answers, nothing worked.
My application started crashing while closing the application with below error. It was working properly few days back, some recent changes is causing the issue. And one this starts on a machine, even though I replace with previous working DLL, still the issue comes.
Microsoft Visual C++ Runtime Library
Runtime Error!
Program:C:\DigiMic\...
This application has requested the Runtime to terminate it in an unusual way...
This pop-up comes for 1 second with OK button, then automatically closes. The main problem is it happens while shutting down my application.
My Application: It is a WPF, C# application which uses Matlab used business DLL for few functionality. The application works fine while using the Matlab used DLL and its function, only crashes while exiting the WPF.
I tried to Wrap the App.Current.ShutDown with try..catch... but the it never hits catch orfinally block. Then I also tried AppDomain.Current.UnHandledException += new..., it still does not hit the function on exception.
The other problem is, I am not able to see the complete path of the exe that causes this exception.
Question:
Is there a way, I can suppress this error?
Where is this error gets logged in windows?I tried to look into Event Viewer, but nothing is there.
Is there any workaround? Since it's software delivery time for the product. :(

How to catch this type of exceptions?

I'm starting getting tired of this exception. Can't handle it, even so I'm using this:
AppDomain.CurrentDomain.UnhandledException += new UnhandledExceptionEventHandler(CurrentDomain_UnhandledException);
Still no success, Can anyone explain me, how I should handle it in a nice way. Or how to detect that it have fired this message and close the application, because I'm starting it automatically everytime it closes.
Btw, It's Console application.
Have you tried placing a try{...} catch(Exception e){...} block in your main, then posting all exception data to the Windows Event Viewer?
Or similarly checking the Windows Event information that is currently there.
IMHO best way solving this is to use remote debugging.
Here and here ´s are some good posts, why you get the Dialog even when you register the UnhandledExceptionEvent.
If you register to the event, it doesn´t prevent the application from beeing closed/exited. As far as i know it is by design. In the Event you have the option to log the exception and verify what went wrong in your application.
Are you using any P/Invoke calls at all? I have had issues in the past with C interop before, where the C dll was causing an access violation error internally, which in turn crashed the C# application catastrophically - much like your screenshot above. Unfortunately it turned into a case of hunting down the entry point (P/Invoke) into the C dll by trial and error, and then fixing the C code.
If you are using P/Invoke, are all the expected dependencies on the machines and the correct versions?

Categories

Resources