🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.windows.ms.programmer
Article #87

Re: System Error, Cannot Read from Device AUX

#87
From: Heath Ian Hunnicutt
Date: Tue, 28 Jul 1992 04:42
65 lines
2900 bytes
ben@mlb.dmt.csiro.au (Ben Simons) writes:
>Hi all,
>	I'm getting this error dialog box that says:

>		System Error

>	Cannot read from device AUX

>and it just keeps coming up, despite my selection of Cancel or Retry.
>I wish I knew what this meant - can anyone tell me? I know that I
>only get this message when i'm running in the debug version of
>windows 3.1.
	
	The box comes up because the debugging kernel expects
you to have a terminal connected to COM1. (aka AUX)  The kernel
uses the terminal to write out stack traces when a GPF or RIP occurs.
(General Protection Fault and Rest In Peace, respectively...)
If you don't have the terminal installed, things really go bad for you,
as you noticed.

	There have been sporadic reports of the retail windows
kernel trying to use a debug terminal when it is exceedingly stressed
out, but the likelihood is that a misbehaving application is the true
culprit.  
	
	You see, any program can write a string of debug output
using the (aptly named) DebugOutput and OutputDebugString API
calls.  For a good time, try the following code (in either
retail or debug build of Windows):
	:
	:
	case WM_PAINT:
	   DebugOutput("Crash-o-rama!");
	:
	:

	You'll get another visit from the friendly double-plus-ungood
system error dialog box.  MS left the code for DebugOutput in the
retail version so that apps could retain debug code (which would
have to be enabled via some sort of hidden mechanism).  Then, if your
app goes nuts in the field, you just take a terminal to the 
customer's site, turn on the debugging features via some hidden
menu option (or whatever...) and rock-n-roll.

	Unfortunately, MS did not really stress in the SDK docs
that DebugOutput() can lead to very bad times when used without
an attatched terminal.

	In the very near future, I'll be releasing a Shareware
utility that traps all DebugOutput strings, displays them in
a window, and averts sending them to the (non-existent)
terminal.
	There are other such utilities, notably OX.SYS,a device
driver for DOS which traps the terminal output.  I forget
who wrote it, but you can probably get it off of ftp.cica.indiana.edu.


See ya,
Heath

PS: This was typed over modem connection with lots o line noise. 
Please forgive me a few omitted/superfluous letters.

-- 
On Saturday, April 18, 1992, this .sig became self-aware.
Technical Details
Message-ID: <1992Jul28.044209.26976@cco.caltech.edu>
Path: arc1-ca.pugleaf.net!sparky!uunet!usc!sdd.hp.com!elroy.jpl.nasa.gov!nntp-server.caltech.edu!heathh
References: <179@hati.mlb.dmt.csiro.au>

Show Full Headers
Complete Article Headers
Newsgroups: comp.windows.ms.programmer
Path: arc1-ca.pugleaf.net!sparky!uunet!usc!sdd.hp.com!elroy.jpl.nasa.gov!nntp-server.caltech.edu!heathh
From: heathh@cco.caltech.edu (Heath Ian Hunnicutt)
Subject: Re: System Error, Cannot Read from Device AUX
Message-ID: <1992Jul28.044209.26976@cco.caltech.edu>
Sender: news@cco.caltech.edu
Nntp-Posting-Host: bartman
Organization: California Institute of Technology, Pasadena
References: <179@hati.mlb.dmt.csiro.au>
Date: Tue, 28 Jul 1992 04:42:09 GMT
Lines: 66