Instrument Control (GPIB, Serial, VISA, IVI)

cancel
Showing results for 
Search instead for 
Did you mean: 

Crashes using NI-Device and ibnotify

Last night I tried a test with release mode on the w2k side and debug mode on the NI-Device computer. The acquistions occur more slowly. They eventually stopped at some point in the night, although neither side crashed or froze. Probably ibnotify failed, I can put in something to check that for sure tonight. So I have two problems as far as making this run reliably for a significant period of time: sometimes ibnotify fails to notify, other times the local machine crashes. Do you think that moving to NI-Device 1.5 would help?
0 Kudos
Message 11 of 14
(1,523 Views)
Moving to NI-Device 1.5 will only help if the problem is actually in the NI-Device driver itself. If the problem is something that your callback function is doing, it is unlikely that upgrading NI-Device would make any difference.

Another thing to try is a debug version of your application, but not running it within the debugger. This may help us track down where the crash really is occurring.
0 Kudos
Message 12 of 14
(1,523 Views)
Last night I ran the debug version with the debugger. It crashed but wasn't much help. NiDGpibU loaded at 0x3000000, callstack says

0000000c()
NIDGPIBU! 300144a()

Disassembly window says

0000000C ???
0000000D ???
...

I am not sure why you want me to run the debug version without the debugger. If there's some utility for me to download (like listdlls), let me know and I will run it tonight.
0 Kudos
Message 13 of 14
(1,523 Views)
My thought was that maybe it would change the timing so that we could see the crash better. However, that would not be necessary since you have duplicated the crash. Unfortunately, it doesn't say really anything new since it crashed in the same location with the same call stack.

The call stack says that the top entry is 0000000c and the caller of that is NIDGPIBU. The return within NIDGPIBU is 1440 within the DLL, which is directly after we dispatch to the user. The 000000C is strange, and my thought is that it looks like a stack overflow which has corrupted the call stack. That is why I am assuming that it is within your code.

Running without the
debugger will be no help. I would disregard that advice. You can try the test with NI-Device 1.5 (if you already have the port) to see if the behavior is any different.
0 Kudos
Message 14 of 14
(1,523 Views)