BSOD with USB-6211

[charliew_aem]

I have been getting a BSOD while using a USB-6211 multifunction daq, the offending file is "nipalk.sys".

It is not repeatable, sometimes it will work all day with no problems, but when it does crash it does so immediately the software loads. I have tried putting in break points to try and isolate where the crash occurs, but it seems to crash before any code is even called.

After the crash several executable and code files are missing or corrupted on the disk, and have to be re-created, and occasionally I have had to to reinstall Visual Studio itself when some of its files have been corrupted. I have also had the same problem on my development machine which runs Window7, 64 bit, and I have also had it crash when I try and access the device using NI Measurement and Automation Explorer.

Operating system is Windows XP Home, 32 bit, service pack 3.

I have installed NI-DAQmx 9.2

I am accessing the USB-6211 using a custom .NET program written in C#.

I have have a mini-dump from the crash, but cannot add it as an attachment, seems to have the wrong extension.

Any ideas would be appreciated.

Charlie

[Brad_K]

Hi Charlie,

Please put the minidump in a .zip file. Then you should be able to attach it to a post on this forum.

When you say "when it does crash it does so immediately the software loads", what software are you talking about? Is this when Windows boots? Or when you start your application? Do you start your application immediately after boot (e.g. from the Startup folder or Run registry key), or later?

Brad

[charliew_aem]

Brad,

Thank you for the reply.

1)

Attached is a zip file containing 4 minidump files.

The crash, if it is going to happen, occurs as soon as my application starts. The application is started manually some time after the system boots. The crash has occured when the application is run as a standalone executable, and when run in the Visual Studio debugger.

Using the debugger I have found that the problem usually occurs even before the first line referencing the DAQ is called (I put a breakpoint on the first line in the FormLoad event, before referencing the DAQ. When the program stops on the breakpoint, Visual Studio complains that it can no longer find the file. Examining the directory confirms that all the source code files have been deleted or corrupted).

2)

I have once managed to trap an exception on the first line to reference the DAQ. The exception was:

NationalInstruments.DAQmx.DaqException: NI Platform Services:  The requested memory could not be allocated.

Task Name: _unnamedTask<0>

Status Code: -50352
   at nNIMSSAIL100.StatusObserverT<nNIMSSAIL100::ApiTraits<nNIMSSAIL100::DotNetApi> >.CheckWithName(StatusObserverT<nNIMSSAIL100::ApiTraits<nNIMSSAIL100::DotNetApi> >* , tCaseInsensitiveBasicString<unsigned short\,_STL::char_traits<unsigned short>\,_STL::allocator<unsigned short>\,nNIDMXS100::tLocaleConsideringWideStringComparitor\,nNIDMXS100::tLocaleConsideringWideStringCaseForcer>* pName)
   at NationalInstruments.DAQmx.Task..ctor()
   at AEM.CTB._3000Eval.GeneralIOClass..ctor(Form theOwner, MessageDelegate theMessDelegate) in C:\Projects\TestBenches\CTB3000_Eval\ControlIO\ControlIO.cs:line 108
   at AEM.CTB._3000Eval.MainForm.MainForm_Load(Object sender, EventArgs e) in C:\Projects\TestBenches\CTB3000_Eval\MainForm.cs:line 36

The offending line 108 is:

      private NationalInstruments.DAQmx.Task digOutputClampTask = new NationalInstruments.DAQmx.Task();

which is the first time I reference the DAQ, in the FormLoad event.

3)

I have also managed to get a BSOD using MAX explorer. The screen shot of the window is attached. The full text of the error window was:

The niPXIe plug-in caused an exception in the CmxsCfgResourceExpert::SynchronizeToConfiguration function in the nimxs process.
See these files for details:
C:\Documents and Settings\All Users\Application Data\National Instruments\MAX\Logs\20100916_090412-nimxs-000001F8.log
C:\Documents and Settings\All Users\Application Data\National Instruments\MAX\Logs\20100916_090412-nimxs-000001F8.dmp

The log and dump files referenced are attached as a zip file

4)

I do not know if this will help, but when my source code files are deleted 2 binary files are created in the same directory, these are typicall called:

2d9e2e4a-eff0-410a-bde0-b5af491a7dbb and pimmInternalFloatingSharedHeap

I can attach these in another post if required. (Cannot seem to attach more than three files in a post)

Thanks,

Charlie

[Brad_K]

Hi Charlie,

Thanks for posting the minidumps. They reveal more clues about what's going on, but they don't explain everything.

Problem #3 (nimxs.exe crash in niPXIe plugin) seems to be related to problem #2 (-50352 errors from DAQmx). In the MAX crash dump that you attached, the niPXIe plugin requested a memory allocation from NI-PAL, but didn't check for NULL before dereferencing the result. NI-PAL probably returned another -50352 "memory full" error in this case as well, and PXI should handle this situation better, so I reported this issue to the appropriate R&D team as CAR #249454. However, that doesn't explain why NI-PAL returned a "memory full" error in these two cases.

Regarding problem #1 (BSODs), the minidumps you posted all have the same stack trace: NI-PAL in kernel mode is cleaning up memory used by a crashed user mode process (one time it was the PXI resource manager service, the other three times it was your application). This code is outside my area of expertise, so I reported it to the appropriate R&D team as CAR #249459.

Where does that leave you? Unfortunately, I don't have any good suggestions, but here are a few more questions:

• Does your system have any other NI devices installed, or just the USB-6211?
• Is your system low on memory (or using a large amount of pagefile space) when these crashes occur?
• How much RAM does your system have?

Brad

[Justin_E]

Hey Charlie,

Our R&D team is looking into this issue as we speak. We'd like to grab two more pieces of information from you:

1) Obtain a MAX Technical Report from your system. This report will contain information about the NI software installed on your system. You can FTP this .zip file to us. Rename it to something other than the default "ni_support.zip", and upload it to ftp://ftp.ni.com/incoming through Windows Explorer. Please post here with the name of that zip file once you've uploaded it so I can grab it (and remove it as well).

2) Check to see if this directory exists: C:\Documents and Settings\All Users\Application Data\National Instruments\Shared Memory\platform\memory\sharedMemoryFiles

[charliew_aem]

Below is the information you requested:

• Does your system have any other NI devices installed, or just the USB-6211?

The system does not have any other devices installed, but MAX does report a 'NI PCI-4472', see attached file 'MaxDevices.jpg'. I have no idea what this is or where it came from (I inherited this project from another developer who has since left)

• Is your system low on memory (or using a large amount of pagefile space) when these crashes occur?
• How much RAM does your system have?

The system only has 1 GByte of RAM, but the application is small, and I am not allocating any larger ammounts of memory. Attached is a screen shot of the TaskManager showing memory useage with the development environment and application running. (Note: the apparent ramping up of the page file useage is from the loading of the development environment, it does does not get any higher than that shown).

MAX Technical report

Report has been saved to ftp://ftp.ni.com/incoming as 'CAR_249459_Aem_ni_support.zip'

Shared memory files directory

The directory 'C:\Documents and Settings\All Users\Application Data\National Instruments\Shared Memory\platform\memory\sharedMemoryFiles' does exist, and contains some files, see attached screen shot 'SharedMemoryDir.jpg'

Thanks guys,

Charlie

[charliew_aem]

Bump.

Any news on this or suggested workarounds?, It is driving me mad, and we need to ship this system out soon, which we cannot do while it is prone to BSODs.

Once the system is up and running it is fine for days, but if the computer is ever re-started it is virtually impossible to get the software running again without multiple BSODs and directories being overwritten.

Charlie.

[John_P1]

Hi Charlie,

The 4472 is likely showing up due to a known bug in DAQmx.  As a result of this bug, some HID devices (are you using an optical mouse from HP by any chance?) incorrectly enumerate as NI-DAQmx devices in the mxs database.  NI has released a patch to address this bug which can be found here.

This very well might not have anything to do with your BSOD problem, but I think it would be a good idea to install the patch just to be sure.  I haven't seen the HID bug cause blue screens before, but perhaps there are unintended consequences of the bug that I am not yet aware of.

Best Regards,

[charliew_aem]

John,

Many thanks for the reply. I installed the relevant patch, but unfortunately it did not make any difference, I still get a phantom PCI-4472 device reported, and BSODs.

The phantom 4472 is reporting as a PCI device, not a USB device. not sure if this is relevant.

Thanks,

Charlie.

[Seth_B.]

With the patch installed, please try the steps in this KnowledgeBase article.  This will completely clear the MAX database, and should prevent the PCI-4472 from showing up again.