Computer crashing from device driver nimsdrk.dll

[U.ofT.]

I have been running LabView for sometime without any problems. Recently, I have found that after a relatively brief period of time, LabView will crash my computer and cause a system memory dump. The crash analysis suggests that it was caused by the device driver nimsdrk.dll. This error is now happening consistantly.

[gus]

Hrm. That seems strange. Which device were you using at the time? What application was running? What OS are you using with this system? It does seem really strange that the error would start to happen more though.

gus....

[sergesl]

Hello U. of T.
This error might occur under several circumstances, all due to some error in the program so far. If you are running some data acquition using NI-DAQ or NI-DAQmx, I would advise you to upgrade your driver to the newest version. If that does not solve the problem, please post your VI and provide some information about your hardware and software setup as well as your system settings.
Thanks for calling National Instruments. It is always a pleasure to help our customers.

Serges Lemo
Application Engineer
National Instruments

PS: If I assume that U. of T. means University of Texas, go horns for tomorrow. I can't wait...

[Bob_Y.]

I would lkie to add a big ol' ME TOO to this.

I have a customer that has been seeing a system reboot about 1 to 3 times a week. After several weeks of telling him that it must be a microsoft problem, we figured out a way to get it to log more data during the crash. It turns out that it is reporting that NIMSDRK.DLL is the problem "driver". The blue screen that we finally got XP to provide shows the problem as:

DRIVER_IRQL_NOT_LESS_OR_EQUAL
NIMSDRK.DLL
f2e89f7a f2e86000 Datestamp 40ede044
STOP 0x000000D1 (0x00000000, 0x00000002, 0x00000000, 0xf2e89f7a)

Unfortunately, I did not get all of the message recorded, but merely took down the highlights. After the reboot, I looked at the dll's properties. Version 1.2.1.49152 or Version 1.2.1f0 depending on where you look. The name for this DLL is National Instruments Measurement Streaming DMA Runtime Co (which I assume is controller).

The system is a Pentium 4 (with HyperThreading) running XP-pro SP1; connected through a MXI-4 bus to a PXI-8331 in a PXI/SCXI chassis.

Let me know if you figure out what the problem is or better yet a fix for it.

Thanks
Bob Young

[gus]

Hello Bob-

Can you give me some more information about what your application was doing when you saw this error? And what device(s) you were running at the time?

Thanks!
gus....

[Bob_Y.]

It has crashed several times. These are not always in the same place or while doing the same things. This made it very difficult to track down. At first I believed that it was a Microsoft problem. The I was convinced that it was a BIOS problem. Then I spoke to our IT person and he gave me some help on getting more information about the crash. It turns out that it is a problem with the NIMSDRK.DLL.

That being said, usually just before the crash we were using LabVIEW to control a PXI/SCXI chassis with the following cards:
PXI-8331 to communicate with the PC
PXI-6509 Digital I/O to switch some relays
PXI-2530 with TB-2632 configured as an 8X16 matrix to simulate an encoder (via Switch Executive)
PXI-6071E MIO used mainly to communicate with the SCXI portion of the chassis
SCXI-1104C with SCXI-1300 AI is used to scan some digital (non-TTL level) lines
SCXI-1124 with SCXI-1325 AO is used to simulate some sensors
SCXI-1127 with SCXI-1332 configured as an 8x8 matrix to simulate some outputs

The customer has been unable to figure out a commonality among the crashes. He has not been able to figure out any particular setting or change or transition that is causing the crash. It is a lot of HW through MAX from LabVIEW (and even that sometimes being called from TestStand) and there is not an easy way to make it repeat. It does not always crash. You can do the same thing several times in a row and then suddenly, it will crash on exactly the same thing. Or on the first time through something.

I am not sure if it is more AI, AO, DI, DO, switch control or what. I know that this not much to go on, but it really is very random. One thing to note is that it seems to happen more often if there are a lot of things (like sub-vis) open at once. This may be a false clue however, since it's usually much more annoying when you are in the middle of debugging something so it may just _seem_ to happen more often then.

Thanks,
Bob Young

[Salvador_Santolucito]

We've seen this error in the past with Windows 2000 and the nimsdrk.dll. We found that the error was due to the computer running low on memory resources and DMA data transfers. In a couple cases, we saw that when a system was operating for long periods of time or doing large finite acquisitions using several boards, the computer's memory resources would get very low and this error would be seen. In those cases, the error went away when interrupts were used instead of DMA transfers.

I would suggest trying your application with one (or more) of your boards set to use interrupts instead of DMA.

Here is a KB on how that can be accomplished: http://digital.ni.com/public.nsf/websearch/E30189253619A50086256D1300727C80?OpenDocument

-Sal

[Bob_Y.]

For those that find this thread, there is the info in the KB:

How do I set my DAQ device to use Interrupts instead of DMA?
Primary Software: LabVIEW Development Systems>>Full Development System
Primary Software Version: 7.1
Primary Software Fixed Version: N/A
Secondary Software: LabWindows/CVI Development Systems, Measurement Studio, LabVIEW Development Systems, Measurement Studio>>.NET Support, Measurement Studio>>Visual C++ Support, Measurement Studio>>ActiveX Support

Problem: How do I set my DAQ device to use Interrupts (IRQ) instead of DMA or vice versa?

Solution:

For LabVIEW:

* For Traditional DAQ: Use the "Set DAQ Device Information.vi", which is located on the Functions Palette » Data Acquisition » Calibration and Configuration. Using this VI you can change the transfer mode to use DMA or interrupts. See the LabVIEW help for information on using this VI.

* For DAQmx: Use the DAQmx Channel Property Node, which is located on the Functions Palette » DAQ - Data Acquisition palette. Right click and select Properties » Analog Input » General Properties » Advanced » Data Transfer and Memory » Data Transfer Mechanism.


For CVI (or Visual Basic / Visual C++):

* For Traditional DAQ: Use the "Set_DAQ_Device_Info" function. Refer to the NI-DAQ Help file for more information on using this function.

* For DAQmx: Use the DAQmxSetAODataXferMech function.

[Bob_Y.]

I don't have acces to the crashing system right now; it is at a customer site. I have tried to look at the DAQmx Channel Property Node on my main desktop, but the properties that are in the KB are unavailable. Is this because I do not have any DAQ devices on my desktop machine? I installed DAQmx and have the property node, just not the property listed.

If someone could post a VI that has this property node configured in the way described by the KB I would be very grateful.

Thanks,
Bob Young

[Salvador_Santolucito]

Hi Bob,

Here is the property node vi and screenshot.

-Sal