How do I create a fault-tolerant DLL call from LV?

Question

I've created an .exe from a VI that calls a DLL, when that DLL crashes,
it crashes the whole application.  This DLL is too complicated to
completely debug and it, in turn calls DLLs I have no control
over.  It crashes approximately once every 100,000 iterations.
How do I make a DLL call fault-tolerent?
Attachments:
crash.gif ‏19 KB

Answer 1

I might not have been very clear in my answer - this isn't a feature that CAN be added to LabVIEW...the DLL threw an unhandled exception across a DLL interface - which pretty much means a system exception (code shouldn't be throwing language exceptions across DLL boundaries as they are language specific). This means that something went very wrong with the code and there is a good chance that the process space has been corrupted. And from my own debugging experience, if it's only crashing 1 time out of 100,000, that doesn't mean it isn't corrupting memory or otherwise causing problems...it was just the time it was caught.
Considering this, the Call Library Node already is fault tolerant - we catch the exception and report it to the user. You have a valid position that we should simply return this as an error. It's also a valid position that it would be a road paved with good intentions. All you need to do is remember what life was like in Windows 3.1 - where one process could silently corrupt another - to realize the amount of untraceable errors that could occur. Yes, the error out value should be handled by the user, but when an application of 100's or 1000's of VIs crashes seemingly at random because someone didn't, you can see the problem.
I will say I like the idea of a separate memory space. It is unfortunate that Windows only offers that through creating a separate process, but it is a neat idea. I worked in the VXI/VME world for a while, which does have multiple address spaces.
BTW - using signal handlers to catch exceptions is unfortunately not a 100% solution...signals are a partial port of a Unix concept in Windows. You would be best to use SEH around the call (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccelng/htm/key_s-z_4.asp). If the DLL is already a C++ DLL, then you can use the global catch of C++ instead
int err = 0;
try {
} catch(...) {
   err = -1;
Again, you still are at risk of a corrupted process, but this allows you to avoid our handling of it.
Having spent years writing and (god help me) debugging device drivers, I love this topic. If you want to talk more about it and various options, feel free to shoot me an email at [email protected].
Brian Tyler
http://detritus.blogs.com/lycangeek