lwallace@javelin.es.com (Lynn Wallace) (02/01/91)
Several of the Microsoft SDK sample programs, as well as Notepad and others, cause my system to hang for about a minute, then display an "error writing to device AUX/cancel/retry" message. If I'm lucky, this is a one-time msg, but it usually shows up as an infinite(?) loop. I conjecture this: The AUX is supposed to be my auxillary monitor, which I don't have, and the message is coming from the debugging version of Windows which detects a normally passable condition but wishes to inform me of the "problem". This sounds pretty naive I know, but I'm fairly new to PC's in general, and all my knowledge of the PC is in the Windows environment. I don't even know if I've got the debugging version of the kernal installed... (This hasn't stopped me from writing an application though.:-) -- Lynn Wallace |I speak for absolutely no one. Evans and Sutherland Computer Corp.| Salt Lake City, UT 84108 |Internet: lwallace@javelin.sim.es.com War not make one great! -- Yoda
mathew@mantis.co.uk (mathew) (02/01/91)
lwallace@javelin.es.com (Lynn Wallace) writes: > Several of the Microsoft SDK sample programs, as well as Notepad and others, > cause my system to hang for about a minute, then display an "error writing > to device AUX/cancel/retry" message. If I'm lucky, this is a one-time msg, > but it usually shows up as an infinite(?) loop. > > I conjecture this: The AUX is supposed to be my auxillary monitor, which I > don't have, and the message is coming from the debugging version of Windows > which detects a normally passable condition but wishes to inform me of the > "problem". Correct. Note that even if you have a second monitor, your problems are not over. You'll need the OX.SYS driver which redirects AUX: to the second screen. mathew. -- Internet: mathew@mantis.co.uk / mathew%mantis.co.uk@ukc.ac.uk UUCP: mathew@mantis.UUCP / ...!mcsun!ukc!ibmpcug!mantis!mathew If you know anything significant about ISDN, please mail me...
awd@dbase.A-T.COM (Alastair Dallas) (02/03/91)
In article <1991Jan31.182905.7337@javelin.es.com>, lwallace@javelin.es.com (Lynn Wallace) writes: > Several of the Microsoft SDK sample programs, as well as Notepad and others, > cause my system to hang for about a minute, then display an "error writing > to device AUX/cancel/retry" message. > I conjecture this: The AUX is supposed to be my auxillary monitor, which I > don't have, and the message is coming from the debugging version of Windows > which detects a normally passable condition but wishes to inform me of the > "problem". This sounds pretty naive I know, but I'm fairly new to PC's in ^^^^^ > general, and all my knowledge of the PC is in the Windows environment. Not naive at all. I've got over ten years in the PC software business, at least four years exposure to Windows (only six months active Windows dev, though). In short, I'm a professional :-). Your conjecture exactly duplicates my thought processes from six months ago. I never looked back. The question remains what the professionals at Microsoft thought they were doing when they left this hardware-specific trap in their shipping product. I'd be curious if "real" Windows programmers actually hook up a third monitor to catch these errors or whether they ignore them like us. Funny thing is, I've got an old H19 kicking around; I just don't think it's worth 5 minutes of my time (or 2 sq ft of desk space) to experiment. /alastair/
goodearl@world.std.com (Robert Goodearl) (02/03/91)
In article <aD5ow17w163w@mantis.co.uk> mathew@mantis.co.uk (mathew) writes: >lwallace@javelin.es.com (Lynn Wallace) writes: >> Several of the Microsoft SDK sample programs, as well as Notepad and others, >> cause my system to hang for about a minute, then display an "error writing >> to device AUX/cancel/retry" message. ... >> >> I conjecture this: The AUX is supposed to be my auxillary monitor, which I >> don't have... > >Correct. Sort of correct. AUX is a synonym for the output side of COM1. If you were to connect a terminal, serial printer or another computer running a communication program to your COM1 port (with the appropriate cable), windows would give you information about the FATAL EXIT it is making. This includes the type of error and a stack dump. Of course if you don't have the symbolic stack information what you mostly get is a bunch of hex addresses that don't mean much to you. You can get fatal exit messages from the non-debugging version of windows, though because of the additional error checking built into the debug version you are more likely to get a fatal exit from it. > >Note that even if you have a second monitor, your problems are not over. >You'll need the OX.SYS driver which redirects AUX: to the second screen. > OX.SYS (notice how it sounds like AUX) is a driver that redirects the AUX device to output on a monochrome montitor in a system that has both color and monochrome displays. It will not work on a PS/2 with both VGA and 8514 display adaptors. -- Bob Goodearl -- goodearl@world.std.com
nee@cf_su14.Sbi.Com (Robert Nee) (02/04/91)
I would like to point something out to programmers with a second monitor. If you run the device driver OX.SYS then you can tell the SDK spy application to route it's output to COM1 a.k.a AUX a.k.a your second monitor. This is very helpful and I use it alot. One other piece of info: OX.SYS while it will let you see the fatal exit messages and stack trace, it does not let you reply to the Abort, Break, Ignore prompt. I have a utility that will let you do this. It redirects messages to the monochrome monitor by replacing the OutputDebugString routine after it is run (I guess it does this similar to the way ATM replaces the Windows font routines.) It will also let you reply the prompts after the stack dump rather than being forced to reboot. This program does not completely replace OX.SYS. As mentioned above, if you want to redirect AUX to the MDA you still need OX.SYS. One last thing: OX.SYS does nothing for users with a 8514/VGA setup. This program (MDA.EXE) will work in this configuration and it will also send output to your primary monitor if you only have one! Please mail me if you would like this utility. I do not have ftp access, I would ask that the first person who mails me a reply who does place this utility on cica or where ever appropriate. Robert F. Nee <nee&cf_su20.Sbi.Com>
akm@cs.uoregon.edu (Anant Kartik Mithal) (02/05/91)
In article <161@cf_su20.cf_su10.Sbi.COM> nee@cf_su14.Sbi.Com (Robert Nee) writes: >I would like to point something out to programmers with a >second monitor. If you run the device driver OX.SYS then >you can tell the SDK spy application to route it's output >to COM1 a.k.a AUX a.k.a your second monitor. This is >very helpful and I use it alot. Two questions. First, I have my mouse on Com1:, will using OX.sys screw the mouse up? Second, is OX.sys part of the SDK? If so, where is it documented in the SDK? If not, where can one get it from? cheers! kartik -- Anant Kartik Mithal akm@cs.uoregon.edu Research Assistant, (503)346-4408 (msgs) Department of Computer Science, (503)346-3989 (direct) University of Oregon, Eugene, OR 97403-1202
nee@cf_su14.Sbi.Com (Robert Nee) (02/05/91)
> Two questions. First, I have my mouse on Com1:, will using OX.sys > screw the mouse up? > Second, is OX.sys part of the SDK? If so, where is it documented in > the SDK? If not, where can one get it from? I have my mouse on COM1: also and use OX.SYS without any problems. I think DOS routes all output for AUX: and sends it to COM1: but if someone traps output to AUX: and sends it to the MDA then the COM port never gets involved and should have no problems. OX.SYS is not part of the SDK. It is just one of those things that is floating around. It is probably on cica.cica. Look there. Robert F. Nee <nee@cf_su20.Sbi.Com>
kvitekp@jvd.msk.su (Pete Kvitek) (02/06/91)
In article <161@cf_su20.cf_su10.Sbi.COM> nee@cf_su14.Sbi.Com (Robert Nee) writes: >I would like to point something out to programmers with a >second monitor. If you run the device driver OX.SYS then >you can tell the SDK spy application to route it's output >to COM1 a.k.a AUX a.k.a your second monitor. This is >very helpful and I use it alot. I'm using OX.SYS even in dos mode -- to put something on the secondary monitor while i'm working on the primary one. For example, if you're going to do some work which requires file name riminder: dir *.zip > aux > Pete -- -- Pete I. Kvitek <kvitekp@jvd.msk.su> | Phone: (095) 328-1327 Speaking from but not for JV Dialogue, Moscow, USSR | Fax: (095) 329-4711
jporter@twaddle.dell.com (Jeff Porter) (02/07/91)
It sounds like you are running a buggy application under the debugging version of Windows. When a Windows API function receives a invalid window handle (i.e. NULL or such), it generates a trap that displays a stack trace on the AUX port. If you don't have a terminal connected and the port initialized (MODE COM1:2400, for example), Windows will choke when trying to write message. If you have a monochrome card installed, Windows will display the message on that instead. I've noticed that Word For Windows 1.0 also generates these error messages. It sounds like MicroSoft didn't get quite all of the bugs out... Jeff Porter
yaturner@Sun.COM (James Turner) (02/20/91)
In article <aD5ow17w163w@mantis.co.uk>, mathew@mantis.co.uk (mathew) writes: |> Note that even if you have a second monitor, your problems are not over. |> You'll need the OX.SYS driver which redirects AUX: to the second screen. |> |> |> mathew. (this may be a repost, if so I apologize) you`re troubles still aren't over. Under windows 3.0 ox.sys (at least the version on cica) does not support input from the keyboard. So when you get the "Abort, Ignore, or Continue" message you can't respond and your system is now hung (can you say reboot, I knew you could). Does anyone have better solution for 3.0 ??? HELP!!! -- Mencsh tract und Gott lacht yaturner@corp.Sun.COM
poffen@sj.ate.slb.com (Russ Poffenberger) (02/21/91)
In article <3418@jethro.Corp.Sun.COM> yaturner@Sun.COM (James Turner) writes: >In article <aD5ow17w163w@mantis.co.uk>, mathew@mantis.co.uk (mathew) writes: >|> Note that even if you have a second monitor, your problems are not over. >|> You'll need the OX.SYS driver which redirects AUX: to the second screen. >|> >|> >|> mathew. > >(this may be a repost, if so I apologize) > >you`re troubles still aren't over. Under windows 3.0 ox.sys (at least the >version on cica) does not support input from the keyboard. So when you >get the "Abort, Ignore, or Continue" message you can't respond and your >system is now hung (can you say reboot, I knew you could). Does anyone >have better solution for 3.0 ??? HELP!!! > winrip (also on cica) works better, but only in 386 mode. Russ Poffenberger DOMAIN: poffen@sj.ate.slb.com Schlumberger Technologies UUCP: {uunet,decwrl,amdahl}!sjsca4!poffen 1601 Technology Drive CIS: 72401,276 San Jose, Ca. 95110 (408)437-5254
rommel@Informatik.TU-Muenchen.DE (Kai-Uwe Rommel) (02/22/91)
In article <1991Feb20.212028.18502@sj.ate.slb.com> poffen@SunOS (Russ Poffenberger) writes: >winrip (also on cica) works better, but only in 386 mode. > I found Winrip to have some bug. In a program I use GetModuleFilename() on a hInst returned by WinExec() (not fully documented) to determine if the program still runs. When it is gone, this causes a fatal-exit-sequence (as intended) which doesn't bother me without winrip when using my own AUXIL.SYS (which returns 'I' on reads -> ignore) but with winrip, I get a protection fault (UAE) at this point. Probably winrip does not know about the fatal exit code and when trying to print a descriptive message (as it does with the other codes) it generates an UAE. Kai Uwe Rommel
mk@vall.dsv.su.se (Magnus Karlson) (02/27/91)
Regarding reported problems with winrip on cica. I have spoken with the authour and he confirmed there was a problem with all versions of winrip before 1.41 that gave the symtoms you reported even if the problem not exactly was what reported, anyhow i have now uploaded winrip141.arc on cica.cica.indiana.edu (uploads directory). If you find any other problems with winrip you can send them to me and i will forward them to the authour since he is not on this net. Magnus Karlson, University of Stockholm, mk@vall.se