I'm developing an application with C#.NET 4.6
It references an old OCX LAPI.ocx
When this OCX receives some special message called PCPCM entire application crashes with HEAP Corruption exception.
Unfortunately I can't catch or handle that exception in my application.
Yesterday I tried my application with x32dbg. And it worked. x32dbg can catch exceptions and ignores them. How it can ignore such an exception? How I can do this in my application to prevent a crash?
UPDATE: I used dbg to find the point that the ocx raises an exception and tried to jump over it(and patched the original ocx). I put it under test. Hope it works.
UPDATE 2: I couldn't find a way to ignore or catch such exceptions. I couldn't make AddVectoredExceptionHandler working. But downgrading application to .NET 4.0 solved the original problem(No more exception and application crashed message).
Using .NET 4.0 I solved the problem entirely. See UPDATE 2.
Related
I have a WinForms application which dynamically loads an assembly generated by MatLab (3rd Party). Currently, I encountered the problem that an error (maybe exception) somewhere in the MatLab code structure, cannot be caught on C# side. And by this, the whole application goes down...
What I tried is:
Try/Catch Block (even with no exception type, as described here: https://stackoverflow.com/a/150675/3809520)
HandleProcessCorruptedStateExceptions attribute, as described here: https://stackoverflow.com/a/10517244/3809520)
Is there anything that I could do more?
Thanks!
Edit:
Application is using .NET 4.5 Framework
Edit2:
Tried Application.ThreadException event together with Application.SetUnhandledExceptionMode(UnhandledExceptionMode.CatchException) and AppDomain.UnhandledExceptions event as proposed in comment - both events not triggered.
Edit3:
I will try to nail it down to a minimal example, the questions was intended to be more generic, like: what else can be done on my code side to catch exceptions
I have an application (written in C# / ClickOnce) which, for the most part, works fine; it has no memory leaks and runs reliably and is stable for days at a time.
However, it also utilises MEF (so plugins/extensions can be dynamically added to the core assembly). Again, this 'works' currently, but if an exception/fatal error occurs in an externally linked assembly/plugin, it will crash the entire application.
After some recent testing, I found that the application had crashed after around 14 hours of [successful] operation.
With that in mind, my question is really two-fold:
a) is it possible to catch any unhanded exception a plugin (or the main application) may throw, so it can at least output info for debugging assistance?
b) I can't be sure if it was the plugin or the main application which failed. Therefore, I cannot think where to start debugging/tracing the issue. How does one go about finding a bug which only occurs after such a long period of time?
Thanks for any input.
As noted in the comments (I guess I should have read those before I started typing up an answer...)
When an application throws an exception that is unhandled, it fires the UnhandledException event just before death and you can subscribe to that in order to log any details that will help you figure out what happened.
See this SO post for an example on how to use it (includes ThreadException).
Dll has no entry point in C#, so i need to put the code for global exception handling in one place as these dlls are referenced in exe and all have there try catch but there are some errors due to which it is crashing and to identify we are trying to create a crash dump. Can anyone suggest is it the feasible solution to do that or anything else has to be done.
Thanks.
As Cody said you should enclose every call to that dll in a try catch block to handle the exception. Your statement is a bit confusing I am assuming you are already using try catch block. If that's the case you can handle global exceptions as well to make sure it's not the exe itself throwing exception.
For example in Win Form application you can handle Application.ThreadException to catch global exceptions. You can also try with handling AppDomain.Unhandled event
I have an application containing both managed and native code. The application currently has an unhandled exception filter, set via SetUnhandledExceptionFilter, which catches any critical errors, generates a minidump, records various application parameters, and exits the program.
The unhandled exception handler does not catch an EngineExecutionException which occurs in the .NET runtime. We suspect the problem is memory corruption caused by the native portion of the application.
The problem is, when the exception occurs, the application just exits without a trace. We'd like to record a minidump when this happens. Does anyone know how our application can install a handler capable of catching this?
AFAIK this exception is not catchable on the managed side of things (at least not in .NET 4).
One way to "catch" it would be to create a (native) custom starter/loader for your application which loads the .NET runtime - this custom starter can install an exception handler on the native side of .NET runtime.
Reference links:
http://msdn.microsoft.com/en-us/magazine/cc163567.aspx
http://msdn.microsoft.com/en-us/library/ms164336.aspx
http://msdn.microsoft.com/en-us/library/dd380851.aspx
http://msdn.microsoft.com/en-us/library/ms231221.aspx
I'm writing an app in C# on Windows CE 5.0 with .NET Framework 3.5 that uses the WebBrowser control. It's almost exactly what I need, with the exception that it throws a global exception when it fails to .Navigate(...) as opposed to an exception out of the Navigate call.
I've found this article:
http://msdn.microsoft.com/en-us/library/system.windows.forms.webbrowser.createsink.aspx
While this compiles for a Windows application, there are a few things missing when I try to compile them for WinCE. Those being:
AxHost
StandardOleMarshalObject
Anything that starts with Permission*
... and a few more that I can't recall at the moment.
I can go ahead writing the app and deal with global exceptions, but it would be much cleaner if I could handle navigation errors properly. Any advice would be appreciated.
which thread is the exception coming from? if you could find/access that thread, you could theoretically handle it's exceptions.