VC++6.0 NT Blue Screens Frequently (CW2.0)

[Bill Garber]

I am using Component Works 2.0 in a Visual C++ application for data acquisition
from a PCI6071 DAQ card, and frequently get "Blue Screens of Death", and/or
a message something to the effect "The Instrument is not a National Instruments
product..." when debugging the code.

The problem has increased recently, to what might be called a catastrophic
level: almost 100% of the time the initialization process hangs: requiring
a reboot.

Is there Visual C++ sample code which might show how to trap and handle these
DAQ errors gracefully? I have not been sucessful in capturing error numbers/messages
using the return value from

[Denise Riedlinger]

For error handling, I would recommend writing event handlers for the DAQError
and DAQWarning messages which are generated by each of the ComponentWorks
DAQ controls.
The ErrorEventMask property defines which types of errors are handled by
these events. The behavior of the remaining Error or Warning messages are
handled through the ExceptionOnError property. ExceptionOnError is true
by default. Set this property to False in order to check the return values
of method calls such as Configure and Start to see if an error has occurred.


I believe that the error you are encountering is -10401, Unknown Device Error.
A common reason for this error is an invalid device number.
If you are using named channels and the device is NOT device 1, you would
also recieve
this error. This was a ComponentWorks bug. A workaround is
to set the correct device number instead of selecting the "Use Named Channels"
option in the property pages. This has been fixed in CW3.
In most other cases, the error is being returned by the NI-DAQ driver. I
would recommend upgrading to the latest version of the driver.

Denise

"Bill Garber" wrote:
>>I am using Component Works 2.0 in a Visual C++ application for data acquisition>from
a PCI6071 DAQ card, and frequently get "Blue Screens of Death", and/or>a
message something to the effect "The Instrument is not a National Instruments>product..."
when debugging the code.>>The problem has increased recently, to what might
be called a catastrophic>level: almost 100% of the time the initialization
process hangs: requiring>a reboot.>>Is there Visual C++ sample code which
might show how to trap and handle these>DAQ errors gracefully? I have not
been sucessful in capturing error numbers/messages>using the r
eturn value
from

[Bill Garber]

Thanks, Denise.

As it turns out, when stopping the VC++ debugger without exiting normally
(such as occurs when threads fail to initialize), the DAQ gets into an unknown
state. Subsequent to this, I either get the aforementioned "unknown device"
message, or the system will "blue screen".

The system will also blue screen if I attempt to open up either the DAQ test
tools or the Configuration utility, after one of these events.

Is there a way to reset the DAQ if the debugger needs to be stopped pre-emptively,
such that the DAQ will not create blue screen conditions?

As an aside, when the blue screens have occurred, over time, the *.rc (resource)
file got corrupted. Ultimately, the size of the file went from a "pristine"
128kB to >380MB! The compile/load process took several minutes to perform
(normally it took < 30 seconds). This has subsequently been corrected, but
the blue screens continue and, I suspect, the file corruption will again
rear its ugly head.

The error checking you addressed (from within the normal program operation)
is a very good idea, and I have attempted (with limited success) to do this
in the past.

The blue-screen condition is different, I believe, due to the abnormal termination
of the debugging process. Do you know of a way to gracefully trap the "debug-exit"
condition and restore the DAQ to a known state? I have tried using the "SetNextStatement"
feature of the debugger to branch to "OnFileExit()" code, but this creates
Assertion errors if the debugger is exited before there is a valid HWnd for
the process. (Subsequent running of the debugger also creates blue-screens
immediately upon attempting to rerun the program or invoke one of the DAQ
programs).

Thanks, Bill

"denise" wrote:
>>For error handling, I would recommend writing event handlers for the DAQError>and
DAQWarning messages which are generated by each of the ComponentWorks>DAQ
controls. >The ErrorEventMask property defines which types of errors are
handled by>these events. The behavior of the remaining Error or Warning
messages are>handled through the ExceptionOnError property. ExceptionOnError
is true>by default. Set this property to False in order to check the return
values>of method calls such as Configure and Start to see if an error has
occurred.>>>I believe that the error you are encountering is -10401, Unknown
Device Error.>A common reason for this error is an invalid device number.
>If you are using named channels and the device is NOT device 1, you would>also
recieve this error. This was a ComponentWorks bug. A workaround is>to set
the correct device number instead of selecting the "Use Named Channels">option
in the property pages. This has been fixed in CW3.>In most other cases,
the error is being returned by the NI-DAQ driver. I>would recommend upgrading
to the latest version of the driver.>>Denise>>"Bill Garber"
wrote:>>>I am using Component Works 2.0 in a Visual C++ application for data
acquisition>from>a PCI6071 DAQ card, and frequently get "Blue Screens of
Death", and/or>a>message something to the effect "The Instrument is not a
National Instruments>product...">when debugging the code.>>The problem has
increased recently, to what might>be called a catastrophic>level: almost
100% of the time the initialization>process hangs: requiring>a reboot.>>Is
there Visual C++ sample code which>might show how to trap and handle these>DAQ
errors gracefully? I have not>been sucessful in capturing error numbers/messages>using
the return value>from

[Denise Riedlinger]

Bill,

I don't know of a way to nicely terminate the ongoing operation on the DAQ
device within the debugger before stopping in the middle. However, you could
use the DeviceReset method on the CWDAQTools control to reset the hardware.
You can either add this call as the first call within you app, or create
a separate exe that you run after quiting the debugger. After calling DeviceReset,
you should be able to run the program, access the test panels, etc. without
any further errors.

Regards,
Denise

"Bill Garber" wrote:
>>Thanks, Denise.>>As it turns out, when stopping the VC++ debugger without
exiting normally>(such as occurs when threads fail to initialize), the DAQ
gets into an unknown>state. Subsequent to this, I either get the aforementioned
"unknown device">message, or the system will "blue screen".>>The system will
also blue screen if I attempt to open up either the DAQ test>tools or the
Configuration utility, after one of these events.>>Is there a way to reset
the DAQ if the debugger needs to be stopped pre-emptively,>such that the
DAQ will not create blue screen conditions?>>As an aside, when the blue screens
have occurred, over time, the *.rc (resource)>file got corrupted. Ultimately,
the size of the file went from a "pristine">128kB to >380MB! The compile/load
process took several minutes to perform>(normally it took < 30 seconds).
This has subsequently been corrected, but>the blue screens continue and,
I suspect, the file corruption will again>rear its ugly head.>>The error
checking you addressed (from within the normal program operation)>is a very
good idea, and I have attempted (with limited success) to do this>in the
past. >>The blue-screen condition is different, I believe, due to the abnormal
termination>of the debugging process. Do you know of a way to gracefully
trap the "debug-exit">condition and restore the DAQ to a known state? I
have tried using the "SetNextStatement">feature of the debugger to branch
to "OnFileExit()" code, but this creates>Assertion errors if the debugger
is exited before there is a valid HWnd for>the process. (Subsequent running
of the debugger also creates blue-screens>immediately upon attempting to
rerun the program or invoke one of the DAQ>programs).>>Thanks, Bill>>"denise"
wrote:>>>For error handling, I would recommend
writing event handlers for the DAQError>and>DAQWarning messages which are
generated by each of the ComponentWorks>DAQ>controls. >The ErrorEventMask
property defines which types of errors are>handled by>these events. The
behavior of the remaining Error or Warning>messages are>handled through the
ExceptionOnError property. ExceptionOnError>is true>by default. Set this
property to False in order to check the return>values>of method calls such
as Configure and Start to see if an error has>occurred.>>>I believe that
the error you are encountering is -10401, Unknown>Device Error.>A common
reason for this error is an invalid device number.> >If you are using named
channels and the device is NOT device 1, you would>also>recieve this error.
This was a ComponentWorks bug. A workaround is>to set>the correct device
number instead of selecting the "Use Named Channels">option>in the property
pages. This has been fixed in CW3.>In most other cases,>the error is being
returned by the NI-DAQ driver. I>would recommend upgrading>to the latest
version of the driver.>>Denise>>"Bill Garber" >wrote:>>>I
am using Component Works 2.0 in a Visual C++ application for data>acquisition>from>a
PCI6071 DAQ card, and frequently get "Blue Screens of>Death", and/or>a>message
something to the effect "The Instrument is not a>National Instruments>product...">when
debugging the code.>>The problem has>increased recently, to what might>be
called a catastrophic>level: almost>100% of the time the initialization>process
hangs: requiring>a reboot.>>Is>there Visual C++ sample code which>might show
how to trap and handle these>DAQ>errors gracefully? I have not>been sucessful
in capturing error numbers/messages>using>the return value>from

[Bill Garber]

Hi, Denise;

I might try placing the reset code within a "#idef Debug"-type statement,
or, os you suggested, making it the first call of the app, and/or generate
a separate app.

Thanks.

Regards, Bill

"denise" wrote:
>>Bill,>>I don't know of a way to nicely terminate the ongoing operation
on the DAQ>device within the debugger before stopping in the middle. However,
you could>use the DeviceReset method on the CWDAQTools control to reset the
hardware.> You can either add this call as the first call within you app,
or create>a separate exe that you run after quiting the debugger. After
calling DeviceReset,>you should be able to run the program, access the test
panels, etc. without>any further errors.>>Regards,>Denise>>"Bill Garber"
wrote:>>>Thanks, Denise.>>As it turns out, when stopping
the VC++ debugger without>exiting normally>(such as occurs when threads fail
to initialize), the DAQ>gets into an unknown>state. Subsequent to this,
I either get the aforementioned>"unknown device">message, or the system will
"blue screen".>>The system will>also blue screen if I attempt to open up
either the DAQ test>tools or the>Configuration utility, after one of these
events.>>Is there a way to reset>the DAQ if the debugger needs to be stopped
pre-emptively,>such that the>DAQ will not create blue screen conditions?>>As
an aside, when the blue screens>have occurred, over time, the *.rc (resource)>file
got corrupted. Ultimately,>the size of the file went from a "pristine">128kB
to >380MB! The compile/load>process took several minutes to perform>(normally
it took < 30 seconds).> This has subsequently been corrected, but>the blue
screens continue and,>I suspect, the file corruption will again>rear its
ugly head.>>The error>checking you addressed (from within the normal program
operation)>is a very>good idea, and I have attempted (with limited success)
to do this>in the>past. >>The blue-screen condition is different, I believe,
due to the abnormal>termination>of the debugging process. Do you know of
a way to gracefully>trap the "debug-exit">condition and restore the DAQ to
a known state? I>have tried using the "SetNextStatement">feature of the
debugger to branch>to "OnFileExit()" code, but this creates>Assertion errors
if the debugger>is exited before there is a valid HWnd for>the process.
(Subsequent running>of the debugger also creates blue-screens>immediately
upon attempting to>rerun the program or invoke one of the DAQ>programs).>>Thanks,
Bill>>"denise"> wrote:>>>For error handling, I
would recommend>writing event handlers for the DAQError>and>DAQWarning messages
which are>generated by each of the ComponentWorks>DAQ>controls. >The ErrorEventMask>property
defines which types of errors are>handled by>these events. The>behavior
of the remaining Error or Warning>messages are>handled through the>ExceptionOnError
property. ExceptionOnError>is true>by default. Set this>property to False
in order to check the return>values>of method calls such>as Configure and
Start to see if an error has>occurred.>>>I believe that>the error you are
encountering is -10401, Unknown>Device Error.>A common>reason for this error
is an invalid device number.> >If you are using named>channels and the device
is NOT device 1, you would>also>recieve this error.> This was a ComponentWorks
bug. A workaround is>to set>the correct device>number instead of selecting
the "Use Named Channels">option>in the property>pages. This has been fixed
in CW3.>In most other cases,>the error is being>returned by the NI-DAQ driver.
I>would recommend upgrading>to the latest>version of the driver.>>Denise>>"Bill
Garber" >wrote:>>>I>am using Component Works 2.0 in a
Visual C++ application for data>acquisition>from>a>PCI6071 DAQ card, and
frequently get "Blue Screens of>Death", and/or>a>message>something to the
effect "The Instrument is not a>National Instruments>product...">when>debugging
the code.>>The problem has>increased recently, to what might>be>called a
catastrophic>level: almost>100% of the time the initialization>process>hangs:
requiring>a reboot.>>Is>there Visual C++ sample code which>might show>how
to trap and handle these>DAQ>errors gracefully? I have not>been sucessful>in
capturing error numbers/messages>using>the return value>from