External code error handling (2)

[Greg Rupp]

Is there a way to capture an error when the Call Library Function Node vi.? For instance, if the program crashes due to a .dll error, I want to be able to capture that error and create a work around so the whole program doesn't crash. I dont have access to the source code so i cant fix the dll.

Any advise would be helpful!!

Thanks,
GR

[TylerS]

Greg,

Unfortunately, the only information you'll have access to when calling a dll are the inputs and outputs of that dll. So unless the dll has built-in error handling and provides error codes, there's not much you will be able to do.

Tyler S

[shuttlefan]

since this last reply in 2005, has LabVIEW improved / expanded support for this situation?

[GerdW]

Hi fan,

---

@shuttlefan wrote:

since this last reply in 2005, has LabVIEW improved / expanded support for this situation?

---

How should LabVIEW improve on catching errors in external code (like DLLs)?

When the code in the DLL crashes, then the whole task (including LabVIEW) crashes…

[shuttlefan]

---

@GerdW wrote:

Hi fan,

---

@shuttlefan wrote:

since this last reply in 2005, has LabVIEW improved / expanded support for this situation?

---

How should LabVIEW improve on catching errors in external code (like DLLs)?

When the code in the DLL crashes, then the whole task (including LabVIEW) crashes…

---

Well, I've hit a case where it doesn't crash.  Just part of the code is locked or prevented from responding.
https://forums.ni.com/t5/DQMH-Consortium-Toolkits/random-EHL-MHL-transition-failure/td-p/4421173

[GerdW]

Hi fan,

so you don't call DLLs, but some DQMH modules?

How is this related to this old thread?

[shuttlefan]

---

@GerdW wrote:

Hi fan,

so you don't call DLLs, but some DQMH modules?

How is this related to this old thread?

---

no, I am calling a dll, that's what is causing the socket errors.  
So somehow, that is causing the module to be like a zombie.  

How it relates to this thread is I'm trying to see how to use the DLL call with crash error handling

[GerdW]

Hi fan,

---

@shuttlefan wrote:

I'm trying to see how to use the DLL call with crash error handling

---

You need to avoid any crashes in that external code!

Instead of doing this in a larger DQMH environment I would test that in a small dedicated "test VI"…

[rolfk]

It depends what your DLL does wrong. And it is ONLY solvable by writing your own intermediate DLL that is exactly tailored to the problems your DLL can cause.

Basically your DLL can throw C++ exceptions, which you can only catch with other C++ code written in the same C++ compiler and in some cases the same compiler version than what was used in your DLL that exposes that bad behavior.

Or it could cause Windows exceptions which you only can catch with the according Windows API functions.

Possible reads: https://learn.microsoft.com/en-us/answers/questions/2110867/exception-handling-in-windows

LabVIEW actually does this to a large extend if you set the Error Handling in the Call Library Node configuration to maximum, and for some things it can attempt to do a recovery. However, for most things such as illegal address access etc. there is simply nothing LabVIEW can do other than trying to do a crash log and let the process die anyhow. Anything else would need very detailed knowledge of what exactly was done wrong in the called code, to be even remotely able to try to recover from the error.

Generally, it is always a million times easier to debug the code that causes the crash or hangup and fix that, than trying to work around the bug after the fact. It's an enormous effort, with a very high chance to still go wrong sometimes or even most of the times, depending on the moon phase or the health of the dog of the operator! 😁

That's why LabVIEW even after 25 years hasn't really been able to "fix" such errors!