Catching Exception caused by external library call / DLL before reaching NIER

[LLindenbauer]

Dear all!

Can I intercept an error emitted by a library function call that would otherwise crash my executable and emit a NIER dump?

I am using a DLL provided by a third party that sometimes causes my executable to crash and emit a NIER crash dump with error "Unknown (0x0EEDFADE)". This error is emitted by the DLL - it is also emitted as "Winerror 250477278" (the decimal value of 0xEEDFADE) when I use python to access the DLL.

A quick search for this error suggests that it is an unspecific "File Not Found" error code, possibly from trying to access a NULL-Pointer. I'm guessing it comes from an unhandled error state within the device that I'm using the DLL to control.

Here is the thing: I could absolutely handle the error state from within my LabVIEW executable. If I could somehow intercept the error in the external library call, I would be able to reset the device and try again.

Is there a setting of the node or execution mode that would let me intercept the error? Enabling debugging in the build options, execution mode and the call library node did not do the trick.

Thanks,

Leo

[GerdW]

Hi Leo,

---

@LLindenbauer wrote:

Can I intercept an error emitted by a library function call that would otherwise crash my executable and emit a NIER dump?

---

No.

[rolfk · Accepted solution]

---

@GerdW wrote:

Hi Leo,

---

@LLindenbauer wrote:

Can I intercept an error emitted by a library function call that would otherwise crash my executable and emit a NIER dump?

---

No.

---

Actually it's not that categorically No.

The answer is rather Yes, BUT!!!!!!!!

You need to wrap your DLL in another DLL written in C++ in which you initialize an exception handler for the specific exceptions you are interested in and then catch and properly handle the exception and then clear the exception stack and return anyways successfully. And no you should not categoricaclly catch all exceptions in there and return anyways.

That would be analogous to switching of all indicator lamps in your car because you hate the lamp that shows you that you are low on full and then miss all kind of very dangerous indictors such as low oil level or a brake problem.

Exception catching in a library is pretty advanced programming although C++ inherent exception handling does most of the hard work for you, but if this is worth writing a seperate DLL to hide problems that should in fact rather get handled at the root by avoiding the situation that causes them is something you will need to decide yourself. I for myself find suppressing errors unless I know 120% for sure that they are indeed expected and harmless, a complete no go.

[LLindenbauer]

---

@rolfk wrote:

---

You need to wrap your DLL in another DLL written in C++ in which you initialize an exception handler for the specific exceptions you are interested in and then catch and properly handle the exception and then clear the exception stack and return anyways successfully. And no you should not categoricaclly catch all exceptions in there and return anyways.

Thanks! This sounds like a nice option to have when the primary library cannot be fixed! I will certainly give it a try!

That would be analogous to switching of all indicator lamps in your car because you hate the lamp that shows you that you are low on full and then miss all kind of very dangerous indictors such as low oil level or a brake problem.

Exception catching in a library is pretty advanced programming although C++ inherent exception handling does most of the hard work for you, but if this is worth writing a seperate DLL to hide problems that should in fact rather get handled at the root by avoiding the situation that causes them is something you will need to decide yourself. I for myself find suppressing errors unless I know 120% for sure that they are indeed expected and harmless, a complete no go.

---

Yes, this is exactly what I want to do. Right now, I don't even get an indicator lamp. Instead, when I try to start the car while the braking fluid is low, the engine just explodes. While I cannot fix the problem in the braking system, by wrapping up the (3rd party) engine startup I might be able intercept the engine self destruct sequence.

Once I have prevented the car from self destructing, politely telling the driver that something went wrong becomes trivial.