irql stop error probably caused by nimdsk

[luke.bissell]

I am using the NI-DAQmx 8.7 driver with Labview 7.1. I get an IRQL stop error when the driver is running and data is being written to a file from the PCI 6602 counter card. The bugcheck output follows below. Any suggestions are appreciated.

Cheers,

Luke Bissell

************************

Loading Dump File [C:\WINDOWS\Minidump\Mini081910-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: symsrv*symsrv.dll*c:\localsymbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows XP Kernel Version 2600 (Service Pack 2) MP (2 procs) Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 2600.xpsp_sp2_gdr.100216-1441
Machine Name:
Kernel base = 0x804d7000 PsLoadedModuleList = 0x8055c700
Debug session time: Thu Aug 19 19:43:21.515 2010 (UTC - 4:00)
System Uptime: 2 days 7:06:59.210
Loading Kernel Symbols
...............................................................
................................................................
..............................
Loading User Symbols
Loading unloaded module list
................
Unable to load image nimdsk.dll, Win32 error 0n2
*** WARNING: Unable to verify timestamp for nimdsk.dll
*** ERROR: Module load completed but symbols could not be loaded for nimdsk.dll
Unable to load image Nidaq32k.SYS, Win32 error 0n2
*** WARNING: Unable to verify timestamp for Nidaq32k.SYS
*** ERROR: Module load completed but symbols could not be loaded for Nidaq32k.SYS
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 100000D1, {e188bf20, 2, 0, a9ed3f69}

*** WARNING: Unable to verify timestamp for nipalk.sys
*** ERROR: Module load completed but symbols could not be loaded for nipalk.sys
Probably caused by : nimdsk.dll ( nimdsk+3f69 )

Followup: MachineOwner
---------

1: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high.  This is usually
caused by drivers using improper addresses.
If kernel debugger is available get stack backtrace.
Arguments:
Arg1: e188bf20, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: a9ed3f69, address which referenced memory

Debugging Details:
------------------


READ_ADDRESS:  e188bf20

CURRENT_IRQL:  2

FAULTING_IP:
nimdsk+3f69
a9ed3f69 393c98          cmp     dword ptr [eax+ebx*4],edi

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  DRIVER_FAULT

BUGCHECK_STR:  0xD1

PROCESS_NAME:  LabVIEW.exe

LAST_CONTROL_TRANSFER:  from a9604f59 to a9ed3f69

STACK_TEXT:  
WARNING: Stack unwind information not available. Following frames may be wrong.
f88e4e74 a9604f59 00000000 00000000 f88e4e94 nimdsk+0x3f69
f88e4e98 a9605cf6 f88e4f3c f88e4f3c a88f5730 Nidaq32k+0x5ef59
f88e4ebc a9603bc7 000000a2 f88e4f3c a88f5730 Nidaq32k+0x5fcf6
f88e4ee0 a9604b09 0000000d 000000a7 a8974538 Nidaq32k+0x5dbc7
f88e4f04 a960584e 0000000d 00000000 f88e4f3c Nidaq32k+0x5eb09
f88e4f20 a96050d3 0000000d 00000000 00000000 Nidaq32k+0x5f84e
f88e4f40 f827921f f80f8980 00000000 f80f8980 Nidaq32k+0x5f0d3
f88e4fb4 f827d6bb f88e4fcc f8266d17 f80f8980 nipalk+0x4721f
f88e4fbc f8266d17 f80f8980 f82851d2 f8755980 nipalk+0x4b6bb
f88e4fcc 8054510f f80f91a8 f80f6738 f80f8df0 nipalk+0x34d17
f88e4ff4 80544c7b a8671d44 00000000 00000000 nt!KiRetireDpcList+0x61
f88e4ff8 a8671d44 00000000 00000000 00000000 nt!KiDispatchInterrupt+0x2b
80544c7b 00000000 00000009 0081850f bb830000 0xa8671d44


STACK_COMMAND:  kb

FOLLOWUP_IP:
nimdsk+3f69
a9ed3f69 393c98          cmp     dword ptr [eax+ebx*4],edi

SYMBOL_STACK_INDEX:  0

SYMBOL_NAME:  nimdsk+3f69

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: nimdsk

IMAGE_NAME:  nimdsk.dll

DEBUG_FLR_IMAGE_TIMESTAMP:  3ce40f83

FAILURE_BUCKET_ID:  0xD1_nimdsk+3f69

BUCKET_ID:  0xD1_nimdsk+3f69

Followup: MachineOwner
---------

1: kd> .reload
Loading Kernel Symbols
...............................................................
................................................................
..............................
Loading User Symbols
Loading unloaded module list
................
Unable to load image nimdsk.dll, Win32 error 0n2
*** WARNING: Unable to verify timestamp for nimdsk.dll
*** ERROR: Module load completed but symbols could not be loaded for nimdsk.dll
1: kd> lmvm nimdsk
start    end        module name
a9ed0000 a9edb000   nimdsk   T (no symbols)           
    Loaded symbol image file: nimdsk.dll
    Image path: nimdsk.dll
    Image name: nimdsk.dll
    Timestamp:        Thu May 16 15:58:59 2002 (3CE40F83)
    CheckSum:         0000847D
    ImageSize:        0000B000
    Translations:     0000.04b0 0000.04e4 0409.04b0 0409.04e4

[Brad_K]

Hi Luke,

Thanks for posting the crash dump analyze log. nimdsk and nidaq32k are part of Traditional NI-DAQ, not NI-DAQmx. Is part of your application using Traditional NI-DAQ?

Brad

[luke.bissell]

Brad,

The VI I use interfaces with a PCI 6602 counter card and a PCI 6052E (multifunction DAQ). In the measurement and automation explorer, both cards are listed as traditional NI-DAQ and as NI-DAQmx devices. I *want* to say that I installed the NI-DAXmx driver a couple years ago when I tried upgrading to Labview 8. But for whatever reason, my VI didn't run under v8, so I went back to v7.1.

Honestly I don't know whether I need NI-DAQmx or not. Is there a quick way to tell?

[Brad_K]

Hi Luke,

I'm not sure what the best way is, but one approach is to use the "View >> Browse Relationships >> Unopened SubVIs" menu to view the icons of all of the subVIs used by your application (assuming that it doesn't use VI server to dynamically load subVIs). The icons of the DAQmx subVIs are labeled "DAQmx" and should be easy to notice.

Brad

[luke.bissell]

As far as I can tell, none of the subVIs use DAQmx. Could this be a driver conflict, then?

[Brad_K]

Hi Luke,

NI-DAQmx and Traditional NI-DAQ should not conflict with each other. They have some shared code that allows control of DAQ devices to be transfered between the two drivers. Because your app doesn't use any NI-DAQmx VIs, this issue is probably not related to NI-DAQmx. (So don't bother upgrading NI-DAQmx on account of this issue.)

Traditional NI-DAQ is an older, legacy driver. If you're developing a new application, I strongly recommend using DAQmx, but it sounds like this is an older application. Has this application been working correctly for a long time, or has it always crashed like this? Can you reliably reproduce the crash? If you can isolate the code that causes the crash, post it here and perhaps someone will be able to suggest a workaround.

If you installed NI-DAQmx 8.7 and Traditional NI-DAQ from the same NI Device Drivers DVD, then you should already have the latest version of Traditional NI-DAQ, version 7.4.4f7. If you want to double-check, MAX should display the Traditional NI-DAQ version under My System >> Software.

Brad