--------------------------------------------------------------- NOV-BSOD.DOC -- 19950920 -- Info on the "Black Screen of Death" --------------------------------------------------------------- Feel free to add or edit this document and then email it back to faq@jelyon.com WINDOWS AND THE "BLACK SCREEN O' DEATH" >>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. Self-Extracting File Name: BSDUP1.EXE Revision: A 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=BHENDRIC@NOVELL.COM Provo, UT 84606