NI Raptor Runtime: Blue screen of death

[c.hibberd]

Hi

We've suffered two blue screens of death on a Windows 8 system running LabView code in the last couple of months. The event logs show the cause to be the NI Raptor Runtime driver. We are running LabView 2012 SP1 with all critical updates installed. Are there any known issues with this driver?

Best regards,

Chris

[mikeporter]

Assuming you are not studying predatory birds of Northern Ireland, what is NI Raptor? What is your program doing?

Mike...

[c.hibberd]

Hi Mike

Thanks for your reply. We're not using it to do anything nearly as exciting as birdwatching, the system is recording analogue and digital data and setting digital lines to control and monitor a piece of test equipment. With regards to what NI Raptor Runtime is, I don't know except that it came from National Instruments. Our sys admin just gave me the following details pulled from the blue screen dump files the first time the error happened back in June:

==================================================
Filename : niraptrk.dll
Address In Stack : niraptrk.dll+ec4cf
From Address : fffff880`05cfd000
To Address : fffff880`05f76000
Size : 0x00279000
Time Stamp : 0x5064b14e
Time String : 27/09/2012 21:04:30
Product Name : NIRAPTR
File Description : NI Raptor Runtime
File Version : 2.10.1f0
Full Path : C:\Windows\system32\drivers\niraptrk.dll
==================================================

The dll mentioned appears in a couple of other NI forum posts, without conclusions:

http://forums.ni.com/t5/Multifunction-DAQ/PCIe-6320-technical-problems-Windows-7-amp-XP-Crashing-Err...

http://forums.ni.com/t5/PXI/PXIe-1073-not-detected/td-p/1295178

We have PCI-6143 and PCIe-6323 cards installed in the machine, both appear to be working fine and we have no problems loading MAX.

Regards,

Chris

[robertpf]

 Chris,

I have found some reports on other customers using X series DAQ devices getting the same error, a DAQmx upgrade solved the problem in some if the cases. Which version of DAQmx are you using?

How does your code look like, do you start/stop the task often? In some of the reported cases the error is caused by an interrupt handler race condition.

Best regards,

[c.hibberd]

Hi Robert

Thanks for your reply. I resinstalled and updated all of the National Instruments software on the machine this week so the DAQmx version should be up-to-date. I've pasted the versions below. We experienced another blue screen within a day of the reinstall/update though.

With regards to the code, it isn't mine so I don't know it inside out. However, the general architecture is a flat sequenece in a while loop. The total loop rate is around 1-3Hz. Within individual frames of the sequence, analogue and digital input tasks are created, run, stopped and cleared in series on each loop iteration. Individual frames may not have rate limiting timers, so a create may happen quite quickly after a clear. State changes on the front panel can cause certain frames to create and run digital output tasks that change the value of output lines, however no front panel interaction was performed within at least a few hours of any of the crashes.

Do you think that it would be worth placing a frame-rate-limiting timer into the code, to reduce the rate at which tasks are stopped and started?

Best regards,

Chris

National Instruments Software: Version:

CVI Run-Time 10.0.1.434
NI-DAQmx Device Driver 14.2.0f1
NI-DAQmx ADE Support 14.2.0
NI-DAQmx MAX Configuration 14.2.0
NI Script Editor 1.3.4
NI-DMM 3.0.5
DMM Soft Front Panel 3.0.5
NI-FGEN 2.8.1
FGEN Soft Front Panel 2.7
NI-488.2 Software 2.81
NI I/O Trace 14.0.0f0
IVI Compliance Package 4.4
LabVIEW Run-Time 2010 SP1 10.0.1
LabVIEW Run-Time 2009 SP1 (64-bit) 9.0.1
Measurement & Automation Explorer 14.0.0f0
Measurement Studio Visual Studio 2010 Support - See individual versions below.
DotNET
Common 13.0.40.190
Common (64-bit) 13.0.40.190
NI-USI 2.0.0.4901
NI-DCPower 1.6.1
NI-DCPower Soft Front Panel 1.6.1
NI-HSDIO 1.7.5.1
NI-HWS 1.4.9
NI PXI Platform Services Configuration 14.0.0f0
NI PXI Platform Services Runtime 14.0.0f0
NI-RFSA 2.4.5
NI-RFSA Soft Front Panel 2.4
NI-RFSG 1.7.2
NI-PAL Software 14.0.1
NI-SCOPE
Configuration Support 3.8.5
Development Support 3.8.5
Run-Time 3.8.5
SCOPE Soft Front Panel 3.8
LabVIEW SignalExpress 6.0
NI-SWITCH 4.3.5f0
Soft Front Panel 4.3.5.49152
NI System Configuration 14.0.0f0
NI-TClk 1.9.1
NI-VISA 5.2
NiVisaServer.exe 5.1.0.49152
NIvisaic.exe 5.1.0.49152
NI-VISA Runtime 5.2
LabVIEW 12.0.1
LabVIEW Run-Time 2011 SP1 f2 11.0.1
LabVIEW Run-Time 2012 SP1 f9 12.0.1
LabVIEW Run-Time 8.2.1 8.2.1
LabVIEW Run-Time 8.5.1 8.5.1
LabVIEW Run-Time 8.6.1 8.6.1
LabVIEW Run-Time 2009 SP1 9.0.1

[Brad_K]

Hi Chris,

"NI Raptor Runtime" is the driver for the PCIe-6323 (among other devices).

Thank you for posting the DLL version and the faulting instruction address relatvie to the DLL load address (niraptrk.dll+ec4cf). That was enough information for me to load the DLL in the debugger and check which line of code crashed. Based on that, it looks like this is the interrupt handler problem that Robert referred to, which was reported to NI R&D as CAR #520554.

Brad

[c.hibberd]

Hi Brad

Thanks for your input on the source of the problem. Since it looks like it is a race condition, I've inserted a delay after every task clear to try and reduce the chances of it occuring. The code is running and time will tell if the delay avoids the problem.

Regards,

Chris

[hvontres]

Brad,

Thank you for confirming this issue. Is there an ETA for a fix for this? I am currently seeing this issue anywhere from 30 minutes to 16 hours into a test. If not, is there at least a reccomended workaround to minimize the potential for this issue to cause a Blue Screen ?

Thanks,

Henry

[J-Barticus]

Hi Henry,

Unfortunately we do not have an ETA for when a fix will be available, however as Brad mentioned there is a CAR filed for this issue so a fix is expected in a future NI-DAQmx release. The readme for each release lists a subset of all "Bug Fixes" by CAR ID, you can check the readme of future NI-DAQmx versions to see if CAR 520554 has been addressed. As this is only a subset of all fixes we do recommend that you upgrade to the latest version of NI-DAQmx when possible.

This issue is more prevalent in code that continuously/frequently creates and destroys tasks. As such I would recommend re-architecting your code to reduce the frequency of this behavior if this is the case or increasing the time between the clearing of a task and the creation of a new task. Depending on your application and complexity of the code, if you are able to share the code we may be able to advise on a more suitable method of performing the acquisition.

Best,

Jake Bartholomew
NI R&D - PSE

[hvontres]

Jake,

Thanks for the update.

I can post the code, but basically we are using the C-api through ctypes from a python scrpt.

Looking at our code, we don't re-create the task once we have it initialized. We do howerver make repeated callst to DAQmxReadAnalogF64 and DAQmxStopTask.  Is this a likely scenario to trigger this problem ?