WinBatch Tech Support Home

Database Search

If you can't find the information using the categories below, post a question over in our WinBatch Tech Support Forum.

TechHome

WinBatch
Networks - Servers
Logon Issues

Can't find the information you are looking for here? Then leave a message over on our WinBatch Tech Support Forum.

Winbatch in Netware Login Scripts Locking up Machines with McAfee AntiVirus

Keywords: 	 mcafee logon script locks

Question:

In Netware login scripts, I use the # for quickies. Small browser updates, make a quick icon, McAfee DATS, etc. The # means - halt the login script and wait for this program to end to continue on. The obvious advantage is that the program runs alone - less chance for conflict.

The @ is for larger programs - Office installs, major application rollouts. I use the @ sign because that means Run this program and continue the login script. So my program runs and checks the registry to see if itself has already run. If it hasn't, it waits for the login script to end (with a WinWaitClose("~Results")) and then pops up a big screen announcing the new app and giving the user to decline, help screens, etc. I cannot lock up a login script for 45 minutes while office 2000 installs - it messes up other stuff.

Using the following Netware login script: 

   #z:TestPro1.exe
   @z:TestPro2.exe
   @z:TestPro3.exe
   #z:TestPro4.exe
With this program, message box #1 came up as it should. Then the machine locked up (on Windows 98SE only). A Ctrl-Alt-Delete and the task manager reported #2 as not responding. I did an endtask - still locked. Now #3 is not responding. Another endtask and the message for program #4 came up and everything continued normally.

The only TSR we run at startup is McAfee (and Client32 - various flavors of version 3) .

Answer:

Based on what I am seeing on my test platform which is similar to yours, I pretty much have to rule this problem to be an environmental problem. There is most likely some software conflict, corrupted registry or other damage to the Win98SE image that is causing this problem. I have a fresh install of Win98SE and the Client32 v3.10 SP1 software that does not experience this problem at all. Some of the additional software that you have layered on in your image is most likely to be the culprit. I'll spend a little more time trying to identify what is causing the problem. I'm thinking about installing the REGMON utility on my test system to help identify which programs and device drivers have their claws on the registry at the time that the problem happens.

I installed REGMON to see what is being accessed in the registry at the time that the script is locking up.

I am launching compiled (small exe) scripts as follows: 

#TestPrg1.exe
@TestPrg2.exe
@TestPrg3.exe
#TestPrt4.exe
I occasionally still get a MPR.EXE hang while my login script is being processed. However, if MPR.EXE is not hung up then TestPrg3.exe always seems to be the one that gets hung. If I terminate that task then the other scripts run to completion. While either a script is hung or MPR.EXE is hung, I am finding that I cannot ALT+TAB to another window. I discovered this when I had REGMON running because I was able to ALT+TAB between REGMON and the login results window. I'm launching REGMON with "@REGMON" and that is followed by a PAUSE command in the login script that is used to allow REGMON to get fully started before any additional login script commands are executed.

Since ALT+TAB is disabled I tend to think that this is an operating system level problem and not a WinBatch problem. If it was just a single app that was hung due to an internal app problem then the whole system should not be frozen. However, if th app is dependent on some API function in the operating system and the OS goes out to lunch then the app may appear to be hung.

Each time that the test script gets hung up, it hangs while initializing itself. It *NEVER* gets to the point where it is able to process the actual WIL commands in the compiled script and I never get a DebugTrace() log file created for the script. The point at which the script hangs up varies with each particular run of the script. Some times the initialization of the compiled script runs nearly as far as what I see in the REGMON logs for the other scripts that run OK. In other cases, the initialization only gets in a few accesses to the registry and then the script gets hung up.

Does this description of the problem match what you are experiencing now? For the script that gets hung up on your systems, does a debug trace file get created showing an actual WIL statement for which the script got hung up or do you just not get a debug trace file at all?

Question (cont'd):

You are correct - when I was doing the testing, when the machines hung I would not even get a debug trace file. Since that was the first line in the code, I figured it couldn't be registry checks, but merely a Winbatch trying to initialize while another Winbatch (right before it) was checking the registry. If the ones before it just had message lines, or filechecks - NOT registry checking - all scripts work fine.

We are all on the same page, so now what? I am fearful the answer is I must change my entire methodology on how I deploy and track application distribution. That really puts a damper on my entire job function. I have built a Winbatch empire here and part of the foundation appears to be crumbling.... Please say it isn't so!!

Answer:

Anyway, here's what I'm learning about this problem:
  1. McAfee VirusShield is intimately involved in the problem. If I disable the "system scanning" functionality or if I simply disable the entry for VirusShield under the "HKLM,...RunServices" key (via MSCONFIG or REGEDIT) then the problem goes away.

  2. Even if McAfee VirusShield is running with the "system scanning" functionality enabled, I cannot duplicate the problem if the compiled scripts are located in "C:\" and are found by having "C:\" in the search path, e.g. login script just uses "@TestPrgX.exe" or "#TestPrgX.exe" to launch the scripts.
Since I can turn the problem off and back on again very reliably by disabling McAfee VirusShield I am going to have to rule this to be an environment/configuration problem that is being caused by your anti-virus software. The fact that the anti-virus software only interferes with the scripts (which read/write the registry) that are being run from a NetWare server via the login script for the very first login to the network after rebooting the workstation is a very unusual set of circumstances. However, this unusual set of conditions only serves to help the Network Associates tech support & development staff to identify why this is happening.

Please see if you can duplicate my testing results and let me know what your testing results are. Remember that when you try to launch the compiled scripts and you have them on the local hard drive then they must be explicitly referenced with path information or else they must be located on the search path before the copies of the compiled scripts that are located in the SYS:PUBLIC directory on your server. I'm attaching my test script. You can copy the .EXE file to 4 different names - TestPrg1.exe, TestPrg2.exe, TestPrg3.exe and TestPrg4.exe - as necessary. Please use this exact same script as I have compiled it. It was compiled as SMALL .EXE under WinBatch 99P.

Other Notes:

MPR.EXE is the Multiple Provider Router component of Win9x that allows multiple network clients to work simultaneously. This is important when you want to resolve a UNC name that could refer to either a LANMAN server & share, a NetWare server & volume or a NDS tree & object. I've been doing some research on problems related to MPR.EXE and there are literally thousands of Usenet postings related to this problem. Micro$oft has some tech support articles about it, too, although none of them has resulted in any truly positive results. Novell also has numerous references to MPR.EXE (and MPREXE - no dot ".") in their KB; all of their references appear to relate to older versions of Client32 on Win9x (mostly Win95). Based on what I've seen, MPR.EXE can go belly-up & die for reasons that are too numerous to enumerate in a single email. In most of the cases where MPR.EXE actually gives an IPF or GPF error the cause of the problem cane usually be found. The situations where MPR.EXE simply stops responding are the difficult ones that are caused by something else that is interfering with MPR.EXE.

Resolution:

Further research at Novell's support site provides additional evidence that pins McAfee as the culprit. In all cases where similar such problems occurred, the only solution was to either completely remove McAfee or else prevent it from starting up via the RunServices key and instead put it under the Run key or in the Startup folder. Numerous reports of files being held open and other strangeness associated with McAfee all points to you having the bad luck of having a bad version of McAfee installed.

For More Info:

Go to http://support.novell.com and then click on the "knowledge base" link. Search for "McAfee" and review the various technical documents that come up. Many of them require the removal or disabling of McAfee VirusShield to resolve the problems that are described. I get the feeling that the Novell tech support folks are *NOT* on good speaking terms with NAI right now regarding the McAfee anti-virus line of products.

Also, go to http://www.deja.com/home_ps.shtml and search on two keywords - "McAfee" and "NetWare" (don't use the logical operator "AND" in the search) and you will get a lot of hits regarding lockup/hangup problems during login and some hits regarding an inability to run programs from off of a NetWare server volume via the login script when using a Win9x workstation that has McAfee installed on it.

Then, of course, there is always the situation where you can easily turn the problem off and on by disabling/enabling the McAfee VirusShield software. Also, moving the compiled scripts to a local hard drive and making *SURE* that they are being run from the hard drive via the login script w/o any problems is another good diagnostic situation. If you can re-create these two situations in house then you can get a NAI engineer to come look at it.

Final Words:

Article ID:   W14471

Filename:   Winbatch in Netware Login Scripts and McAfee Issues.txt
File Created: 2000:05:31:11:08:50
Last Updated: 2000:05:31:11:08:50