PROBLEM: ARCserve Caused a General Protection Fault in Module DSHELL
EXPLANATION: The DSHELL error occurs during the installation of ARCserve.
It is most frequently seen when installing ARCserve on a
Netware 4.x file server. However, it can appear on a
Netware 3.1x file server as well.
RESOLUTION:
Installing to a NetWare 3.x file server:
1) DSHELL actually refers to a file called ASSETUP.DLL on the first
ARCserve installation disk. ASSETUP.DLL contains many routines
which communicate with NetWare. In many cases, the DSHELL errors
may occur due to the use of outdated network drivers on the workstation. Verify that the workstation is running IPX version 3.10 and NETX version 3.26 or later, or VLM.EXE version 1.1 or later. The versions being used can be displayed using the NetWare NVER utility.
2) The error may be caused by a problem with workstation disk access.
Run the DOS CHKDSK /F command or another disk repair utility.
Installing to a NetWare 4.x file server:
1) If installing to a NetWare 4.x server, the Bindery Context must be
set on the server. This can be accomplished by typing SET BINDERY
CONTEXT = <context> at the file server console. Once the context
has been set, the workstation must be logged into the server using
bindery emulation. This is done by using the /B parameter as follows:
LOGIN <login name> /B.
2) Make sure BIND.VLM is being loaded by checking the workstation's
NET.CFG file. This is the VLM that gives access to Bindery Emulation.
Typing VLM /D at the workstation will display the currently loaded VLMs.
Also, make sure that Bindery Emulation is enabled for the ORGANIZATION
to which ARCserve is going to be installed. This would be under the
same context previously set at the server.
3) In some cases, during the installation process, the ARCserve Job Queue
(AQ_<servername>) may become corrupt. This may have been caused by
the use of DS.NLM revision (290). Novell recommends that the (290)
revision of DS.NLM not be used. The latest version is available from
the CompuServe NOVFILES forum. If this occurs, the corrupted queue
must be deleted from the NDS before ARCserve is reinstalled.
NOTE: If the NDS determines an object to be "Unknown and Corrupt", it is
recommended that the NetWare 4.x NETADMIN utility be used to delete
the corrupted Job Queue. NWADMIN, the Windows NetWare 4.x
administration utility, may not be able to delete the corrupt queue.
This is due to character limitations of NWADMIN's graphical user
interface, which render it unable to see all non-NDS objects. In
any case, it is strongly recommended that the DSREPAIR utility be
run after deleting the Job Queue in this manner. Release 4.02 of
Novell NetWare ships with version 4.41 of the NETADMIN utility.
This version of NETADMIN has been shown to be incapable of deleting
bindery queues from the NDS. Cheyenne is presently pursuing the
issue with Novell; it will be addressed in a later release. The
only solution at this time is to use an earlier version of NETADMIN,
Click Backup icon, and the workstation hangs with an Hourglass
PROBLEM: When accessing Device Management, no devices are listed.
EXPLANATION: This problem occurs exclusively on the Windows workstation.
When ARCserve is running, and the tape device is properly
recognized and initialized by the system, (this can be
verified by checking the server console and verifying that
an ARCSERVE TAPE SERVER screen is present), then all devices
attached to the adapter should be displayed on the
workstation's Device Management screen. If nothing but
null symbols are displayed (circles with lines through them),
this indicates a communication or driver problem. This same
problem may cause the second condition listed above, that is,
when the Backup icon on the ARCserve Manager Quick Access
screen is clicked, the workstation hangs with an hourglass
displayed indefinitely.
In both cases, follow the steps below.
RESOLUTION:
1) Verify that the network drivers meet the following minimum requirements:
IPX = 3.10 or greater
IPXODI = 2.10 or greater
NETX.EXE = 3.26 or greater
VLM.EXE = 1.10 or greater
LSL.COM = 2.01 or greater
NOTE: The latest drivers may be obtained from CompuServe (GO NOVFILES).
2) Verify that a TSR called TBMI.COM or TBMI2.COM is NOT loaded on the
workstation. These files would normally be loaded from the AUTOEXEC.BAT. TBMI2 is intended for users running programs which use the IPX or SPX communications protocol from the DOS prompt in Windows (standard or real mode). TSRs running under DOS prompts in Windows Enhanced mode do not need TBMI2, since VIPX.386 will track IPX and SPX functions. If no DOS applications are being run in Standard mode that require IPX or SPX support, then neither of these programs are required.
3) When running Windows for Workgroups, if there is no frame type specified
in the workstation's PROTOCOL.INI file, the Device Management screen on
the workstation will display blank entries. If the workstation is
running Windows for Workgroups, please refer to document number 12010.
4) Verify that the VIPX.386 driver is present on the "NETWORK=" line in
the SYSTEM.INI file (in the \WINDOWS directory) under the [386Enh]
section. It should appear as follows:
network=*vnetbios,vnetware.386,vipx.386.
VIPX.386 (the Virtual IPX 386 Enhanced Mode VXD Driver) is required for
Windows to work correctly with the current IPX based protocol shells
for Windows 3.x. If the this Enhanced mode driver is not loaded, there
will be numerous other network connectivity problems. This driver
should always be loaded from the SYSTEM.INI file when using the Novell
client shells for Windows.
5) Make sure that the Windows SETUP.EXE program displays the network
shell version as "Novell NetWare (shell version 3.26 and above)".
6) Verify that the ARCserve versions running on the server and the
workstation are the same. If ARCserve has been updated recently,
verify that the Manager has been updated correctly. By default,
the ARCserve update programs only update the Manager directory
on the file server. If the Manager is running from a
workstation's local hard drive, then the update program must be
run twice. The version histories must be the same for the ARCserve
