LV 8.2 niswdk.dll crash

[Mister_Rose]

I had a "Blue Screen of Death" when running my application, and I was wondering if anyone can tell me what happened.

The crash info was as follows...

niswdk.dll  at address A83C66C7 base at A83AE000 datestamp 44B89B41

This is a Labview 8.2 application running in the runtime environment on a Windows XP computer with a PCI MXI-4 card interfacing to a PXI chassis with three 64-port relay driver cards and two 64-port RS-232 serial cards. Has NI-Switch and NI-Serial installed, along with the Office report generation toolkit.

It is intermittent, so I cannot reproduce it at will.

[chericks1]

Hi Brian,

There was a similar issue in the past, but the blue screen only occurred when trying to initialize a switch with the PXI chassis powered off.  Also, this issue was fixed with NI-SWITCH 2.3.

Is it possible you are intermittently attempting to initialize a switch with the PXI chassis powered off?

What version of NI-SWITCH is installed on your computer?

Thanks!

Chad Erickson

Switch Product Support Engineer

NI - USA 

[Mister_Rose]

I have NI-Switch 3.3 installed on that machine.

It is possible that power was toggled on the machine. The entire machine is normally left on. When powering up, there are procedures to start the PXI rack before starting the computer. However since we are still in preproduction, some engineers are still mucking with the system and toggling power. Since the PC is on a back-up power supply, it never restarts.

I have noticed that the PXI ceases to communicate with the PC if power is interrupted.

[sead_suskic]

Brian, Is the XP system configured to produce a memory dump on a system failure? (My Computer >> Properties >> Advanced >> Startup and Recovery, System failure section; it would be great if the system is configured to produce the "kernel memory dump"). If and when you provide the crash dump, please attach a report that you can create with MAX that will help us obtain the information about the versions of the various National Instruments software components on the system (if you are not familiar with this MAX utility, please see http://digital.ni.com/public.nsf/allkb/271f252b4ef0a2e0862570e70056a1e4).

Regards,

[Mister_Rose]

It looks like it was configured for a mini dump, so I don't know how useful it will be. I also have the MAX report in there (haven't looked at it yet).

Can you clarify what the difference is between the three dumps?

Mini-dump : Application memory
kernel dump : kernel memory
Complete : All Applications + kernel.

I have no problem keeping complete memory dumps, if it is useful. This is production equipment running only our software. Our software uses the Office report toolkit, so I guess that application is also running.

[sead_suskic]

Brian,

Thanks for uploading the zip archive. The Switch Software group is already analyzing the crash dump, and most likely we will come back with a few more questions for you to better understand the system and the context in which this crash happens.

I wanted to briefly respond to your question about the different memory dump configurations. I am sure that you will be able to find a more complete set of answers to this question elsewhere on the web, but in short, the three different options provide three different contexts that help developers debug kernel crashes on Windows. The mini dump provides the state of registers and the function stack trace where the fault occurs. The kernel dump provides the picture of the complete Windows kernel allowing the developers to see more of this part of the system when the system failure happens. The complete dump gives the view of the entire memory with all user mode and kernel mode processes that were loaded at the time of the crash.  It might be obvious that the different options result in significantly different memory dump file sizes, Sometimes the mini dump will be all it takes to identify an issue, but other times it might require a bigger picture (the kernel, and then the whole system) - it depends.

Regards,

[chericks1]

Hi Brian,

Thank you for your help so far.  I have some additional questions.  Each one is important to assist R&D in isolating the specific cause of this issue.

1) Do you see the crash as soon as you start your application or do you have to leave it running for a while?
2) If the crash is happening while the application is running, have you enabled your machine to go to sleep or hibernate after a period of time?
3) Do you know what calls you are making right before the crash?  Is it a NI-SWITCH Initialize call by chance? 
4) Did anything trigger this blue screen - for example, did you install a new version or NI-SWITCH or NI-Serial (or any other software)?
5) Do you believe the power sequence has somehow triggered this crash?  The description you gave before is a little confusing:

"It is possible that power was toggled on the machine. The entire machine is normally left on. When powering up, there are procedures to start the PXI rack before starting the computer. However since we are still in preproduction, some engineers are still mucking with the system and toggling power. Since the PC is on a back-up power supply, it never restarts.
I have noticed that the PXI ceases to communicate with the PC if power is interrupted. ".

Please let me know if you're able to recreate the crash with a certain power sequence.  Also, any additional information you can give us referencing what you are doing in your application and when you are seeing the crash will assist R&D in isolating the problem.

Thanks again!

Chad Erickson
Switch Product Support Engineer
NI - USA

[Mister_Rose]

1) Do you see the crash as soon as you start your application or do you have to leave it running for a while?
It happens when after the program is running and when I go to initialize a particular relay. I have an Initialize, with the reset card=TRUE, when the app starts up and this does not cause a problem. When I operate a VI, I have an initialize, with reset card=FALSE, and this may be the problem. I have included my VI in the crashdump (below).

2) If the crash is happening while the application is running, have you enabled your machine to go to sleep or hibernate after a period of time?
No sleeps or hibernates. The computer is on 24/7.

3) Do you know what calls you are making right before the crash?  Is it a NI-SWITCH Initialize call by chance?
There is a call to NI-SWITCH Initialize in the area where the crash is happening. I have included the VI with the crashdump.

4) Did anything trigger this blue screen - for example, did you install a new version or NI-SWITCH or NI-Serial (or any other software)?
5) Do you believe the power sequence has somehow triggered this crash?  The description you gave before is a little confusing:

The procedure to replicate the problem (I figured it out) is this...
a) Start machine
b) Turn off PXI chassis
c) wait 30 sec
d) Turn on PXI chassis
e) wait 30 sec
f) run application (no problem)
g) wait 30 sec
h) begin UUT test (crash!)

I have a full crashdump, which includes the minidump, as well as my VI at this location...
http://brianrose.net/data/STA10034_Crash.zip

Let me know if you have problems retrieving the file.

[chericks1]

Hi Brian,

It appears your zip file (http://brianrose.net/data/STA10034_Crash.zip) is corrupted.  I am not able to open it with WinZip.  Can you attempt to upload it again?  Either that or include the VI as an attachment in your next post?

Thanks!

Chad Erickson

Switch Product Support Engineer

NI - USA

[chericks1]

Hi Brian Rose,

I believe the issue here is you have a MXI link (MXI-4) connecting your PC to a PXI chassis. In this case, the only supported way of power-cycling the PXI chassis is to power down the host computer, cycle power on the PXI chassis, and then power up the host CPU again.

Power cycling the PXI chassis with a live host is not a supported procedure, and will likely never be supported, as it severs the PCI bridge connection to the PXI chassis. Most computers, and OSes, won't expect this to happen since all devices on that PCI bus are usually restricted to the same chassis (all devices are powered down and up at the same time). Rebooting the PXI chassis with the host computer still active will often result in a hang though the behavior would be system specific. In your case, you do not have a hang until you call into a specific driver in a certain configuration.

I would like to try reproducing your issue to see if I can get similar behavior, but I am not able to download your VI due to a corrupt STA10034_Crash.zip.  If you're able to fix this problem, I will be happy to give it a shot!

Thanks and best regards,

Chad Erickson
Switch Product Support Engineer
NI - USA