Why does WFM_Op call crash Windows XP

[Greg Flynn]

I recently installed CVI 7.0 on a new PC running Windows XP. When I attempt to compile and run an existing software application (running stably with CVI 5.5.1 and Windows 2000 for the last year on a different PC), the application compiles fine, and runs most of the time, but occasionally crashes windows (as in the system freezes completely, Ctrl-Alt-Del doesn't work, and only the on/off button can be used to reboot the system). I have isolated the cause of the crash to a call to WFM_Op. I am talking to a PCI_6711 AWG board with the WFM_Op function. I have verified that all variables being passed to WFM_Op are valid, even on those particular calls when it crashes the PC (most calls to WFM_Op work just fine). Some other points:
Occasionally I get errors when I boot the new PC with CVI 7.0 - either "C:\WINDOWS\system32\nipalsm.exe, R6025, Pure Virtual Function Call", or "NI Max had an error and was closed, do you want to send a message to Microsoft?" I get one or the other of these errors about 1 in 5 or 10 reboots. I tried repairing the CVI 7.0 installation using the CD, but the errors persisted. I then uninstalled and reinstalled all NI software, and the errors still persist. I have reverified that the current version of the application continues to compile and run just fine on a different PC with CVI 5.5.1 and Windows 2000. Any ideas?

[JoshuaP]

Hey Greg,

I am not quit sure what is wrong in you system. I ran the C:\Program Files\National Instruments\CVI70\samples\daq\Ao\WFMsingleBufSync.C shipping example on my computer and it ran fine.

I am currently running XP Pro, CVI 7.0 and NI-DAQ 7.0.1. You might want to make sure you have 7.0.1, because I am not sure how well the other version run on CVI 7.0. To upgrade to 7.0.1 you want to make sure you remove 7.0.0 first and then install 7.0.1, which you can get from www.ni.com/support.

It really sounds like your NI-DAQ is having problems. You might want to try to reinstall everything on a different machine to make sure Windows has not corrupted something. Then I would try to run the shipping example.

I hope this helps.

Joshua

[Greg Flynn]

Joshua,

It sure looks to me like NI-DAQ 7.0.1 or CVI 7.0 has a problem. I just upgraded to CVI 7.0, and my CD includes NI-DAQ 7.0.1.

I was having problems with uninstall on CVI/NI-DAQ not really working( i.e., result after uninstall of version A and install of version B not the same as result after reformat hard drive, reinstall operating system, and install version B), so I eventually ended up with a troubleshooting process which involved reformating the hard drive and reinstalling the operating system for each attempt to get things working. I have three identical test systems, so I was able to swap out computers, DAQ boards, and all hardware connected to the DAQ boards. What I discovered was that neither the boards (PCI-6711, PCI-6602, PCI-6036E, and PCI-GPIB), nor the computer, nor any other tester hardware, nor the operating system (Windows 2000 Pro vs Windows XP Pro) were linked to the problem.

What is linked to the problem in every case is the combination of CVI/NI-DAQ version. Basically, Windows 2000 + NI-DAQ 6.9.3 + CVI 5.5 (I don't have CVI 6.0) works. Windows 2000 + NI-DAQ 7.0.1 + CVI 7.0 does not work, and Windows XP + NI-DAQ 7.0.1 + CVI 7.0 does not work. These are all the combinations that I can try, since NI-DAQ 7.0.1 does not support CVI 5.5 and CVI 5.5 does not support Windows XP. I did at least three clean installs of operating system + NI-DAQ + CVI, on at least two different computers using two different operating systems, and obtained exactly the same (rather peculiar) failure mode in every case. The fact that I can reproduce this failure on different computers, with different PCI-6711 boards, different operating systems, and different installs indicates to me that the problem is either in CVI 7.0 or NI-DAQ 7.0.1.

The fact that WFMsingleBufSync works is not surprising. Most of the time when my program calls WFM_Op it also works. It's just that sometimes it doesn't. Every call to WFM_Op which has NIterations=1 works. Only the calls with NIterations>1 fail, and then only sometimes (about 1 time out of 5). Note that ulIterations=1 in WFMsingleBufSync.

I have not tried running WFMsingleBufSync with the combination Windows (2000 or XP) + NI-DAQ 7.0.1 + CVI 7.0, and I do not have either of those combinations installed on any system at this time. I will try it next week (including varying ulIterations to something greater than 1) and let you know whether or not it works. I did generate sine waves from NIMAX (3.0.1) with no problems on both combinations - don't know whether or not that uses WFM_Op.

Greg

[Greg Flynn]

Hello Joshua,

I tried WFMsingleBufSync with parameters which more closely match what my program uses, and sure enough it crashes. The configuration was Window XP Pro (factory installation plus all MS updates) + CVI 7.0 + NI-DAQ 7.0.1. I have attached a copy of my doctored-up WFMsingleBufSync.c if you'd care to try it. The changes that I made are: ulCount 5000 -> 500; ulIterations 1 -> 500. dUpdateRate 1000.0 -> 1000000.0 (Note: Also iDevice 1 -> 3, since my PCI-6711 board is device 3). Since the failure is still intermittent, I put a for loop (i<50) around the WFM_Op statement and the following NIDAQErrorHandler call. The exact nature of the crash is a little different (system not totally frozen, but "stop" button doesn't work, no return a
t timeout, and application impossible to kill with task manager), but certain things are very similar (intermittant, about 1 in 5, and doesn't seem to fail in "step-over" debugging mode).

By the way, I am assuming that you work for NI. If not, please let me know so that I can contact them directly.

Greg

[Mark@4D]

I have a very similar problem with WFM_Op on XP. I'm using Nidaq 6.9.3 (although my older Nidaq version has the same problem so it's probably not version-specific). I replaced the high-level call to WFM_Op with the equivalent lower-level code from WFMsingleBufSync.c, and by writing debug output to a file, determined that it was hanging in WFM_Check. The exact symptoms vary: the crash is sometimes "soft", sometimes hard, sometimes blue-screens in nipalk.sys, and varies across computers.

Two simple improvements to the WFMsingleBufSync.c code can reduce the failure rate drastically. We know that WFM_Check will crash sometimes, so in the absence of a proper fix from NI, the goal is to reduce the number of calls to WFM_Check. The WFMsingleBufSync.c s
ample makes far more calls than necessary.

First, it starts the waveform and then immediately starts checking whether the waveform is finished. It would be better to start the waveform and then sleep until the waveform might conceivably be finished, based on the length of the buffer and the update rate. Only then should it begin checking for completion.

Second, once it starts checking, it could sleep between checks. Sleeping say 10 or 100 ms between checks would greatly reduce the number of calls and might not be objectionable for many applications.

These changes do not fix the real problem, but can reduce the occurence of the crash by orders of magnitude.

[Mark@4D]

Just a followup to my previous post... Before making the two code changes, I was getting a crash about once every 5000 waveforms. After making the two changes, I have run 2 million waveforms without a crash. Attached is my modified WFMsingleBufSync.c, with the two changes clearly commented. The same changes probably apply to other AO samples also- anywhere WFM_Check is used.

[edwardryklin]

You have a memory leak somewhere in your own code.