home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!munnari.oz.au!asgard!ben
- From: ben@mlb.dmt.csiro.au (Ben Simons)
- Newsgroups: comp.windows.ms.programmer
- Subject: SUMMARY: The System Error - cannot read from device AUX
- Summary: This is a SUMMARY.
- Message-ID: <180@hati.mlb.dmt.csiro.au>
- Date: 29 Jul 92 04:58:33 GMT
- References: <1992Jul15.013026.7819@nuscc.nus.sg> <1992Jul15.081305.13948@cs.tu-berlin.de> <8922@travis.csd.harris.com>
- Organization: CSIRO Division of Manufacturing Technology, Melbourne, Australia
- Lines: 83
-
-
- Thank you all for your swift replies! I recieved mail from:
-
- msaletni@Jade.Tufts.EDU (Michael J. Saletnik)
- courtney@data.rain.com (Courtney Meissen)
- heathh@cco.caltech.edu (Heath Ian Hunnicutt)
- magmy@modeld.no (Magne Myrtveit)
- poffen@sj.ate.slb.com (Russ Poffenberger)
- raymondc@microsoft.com
-
- which indicates that a wide variety of people are reading this newsgroup.
- This is very encouraging. It appears that the solution is quite simple,
- my problem was that i didn't understand what the AUX port had to do with
- anything. I will give you a flavour of the replies...
-
- In summary, the situation is this:
-
- "Since you are running the DEBUG kernel, it is attempting to log errors
- and warnings to device AUX. This device can be an additional monitor,
- CodeView, or the DBWin sample application included in the 3.1 SDK.
- [ ... ] [ie: Michael mentions \c700\bin\dbwin]" - msaletni.
-
- "I get this when I run debug Windows with certain applications
- (Actor, Toolbook), so I've gone back to retail Windows. I believe
- that Windows is trying to 'RIP' and send info out the com port
- on an error that occurred. [ ... ] " - courtney.
-
-
- [The most amazing reply was from heathh, I hope heath doesn't mind me
- including his mail - i found it VERY entertaining - it brightens a dreary day!]
-
- " 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.
-
- 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.
- " - heathh.
-
-
- "It seems to me that you are running DBWIN.EXE with output to COM1.
- See the DBWIN options menu." - Magne.
-
-
- "When running the debugging kernel, it wants to send the debug output to the
- AUX port (com 1) by default. The way around this with Windows 3.1 is to load
- the dbwin sample application which re-directs the debug output how you choose."
- - poffen.
-
-
- "The debug version of Windows 3.1 uses COM1 (aka AUX) to communicate
- with the programmer." - raymondc.
-
-
- ==================
- AHA! Once again thank you all. I guess it was pretty simple, really.
- It always is once you see the answer... :-)
- ben.
-