Discussion: Problem using Winbatch scripts in Netware login script

Keywords:

Question:

I've got two Winbatch scripts that I'm trying to run inside of a Novell 4.x login script. They run fine if I only login once, but if two logins try to run the scripts I get an error on the second instance. While one script is running fine, the other gets an "Invalid Page Fault". The platform is Windows 95 OSR2. At first I had thought that it was an issue with me logging on as myself more than once, but we tried with other users logging in and running the scripts.
I have the script executables, and the WBDxxxxI.dll and WBOxxxxI.dll files in a directory that the user account has access to, and all the files are marked as read-only and shareable.

Help!! I have 500 customers to roll out a software install to, and I thought I would be able to do it with these scripts. So far it looks like it's a disaster...

Answer:

Expert #1:

Hmmm. Not a usual problem. A lot of installations do this all the time.

Hopefully someone might recognise this problem and provide a few clues. In the meantime I'll try to fill in bits and pieces of background info.

In *almost* all cases, a page fault error only occurs when a running WinBatch script is denied access to its EXE or DLL files. The general condition where this occurs is when a drive mapping to the spot where the EXE's and DLL's live is somehow unmapped.

(Please correct me if I am wrong, but its something like this) In Novell, before the logon a Z: drive is mapped to the Netware logon directory. If the exe's and DLLs are in the Netware logon directory and the script is running, and during the login process the Z: Drive is remapped to a different point while the WinBatch script is still running, generally a page fault results. The general solution is to put the EXE's on each workstation for this.

When Windows loads an exe or DLL it does not necessarily load the whole thing, and the page fault occurs as windows attempts to load some unloaded piece. On some machines, especially those with lots of memory and otherwise unoccupied, sometimes it managed to load all the DLL and exe and thus works, whileas on other more constrained workstations it crashes. Gets tricky to debug.

If the problem happens on lots of computers and other applications seem ok, that pretty much rules out one of my favorite victims, a bad network card.

Be sure to use the small model exe's along with the required DLLs for placement.

Also not that when WinBatch exe's start up they search the path for the DLLS. Even if the DLLs are in the same directory, there is a chance it is finding them elsewhwere - such as in the login directory or some other searchmapped drive.

If this other drive is unmapped...

However it seems the second script does not even get started. Crashes immediately. I'm not sure about that.

Another possible issue is that the Winbatch script launches and then the netware login script continues to execute. And something else in the script is causing problems.

Unfortunatly I'm not a real expert on Novell, but perhaps someone here can see what I am trying to do and let me know the correct way to do it. If your login script line read like...

	command.com /c start /w yourscript.exe

that in theory would force the login script to wait for the yourscript.exe module to complete execution. That might help.

Expert #2 Insights:

Sorry - already at home when I saw this. I do this ALL the time. Marty is right on the money - you must be continuing the login script and remapping Z: *after* the WinBatch starts. Be sure if you are changing the default mapping you put it at the TOP of the login script in the users container - and don't remap Z: higher up (if you include higher containers.) If Novell 3.x - well, be sure you map and then run the Winbatch, and don't remap in the personals.

For edification:

If Login script reads -

	@Z:Yourscript.exe

(Run script and continue on further down the line)

	#Z:Yourscript.exe

(Run script and wait for program to close)

I do this rather than get command.com and start.exe mixed up in there...

Now - some lessons learned this year by me.

Check the public directory for stray DLL files. Some yahoo copied their Windows System from 95A to public on a server. NT Winbatchs were not happy.
NT when mapping a drive like Z: to Public actually looks like a Map Root, whereas 95/98 does a regular map. I used to do things like:
```
	#Z:\Public\MyScript.exe
```
Which works fine on 95/98 - but NT couldn't find the file. That's why I just use Z: now - and both work fine.

BTW - I have sometimes had 6 or 7 different Winbatchs all kick off on top of each other updating client PC's at once for different apps. You have something weird going on. Good luck tracing it.

Expert #3 Insights:

We noticed that the problem was occurring when user login script was blank (null), which was causing netware to remap Z: while a winbatch was loading/initalizing from the system/container login script.

While the remap was occurring, winbatch got the "rug" yanked out from underneath it, and presto GPF...

Because varing machine/network speeds and resources, sometimes the timing worked for you or againist you. This burned up alot of resources to track down...

Lesson, never let netware decide what to apply for default script entries. If you want no user login script, add a "REMARK" line as the user login script.

If you place NO_DEFAULTS in the first NetWare script you stop any of the default scripts from processing.

Article ID:   W14163

Filename:   GPF using WB scripts in NW login script.txt

File Created: 2001:03:02:14:47:06

Last Updated: 2001:03:02:14:47:06

Database Search

TechHome

Discussion: Problem using Winbatch scripts in Netware login script

Question:

Answer:

Expert #2 Insights:

Expert #3 Insights: