DAQmxResetDevice never returns. PC must be rebooted

[Mitch7]

We have a problem where our program never returns from a call to DAQmxResetDevice(). The program cannot be stopped via task manager. Trying to shutdown the PC frequently results in a blue screen of death (BSOD). Sometimes the Windows won't even shut down and we must resort to physically powering off the PC.

This is the code that gets called when the program starts and when it tries to recover from an error such as the USB cable is removed and reinserted. Is there some precondition that should be checked before calling DAQmxResetDevice? Or should it ALWAYS be safe to call it? Note that some of the args and error handling has been removed so you can see the sequence of calls.

            err = DAQmxResetDevice( m_device );   <= hangs on this statement
            if (err != 0)
            {
                DAQmxGetErrorString(err, errorString, 1024);
                Log(errorString);
            }

            if( DAQmxCreateTask( "", &m_analogTaskHandle ) == 0)
            {
                err = DAQmxCreateAIVoltageChan( ... m_analogTaskHandle ... );
                
                if( err == 0 )
                {
                    DAQmxStartTask( m_analogTaskHandle );
                }
            }

Thanks for any ideas, we're getting close to product release and we don't want our customers having to reboot their PC just because of glitch in the NI code.

Hardware is a USB6008 connected to PC via an external hub. Sometimes we have two of these systems (two hubs, two USB6008 cards) connected to one PC. But it will happen when only one is currently conected.

Win7 64

DAQmx 9.2

Mitch

[Mitch7]

Additional Info. This is the WinDbg analysis of the minidump file created when the BSOD happens during shutdown. Note that the probable cause is nipalk.sys.

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

DRIVER_POWER_STATE_FAILURE (9f)
A driver is causing an inconsistent power state.
Arguments:
Arg1: 0000000000000004, The power transition timed out waiting to synchronize with the Pnp
    subsystem.
Arg2: 0000000000000258, Timeout in seconds.
Arg3: fffffa8006d58680, The thread currently holding on to the Pnp lock.
Arg4: fffff80000b9c510

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


DRVPOWERSTATE_SUBCODE:  4

FAULTING_THREAD:  fffffa8006d58680

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

BUGCHECK_STR:  0x9F

PROCESS_NAME:  System

CURRENT_IRQL:  2

LAST_CONTROL_TRANSFER:  from fffff80002ad5992 to fffff80002ad45da

STACK_TEXT:  
`00000000 : nt!KiSwapContext+0x7a
`08e5ca90 : nt!KiCommitThreadWait+0x1d2
`8002de00 : nt!KeWaitForSingleObject+0x19f
`009b2180 : nipalk+0x8e784
`00024010 : 0xfffff8a0`14132000
`03569460 : 0xfffff800`00000000
`03a3d7b5 : 0xffff0000`00020000
`03569460 : 0x8002de00
`03a78488 : 0xfffff880`009b2180
`00000000 : 0xfffff8a0`00024010
`000e0082 : 0xfffff880`03569460
`00000000 : nimxdfk+0xb7b5
`ffffffff : 0xfffff880`03569460
`00000020 : nimxdfk+0x46488

BugCheck 1000009F, {4, 258, fffffa8006d58680, fffff80000b9c510}

Unable to load image \SystemRoot\System32\drivers\nipalk.sys, Win32 error 0n2
*** WARNING: Unable to verify timestamp for nipalk.sys
*** ERROR: Module load completed but symbols could not be loaded for nipalk.sys
Unable to load image \SystemRoot\system32\DRIVERS\nimxdfk.dll, Win32 error 0n2
*** WARNING: Unable to verify timestamp for nimxdfk.dll
*** ERROR: Module load completed but symbols could not be loaded for nimxdfk.dll
Probably caused by : nipalk.sys ( nipalk+8e784 )

BSODs are really unacceptable. Thanks for your help.

Mitch

[Seth_B.]

Hello Mitch,

What you are seeing is likely a known issue with certain USB host controllers that we are working to fix.  What operating system are you using?

With certain USB host controllers, it's possible for a USB-6009 that is connected to a device to hang indefinitely.  When a call is made to reset the device, this call also hangs in the kernal and can't return.  Restarting the operating system can cause a BSOD at that point, because Windows is still hung at a kernal level.  The safe recourse is to physically unplug the device and plug it back in.  You can also try using the devcon utility to force Windows to remove and readd the USB device.  More information can be found in this KnowledgeBase: How Do I Force Windows to Remove and Redetect a USB Device?

We have been investigating this issue and are working on a fix for it, though due to that fact that the issue is exacerbated by the Operating System and the specific USB Host Controller used, the issue is very complicated to fix.

[Mitch7]

Thanks Seth,

> What operating system are you using?

We are using Win7 64 bit.

> We have been investigating this issue and are working on a fix for it,

Is there any way for me to track this investigation? I'd like to know if and when there is a fix. I can even beta test things if that will help.

> ... due to that fact that the issue is exacerbated by the Operating System and the specific USB Host Controller used...

The PC is a Dell Precision T1500. Looking in device manager, the name of the host controller is

Intel 5 Series / 3400 Series Chipset Family USB Enhanced Host Controller

Driver date 6/4/2009

Driver Version 9.1.1.1013

Can I provide any other information?

Mitch

[Seth_B.]

Hello Mitch,

Windows 7 64-bit is the only operating system in which resetting the device will not correct this issue and may result in hanging or a crash.  If you can move to Windows Vista 62-bit or Windows Seven 32-bit, you will not encounter this issue.  On all other supported operating systems, Device Reset should return the device to a functioning state.

We are investigating this issue under Corrective Action Request #181229.  We will likely not be able to fix this issue in time for our upcoming release (some time in late Q1 or early Q2), but we are hoping to have a resolution for the release after that, some time in the mid to late summer.

[Mitch7]

Hi Seth,

you wrote:

> Windows 7 64-bit is the only operating system in which resetting the device will not correct this issue and may result in hanging or a crash.

The USB6008 board is embedded into an instrument we sell, so it would be too restrictive to tell our customers they can't use the latest windows OS. So, given that we will be using Win7 64 with the USB6008 board, can you think of any work arounds?

Maybe there are other calls, that taken collectively, will be the equivalent of resetting the device? Maybe manually testing and aborting task? or something like that? I only know what I need to know to get this card running in our instruments, I have no prior experience with NI cards or NI APIs.

One situation that causes a freeze is calling DaqMxResetDevice after coming back from a power fail scenario. I read in the online help that we can write some of the config info into EPROM using DAQmxSetDigitalPowerUpStates. Since we always configure the channels the same way, will this help us in coming back after a power fail?

I'm just looking for ideas so we can ship our product.

Thanks,

Mitch

[Seth_B.]

Hello Mitch,

DAQmx Device Reset is a unique function that uses code on the device itself to return to a largely uninitialized state.  There aren't really equivalent functions that would allow for building up an equivalent operation.

One thing that you might do is self-test the device first.  If the device passes self test, it shouldn't be in a situation where resetting the device will cause an error.  If the device fails self-test for some reason, I would recommend investigating the option of using the devcon utility that I mentioned earlier to do the programmatic eqivalent of unplugging the device and plugging it back in.

As for setting digital power up states, the USB-6008 does not support programmable power up states.

[Mitch7]

Hi Seth,

> One thing that you might do is self-test the device first.

I assume you are referring to something like the following?

if ( DaqMxSelfTestDevice(deviceName) == 0)

{

    // self test passsed

    DaqMxResetDevice(deviceName)

}

else

{

     // what to do here  if the "self test" fails?

}

If so, what should I do if the self test fails?

Are you suggesting that I try to use devcon to get it out the the unresettable state? And then figure out how to write code that will do the same thing that devcon is doing?

Thanks,

Mitch

[Seth_B.]

I would recommend code that uses DAQmx Device Reset if the OS is not Windows 7 64-bit.  If it is, then use the devcon utility to remove the USB device and the rescan for it to add it again.  Then, self test again to make sure the device is working and if so, proceed as normal.

If you aren't able to distribute devcon with your application, you may want to instead present the user with a message requesting that they unplug the USB device and plug it back in.

[VeeJay]

Don't mean to highjack this conversation. My question is on similar lines.

I use Windows 7 64 bit OS. Does that mean, I should not use daqmx reset.vi at all? I have a reset state in a state machine that resets the daq channels (or atleast I think it does). My program runs 24x7 and resets every midnight. Please find attached screenshot.

Is the alternative you suggested the only way to work around?

V