Task.Dispose() causes internal System.AccessViolationException

[zkhan.cimtec]

This is a bit of a strange one in that this functionality had been working for us for quite some time, but stopped doing so recently. To summarize, our application has an Initialize() method that sets up the DAQ. This includes creation of tasks. If these tasks already exist (e.g. if we are "re-initializing), then the .Dispose() method of the existing task is invoked before it is replaced with a new Task object. What we see now is that upon re-initializing, this call to Dispose() throws a System.AccessViolationException within the internals of Measurement Studio. I have even tried catching this exception, but to no avail.

Here is the relevant parts of the stack trace:

Application: Enhanced.UI.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.AccessViolationException
Stack:
   at <Module>.nNIMSAI100.MAPIDestroyTask(nNIMSAI100.tTask*, nNIMSAI100.iTaskRegistrar*, nNIMDBG100.tStatus2*)
   at NationalInstruments.DAQmx.Task.!Task()
   at NationalInstruments.DAQmx.Task.~Task()
   at NationalInstruments.DAQmx.Task.Dispose(Boolean)
   at NationalInstruments.DAQmx.Task.Dispose()
   at Enhanced.DSP.NiDaqManager.disposeTask(NationalInstruments.DAQmx.Task)
   at Enhanced.DSP.NiDaqManager.Initialize(Enhanced.DSP.InitParams)
   ...
   at System.Windows.Forms.Application.Run(System.Windows.Forms.Form)
   at Enhanced.UI.Program.Main()

[zkhan.cimtec]

To add some more context, the Initialize() method also always resets the DAQ programmatically before any tasks are disposed, like so:

 Device dev = DaqSystem.Local.LoadDevice(initParams.AddrI.Device);
 dev.Reset();

Initially I was under the impression that resetting the device in this manner would dispose of all tasks anyway, but I found that when trying to re-create a task, I got an exception stating that a task with that name already existed. This is why each task is disposed before it is re-created.

This seemed to be working fine up until recently, but after combing through recent changes, I can't find what might have led to uncovering this error. That said, the error appears to occur inside Measurement Studio, so at the very least, if I'm doing something wrong, I would expect Measurement Studio to provide an actionable error message (instead of a System.AccessViolationException in its internals).

[Sil.VI]

Hi zkhan.cimtec,

I have been reading a bit through the task.dispose() funciton for Measurement Studio, I found some interesting information that when you use the task.dispose() How are you making the call to the method? Are you stopping it first?

Probably there might be a conflict or some unhandled error with the threads that are being used.

Have you tried getting some info placing some breakpints near the methods that triggers the Access Violations?

[zkhan.cimtec]

---

@s.jimenez wrote:

Hi @zkhan.cimtec,

I have been reading a bit through the task.dispose() funciton for Measurement Studio, I found some interesting information that when you use the task.dispose() How are you making the call to the method? Are you stopping it first?

Probably there might be a conflict or some unhandled error with the threads that are being used.

Have you tried getting some info placing some breakpints near the methods that triggers the Access Violations?

---

The .Dispose() call on the task is being made after the Device.Reset() call has been made. I believe the .Stop() method is also called before that, but I would presume that resetting the device stops all tasks in any event.

Yes, I used breakpoints to find the call which was triggering the exception, but as you can see from the call stack, the exception is being thrown inside Measurement Studio (for which I do not have the source code). The last line inside of our code before the exception is the Task.Dispose() call.