System crash when aborting data collection

[Janos 53]

Hi,
I am programming a DAQPad-6507 using a VC6 development system, on a Win2000. The program is slightly developed from the sample program daqevt8VC.c.
The data collection runs in the cycle shown below. When the cycle finishes (through keyboard hit, it runs OK, endlessly). When I stop either in the debug environment or close the DOS window where the output of the stand-alone app goes, with cca 30% chance my operating system crashes (i.e. not my application).
As far as I know, such kind of crash might come only from the system libraries. My guess is that my app asks for some operation, than dies and the system library attempts to pass the reply to the already non-existing application. Is this a known issue?

Regards

Janos



iStatus = DIG_SCAN_Setup(iDevice, iGroup, 2, portList, 0); // Set up scan, read 2 ports
iRetVal = NIDAQErrorHandler(iStatus, "DIG_SCAN_Setup", iIgnoreWarning);

do{
ulRemain = 2; OldRemain = ulRemain;
iStatus = DIG_Block_In(iDevice, iGroup, piBuffer, ulRemain); // Set up to read 2 bytes
while ((ulRemain > 0) && !kbhit())
{
iStatus=DIG_Block_Check (iDevice, iGroup, &ulRemain);
if(OldRemain-1 > ulRemain)
{
printf("DAC#%.4d= %.2x%.2x\n",i++,~piBuffer[0] & 0xff,~piBuffer[1] & 0xff);
OldRemain = ulRemain;
}
}
}
while (!kbhit());

[Andre Saller]

You always should clear the resources before ending an application (DAQ_Clear). If you do not clear resources, and you break an application, the operating system might crash, because of the daq-driver hanging. So always try to stop the program normally. The latest driver should be installed, too.

[Janos 53]

Hi,
thanks for the reply. However:
1./ I checked:
only the example programs
...\VisualC\Ai\*.c
and ...\VisualC\Cdio\*.c
programs use DAQ_Clear(), the others do not. Maybe the other sample programs leave back the operating system in a crash-near state?

2./ The DAQ_Clear() description said:
"If your application calls DAQ_Start, SCAN_Start, or Lab_ISCAN_Start, always make sure you call DAQ_Clear before your application terminates and returns control to the operating system. Unpredictable behavior can result unless you call DAQ_Clear (either directly, or indirectly through DAQ_Check, Lab_ISCAN_Check, or DAQ_DB_Transfer)."
In my vocabulary, the "Unpredictable behavior" means only a chance to crash my own application, but not that of the operating system. So I think the documentation is wrong at this point.

3./ I did not use any of the functions mentioned. Yes, I understand it is one of the "Low-Level Data Acquisition Functions", but neither of the higher lever function mentions which low level functions are called. I guess that my function DIG_Block_In() uses SCAN_Start() some time, but I could not figure out which low-level function DIG_SCAN_Setup() uses. I think this information *must* be included in the docs. How can I find out which low level functions are used by the high level functions if the docs do not include this information?

4./ I do not really understand the warning in the docs of SCAN_Start:
"You must use the SCAN_Setup and SCAN_Start functions as a pair. Making a single call to SCAN_Setup with multiple calls to SCAN_Start fails and returns error code -122 (noSetupError)."
Although I cannot completely follow down because of the lack of documentation and source, if my functions use the two named functions, but I definitely used in my program a setup once and a start many times, and without problems. In additition, I do not see any parameter in the prototype "SCAN_Setup (deviceNumber, numChans, chanVector, gainVector)" which needs repeated initialization after calling a "SCAN_Start(). Could you please comment this?

5./ In the case of closed-source libraries I do not have a chance to figure out from the source (in a hard but possible way) what actually the function calls do, so the documentation *must* give me the information I need. I think it is not the case in connection with these function calls.

6./ If one takes some actions from user space to the kernel space, one *must* take care of the chance of crashing the operating system. In case of user failure, one is allowed to return an error condition or not to carry out the action, but never to crash. It is a serious security hole and I consider it as a result of poor design.

Best regards

Janos