Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

BSOD blue screen crash if a task containing simulated devices is explicitly committed

Hi,

 

The attached code is based off of the ContAcq-IntClk.c code example from NI.

The code works correctly with actual hardware but blue screen crashes when run with simulated devices.

 

I did some investigation and it seems that the crash happens only with simulated devices and only if I explicitly commit the task using DAQmxTaskControl

The crash always happens when acquiring a 2nd set of data with a larger number of scans than the 1st set of data acquired.

 

cDAQ1Mod1 is a simulated device
Running on Windows 7 (32 bit)
NIDAQmx Driver: 9.1.0f0

 

Please find the code to reproduce this problem attached.

 

Thanks,

   whemdan, The MathWorks

0 Kudos
Message 1 of 4
(3,452 Views)

Here's the code to reproduce this issue.

 

Thanks,

   whemdan, The MathWorks

0 Kudos
Message 2 of 4
(3,451 Views)

I was able to reproduce this and I've filed Corrective Action Request #242484 with R&D to investigate and correct this issue.

 

May I ask why you chose to explicitly commit the task? DAQmxCfgSampClkTiming will move the task back into the verification state, which means that your task will be implicitly re-committed at DAQmxStartTask. In your example, you gain nothing by having done the explicit commit, thus the workaround that you noted of not doing DAQmxTaskControl(Commit) will give you identical results as it would if it had not bluescreened.

 

Thank you for bringing this to our attention-- we're not fond of bluescreen bugs. If you'd like to check on the status of this Corrective Action Request in the future, post to the forums requesting an update on CAR#242484 and we'll let you know the status.

——
Brandon Streiff
ni.com/compactdaq · ni.com/daq
Message 3 of 4
(3,425 Views)

Hi,

 

Thank you for your quick response.

 

I am running code where I am reusing tasks for multiple acquisitions and I was committing the task explicitly to reduce the latency of future calls to DAQmxStartTask.

 

Thanks,

   whemdan, The MathWorks

0 Kudos
Message 4 of 4
(3,417 Views)