What happens to daqMX tasks when not properly closed?

[BowenM]

I'm looking for a whie paper or something explaining what exactly happens to daqMX tasks when they are unexpectedly aborted.  Computer crashes, someone pushes the "Abort Execution" button, program is closed from task manager, etc.

I ask because I'm getting some unexpected behavior in this case, and I want to understand what is going on.

[NIquist]

They become disconnected virtual spirits doomed to roam the interwebz for all eternity.    If you listen closely in the still of the night sometimes you can hear them wailing...

No wait, those are just COBOL programmers. 

[BowenM]

---

@NIquist wrote:

They become disconnected virtual spirits doomed to roam the interwebz for all eternity.    If you listen closely in the still of the night sometimes you can hear them wailing...

No wait, those are just COBOL programmers. 

---

While amusing, not exactly useful.... 

[rolfk]

Depends a bit. If the LabVIEW hierarchy in which they were created terminates normally (meaning the  top level VI goes idle) the task is automatically cleaned up by LabVIEW, just like with refnums. If you terminate the process brutally the daqMX DLL should clean them up as soon as it gets unloaded after the process died (either from a crash or process kill).

However, Windows may not always allow a DLL to execute its cleanup routine when the process loading that DLL was fatally terminated. Also certain things are not safe to do for a DLL during loading and unloading, as that could deadlock the Windows module loader.

[crossrulz]

In a test system I was developing, if we did not close out our DAQmx tasks, we would get a "resource not available" error.  The only way out of it was to shut down LabVIEW and TestStand.  That was a few years ago, so things may have changed.  But based on that experience, the tasks are still there, you just lost your reference to it.  Aren't memory leaks so much fun?

[BowenM]

---

@rolfk wrote:

Depends a bit. If the LabVIEW hierarchy in which they were created terminates normally (meaning the  top level VI goes idle) the task is automatically cleaned up by LabVIEW, just like with refnums. If you terminate the process brutally the daqMX DLL should clean them up as soon as it gets unloaded after the process died (either from a crash or process kill).

However, Windows may not always allow a DLL to execute its cleanup routine when the process loading that DLL was fatally terminated. Also certain things are not safe to do for a DLL during loading and unloading, as that could deadlock the Windows module loader.

---

I figured it had some automatic cleanup stuff.  What about the case where the computer locks / shuts down (someone comes by and unplugs it)?  We're talking specifically cDAQ.

[BowenM]

Edit (since a double post anyway)... I figured out the odd behavor I was seeing, but I think it is still important to understand exactly what is going on in the hardware.

[rolfk]

Aaa, well, cDAQ is a special beast! Since it has in fact its own intelligent controller onboard and needs to have some resource locking in order to prevent two clients trying to access the same resource at the same time over the network. So you have some special functions in the DAQmx API to try to claim and reserve the resource and then to release it again.

Look at DAQmx Reserve Network Device.vi and DAQmx Unreserve network Device.vi