Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!decwrl!labrea!rutgers!rochester!pt.cs.cmu.edu!andrew.cmu.edu!ks26+
From: ks26+@andrew.cmu.edu (Kenneth Sykes)
Newsgroups: comp.windows.ms
Subject: Re: System Error...HELP!
Message-ID: <sYJJ-3y00WB3MKxkUN@andrew.cmu.edu>
Date: 26 Apr 89 05:24:19 GMT
Organization: Mellon College of Science, Carnegie Mellon, Pittsburgh, PA
Lines: 31

> I recently reinstalled a "slow boot" version of Windows 2.1 and SDK 2.0.
> Now when I try to run some programs I get the system error, "Cannot write to
> device AUX".  The dialog box provided "Retry" and "Cancel" but neither seem
> to let me exit the dialog box.
> Can anyone guess at what's wrong ?
>
> Thanks in advance,
>                -Rob Kedoin

This problem stems from the differences in the retail and debug versions
of Windows.  The debug version contains additional runtime code that validates
function input (For instance, making sure handles are not NULL).  When a 
validation test fails, the kernel writes the appropriate fatal exit code 
and a stack trace to the COM port, which presumably is connected to a debugging 
terminal.  At this point the person can "Abort, Break, or Ignore" the fatal 
error.  If nothing is attached to the com port you get the dialog box that you 
mentioned, and you have no choice but to reboot.  There is no *easy* way I know 
of to get Windows out of this loop.  Perhaps a TSR could be written that would 
monitor COM output for the prompt and return an "abort" reply, but this would
probably cost more than paying for a cheap terminal.

The retail version of Windows does not contain any of the runtime checks, So it
will do whatever it can with the input it is passed.  This explains why some
programs "work" in the retail version and "break" in the debug version.  Deleting
a NULL object, say, may not produce an adverse effect on the system, but the 
validation code will catch this and perform a fatal exit.

Hope this helps.

Sincerely,
   Ken Sykes