nimxdfk.dll causes blue screen

[sledstorm25]

Attached is a full memory dump from a crash that just happened.

[Brad_K]

Hi sledstorm25,

It looks like the attachment didn't make it. The forum software probably doesn't support enormous attachments. Can you upload it to ftp://ftp.ni.com/incoming instead?

Also, this thread got split up. Here's the first half: http://forums.ni.com/t5/Multifunction-DAQ/nimxdfk-dll-causes-blue-screen/m-p/1751632/highlight/false

Brad

[sledstorm25]

Thanks Brad.

I uploaded the memory.zip file to the ftp site. Another piece of information is a co-worker of mine ran his similar app and got the same thing happen. His app is using the 6602 counter card as well, but is using interrupts. The PC crashed as soon as we changd the sample rate to 3000 from 512. I know there were issues when we tried to use interrupts when using a wireless N NIC card(Asus PCE-N1511n). We disabled the wireless nic card and we were able to run his app without any crashes. Let me know if there is any other information I can provide.

-sledstorm

[Brad_K]

Hi sledstorm,

Thanks for uploading the kernel memory dump. It shows a crash in a slightly different location than the previous two minidumps, but it appears to be the same basic problem: a specific driver component is getting unloaded while it is still in use. I'll forward the kernel memory dump to the developer who will investigate this crash so that they can figure out what went wrong.

I'm not 100% sure, but it looks like the crash probably occurred during process exit, when DAQmx cleans up after tasks that haven't been cleared. This shouldn't crash the machine, but maybe you can work around this bug by clearing tasks instead of letting DAQmx clean them up when the application exits.

The interaction with the wireless NIC card sounds like it's probably a separate problem. Was that a system crash, application crash, or an error (such as a timeout error)? If it's a system crash, a minidump can confirm whether it's the same problem or a different one.

Brad

[sledstorm25]

Hi Brad,

I did find a problem with my code for one of the conditions. In the end, I setup the channels to read a certain number of points and I accidentally was reading WAY more points than I should have. I think in one case, I had the channels setup to acquire 35,000 points and I was reading 45,000 points. I had a system crash every time this happend. I fixed that in my program and did not get anymore system crashes. 

As for the wireless NIC card, in my app I would get error -200141 anytime I would try to use a channel setup to use interrupts (only 1 channel). I would catch this exception and everything would be fine, except I couldn't use that channel. My co-workers app uses all channels setup as interrupt. As soon as he upped the sample rate, he would get a error message and then the system would crash. The memory dump that was uploaded was from this scenerio.

So far, we have switched out this NIC card for another type and currently everything is working. Let me know if I can provide any further information.

-sledstorm

[sledstorm25]

Hi Brad,

Just an update on some things we tried. We ordered a new wireless card (http://www.dlink.com/products/?pid=549) and installed it. We get the system to crash constantly now when trying to run one of our apps. I uploaded a Dumps.zip file to the ftp site. This has two minidumps and a full memory dump. So far, two different wireless cards cause the system to crash. With this particular app, 4 channels are configured to use interrupts and stream data.

We also tried this http://usa.asus.com/Networks/Wireless_Routers/WL330N3G/. This seems to work well. I am going to do some downloading of files while running our app and see what happens, but initially it seems to work and not crash the system while running our application.

-sledstorm

 

[Brad_K]

Hi sledstorm,

All six crash dumps that you've uploaded show the same cause: the nicdcck service is getting unloaded while it's still in use. This shouldn't happen, and the fact that it is happening seems to be a bug in DAQmx. Here's a potential workaround (which is completely untested): run "net start nicdcck" (as an administrator user) and then run your app. I think this will prevent nicdcck from getting unloaded. Could you please try this and let me know what the result is?

I'm not sure what the connection between this crash and the wireless card is. Perhaps the wireless card is sharing an IRQ with the 6602 and this is slowing down the 6602's interrupt handling, leading to the counter overflow errors (-200141) you described? Could you also check the IRQ assignment for the wireless card and the 6602 in Windows Device Manager?

Brad

[Brad_K]

> Could you also check the IRQ assignment for the wireless card and the 6602 in Windows Device Manager?

Nevermind, this information is in the kernel memory dump. Both the PCI-6602 and the Atheros AR5416 wireless NIC are sharing IRQ 18. Perhaps moving one of the cards to a different slot will change the IRQ assignment so that they are not sharing the same IRQ.

Brad

[sledstorm25]

Brad,

I ran the command "net start nicdcck" and then ran my app. I still get the bug report, but when I click the "Don't Send" button the system does not crash. Definitely on to something with that.

I can get a different computer to crash now, which does not have a wireless card at all. I'm guessing the wireless card has nothing to do with the problem.

I also took one of the apps that we have and stripped out everything except for the 6602 counter stuff. If I up the sample rate high enough, it will cause a crash. Let me know if you would like this. 

I also noticed that we were not using any exception handling at the moment. Our thinking is by not doing this only the app should crash, not the entire system. Am I correct? 

[Brad_K]

Hi sledstorm,

> I ran the command "net start nicdcck" and then ran my app. I still get the bug report, but when I click the "Don't Send" button the system does not crash. Definitely on to something with that.

Good. That means the workaround works.

> I can get a different computer to crash now, which does not have a wireless card at all. I'm guessing the wireless card has nothing to do with the problem.

I think that if the wireless card is having any effect, that effect is that it's slowing down the acquisition, which leads to a DAQmx error.

 

> I also took one of the apps that we have and stripped out everything except for the 6602 counter stuff. If I up the sample rate high enough, it will cause a crash. Let me know if you would like this. 

Thanks, that would be helpful.

> I also noticed that we were not using any exception handling at the moment. Our thinking is by not doing this only the app should crash, not the entire system. Am I correct?

By "exception handling" do you mean that this is a .NET application? The DAQmx .NET API reports errors as .NET exceptions, which cause the application to terminate unless they are caught. This should not crash the entire system, and the fact that it does indicates the presence of a bug in some of the DAQmx cleanup code.

Other than .NET exceptions, a DAQmx error shouldn't crash either the application or the entire system.

Brad