Windows vs. NetWare Troubleshooting Tips Compiled by Brett Warthen (Infinite Technologies) Fourth Edition: July 8, 1994 The most important troubleshooting tip for solving conflicts between Windows and NetWare is to remember to use logical deduction and the process of elimination to isolate and identify conflicts. For example, if you are using a 3rd party memory manager like QEMM or 386-to-the-MAX, de-install it and try your configuration running Microsoft's HIMEM.SYS that ships with Windows 3.1 instead (try without EMM386). Then, if the problem is related to your memory manager, you should contact that vendor for technical support suggestions. If you are loading any additional TSRs or device drivers, try your configuration without them loaded, and add them back into your system one by one to determine which is causing the conflict. If you are using EMSNETX or XMSNETX, try using regular old NETX instead. If you are attempting to use the newer VLM drivers, you may also want to try your configuration with NETX. While far from being a comprehensive guide to all possible Windows and NetWare conflicts, this document contains some troubleshooting tips for common problems running Windows in the NetWare environment. (Thanks to everyone in NOVCLIENT Section 6, the Windows section of the Novell NetWire forums on CompuServe for helping to compile this list. Acknowledgements are presented at the end of this document.) Recommendations for ALL Systems: 1.) In the Windows SYSTEM.INI file, verify the following settings: Under the [boot] section header: network.drv=netware.drv Under the [386Enh] section header: network=*vnetbios,vnetware.386,vipx.386 NOTE: *vnetbios can cause some problems with some current LAN card drivers, especially the IBM LAN Support drivers. If you are not using any NETBIOS applications, then you may be better off leaving *vnetbios out of this statement. If you are using NETBIOS and the IBM LAN Support drivers, then you may want to consider using the native Token Ring drivers in TOKWS.EXE in NOVLIB Library 6 on CompuServe. 2.) Update to the latest NetWare drivers, a minimum level of IPXODI v2.10 and NETX v3.32 or VLM v1.10 for proper support of the Windows 3.1 environment. If you must use the linked IPX driver (IPX.COM), use v3.10, however note that the last VIPX.386 driver released by Novell that was explicitly tested with the linked IPX was v1.10. The ODI drivers should be used whenever possible. The current versions of NetWare-related DOS/Windows drivers is presented at the end of this section. 3.) Check for duplicate copies of the NWPOPUP.EXE, VNETWARE.386, VIPX.386 and NETWARE.DRV files. (You may find one version in the Windows directory and another in Windows\SYSTEM.) Make sure that the only versions that remain on your system are 1992 or 1993 (or later) dated versions. (The latest versions are available for download from the WINUP*.EXE file in the NOVFILES file area on CompuServe, which is currently WINUP9.EXE.) 4.) Verify that the NETWARE.DRV file is at least 125,000 bytes in size. We've seen plenty of problems where installation routines did not properly expand this file. An old version of the NetWare DOS/Windows Workstation Kit NWSETUP installation procedure was particularly notorious for this type of problem. 5.) Use WINSTART.BAT with care. There is a bug with WINSTART.BAT processing under Windows 3.1 on some PCs, which can cause Windows to hang-up when exiting. An old version of the NetWare DOS/Windows Workstation Kit NWSETUP installation procedure created a dummy WINSTART.BAT which can trigger this problem. 6.) If you want to receive broadcast messages while in Windows, then make sure that NWPOPUP.EXE is included in the "load=" statement in your WIN.INI file. (Alternatively, NWPOPUP can be included in your Windows startup group.) 7.) In your NET.CFG (or SHELL.CFG) file, be sure to allocate plenty of file handles. FILE HANDLES=80 is a recommended minimum. 8.) If you must use NETX v3.26 or earlier: In your NET.CFG (or SHELL.CFG) file, allocate additional stacks for IPX/SPX usage by specifying GET LOCAL TARGET STACKS = 5. The default setting is 1 stack, which can lead to system lockup problems when receiving NetWare broadcast messages. If you plan on making use of IPX/SPX applications on a regular basis, then you should increase this value to GET LOCAL TARGET STACKS = 10. (The GET LOCAL TARGET STACKS setting works around a bug in NETX v3.26, and is not necessary if you are running NETX v3.31 or later, which fixes this bug.) 9.) If you are running DR-DOS 6, make sure that you have the April 1992 Business update installed for Windows 3.1 compatibility. This file can be downloaded from the Novell Library forum (NOVLIB) on CompuServe, DR6UP2.EXE in Library 12. 10.) If you are attempting to use the Burst Mode shell (BNETX) with Windows 3.1, it may be a futile effort, as there are some timing problems which can cause severe system slowdowns. Note that Novell has since discontinued the BNETX shell, and packet burst is only supported from a DOS workstation when using the VLM requester. 11.) The VIPX.386 driver can only virtualize packets that are 8000 bytes or smaller. You should not attempt to use a driver with larger packet sizes with Windows (for example, IBM Token Ring can be configured for 16KB packets). 12.) Microsoft's VTDA.386 driver should be loaded on your system. This file should be located in your Windows SYSTEM directory. If you do not have this file, acquire either the WW0863.EXE or WW0981.EXE file from Microsoft, which include the VTDA.386 file (on CompuServe, these files are available in the Microsoft Software Library - GO MSL). WW0863.EXE includes VTDA.386 only. WW0981.EXE includes VTDA.386 as part of the Windows 3.1 to Windows 3.11 upgrade files. If VTDA.386 is present on your system, it must be activated. In the [386Enh] section of SYSTEM.INI, a "device=vtda.386" statement should be present, and a "device=*vtd" statement should NOT be present. (VTDA.386 replaces the built-in *VTD driver.) 13.) If using IBM LAN Support, be sure that you are using VIPX.386 v1.15 or later. In the SYSTEM.INI file, you also need to let VIPX.386 know what IRQ your network card is using to prevent possible conflicts. This is done by creating/updating a [VIPX] section in SYSTEM.INI, and including a VirtualizeIRQx=TRUE statement, where "x" is the IRQ that is being used by the network adapter. Valid values for this IRQ are 2 thru F, and are specified in hexidecimal notation (A = 10, F = 15). 14.) Novell recommends including the statement "TimerCriticalSection=10000" under the [386Enh] section header of SYSTEM.INI when using VIPX.386 v1.15 or higher. 15.) NETX and the VLM drivers require the use of a different NETWARE.DRV file, depending on what client software you are running. To determine the version of NETWARE.DRV, use the NetWare VERSION.EXE program (e.g., VERSION NETWARE.DRV). v2.x versions of NETWARE.DRV should be used only with NETX, while v3.x versions of NETWARE.DRV are for the VLM client only. Latest Versions of NetWare-related drivers for DOS/Windows: Novell and Microsoft periodically release new drivers to address problems in existing drivers. As new drivers are released, older drivers/patches are often deleted and replaced by the newer files. These filenames are current as of the release of this document, but are subject to change. Novell drivers in the NOVFILES file area on CompuServe: DOSUP9.EXE - Contains updates for the DOS ODI drivers, NETX (v3.32 PTF), and the VLMs (v1.10). WINUP9.EXE - Contains updates for the Windows-specific drivers. NOTE: As Novell releases new drivers, the filenames will be updated. The next release will most likely be DOSUPA.EXE and WINUPA.EXE or DOSUP10.EXE and WINUP10.EXE. Novell drivers in NOVLIB Library 5 on CompuServe: VPX118.EXE - Contains an update to VIPX.386 v1.18. VLMUP2.EXE - Updates selected VLMs (FIO, AUTO, CONN, REDIR, GENERAL and VLM.EXE) to v1.11. PBURST.EXE - Contains patches for packet burst to be used with VLM v1.11. Includes an updated PBURST.NLM for NetWare 3.11, and patches for NetWare 3.12 and 4.01. NOTE: As Novell releases new drivers, the above files may be deleted, and rolled into future DOSUPx and WINUPx releases. Other Novell Pre-Release Drivers on CompuServe: VPX119.EXE - Contains an update to VIPX.386 v1.19 to correct a problem that could cause a "Black Screen of Death" error. This file is not officially released, but is available in the NSD area (GO NSD) of CompuServe or on the NSE Pro. The existence of this file is documented by Novell's Technical Information Database: TID021138 and TID021125. Microsoft driers in the Microsoft Software Library (MSL) on CompuServe: WW0863.EXE - Includes VTDA.386 WW0981.EXE - Upgrade files for upgrading Windows 3.1 to Windows 3.11 (also includes VTDA.386). WW1000.EXE - Includes VSHARE.386 (a Windows replacement for SHARE.EXE). Filename Date Size Version Where ---------------------------------------------------------- LSL.COM 9/10/93 17805 2.05 DOSUP9.EXE IPXODI.COM 3/14/94 30126 2.20 VLMUP2.EXE NETX.EXE 11/17/93 78654 3.32 PTF DOSUP9.EXE VLM.EXE 3/14/94 36635 1.11 VLMUP2.EXE (NOTE: Individual VLMs are v1.10 or v1.11 from DOSUP9.EXE and VLMUP2.EXE) VIPX.386 1/19/94 23855 1.18 VPX118.EXE (prerelease) 5/23/94 23855 1.19 VPX119.EXE VNETWARE.386 11/19/93 15133 2.03 WINUP9.EXE NWPOPUP.EXE 10/28/93 4592 3.01 WINUP9.EXE NETWARE.DRV (vlm) 11/24/93 146736 3.02 WINUP9.EXE NWUSER.EXE (vlm) 10/28/93 5072 1.02 WINUP9.EXE NWGDI.DLL (vlm) 11/19/93 81792 1.0 WINUP9.EXE NETWARE.DRV (netx)10/27/92 126144 2.02 WINUP9.EXE VTDA.386 10/1/93 6816 n/a WW0863.EXE (same as above) 12/31/93 6816 n/a WW0981.EXE VSHARE.386 1/11/94 14933 n/a WW1000.EXE Windows hangs while loading: 1.) For Windows 3.0, is your network card set to IRQ 2 or 9, 10 or higher? If it is, then you will need to install the VPICDA.386 patch (included in WINUP*.* in the NOVFILES file area on CompuServe). Copy VPICDA.386 into your Windows\SYSTEM directory, and edit your SYSTEM.INI, replacing the line "device=*vpicd" with "device=vpicda.386". NOTE: VPICDA.386 is not required for Windows 3.1, you should specify "device=*vpicd" instead. Using VPICDA.386 with Windows 3.11 can cause severe problems. 2.) Try loading Windows with a command-line parameter of /D:XSFV (e.g., WIN /D:XSFV). Each of the letters following the /D: are equivalent to placing the following statements under the [386Enh] section header in SYSTEM.INI, one time only: X -> EMMExclude=A000-EFFF S -> SystemRomBreakpoint=OFF F -> 32BitDiskAccess=OFF V -> VirtualHDIrq=OFF If Windows now works, use a process of elimination to determine which of the parameters was the key to your success. WIN /D:X is most often the solution to these types of problems, which indicates that the shared RAM area used by your network adapter is not properly excluded from your memory manager, or the Windows internal memory manager. For Windows internal memory manager, you exclude this memory range with an EMMExclude=xxxx-xxxx statement under the [386Enh] section header of your SYSTEM.INI. If you are unsure of this range, use EMMExclude=A000- FFFF while troubleshooting. As an example, to exclude a 16KB range of memory at segment D000h, you would specify EMMExclude=D000-D3FF. For the Microsoft EMM386.EXE memory manager, use a /X=xxxx-xxxx parameter to tell it what range of memory to exclude for your network card. For the DR-DOS EMM386.SYS memory manager, use a /E=xxxx-xxxx parameter to tell it what range of memory to exclude for your network card. Disabling 32-bit disk access (WIN /D:F) has been necessary for getting Windows to load properly on some systems using the new NetWare VLM drivers. 3.) Are you loading MS-DOS SHARE or running MS-DOS 4 (DOS 4 automatically loads SHARE if you have a hard disk larger than 32MB)? If you can avoid loading SHARE, do so. If you cannot, be sure to load SHARE before IPX and NETX, and avoid specifying more than FILE HANDLES = 127 in the NET.CFG file. Additionally, a Windows based replacement for SHARE.EXE, called VSHARE.386, is available from Microsoft as part of a patch file called WW1000.EXE. Instead of loading SHARE.EXE from DOS, VSHARE.386 is loaded by a "device=vshare.386" statement in the [386Enh] section of SYSTEM.INI. 4.) There are conflicts between some LAN card drivers, most notably the IBM LAN Support drivers for Token Ring, and the "*vnetbios" driver supplied with Windows. If you can use the NetWare drivers that talk directly to the Token Ring adapter (TOKWS.EXE in NOVLIB Library 6), this should work. Otherwise, do not include "*vnetbios" on the "network=" line under the [386Enh] section header of your SYSTEM.INI file, and avoid running any applications that use NETBIOS under Windows. 5.) If using IBM LAN Support, be sure that you are using VIPX.386 v1.15 or later. In the SYSTEM.INI file, you also need to let VIPX.386 know what IRQ your network card is using to prevent possible conflicts. This is done by creating/updating a [VIPX] section in SYSTEM.INI, and including a VirtualizeIRQx=TRUE statement, where "x" is the IRQ that is being used by the network adapter. Valid values for this IRQ are 2 thru F, and are specified in hexidecimal notation (A = 10, F = 15). 6.) Are you loading SuperStor 2.0, a disk compression device driver? There is a deadlock problem between NETX v3.26 and SuperStor 2.0 under Windows. As a temporary work-around, use the NETX v3.22 shell and contact the software manufacturer for other possible work-arounds. 7.) There could be an interrupt or I/O conflict between your network card, and Windows searching your COM ports for a mouse. These are the default COM port interrupt (IRQ) & I/O assignments: COM1 = IRQ 4, I/O 3F8h COM2 = IRQ 3, I/O 2F8h COM3 = IRQ 4, I/O 2E8h COM4 = IRQ 3, I/O 2E0h (NOTE: On IBM PS/2s, the settings for COM3 or COM4 are different.) Windows looks for a serial mouse starting at the highest numbered COM port in your system. So, if a serial mouse is attached to COM1 (IRQ 4), and your network adapter is configured for IRQ 3, when Windows searches for a mouse on COM2, using IRQ 3, this may disrupt the network connection. In the [386Enh] section header of SYSTEM.INI, you can specify COM#Irq=-1 to disable a particular port. For example, specify COM2Irq=-1 to disable COM2. You could also specify MaxCOMPort=2 under the [386Enh] section header to ensure that COM3 and COM4 are not being used. COM4 may sometimes conflict with Arcnet boards configured for I/O address 2E0h. 8.) Are you using an NE3200 32-bit EISA network adapter, or an OEM version of this adapter, such as the Intel EtherExpress/32? If so, in the NET.CFG file, under the "LINK DRIVER" section for this adapter, include an indented statement reading "DOUBLE BUFFER". 9.) If you are using the VLMs, try disabling packet burst, by putting a PB BUFFERS = 0 statement in your NET.CFG file. If you do not encounter problems with this configuration change, then investigate Novell's packet burst updates for 3.11, 3.12 and 4.01. (PBURST.EXE in NOVLIB Library 5.) System Hang-ups running RCONSOLE or other IPX/SPX applications under Windows: 1.) Verify that you have all of the latest drivers for running IPX/SPX under Windows. A minimum version level of IPX v3.10 or IPXODI v2.10 is required, with IPX ODI drivers preferred. For Windows in 386 Enhanced Mode, make sure that you have VIPX.386 v1.18 or higher. (Use the NetWare VERSION utility to run against VIPX.386 to determine the version.) Make sure that you do not have duplicate copies of VIPX.386 elsewhere in your path. In particular, check both the Windows and Windows\SYSTEM directories for duplicates. Furthermore, ensure that VIPX.386 is included in the "network=" statement under the [386Enh] section header of your SYSTEM.INI. For Windows in Standard Mode, make sure that TBMI2.COM is loaded before going into Windows, but this will not be sufficient for many IPX/SPX applications. 2.) If you are running NETX v3.26 or lower, place the statement GET LOCAL TARGET STACKS = 10 in your NET.CFG (or SHELL.CFG) file to allocate additional stacks for IPX/SPX multi-tasking. 3.) For RCONSOLE, if all servers do not show up in the display, you need RCONSOLE v2.9 or higher, which is currently available for download from CompuServe/NetWire as RCNSLE.EXE in NOVLIB Library 4. System Hang-ups running NETBIOS applications under Windows: 1.) Follow the same guidelines as described for running IPX/SPX applications under Windows above. 2.) Include a statement "TimerCriticalSection=10000" under the [386Enh] section header of SYSTEM.INI. This statement will help prevent deadlocks and re-entrancy problems associated when network activity is generated from a timer interrupt. Cannot locate NETWARE.DLL error when loading NetWare Tools or another application: 1.) See the "Recommendations for ALL Systems" section. There is no NETWARE.DLL, it is actually NETWARE.DRV, which is either not specified as "network.drv=netware.drv" under the [boot] section of SYSTEM.INI, or the NETWARE.DRV file is corrupt. Remote Boot PCs cannot find WINA20.386: 1.) WINA20.386 is a DOS 5 file that is required for running Windows 3.0 in enhanced mode with DOS=HIGH in the CONFIG.SYS. (It is supposedly no longer used by Windows 3.1.) Windows looks for WINA20.386 when it is loading in the root of the boot drive *UNLESS* you include SWITCHES=/W in your CONFIG.SYS file, and specify "device=d:\path\WINA20.386" under the [386Enh] section header of SYSTEM.INI to tell Windows where to find this driver. Remote Boot PCs cannot find EMM386.EXE: 1.) If you are using the Microsoft EMM386.EXE device driver to provide expanded memory emulation, then be aware that Windows needs to reload EMM386.EXE when Windows is started to load a virtual device driver for upper memory management in 386 enhanced mode. Windows looks for EMM386.EXE in the drive/directory that it was loaded from in CONFIG.SYS. If you need to specify an alternate path, include a /y=d:\path\EMM386.EXE parameter when loading EMM386.EXE in CONFIG.SYS. This path should be a path that will be valid when Windows is later started. Remote Boot PCs running QEMM v6.0x will not run Windows in enhanced mode: 1.) Similar to the EMM386 issue above, if you are running QEMM v6.0x, several files need to be reloaded when Windows v3.x is being initialized. These files are WINHIRAM.VXD and WINSTLTH.VXD. Windows looks for these files in the drive/directory that QEMM was loaded from in CONFIG.SYS. If you need to specify an alternate path, include a VXDDIR=d:\path parameter when loading QEMM in CONFIG.SYS. This path should be a path that will be valid when Windows is later started. Broadcast Messages do not display when in Windows applications: 1.) Verify that NWPOPUP.EXE is included in the "load=" statement of your WIN.INI file. 2.) In the Windows Control Panel, Network Options, ensure that the "Messages Enabled" button is clicked. 3.) Older versions of NWPOPUP.EXE cannot be used with newer versions of NETWARE.DRV (and vice versa). If v2.02 or higher of either of these files is in use (run the NetWare VERSION.EXE utility to determine versions), then both must be at least at v2.02 in order for NWPOPUP.EXE to process broadcast messages properly. 4.) See the "Recommendations for ALL Systems" section. Broadcast Messages lock up Windows: 1.) See the "Recommendations for ALL Systems" section. In particular, focus on the GET LOCAL TARGET STACKS statement that should be placed in your NET.CFG (or SHELL.CFG) file. It is recommended that you upgrade to NETX v3.31 or higher to avoid this problem. Ensure that this statement is echoed to the screen when IPX or IPXODI is loaded. 2.) To verify that broadcast messages are indeed related to the problem, you may wish to experiment with disabling these messages through the "Network" option in the Windows Control Panel. DOS DIR Command Shows No Files when used on Network Drives: 1.) See the "Recommendations for ALL Systems" section. In particular, focus on the GET LOCAL TARGET STACKS statement that should be placed in your NET.CFG (or SHELL.CFG) file. It is recommended that you upgrade to NETX v3.31 or higher to avoid this problem. Ensure that this statement is echoed to the screen when IPX or IPXODI is loaded. Windows hangs when opening a DOS Window or DOS application: 1.) Make sure that you have the NetWare drivers for Windows loaded: "network.drv=netware.drv" under the [boot] section of SYSTEM.INI, and for 386 enhanced mode, "network.drv=vnetware.386" (*vnetbios & vipx.386 may also be specified in this command) under the [386Enh] section of SYSTEM.INI. 2.) The *vnetbios driver can cause some problems with some current LAN card drivers, especially the IBM LAN Support drivers. If you are not using any NETBIOS applications, then you may be better off leaving *vnetbios out of "network=" statement under the [386Enh] section header of SYSTEM.INI. If you are using NETBIOS and the IBM LAN Support drivers, then you may want to consider using the native Token Ring drivers in TOKWS.EXE in NOVLIB Library 6 on CompuServe. 3.) For Windows 3.0, is your network card set to IRQ 2 or 9, 10 or higher? If it is, then you will need to install the VPICDA.386 patch (included in WINUP*.ZIP in NOVLIB on CompuServe). Copy VPICDA.386 into your Windows\SYSTEM directory, and edit your SYSTEM.INI, replacing the line "device=*vpicd" with "device=vpicda.386". NOTE: VPICDA.386 is not required for Windows 3.1, you should specify "device=*vpicd" instead. 4.) If using IBM LAN Support, be sure that you are using VIPX.386 v1.15 or later. In the SYSTEM.INI file, you also need to let VIPX.386 know what IRQ your network card is using to prevent possible conflicts. This is done by creating/updating a [VIPX] section in SYSTEM.INI, and including a VirtualizeIRQx=TRUE statement, where "x" is the IRQ that is being used by the network adapter. Valid values for this IRQ are 2 thru F, and are specified in hexidecimal notation (A = 10, F = 15). 5.) You may be running out of file handles. Increase the value specified in the FILE HANDLES statement in your NET.CFG (or SHELL.CFG) file. 6.) You may be experiencing swap file corruption. Refer to the section entitled "Controlling Windows Swap Files" to ensure that swap files are being created in the correct locations. (If you are swapping to the network, swap files must be stored in unique directories.) 7.) A TSR that you are running may require that you specify "TimerCriticalSection=10000" under the [386Enh] section header of your SYSTEM.INI Windows locks up during operation with the "Black Screen of Death (BSOD)": The BSOD is a term of endearment for Windows locking up with nothing but a blank screen and blinking cursor, or with the user being dropped out of Windows completely and left at a DOS prompt. Several different BSOD problems have been isolated, which are outlined below. In all cases, in addition to checking the possible solutions listed below, it may be prudent to check to see if Novell has released an updated version of VIPX.386 (this would most likely be part of a file named WINUP*.EXE or VPX*.EXE), as Novell periodically releases updates to this driver.. Additionally, the *vnetbios driver can cause some problems with some current LAN card drivers, especially the IBM LAN Support drivers. If you are not using any NETBIOS applications, then you may be better off leaving *vnetbios out of "network=" statement under the [386Enh] section header of SYSTEM.INI. If you are using NETBIOS and the IBM LAN Support drivers, then you may want to consider using the native Token Ring drivers in TOKWS.EXE in NOVLIB Library 6 on CompuServe. If using IBM LAN Support, be sure that you are using VIPX.386 v1.15 or later. In the SYSTEM.INI file, you also need to let VIPX.386 know what IRQ your network card is using to prevent possible conflicts. This is done by creating/updating a [VIPX] section in SYSTEM.INI, and including a VirtualizeIRQx=TRUE statement, where "x" is the IRQ that is being used by the network adapter. Valid values for this IRQ are 2 thru F, and are specified in hexidecimal notation (A = 10, F = 15). 1.) Lock up occurs when opening a new DOS application: a.) See "Windows hangs when opening a DOS Window or DOS application" above. 2.) Lock up occurs during regular operation: a.) Problems in processing NetWare broadcast messages can trigger this problem under certain conditions. See "Broadcast Messages Lock Up Windows" above. b.) IPX/SPX applications can generate these types of lockups with older NetWare drivers. See "System Hang-ups running RCONSOLE or other IPX/SPX applications under Windows" above. c.) If you are using the Windows Net-Library (NIK) for Microsoft SQL Server, then there is an updated version of DBMSSPX3.DLL available for download in the MSSQL forum on CompuServe which addresses BSOD problems with this application. The current filename is SPXNL.ZIP in Library 8 of the MSSQL forum. "Cannot Find NETWARE3.DRV or NETWARE4.DRV" Error Starting WordPerfect for Windows 6.0: 1.) WPWin is getting confused by a "Multinet=NetWare3" or "Multinet=NetWare4" statement under the [network] section of SYSTEM.INI. Change this statement to "Multinet=NetWare". This error is generally specific to Windows for Workgroups configurations. "Cannot find NWGDI.DLL" Error Starting Windows 1.) If you are using the VLM requester, this indicates that the NWGDI.DLL driver cannot be found in the Windows system directory. This driver can be found in the WINUP9.EXE file referenced in the "latest versions" section of this document. 2.) If you are using the NETX shell, this indicates that you are using the wrong version of NETWARE.DRV. v2.x of NETWARE.DRV should be used with NETX, and v3.x should only be used with the VLM requester. "NWDRV-3.00-00: The NetWare VLM is not loaded or not configured correctly. Disable Network?" Error Starting Windows 1.) This indicates that either no NetWare shell is loaded, or you are trying to use the NETX shell with the VLM version of the NETWARE.DRV file.v2.x of NETWARE.DRV should be used with NETX, and v3.x should only be used with the VLM requester. "NWDRV-3.00-30: Unable to load the unicode tables" Error Starting Windows 1.) This indicates that you are using the VLMs with the VLM version of NETWARE.DRV, and NETWARE.DRV was unable to locate the Unicode tables that it requires. The Unicode tables are normally installed in an NLS subdirectory beneath the Windows directory. An American English system requires only these files in the NLS directory: UNI_COL.001 UNI_NON.001 1252_UNI.001 UNI_1252.001 437_UNI.001 UNI_437.001 Other languages may require different tables, based on the code page settings in CONFIG.SYS and/or the language specified in the NWLANGUAGE environmental variable. "NWDRV-3.00-20: There was a problem loading or executing the NetWare Directory Support Libraries. All NDS functions are disabled." Error Starting Windows 1.) See the description for the similar error "NWDRV-3.00- 30" above. 2.) In order for NDS functions to be supported, the following DLLs are required: NWLOCALE.DLL NWCALLS.DLL NWNET.DLL Ensure that these files can be found in the Windows or Windows System directory. How do I update to IPX.COM v3.10?: 1.) Note that Novell has discontinued support for the linked version of IPX in recent releases of the NetWare Windows drivers (specifically VIPX.386). If at all possible, upgrade to an ODI version of your LAN card driver. 2.) If you installed Windows 3.1 for a Novell network, it should have copied an IPX.OBJ file to your Windows\SYSTEM directory. Copy this file to your WSGEN or SHGEN diskette, and re- run the WSGEN or SHGEN procedure to create an updated IPX. Now might be a good time to consider migrating to the IPX ODI drivers, which do not require this generating process, and are generally more up-to-date, as Novell is no longer certifying new drivers for the linkable IPX.COM. The IPX ODI drivers are included in the DOSUP*.* file in the NOVFILES file area on CompuServe/NetWire. Windows is very slow while loading: 1.) This is probably due to Windows creating a temporary swap file when loading, possibly to a network drive. Under NetWare 2.x, this process is much slower than with NetWare 3.x. See "Controlling Windows Swap Files" above for more information. 2.) If you are using the VLMs, try disabling packet burst, by putting a PB BUFFERS = 0 statement in your NET.CFG file. If you do not encounter problems with this configuration change, then investigate Novell's packet burst updates for 3.11, 3.12 and 4.01. (PBURST.EXE in NOVLIB Library 5.) Printing to a NetWare Print Queue results in 65,535 copies requested: 1.) This is a problem with the NE3200 EISA network adapter driver. In the NET.CFG file, under the "LINK DRIVER NE3200" section, include a "Double Buffer" statement. Note that there are a number of 32-bit EISA adapters that are OEM versions of the NE3200, including the Intel EtherExpress/32. Controlling Windows Swap Files: 1.) The following statements under the [386Enh] section header of SYSTEM.INI control the creation and placement of Windows temporary swap files in 386 enhanced mode: Paging=Off (disables paging) MaxPagingFileSize=xxxx (max size of temporary swap file in KB) PagingDrive=d (paging files will be placed in the root of this drive) PagingFile=d:\path\SWAPFILE (Windows 3.1 only: name to use for swap file, overrides PagingDrive entry) 2.) The following statement under the [NonWindowsApp] section of SYSTEM.INI controls the placement of swap files created when switching between DOS applications in Windows Standard mode: SwapDisk=c:\path If this path is not specified, then Windows will default to the directory pointed to by the TEMP DOS environmental variable (which many Windows applications also use for controlling where they create temporary files), or the root directory of your first hard disk if the TEMP variable is not defined. 3.) The following statements under the [386Enh] section header of SYSTEM.INI control the location of permanent swap files (Windows 3.1 Only): PermSwapDOSDrive=c (drive letter) PermSwapSizeK=xxxx (desired size of permanent swap file) Accessing more than 3 network printers from Windows: 1.) This is only possible using the VLMs (not NETX). 2.) In the NET.CFG file, add the following line to the "NetWare DOS Requester" section: NETWORK PRINTERS = 9 (The default is 3.) 3.) Use the NWUSER utility to make captures for connections beyond LPT3. (NetWare 3.x versions of CAPTURE are limited to LPT1 thru LPT3.) 4.) Under the [ports] section of your WIN.INI file include lines for these additional printers so that Windows will allow them to be used: LPT4:= LPT5:= LPT6:= LPT7:= LPT8:= LPT9:= Using NWUSER to set the CAPTURE timeout value results in large timeout values: 1.) There is a bug fixed by NETWARE.DRV v3.02 which caused timeout values to be set incorrectly by the NWUSER utility. (Typically timeout values would be off by a factor of 18.) Loading NetWare Windows Drivers when not attached to network displays a warning message that the network is not present: 1.) Specify "NetWarn=0" under the [windows] section of your WIN.INI file, which tells Windows not to warn you about loading network drivers when no network is present, if you wish to disable this warning. Printing to a Local Printer locks the system or kills the network connection: 1.) Using I/O address 360h on many network adapters can conflict wit LPT1 which is often at I/O 378h (NE2000 Ethernet cards have a 20h byte I/O address range). 2.) In your NET.CFG file, include a LOCAL PRINTERS = X statement, where X is the number of the highest LPT port in your system. Garbage when printing from Windows to a network printer: 1.) Are you running PSERVER? If you are, then you need to be running PSERVER v1.22 or later. PSERV6.EXE can be downloaded from NOVLIB Library 6 on CompuServe/NetWire. (Browse on PSERV*.* to find the latest version.) 2.) What is your CAPTURE statement that you execute before going into Windows? You need to specify the NT (no tab expansion) flag, and I recommend a timeout of at least 60 seconds (TI=60). For PostScript printers, NB (no banner) and NFF (no form feed) are also necessary. NA (no autoendcap) is also required in some Windows configurations. The NA flag will cause you some problems if you are printing to LPTx.OS2 (or LPTx.DOS in Windows 3.1) instead of LPTx. While previous recommendations were to print to LPTx.OS2, these recommendations have been superseded because of updated Novell drivers. If you are using all Windows applications, you should be able to set TI=0 to disable the timeout feature, as it is not necessary if applications print through the standard Windows APIs. NETX v3.26 has a bug in handling CAPTURE timeout values under some configurations when running with the IPX ODI drivers. Instead of the timeout occurring after an xx second pause in printing, the timeout occurs xx seconds after printing begins, which can cause considerable printing problems for large print jobs. NETX v3.31 and later address this problem. 3.) In the Windows Control Panel/Printers/Configure menu, disable the print manager if it is not already disabled. (Since NetWare print jobs are spooled to disk anyway, using the print manager when spooling to a network printer is redundant and can slow things down.) 4.) Make sure that you have the latest NetWare drivers for Windows. For Windows 3.1, the drivers that ship with the product are satisfactory. For Windows 3.0, you need VNETWARE.386 v2.0, the version that is included in the WINUP*.* file in the NOVFILES file area on CompuServe/NetWire. 5.) Type CAPTURE SHOW in a DOS Window after going into Windows, and make sure that these settings are the same as what were set before going into Windows. A Windows "permanent list" setting can override the CAPTURE that you set before going into Windows. Check the [network] section of your WIN.INI and delete any statements that reference print captures to avoid confusion. 6.) When all else fails, try connecting the printer to the workstation directly to verify that this is indeed a network problem. 7.) Are you running RPRINTER on a workstation running Windows in enhanced mode? If so, see the "RPRINTER and Windows" section of this document. DOS Environment Missing or Corrupt in DOS windows: 1.) Make sure that you have the NetWare drivers for Windows loaded: "network.drv=netware.drv" under the [boot] section of SYSTEM.INI, and for 386 enhanced mode, "network.drv=vnetware.386" (*vnetbios & vipx.386 may also be specified in this command) under the [386Enh] section of SYSTEM.INI. 2.) Verify that your NetWare drivers are up to date. Review "Recommendations for ALL systems" in this document. Changing directories on a network drive in one window affects all windows: 1.) If you have NWShareHandles=TRUE in the [NetWare] section of your WIN.INI file, then this is what is causing the problem. 2.) If you have a TASK MODE = statement in your NET.CFG (or SHELL.CFG) file, then this is what is causing the problem. 3.) If you are using the VLM drivers, then v2.02 and higher of VNETWARE.386 address this problem. Problems Retrieving Files from Network Drives with Microsoft Word for Windows 1.) Include the statement "NovellNet=Yes" in the [Microsoft Word] section of your WIN.INI file. Problems Saving Files on Network Drives with Microsoft Word for Windows 1.) READ, WRITE, CREATE and DELETE NetWare trustee rights are necessary to save a file that is initially being created. To replace an existing file also requires MODIFY trustee rights. Problems running Windows in Enhanced Mode with Thomas Conrad Token Ring Cards 1.) When using the TCTOKSH ODI driver, in the NET.CFG file, under the "LINK DRIVER TCTOKSH" section, include a "NON_VDS" statement. RPRINTER and Windows: 1.) Third party alternatives may be the best solution. Alternatives include hardware based solutions like network cards installed in laser printers, as well as the Castelle LanPress and Intel NetPort. Software solutions like LanSpool from Intel or I-Queue! Server from Infinite Technologies are other options. I-Queue! Server (IQS) from Infinite Technologies is an additional software based print server solution that is compatible with Windows. In addition to providing Windows compatibility, IQS has also been shown to prevent hair loss, primarily the type that occurs when you're pulling your hair out trying to make RPRINTER work. A 30-day trial version of I-Queue! Server can be downloaded under the filename IQS.ZIP in Library 4 of the NOVVEN forum on CompuServe. Or call Infinite Technologies at 410-363-1097 for additional information. (A subtle plug for my own company. ) If you want to try RPRINTER, you can also experiment with the following suggestions. 2.) Run Windows in Standard Mode (WIN /S) on PCs that are running RPRINTER. 3.) Disable the Windows print manager. 4.) Try increasing the SPX timeout values specified in your NET.CFG (or SHELL.CFG). For example: SPX ABORT TIMEOUT = 4000 SPX LISTEN TIMEOUT = 2500 5.) If you are using a PS/2 Model 56 or similar system, run the Reference Diskette, and ensure that DMA Arbitration is disabled. 6.) With a newer version of RPRINTER (such as the one in PSERV6.EXE in the NOVLIB Library), try using the -P parameter for polled operation. 7.) Review "Recommendations for ALL Systems" to ensure that you have the latest drivers and proper configuration support. Running Windows 3.1 on a non-dedicated NetWare 2.x File Server 1.) This is NOT possible. The NetWare 2.x operating system requires all available extended memory and exclusive control of protected mode operations. Windows Application no longer runs after flagging the executable file Execute Only 1.) The execute-only attribute will not work with any executable files that use internal overlays, which is the inherent design of all Windows applications. You CANNOT use the execute-only attribute with Windows applications. Option for Changing Drives and Printers Built into NetWare Drivers There is an option built into NETWARE.DRV that gives you hot-key access to a dialog that allows you to change drive mappings, print queue assignments, and attach/detach to other servers in your network. Under the [options] section of your NETWARE.INI file, include a statement "NetWareHotKey=1". Restart Windows and press F6. Any time you press F6, it will pop-up a selection menu that gives you access to a menu of NetWare functions. Do not minimize this window or switch away from it while active, or the application that you popped this window up over will no longer be able to receive keystrokes. Where to Go For More Information "Running Windows on NetWare" by Stephen Saxon from M&T Books "Networking Windows: NetWare Edition" by Howard Marks, Kristin Marks and Rick Segal from Sams Books "Microsoft Windows Resource Kit" from Microsoft "Windows 3.1 Secrets" by Brian Livingston "NetWare Power Tools for Windows" by Charles Rose from Bantam Books NOVCLIENT Section 6 in the NetWire Family of Forums on CompuServe +------------------------------------------------------------------+ | Compiled by Brett Warthen (Infinite Technologies). | | | | Address comments via e-mail... | | | | MHS: Brett @ Infinite (via CSERVE or NHUB) | | CompuServe: >MHS:Brett@Infinite | | (or 76704,63 in NOVVEN Sec 4 or NOVB Sec 15) | | Internet: Brett@Infinite.mhs.compuserve.com | | FAX: +1-410-363-3779 | | Others: > NUL | | | | For Infinite Technologies Product Information, call 1-800-678- | | 1097 or 410-363-1097. | | | +------------------------------------------------------------------+ Special thanks to all of those who participate and contribute in the NetWire forums on CompuServe, including: Jimmy Wright, Novell Scott Christensen, Novell Sandra Duncan, Novell Jon Hunt, Novell Mickey, Dave, Andy, Deb, Rich, Dennis, Peter, Jim, Brad, etc. on NetWire Charles Rose, Author "NetWare Power Tools for Windows", from Bantam Books (1-800-223-6834 x9479 to order) Stephen Saxon, Author "Running Windows on NetWare" on M&T Books (1-800-533-4372 to order) Howard Marks, Co-Author "Networking Windows: NetWare Edition" on Sams Books Rick Smith, Synergy Computing Tom Berdan Greg McGovern David Chamberlain Alan Woolfson Barry St. John Peter O'Rourke Peter Hauptmanns Michael Hader Jim Reese ...and the original cast & crew of Gilligan's Island, for their inspiration...