Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Windows and the "Black Screen O' Death"

3 views
Skip to first unread message

Michael E. Goldstein

unread,
Sep 6, 1993, 5:31:40 AM9/6/93
to
Anyone know any fix for the Windows 3.1 "Black Screen O' Death?" Cringley
has mentioned the problem, which seems to appear on PCs running Win 3.1
and attached to a heavy trafficed ipx ethernet, when running apps under
dos windows. Eventually, a DOS session freezes, the netware connection
seems to be gone and reseting the PC is the only way out.

Cringley was blaming Microsoft and bitching about their lack of integrity.
I vaguely remember hearing somewhere else that Novell has said that the
problem lies in their driver for windows 386 enhanced mode.

I think we got it.... anyone hear of a fix?

thanx,
mike goldstein
Michael E. Goldstein gol...@maine.maine.edu
207-764-0311x473 gol...@polaris.umpi.maine.edu
Director - Computer Services University of Maine at PI

Douglas Scott

unread,
Sep 7, 1993, 5:57:26 AM9/7/93
to
Mike Goldstein said:


> Anyone know any fix for the Windows 3.1 "Black Screen O' Death?" Cringley
> has mentioned the problem, which seems to appear on PCs running Win 3.1
> and attached to a heavy trafficed ipx ethernet, when running apps under
> dos windows. Eventually, a DOS session freezes, the netware connection
> seems to be gone and reseting the PC is the only way out.

We have something like that here too.

I have checked Brett Warthen's WINTIPS file that was distributed on this
list recently and all seems well enough.

The symptoms are:
1.
Start windows and immediately start a DOS shell and all is OK.

2.
Start Windows run a few windows apps, start a dos shell and Black Screen
of death often results. (Text mode screen with flashing cursor in top
left.) In particular if Word for Windows 2.0a is run and a file opened
then command.com run BSOD is guaranteed.

3.
Running memgraph.exe (shareware type stuff which shows windows
memory usage) and choosing compact memory usually allows dos shell to
be run.

4.
Occasionally when a DOS shell is started it works OK EXCEPT that there
are NO ENVIRONMENT strings. I have noticed that a program that comes with
optinet (networking CD roms) that is supposed to set an environment var
to the first CD ROM drive doesn't seem to work either. I suspect that
it is finding the wrong copy of the environment. This is SETCD.EXE.


Any ideas?


+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Douglas Scott D.S...@central.napier.ac.uk
Computer Support Group
Mechanical Manufacturing and Software Engineering
Napier University, Edinburgh, Scotland
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Peter Rindfuss

unread,
Sep 7, 1993, 9:44:43 AM9/7/93
to
I'm having similar problems here. After repeated task switching
between several DOS boxes (one of them usually being a telnet app),
one of the boxes freezes; sometimes the box still responds, but
extremely slowly - in that case I can blast it, but most of the time
I have to reboot the machine.

Peter Rindfuss
rindf...@medea.wz-berlin.de
Wissenschaftszentrum Berlin fuer Sozialforschung, Berlin
(Science Center Berlin for Social Research, Berlin, Germany)

Tom Nemeth

unread,
Sep 16, 1993, 7:12:12 AM9/16/93
to
In article <MAILQUEUE-101.9...@polaris.umpi.maine.edu> "Michael E. Goldstein" <GOL...@POLARIS.UMPI.MAINE.EDU> writes:

>Anyone know any fix for the Windows 3.1 "Black Screen O' Death?" Cringley
>has mentioned the problem, which seems to appear on PCs running Win 3.1
>and attached to a heavy trafficed ipx ethernet, when running apps under
>dos windows. Eventually, a DOS session freezes, the netware connection
>seems to be gone and reseting the PC is the only way out.

What ethernet frame type are you using? Is it Ethernet_II, or one of the
weird Novell ones?

Tom Nemeth

Ben Hendrick

unread,
Oct 8, 1993, 12:38:52 PM10/8/93
to
>>Anyone know any fix for the Windows 3.1 "Black Screen O' Death?" Cringley
>>has mentioned the problem, which seems to appear on PCs running Win 3.1
>>and attached to a heavy trafficed ipx ethernet, when running apps under
>>dos windows. Eventually, a DOS session freezes, the netware connection
>>seems to be gone and reseting the PC is the only way out.

BSDUP1.EXE on FTP NETWIRE\NOVLIB\01

more from the readme

NOVELL TECHNICAL INFORMATION DOCUMENT

TITLE: Black Screen of Death
DOCUMENT ID: TID013403
DOCUMENT REVISION: A
DATE: 13SEP93
ALERT STATUS: Yellow
INFORMATION TYPE: Symptom Solution
README FOR: BSDUP1.EXE

NOVELL PRODUCT and VERSION:
NetWare Client for DOS/Windows

ABSTRACT:
These newer files fix a problem when using Windows or Windows for
Workgroups on a network. The symptom is a blinking underlined curser in
the upper left hand corner of the screen when entering a DOS box or DOS
application and the workstation hangs.
_________________________________________________________________

DISCLAIMER
THE ORIGIN OF THIS INFORMATION MAY BE INTERNAL OR EXTERNAL TO NOVELL.
NOVELL MAKES EVERY EFFORT WITHIN ITS MEANS TO VERIFY THIS INFORMATION.
HOWEVER, THE INFORMATION PROVIDED IN THIS DOCUMENT IS FOR YOUR INFORMATION
ONLY. NOVELL MAKES NO EXPLICIT OR IMPLIED CLAIMS TO THE VALIDITY OF THIS
INFORMATION.
_________________________________________________________________

Self-Extracting File Name: BSDUP1.EXE Revision: A

Files Included Size Date

\
BSDUP1.TXT (This File)
VIPX.386 23850 5-11-93 version 1.15 (930511)
IPXODI.COM 30051 4-23-93 version 2.11 (930423)
LSL.COM 17760 7-28-93 version 2.02 (930728)


I. Description
---------------

These newer files fix a problem when using Windows or Windows for
Workgroups on a network. The symptom is a blinking underlined curser in
the upper left hand corner of the screen when entering a DOS box or DOS
application and the workstation hangs. The following factors may
contribute to the problem:

* Third-party device drivers or terminate-and-stay-resident (TSR)
programs.
* An incorrect system configuration including memory management.
* I/O, memory, or IRQ confilcts.
* Problems in VIPX.386.
* A problem in the Windows 3.1 virtual timing driver (VTD).


II. VIPX.386
-------------

VIPX.386 is a Windows 3.X virtualization driver for IPXODI.COM driver that
was enhanced jointly by NOVELL and Microsoft. It virtualizes requests to
the globally loaded IPX driver. When a request is made to IPX, VIPX will
allocate a request buffer in the system's global memory, copy the original
request to the global buffer and give the global request to IPX. When the
global request completes, IPX will call VIPX. VIPX will then copy any
results back to the original request buffer and call the application which
submitted the request.

II.A. Version Compatibility with Dedicated IPX
-----------------------------------------------

Novell officially ceased maintenance on the dedicated IPX driver (IPX.OBJ)
version 3.10 dated 11-21-91. The last version of VIPX to explicitly
support that driver is 1.10. The current version of VIPX supports
IPXODI.COM only. It is strongly recommended that you update your dedicated
IPX driver with IPXODI.COM when using versions of VIPX later than 1.10.
You can find the latest ODI drivers in the DOSUP?.ZIP file, currently
DOSUP7.ZIP.


II.B. Packet Size Limitations
------------------------------

VIPX.386 will only virtualize packets which are 8000 (decimal) bytes or
less. Any DOS and Windows IPX or SPX applications which use networks with
a physical packet size greater than 8000 bytes may not work with VIPX.386.
For example, IBM Token Ring can be configured to run with 16K packets. A
request by a DOS or Windows IPX application to send a 16K packet will be
truncated to 8000 bytes. On the other hand, any 16K packet that is
received by the LAN driver will be dropped because VIPX cannot allocate a
packet big enough to handle it.


II.C. Memory Manager Limitations
---------------------------------

When a request is passed up from IPX, VIPX will immediately test the
request buffer to see if it is in global memory already. If it is in
global memory, the request will be passed back down to IPX without any
virtualization. For example, a TSR loaded before Windows is considered to
be in global memory. If that TSR calls IPX, VIPX will test the requests
and pass them back down to IPX. This is done because there is no need to
virtualize requests which are already global.

The use of UMA memory complicates the test for global memory. There are
two basic scenarios. Scenario One is when a TSR has been loaded high
before Windows was loaded. In this case, IPX requests will come from
global UMA memory. VIPX will simply pass these requests back down to IPX.
Scenario Two is when a TSR is loaded high in a Windows DOSBOX. In this
case, IPX requests will come from local UMA memory. VIPX will virtualize
these requests.

Some memory managers test for global UMA memory and will work properly
under both scenarios. However, there are other memory managers that do not
work properly under Windows. With these drivers, all LOCAL DOSBOX UMAs
look as if they are GLOBAL UMAs. Under Scenario Two, when a TSR calls IPX,
VIPX will test the request buffer and think that it is in global UMA memory
when it is really in LOCAL UMA memory. As a result, VIPX will pass a local
ECB to IPX without virtualization. The normal result of this is a hung
machine or data corruption.

If you are using third party memory managers and hang, don't load TSRs
USING THE IPX INTERFACE (INCLUDING IPX ITSELF) HIGH. THEY MUST BE LOADED
IN CONVENTIONAL MEMORY.


III. Specialized Configuration Parameters
------------------------------------------

Under most circumstances, VIPX will work fine under the default
configuration. However, there may be some applications which require
custom configuration of the driver. This is a list of SYSTEM.INI
parameters which can be used to configure VIPX:

[VIPX]
VipxMappingPages =[number of 4K pages] (default = 16)
VipxFailOverSizedPackets =[ON|OFF|TRUE|FALSE] (default = OFF)
VirtualizeIrq[0-F] =[ON|OFF|TRUE|FALSE] (default = OFF)

III.A. VipxMappingPages
------------------------

This is the number of pages that VIPX can use to globalize requests to the
global IPXODI.COM driver. VIPX is not absolutely guaranteed to have all of
these pages available at any one point, since this is the requested number
of pages for SHARED global mapping which VIPX makes to the Windows VMM at
initialization time.


III.B. VipxFailOverSizedPackets
--------------------------------

This parameter tells VIPX to fail any requests which require more than the
maximum allowed globalization size. The actual maximum will vary according
to which media the user is on. The absolute maximum is 8000 (decimal)
bytes. With media that have smaller packets than 8000 bytes, the maximum
allowed size is the maximum packet size that can be put onto the media.


III.C. VirtualizeIrq[0-F]
--------------------------

VIPX 1.15 avoids a deadlock between the PC and Network Interface Card (NIC)
by virtualizing the NIC's IRQ(s). With ODI and dedicated IPX (IPX.OBJ)
drivers, VIPX will automatically read the configuration of the NIC from the
driver and virtualize the selected IRQs. However, when using the IBM LAN
Support Program with either SLANSUP.OBJ or LANSUP.COM, the LAN IRQ is not
readable from the driver. The only way to get this information is to read
the NIC hardware itself. The problem with doing this is that the hardware
can be Token Ring, PCN2 or Ethernet. VIPX must now be aware of many
different hardware configurations. Instead of this, VIPX requires the IBM
LAN Support user to specify the NIC's IRQ in the [VIPX] section of the
SYSTEM.INI. IRQs range from 0 to F (hex). An example is listed below:

[VIPX]
VirtualizeIrq2=TRUE
VirtualizeIrq3=TRUE

In this example, VIPX will virtualize both IRQ 2 and IRQ 3. VIPX can
virtualize up to 4 different LAN IRQs. The reason for virtualizing
multiple IRQs is to allow other LAN cards and protocols to be installed on
the same PC and prevent them from deadlocking the PC. For example, you may
have IPX running through an NE2000 card on IRQ 3 and TCP/IP running through
to an IBM Token Ring card on IRQ 2.


III.D. TimerCriticalSection
----------------------------

As of version 1.15 of VIPX, TimerCriticalSection is required to be set on.
The recommended setting is as follows:

[386Enh]
TimerCriticalSection=10000

The reason for this parameter is to avoid a deadlock with the LAN IRQ
Virtualization code. See section III.C VirtualizeIrq[0-F].


IV. IPXODI.COM
---------------

IPXODI.COM had a bug in SPX. During a retry, SPX would jump to invalid
memory causing an invalid opcode exception in v86 mode only when SPX is
being used. Few applications use SPX. This usually manifests itself as a
reboot, hung machine or blank screen with cursor in upper left corner.
This version of IPXODI.COM should be used instead of the one found in
DOSUP7.ZIP.


V. LSL.COM
-----------

LSL.COM had a number of bugs and one was a bug that caused a deadlock
situation with the LAN adapter. A Do Send for Windows needed a Start and
End Critical Section call added. It is now language enabled. A memory
calculation bug when calculating the amount of memory to reserve when going
TSR is fixed. This version of LSL.COM should be used instead of the one
found in DOSUP7.ZIP. It will only take about 300 bytes of extra memory.


VI. INSTALLATION
-----------------

* Rename or backup the old VIPX.386, IPXODI.COM and LSL.COM.
* Copy IPXODI.COM and LSL.COM to where the NIC software is initialized.
* Copy VIPX.386 to your WINDOWS\SYSTEM directory.
* Virtualize the NIC's IRQ in the [VIPX] section of the System.ini if using
IBM LAN SUPPORT.
* Put TimerCriticalSection=10000 in the [386Enh] section of the
System.ini.
* Reboot the PC and load the ODI drivers.
* Enter windows.
я
________________________________________________________
Ben Hendrick (CNE, ECNE) Phone # 800-638-9273
Novell Services Division Fax # 801-342-1019
122 East 1700 South Email=BHEN...@NOVELL.COM
Provo, UT 84606 **Customer Driven and Living it!!**
--------------------------------------------------------

0 new messages