From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

Instrument Control (GPIB, Serial, VISA, IVI)

cancel
Showing results for 
Search instead for 
Did you mean: 

BSOD using NI-Device 1.5

Hi GPIB Gurus,

Switched to NI-Device 1.5 from 1.1. Now finding BSOD occurs on NI-Device machine when read (Receive()) commands sent in rapid sucession whether or not there are write commands in between. Using Windows 2000 and Visual C++ 6.0. BSOD displays:

Address BEF91305 base at BEF8B000, DateStamp 403a15b5 - nidkeng.sys
STOP: 0x000000D1 (0x00000024, 0x00000002, 0x00000000, 0xBEF91305)

The BSOD does not occur in debug version. Maybe there's a timing problem, or maybe I haven't initialized a variable. Any ideas?

Thanks,
Gary
0 Kudos
Message 1 of 14
(4,657 Views)
Another problem: During a large number of writes in very rapid succession (from another program, the reads in my first note were sent by clicking a button rapidly), the "Could not acknowledge end of message" error message box appears (NIDEVICE_STATUS_END_MSG_NOT_RECEIVED). It should be noted that my code is derived from the "Simple Example", so I'm not using multi-threading. The comments sound ominous:

// Normally an END message is passed to the parser after the
// input message. When the parser parses the END message, it should
// invoke the following call. The parser used in this example does
// not allow the END message to be passed in, so the END message
// is acknowledged here. Refer to the Multi-Threaded example for a
// more realistic example of the interactions between the I/O control
// and the parser.

This implies that the Simple Example is not "realistic", which perhaps means I shouldn't be using it? It worked fine with NI-Device 1.1

Gary
0 Kudos
Message 2 of 14
(4,650 Views)
More information: The End of Message error message does not pop up if I run the debug version under the debugger. Apparently this is because a lot of status messages are going to the debugger and it is slowing things down.

Also I uninstalled NI-Device 1.5, installed 1.1, used my old software adapted to 1.1 and cannot reproduce either the BSOD problem or the End of Message problem. Everything works fine with 1.1! Of course, my software had to change to accommodate 1.5, but I tried to change it as little as possible.

However, we would like to use 1.5, for several of the new features.

Any help greatly appreciated.

Gary
0 Kudos
Message 3 of 14
(4,647 Views)
Gary,

Can you reproduce the problem using only the NI-Device 1.5 simple example code rather than your own code? This will allow us to focus our attention on your code or on NI-Device depending on the outcome.

Scott B.
GPIB Software
National Instruments
0 Kudos
Message 4 of 14
(4,642 Views)
I was able to duplicate the problems using the Simple Device example and some changes to the attached CSimpleDeviceFramework.cpp that are similar to changes I have made. As you can see, I'm using the "relaxed" output queue mode. If I run a program on the computer sending messages to the NI-Device machine that contains a loop of "Receive()" NI-488.2 calls, it will run for a few thousand loops until the NI-Device machine has either the BSOD or the error message described in the previous notes. Just now I ran a loop and got the BSOD after 44000 loops. Although an actual situation would not call for repeated "reads", actual situations do call for a rapid sending of commands, and it does seem as though the reads are the problem.

Curiously, we only find the problem on our Advantech CPU board, the one we are now committed to using. The problem does not seem to show up with Tri-M or GMS boards.

Gary
0 Kudos
Message 5 of 14
(4,596 Views)
Gary,

Interesting. Sounds like this might be hardware dependent. Can you get us a kernel memory dump at the time of the crash? In XP, right click on My Computer, go to the Advanced tab, Under Startup and Recovery click Settings, and then change the "Write debugging information" section's setting to "Kernel Memory Dump" and note the path of the output file. You'll probably want to ZIP this file up, then attach it to your next posting.

At least we'll know where in our NI-Device it's crashing once we have that.

Thanks,
Scott B.
National Instruments
0 Kudos
Message 6 of 14
(4,593 Views)
Well, I attached my zipped up memory dump file, which was nearly 13 MB, and my trusty IE globe was spinning around for quite some time, but at the end of it all, I don't know if anything got through. So far I don't see my note appearing. Maybe later?

Gary
0 Kudos
Message 7 of 14
(4,583 Views)
Ok, after two attempts to send the 13 MB memory dump file, nothing appears to have reached it's destination, so I'm left with the question: How do I get the file to you?

Gary
0 Kudos
Message 8 of 14
(4,577 Views)
Place it on the ftp site (ftp.ni.com/incoming) and post the filename.
0 Kudos
Message 9 of 14
(4,570 Views)
Memdump.zip now sits in ftp.ni.com/incoming for your perusal. Note that I am using Windows 2000, not XP.

Thanks,
Gary
0 Kudos
Message 10 of 14
(4,562 Views)