jcmorris@mwunix.mitre.org (Joe Morris) (05/23/91)
I'm currently working on a problem with Windows 3 in which bad things happen
after running a DOS (non-Windows) communications program under Windows.
When the DOS window is closed (by the EXIT command if you started the
normal DOS window icon, or by ending the program if started directly from
its own icon) then either the system crashes, or Windows abruptly terminates.
The problem was first seen with YTERM 3.0.1, but I've produced the same
symptoms using MSKERMIT 3.10 (ftp'ed directly from Columbia). The error
occurs with no device drivers or TSR's other than those shipped with
PC-DOS 3.3 and Windows 3.0a. The failure has been seen on NEC and IBM
boxes, VGA and EGA, Windows 3.0 and 3.0a, with and without a WD Ethernet
card installed. The failure occurs only when running Windows in 386
enhanced mode.
The error is completely repeatable. If it fails the third time you run
KERMIT and has a particular failure mode, then every time you boot up
and try the script it will fail at the same point with the same symptoms.
Both the occurrence of the failure and its symptoms are VERY sensitive
to what is where in memory. I built some dummy TSR's to force different
memory mappings and was able to affect the failures.
Failure modes include:
a - Following the EXIT command from the DOS screen, you see some of the
desktop being rebuilt, then the screen blanks and you are presented
with the normal DOS prompt. A memory map shows that Windows is no
longer in the machine.
b - Same as (a) but the screen is left in a strange video mode and you
can see only bars (if that much) where text ought to be. Typing
the command MODE CO80 blindly fixes the screen.
c - Same as (a) but the screen you see was the one which was active in
the DOS window when the EXIT command was issued.
d - Any of the above, but if you re-invoke Windows the fonts used with
icons are incorrect.
e - The message 'INVALID COMMAND.COM, SYSTEM HALTED' (or something like
that).
The fact that both YTERM and KERMIT are triggering the same failure mode
strongly suggests that the problem is in Windows, but so far I've not
gotten any indication from Microsoft tech support that the problem is
known.
A possible band-aid suggested by Microsoft was to check the EXCLUSIVE mode
box in the PIF editor for any DOS app which might be using a communications
program. So far I haven't been able to break the system with this change,
but I'm uncomfortable with not knowing what went wrong...even if the failure
doesn't happen again.
Sure, we could go to some of the commercial packages but there are both
operational and financial reasons why YTERM and MSKERMIT are preferred.
(Thanks, Congress, for cutting the FFRDC funds in this year's budget...)
Does anyone recognize the symptoms, or have a suggestion?
Joe Morrisdcc@hpopd.pwd.hp.com (Daniel Creswell) (05/23/91)
Running in exclusive mode means that only your comms program will run when it's selected. From this you can infer that something in Windows is upsetting the comms program or vice versa. The other thing is that Windows monitors the comm ports in an attempt to resolve conflictions that may occur. This is not wonderful in my experience. Regards, Dan C.