Getting AcceesViolationException from NationalInstruments.DAQmx.Task.UnregisterAsyncWaitHandle

[hpeled]

Hi,

I'm using my own .net application that communicates with NationalInstruments.DaqMx.dll (version 9.7) in order to activate NiDaq in the following configuration:

PXI -1033 chassis with two slots of PXI-6284, measuring differential voltage. This application was already running for some months and was tested under high performance - high sampling rate and long hours, with no problems so far. Recently we were trying a new use case - running short sessions (60 mins each) of measurements in sampling rate = 100 and samples per channel =100. after few iterations we keep getting access violation exception:

Exception Info: System.AccessViolationException

Stack:

   at NationalInstruments.DAQmx.Task.UnregisterAsyncWaitHandle(System.Threading.WaitHandle)

   at NationalInstruments.DAQmx.Internal.DaqAsyncResult.AsyncOpDone()

   at NationalInstruments.DAQmx.Internal.AnalogMultiChannelMemoryOptimizedMultiSampleReadAsyncResult.WorkItem(System.Object)

   at System.Threading.QueueUserWorkItemCallback.WaitCallback_Context(System.Object)

   at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)

   at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)

   at System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()

   at System.Threading.ThreadPoolWorkQueue.Dispatch()

   at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback()

Keeping the sampling rate as 100, but setting samples per channel to 1000 seems to solve this problem.

Can someone explain me what is the cause of this exception?

Thanks,

Hadas

[Poolean]

Could you please give some more information about your issue by answering the following questions:

1. How are you communicating with the NationalInstruments.DaqMx.dll? Are you make calling the DAQmx API? Or, are you doing something different?

2. You stated the issue occurs in your new use case. What is the use case and how does it differ from the old case?

3. What sampling rate and samples per channel settings were you using in the old working application?

-Mike

[hpeled]

1.Yes,I'm using DAQmx API. For reading the samples I create an instance of

AnalogMultiChannelReader and call BeginMemoryOptimizedReadMultiSample and EndMemoryOptimizedReadMultiSample, continuously,providing a local double[,] for the results. 

2+3 - the difference in the new use case is the lower sampling rate + sample per channel. Usually we use 1000 for the both, or higher (up to the limit of 500K aggregated). We always set sample_per_channel = rate.

Thanks,

Hadas

[Poolean]

Thanks for replying. I'll have to look into this issue some more and get back to you with updates. In the meantime, if you're able to post the code you're working on that'd be helpful.

-Mike

[hpeled]

Thanks Mike,

I attached the relevant code pieces. Generally, it is based on the example on NI-DAQ\Examples\DotNET4.0\Synchronization\Multi-Device\AIContAcquisition\cs.

It has 4 classes:

SyncTask - an abstract class that represents one task

NiSyncTask - a derived class that does the actual access to DAQmx API

TaskManager - an abstract class that manages several SyncTasks

NiTaskManager - a derived class that manages NiSyncTasks 

It's quite complicated, but I hope it will be helpful.

Regards,

Hadas

[Poolean]

I have a few more questions to help troubleshoot the issue:

1. You stated the exception is thrown after a few iterations. Could you expand on this and specify the number of iterations?

2. Is the number of iterations before crashing consistent?

3. What are you iterating through?

4. How often are you calling the DAQmx read?

5. I want to confirm that the only difference between the new crashing application and the older long running application is that sample_per_channel = rate for the old application.

6. Are any other errors being thrown?

7. Could the way your error handling is configured be masking other errors?

-Mike

[hpeled]

Hi Mike,

1 + 2 + 3- there is no consistency in the occurrence of the exception, I saw it happens after 8 - 50 iterations = calls to Read

3+ 4.when calling BeginMemoryOptimizedReadMultiSample I supply callback function called ChannelRead wich first calls EndMemoryOptimizedReadMultiSample and starts saving the data to the disk, and than calls BeginMemoryOptimizedReadMultiSample again. so basically, right after Start I call BeginMemoryOptimizedReadMultiSample  for the first time, and it keep being called after every EndRead.. since samples_per_channel = rate - it happens once for every second.

5. I always run with samples_per_channel = rate, the difference now is that rate=100 instead of 1000 or higher.

6. I saw no other errors

7. could be, since I run in a different thread for every task (two tasks),  I'll check it.

Thanks,

Hadas

[Poolean]

Thanks for answering those questions. And, please let me know what you find about errors potentially being hidden. I'm trying to better understand how the read method interacts with WaitHandle. I'll let you know when I have more to go on.

-Mike

[Poolean]

I've been unable to locate an UnregisterAsyncWaitHandle member associated with NationalInstruments.DAQmx or AsyncWaitHandle while searching through NI help or MSDN.

Did you create this call? If not, could you point me to some documentation for it? The same goes for: NationalInstruments.DAQmx.Internal.DaqAsyncResult.AsyncOpDone() and NationalInstruments.DAQmx.Internal.AnalogMultiChannelMemoryOptimizedMultiSampleReadAsyncResult.WorkItem(System.Object)

Also, as an additional troubleshooting step, please check if the reference to the wait handle is still valid between the calls leading up to the AcceesViolationException being thrown.

-Mike

[hpeled]

Sorry, I didn't make those calls, I just called the APIs I mentioned above, nor I have any access to these calls code or documentation. All I've got is the documentation comes along with DAQmx dll.

Regarding the WaitHandle, since I have no access to the code that makes the call, I can't really watch it during debug.

Maybe the problem is related to BeginMemoryOptimizedReadMultiSample, and I shoud use the regular BeginReadMultiSample instead?

Regards,

Hadas