Unhandled exception handling in GB-PVR

[ubu]

I'm trying to deal with several unhandled exception problems, mainly to do with Interop activex modules over which I have little or no control. I'm hoping someone can a) explain GB-PVR's behaviour when these errors occur and b) give me a clue as to the best way to deal with them.

Normally, if I fail to catch an exception in my plugin's code, the exception gets written to the gbpvr log (which is good because the user doesn't see anything and I get info about where I should add exception handling).

But sometimes (as in the case of Interop code) an unhandled exception dialog gets shown (the one with the "Details", "Continue", "Quit" buttons). I'm not sure if this is being displayed by Windows or if GB-PVR has its own exception trapper that displays this.

And then there's the third situation where the Windows "Send Error Report" dialog gets shown. I usually get this one when exiting GBPVR (and it's intermittent, darn it). There's no clue in the log file and no noticeable bad things happened while running GB-PVR. I'm pretty sure it's related to one or more of the activex components I'm using.

Ideally, I'd like to be able to trap "real" errors and handle them properly and to detect "spurious" errors (one's that don't seem to actually affect run time behaviour in any way) so I can ignore them and suppress error dialogs being displayed.

Googling the subject, I've discovered techniques for providing my own unhandled exception manager, but only at the application level (I think :confused: ) and I don't want to be overriding this stuff for GB-PVR as a whole :eek:, just for my plugin.

I imagine I'm not the first developer to encounter this issue (although I can't find any threads discussing it). Any ideas?

[sub]

It depends where the exception occurs. For example, if your start a thread which does not have a big try/catch block around all the code, then causes some exception, then the behaviour in .net 2.0 is to terminate the process. GB-PVR has an unhandled exception handler which gets notified of these, but its to late to stop the process from terminating, so all it can do is log the details error. In this type of situation there isnt anything I could do differently, other than telling the user to change their machine.config file (might have been a different filename) to tell it to treat unhandled exceptions with .net 1.1 compatibility mode, which behaved differently, with unhandled exceptions on a background threads just causing termination of the thread rather than the whole process. .net 2.0 was a lot more painful than 1.1 in this respect.

There are similar sorts of difficulties with exceptions that occur in native code somewhere inside the windows message processing functionality where the execution never gets deep enough in the call stack to make it into GB-PVR code.

[ubu]

It depends where the exception occurs. For example, if your start a thread which does not have a big try/catch block around all the code, then causes some exception, then the behaviour in .net 2.0 is to terminate the process. GB-PVR has an unhandled exception handler which gets notified of these, but its to late to stop the process from terminating, so all it can do is log the details error. In this type of situation there isnt anything I could do differently, other than telling the user to change their machine.config file (might have been a different filename) to tell it to treat unhandled exceptions with .net 1.1 compatibility mode, which behaved differently, with unhandled exceptions on a background threads just causing termination of the thread rather than the whole process. .net 2.0 was a lot more painful than 1.1 in this respect.

Looks like I could just set up my own UnhandledExceptionEventHandler function in my plugin constructor and that "might" catch the Interop exceptions (so I can deal with them but without affecting the rest of the GB-PVR app). Worth trying, I guess.

Right now, I'm not "explicitly" starting the form with the embedded activex control in a separate thread. Maybe that would give a try/catch block a better shot at catching the activex exceptions?

There are similar sorts of difficulties with exceptions that occur in native code somewhere inside the windows message processing functionality where the execution never gets deep enough in the call stack to make it into GB-PVR code.

Pretty sure that's what's happening when the activex components throw an exception. For instance, a try/catch block around the Close() for the parent form doesn't catch anything but, instead, I get an unhandled exception dialog (the "Details, Continue, Quit" one) and the Details button reveals that invalid memory is being addressed somewhere deep in the windows forms internals.

[sub]

Looks like I could just set up my own UnhandledExceptionEventHandler function in my plugin constructor and that "might" catch the Interop exceptions (so I can deal with them but without affecting the rest of the GB-PVR app). Worth trying, I guess.

GB-PVR already has a UnhandledExceptionEventHandler, but from memory this is already too late and it's going down by the time its called...

There are similar sorts of difficulties with exceptions that occur in native code somewhere inside the windows message processing functionality where the execution never gets deep enough in the call stack to make it into GB-PVR code.

Pretty sure that's what's happening when the activex components throw an exception. For instance, a try/catch block around the Close() for the parent form doesn't catch anything but, instead, I get an unhandled exception dialog (the "Details, Continue, Quit" one) and the Details button reveals that invalid memory is being addressed somewhere deep in the windows forms internals.

Yeah, I expect so. .Net is a pain in this respect when it comes to using native components. I've had all sorts of grief from the WMP control.

[bgowland]

Not that I know what I'm talking about but...

I've just been looking at my O'Reilly C# Cookbook in the Exception Handling chapter. Apparently it is legal in C# to have catch blocks without parameters such as...

Code:

try
{
}

catch
{
}

In other words, NOT catch (Exception e) or similar.

It explains it's a 'holdover' from C++ where any object could be thrown in an exception and using catch (Exception e) won't catch the exception if you're dealing with legacy systems (ActiveX = COM = legacy code???).

As I said, not sure if I know what I'm talking about but it might be worth a try. The down side being, of course, as the object that is being thrown isn't caught as a parameter, you won't be able to analyse it to see what happened. The upside is that a catch block without parameters should catch anything regardless of the object type that is thrown.

Cheers,
Brian

[ubu]

As I said, not sure if I know what I'm talking about but it might be worth a try. The down side being, of course, as the object that is being thrown isn't caught as a parameter, you won't be able to analyse it to see what happened. The upside is that a catch block without parameters should catch anything regardless of the object type that is thrown.

I think I've used that form of the catch block by mistake in the past when I forgot to add the parameters.

The MS .Net docs go into excrutiating detail about how COM exceptions get mapped to .Net exceptions. None of which is much use if the bloody exception doesn't get caught! So maybe I'll try your "brute force and ignorance/just use a bigger hammer" approach.

[ubu]

GB-PVR already has a UnhandledExceptionEventHandler, but from memory this is already too late and it's going down by the time its called...

Figures!

Yeah, I expect so. .Net is a pain in this respect when it comes to using native components. I've had all sorts of grief from the WMP control.

One of the recalcitrant activex controls I'm using is the WMP one (and an ill-mannered, evil beast it is too - although fairly civilized compared to Apple's QuickTime one, which seems designed to destroy Windows and force you to buy a Mac).

I notice, however, that your implementation of the WMP one seems to be trouble-free (well, exception-free, at least). Did you find some kind of magic bullet to make it behave?

[sub]

I notice, however, that your implementation of the WMP one seems to be trouble-free (well, exception-free, at least). Did you find some kind of magic bullet to make it behave?

I'm not doing anything special. I try to use as little functionality it offers as possible to minimize the potential problem surface and I'm careful not use it from different threads.