Crashes using NI-Device and ibnotify

[pi]

I am using Windows NT 4 SP 6 on both the computer with NI-Device 1.1 (the "local" computer) and the computer with gpib-32.dll version 1.41.7649 (the "remote" computer). We wish to perform data acquisitions on the local computer and notify the remote when the acquisition is complete. I'm using ibnotify() with the board descriptor, SRQI mask, a callback function, and NULL for the RefData pointer. I've been testing with the application on the remote running in debug mode under Visual C++ 6 SP 5 and the application on the local machine in release mode.

Many messages are sent to the local to set up the acquistion, followed by the command to start the acquisition. The remote machine does nothing more at that point. The local machine performs the acquisition and upon completion, sends out an SRQ. The acquisitions are fairly rapid, maybe 10 to a second, and this notification method works for a short time, on the order of 1 minute. Inevitably, the process stops. The TRACE statements on the remote show that the callback function is not called. However, the application is frozen and cannot be closed, neither by the debugger, nor the task manager. I have to reboot the remote computer to continue. Sometimes, the crash is the BSOD.


This process is much more stable if I run the local application under the debugger, still in release mode but with messages being printed out. Alternatively, it is much more stable without the debugger if I put a 10th of a second delay before sending out an SRQ. The functions used on the local machine are UpdateStatusByte() and RequestService(). Throughout my testing, the eStatusMessage is always NIDEVICE_STATUS_SUCCESS for both functions. On the remote machine, the ibsta value returned from ibnotify is first 0x2164 followed by 0x168 after that. And iberr returned to the callback function is always 0.


We're wondering if we can make the process stable without using a delay. It's doubtful that the delay is completely stable and would always work regardless of the speed of the machines.

[GPIB_Guru]

I would like to clarify the problem if I may. Please let me know if I am interpreting it incorrectly. You have two computers. Both of them are running Windows NT4. In one machine you have NI-Deviec 1.1 and in the other machine you have NI-488.2 with GPIB-32.dll version 1.41 (can you find out the NI-488.2 version number? This should be listed in the add/remove programs).

The NI-488.2 application is using ibnotify along with other calls to communicate to the NI-Deviec based instrument. At times, the NI-488.2 machine will crash or hang. However, if you slow down the NI-Device side (either with delays or running through a debugger), the NI-488.2 computer seems to run correctly. However, you are concerned about the stability of the system and curious why you ne
ed to slow down the instruments.

That is what I understand from reading your question. Here are a couple of things to look at.
1) This may be a difficult suggestion, but I am interested in whether or not you have been able to try to run a newer version of NI-488.2. Unfortunately the latest release, NI-488.2 Version 2.2, is not supported on Windows NT4. It requires you to use Windows 2000 or Windows XP. However, this can help narrow down the problem to the NI-488.2 1.x driver.

2) Are either of the machines multi-processor or hyperthreaded?

3) When you say the application is frozen, is it just the application or the entire machine?

4) When you do get a BSOD, can you write down some of the relevant information? This may help narrow down the particular crash.

Thanks.

[pi]

You have interpreted the problem correctly. The NI-488.2 version in add/remove is 1.60.

1) I installed Windows 2000 and NI-488.2 Version 2.1 on my D drive. I did find that the process lasted longer with W2K. Instead of waiting for a crash, I switched to release mode. I ran it a few times with release version on the remote and it would run very fast (more acquisitions per second) for a time. However, the process would stop (perhaps after about 7 minutes, sometimes I left it running and didn't notice when it stopped.) Unlike before, after it stopped, there was no crash or hang and I could resume. My hunch is that one service request was not picked up by ibnotify and the callback function wasn't called, judging by a status message. This situation is better since there's no crash, though still not acceptable as the process comes to a halt.

Surprisingly, when I went to release mode on NT, it performed as well as release mode on W2K. It would run very fast, but stop after a time. Then there was no crash or hang, I could resume from there.

2) The local application is multi-threaded. An interrupt thread is started when the acquisition takes place, and an interrupt is generated when the acquisition completes. So the SRQ is sent out from a different thread than the main thread. Neither machine is multi-processor.

3) Actually, both have occurred. There have been times when the application is frozen, and sometimes I can apparently close the application. However, when I look at the task manager, the application is still listed. If I try to close it there, I get a message box saying I don't have the authority (or permission, I forget which) to close it. This only has happened when running the debug version with the debugger on NT. (Perhaps it would happen with W2K, but if so, it was taking longer.)

4) Didn't get the BSOD, but if I see it again, will write down some of it.

Perhaps there are two problems here. When there is a crash or hang, I cannot resume doing acquisitions even after rebooting the remote machine. GPIB commands seem to work, but the callback doesn't happen until I close the application on the local and restart. This could be because the acquistion isn't happening.

Without the crash or hang, I can resume doing acquisitions. When it stops, it's probably because the ibnotify isn't working. I need to figure out a way to test this without changing the results. Will get back to you tomorrow.

[pi]

Now I have installed NI-488.2 Version 2.2 on the remote computer. I believe it makes the ibnotify work more reliably. I ran the application on the local machine in release mode but with the debugger for an hour until it crashed. So now the problem seems to be on the local (NI-Device) side. A message box popped up saying "access violation" at 0xc0000005. The call stack window had two lines:

0000000c
NIDGPIBU! 02c7144a()

I would like to be able to have confidence that this process can run indefinitely.

[GPIB_Guru]

I am sorry, I have been unable to help for the last week. I can do a bit more research, however, I need a little bit more information. The address you have provided (2c7144a) is a very big help, but I need to know where the dll is loaded. Then, I can look at the offset an try to determine where the crash is.

If you run the NI-Device side in a debugger, you should see the load address.

Thanks.

[pi]

I don't know where to look for the load address. In the debug window there's a line:

LDR: Dll NiDGpibU.dll base 10000000 relocated due to collision with [one of my dlls]"

Next line is "Loaded" line, says "no matching symbolic information found".

[GPIB_Guru]

If you go to sysinternals.com (same place where you got DbgView), you can download the utility listdlls.

http://www.sysinternals.com/ntw2k/freeware/listdlls.shtml

This will list the load address of all loaded dlls, so launch your application and determine the load address. Then, run until it crashed and let me know the load address and the crash address.

[pi]

For NiDGpibU.dll listdlls says Base: 0x02820000 Size:0x7000 Version: 1.01.0000.0025

After the crash in release mode the VC++ debugger says:
NIDGPIBU! 0282144a()

[GPIB_Guru]

This section of the code appears to be calling into your callback function. You may want to check to make sure that there is nothing within your callback that could be either causing a stack overflow or some other error that could cause this crash.

I will continue to research on this side to try to verify whether or not it could be something within NI-Device.

Have you tried to run a debug version of your NI-Device application to see if that makes any difference?

[pi]

I haven't tried running the debug version since I switched to W2k and NI-488.2 Version 2.2 on the remote computer. Running in debug makes the acquisitions happen much more slowly, and what happened previously was the ibnotify would sooner or later fail to notify. I'll try it again with the later version of NI-488.2 tonight. An inconvenience is that I'm buiding a new dll for NI-Device 1.5 which is quite different from 1.1. I guess I have to uninstall 1.5 and then install 1.1 to test 1.1. Then the next day do the reverse to work with 1.5 again.

By callback function, I presume you mean InputQueueEventCallback or ResponseMsgRequestedCallback. I am not using OutputQueueEventCallback. Wouldn't the
debugger point to my dll (pigpib.dll) as the culprit, if the problem were there? I put in a ClearOutputQueue(NULL) call and EnableInputQueue() in InputQueueEventCallback(). Also in there is the _ParseMessage function which calls another dll (dacq.dll) that does the acquisition. Wouldn't the debugger point to that dll if the problem were there? If it brings up NiDGpibU.dll no matter where the crash is, it's not much help.

I don't see any reason for a crash in ResponseMsgRequestedCallback().