VOICE Home Page: http://www.os2voice.org
Newsletter Index
< Previous Page | Next Page >
Feature Index
|
VOICE Home Page: http://www.os2voice.org |
July 2004
Newsletter Index
|
| By Thomas Klein © July 2004 |
Lately I was experiencing a minor problem with NVC on one of my machines. I was already used to having another machine with NVC that doesn't do the internet update at all (at least the install part) and believed that to be a configuration problem specific to that machine only. But with the second machine at the office starting to show errors or erratic behavior after the internet update, I began to suppose it to no longer be exceptional to myself... that machine was an AthlonXP 2200 with 256 megs RAM, an ATi Radeon 9200 (another 128 megs), IDE-only and eCS ran fast and stable like hell - out of the box with no additional fixes. The machine was built from scratch - thus brand new so to say - when I installed NVC 5.70 for OS/2 (the German version). All went well, including the NVC installation... until I did the first internet update.
After the reboot I had a message showing up telling me "some error has occurred" and I needed to reboot.
Gosh. I couldn't believe it - this darn program didn't even start to
work yet and was already complaining about errors! Fortunately, I knew that
message and that it would re-appear over and over. Fortunately, I knew
what to do as well: The simple solution to it was to run the
delnvc5.exe program in the nvc\bin subdirectory where NVC was
installed and select repair.
Okay - so far for the short story. But... during the last month I took some deep looks into what that internet update actually does. And that helped me to solve the ongoing problems on the other machine as well. I discovered that a lot of people seem to have similar problems with NVC and OS/2 (or eCS) when trying to search for information in the major newsgroups. Well, today, I'll try to provide a detailed how-to on some "common" NVC problems in eCS.
You might ask yourself why I am wasting my time with this article as there is the Norman support. Support you call it? Yeah. Great joke: I wrote three e-mails during four weeks to that so-called support, yet... no response.
My first e-mail included a description of the problems. My second mail included that description again, along with a kind request asking to at least tell me if that mail arrived at least. My third mail then included:
And what was the result? Still no reply.
I was used to not getting responses from the ".de" German support subsidiary while the ".com" support staff helped me... but now, there was no response from any team. Oh, by the way - my partner did sign up for the NAR program (Norman Authorized Reseller) and he didn't get any response from them as well. Now I'm sure that Norman either has severe problems with their mail servers or everything is treated as spam... or there's no one reading e-mails at all. Their products are indeed good, but their support quality seems to have decreased a lot since 2002 when I had a really fast and good response for another issue. Anyway. I'm through with them: I'm now fed up with waiting for responses in vain and instead do the troubleshooting myself.
When dealing with NVC problems, there are some files and directories that you'll have to rely upon:
The POPUPLOG.OS2 file with trap messages from "crashed" programs. According to what is mentioned in the XWorkplace online help, this file is always created automatically since Warp3 w/ FP 29. In this case, your CONFIG.SYS will show a line SUPPRESSPOPUPS=x with "x" being the drive letter where the POPUPLOG.OS2 file will be written to. It'll be always created in the root directory of the given drive.
A file called STARTUP.CMD which is located in the root of your system drive. Upon installation, NVC will add an entry to load ZLH.EXE, which is part of NVC's system tasks on OS/2 or eCS.
The NVC "base directory" - which is to say the directory it was installed to e.g., C:\NORMAN.
The boot and install subdirectories of your OS/2 directory e.g., C:\OS2\BOOT and C:\OS2\INSTALL.
A tool for listing and killing tasks (not just a window list) is required in some cases. In addition, a file manager and editor - both capable of running in VIO mode - are recommended tools for solving NVC update problems.
In some cases you might need to know how to access OS/2's (or eCS's) startup menu screen: This is done by pressing [Alt-F1] when the OS/2 or eCS string along with a white square (the "boot blob") is displayed on the upper left corner of your screen after the machine has started.
Let's first take a look at how that internet update of NVC actually works in order to understand what the possible causes and pitfalls in it are:
NVC downloads a set of files. These are the new versions of the scanning engine, some additional DLLs or the virus definition files.
The files are then stored with temporary names like 08akc7ef.TMP, but are already residing in the Norman subdirectories where they are supposed to replace their appropriate current versions.
To be able to replace files possibly currently in use by the
system, NVC then creates a control file used for the "locked files
system driver" IBMLANLK.SYS. This file is called NORMAN.LST and is
placed in the INSTALL subdirectory of your OS/2 directory (e.g.,
C:\OS2\INSTALL\NORMAN.LST).
It contains multiple single-line statements that mostly are MOVE
commands to rename a temporary file to its actual "real name", thus
replacing the existing version. Hopefully. ;)
In addition, it might contain a dosx ...nrmorb.exe /install command
that tells the locked files system driver to perform an automatic
reboot. The last line of that file is a delete command for NVC's "flag"
file as described in step #5 below.
NVC adds the locked files system driver IBMLANLK.SYS to your CONFIG.SYS along with a file name parameter for the control file (norman.lst).
NVC creates a zero-byte "flag" file called nupd.sem in the Norman base directory. As soon as ZLH.EXE (that system tasks of NVC launched via STARTUP.CMD) discovers this file, the message "you need to reboot" will be displayed.
Upon the next reboot, IBMLANLK.SYS will process the control file, remove itself from CONFIG.SYS and re-reboot automatically.
This is how it basically should work. In theory.
In practice however, there are many things that can go wrong. And according to Murphy's law, anything that can go wrong will do so. Perhaps not on every system, but at least on almost every system I have - with different symptoms and errors.
The first pitfall is the possible erratic behavior of the locked files system driver IBMLANLK.SYS. On my older machine at home, this darn thing simply does not work at all for any reason. Maybe there's no temporary space to process the file list or something. I don't know. All I know is that the IBMLANLK.SYS log file called IBMLSHST.LOG (in the \OS2\INSTALL directory) tells me that it was completed successfully... yet nothing was actually done: The temporary files remain, nothing was replaced and the flag file still remains. Thus, upon each and every boot ZLH.EXE (started by the appropriate line in STARTUP.CMD) tells me that I need to reboot to complete the update. Joke.
The second pitfall is that different updated modules of NVC seem to
crash or simply seem to have bugs. Take a look at your POPUPLOG.OS2 and
you might notice various entries of either NYMSE.EXE crashing with
REGISTRY.DLL or NVCSRV2.EXE crashing with NVCIOCTL.DLL. If any such bug
happens during the installation of updates... hm. One never knows what
comes out of it. Maybe some missing information in the OS/2 registry
files?
I can't tell for the exact reason. All I can do is tell you some tricks
for "living with NVC without letting it drive you nuts" (this is why I
called this article "NUTS", by the way).
Here are the symptoms I have experienced on my machines so far - notice that I run a german version of NVC, thus the exact message texts might differ. But I'm sure you'll be able to guess the meaning and match it to your localized version.
The following message appears:
"Norman Virus Control was installed or updated, but the computer needs to be restarted for the changes to take effect"
(Dialog shows a "reboot now" and a "reboot later" button.)
If you just ran the internet update, this is message is right. If you already know that you have problems with NVC on your machine, you should choose to reboot later, go to the OS2\INSTALL directory and save a copy of the NORMAN.LST (e.g., as norman.l$t) to be able to check its contents because it might get deleted during the locked files replacing process.
If that dialog appears at startup, it'll mean that the nupd.sem file
in the Norman base directory is still present although it should have
been deleted by the locked files system driver after the updates were
installed. So you're likely to have problems because the update process
didn't quite arrive at its last step. Check the subdirectories of the
Norman install directory (especially NVC\BIN and NVC\NSE) if there are
files left with the extension .TMP. The same applies for the \OS2\BOOT
directory where the NVC support driver NVCHOOK.SYS is installed. A
.TMP file here might indicate a
new version of that driver.
All
those .TMP files are updated files which were not installed. You can
then check the contents of the saved NORMAN.LST file to see what the
real names of the .TMP files are (thus the files they should replace)
and replace the old files manually. In order to do this, simply reboot
your system into a command prompt (press [Alt-F1] when the boot blob
appears, then [F2] from the boot menu) and use either a file manager or
rename them one by one. You might need to take notes here or send that
file to a printer by using copy norman.lst lpt1, for instance. My
personal solution to this task is to copy NORMAN.LST to a .CMD file
and edit the lines to make them usable as OS/2 commands. The MOVE commands require the target file to not
exist prior to their execution. Thus, duplicate each "move" line to read
"DEL" along with the target file name (and without quotes of
course). If you prefer, you can also do another MOVE instead of DEL to
save the existing files to a backuped version by using e.g., EX$
instead of .EXE if the file in quesiton is an executable. The actual
MOVE commands need to read the target file name without any drive
letter and colon in order to function properly. A line starting with
dosx needs to be noted and then removed from the .CMD file. That's it.
Simply run the .CMD file, enter the noted dosx command (if there
was one) which will cause the machine to reboot.
Here's an arbitrary example - let's assume NORMAN.LST to include the folllowing lines:
MOVE C:\NORMAN\NVC\BIN\4e67800.TMP C:\NORMAN\NVC\BIN\nvcod.exe MOVE C:\NORMAN\NVC\NSE\e5ff700.TMP C:\NORMAN\NVC\NSE\nvcbin.def MOVE C:\OS2\BOOT\8a56bcde.TMP C:\OS2\BOOT\nvchook.sys DOSX C:\NORMAN\NVC\BIN\NRMORB.EXE /INSTALL DEL C:\NORMAN\NUPD.SEM
In order to process those commands without saving previous file versions make it look like this:
DEL C:\NORMAN\NVC\BIN\nvcod.exe MOVE C:\NORMAN\NVC\BIN\4e67800.TMP \NORMAN\NVC\BIN\nvcod.exe DEL C:\NORMAN\NVC\NSE\nvcbin.def MOVE C:\NORMAN\NVC\NSE\e5ff700.TMP \NORMAN\NVC\NSE\nvcbin.def DEL C:\OS2\BOOT\nvchook.sys MOVE C:\OS2\BOOT\8a56bcde.TMP \OS2\BOOT\nvchook.sys DEL C:\NORMAN\NUPD.SEM
And in order to process these commands with saving previous file versions make it look like this:
MOVE C:\NORMAN\NVC\BIN\nvcod.exe \NORMAN\NVC\BIN\nvcod.ex$ MOVE C:\NORMAN\NVC\BIN\4e67800.TMP \NORMAN\NVC\BIN\nvcod.exe MOVE C:\NORMAN\NVC\NSE\nvcbin.def \NORMAN\NVC\NSE\nvcbin.de$ MOVE C:\NORMAN\NVC\NSE\e5ff700.TMP \NORMAN\NVC\NSE\nvcbin.def MOVE C:\OS2\BOOT\nvchook.sys \OS2\BOOT\nvchook.sy$ MOVE C:\OS2\BOOT\8a56bcde.TMP \OS2\BOOT\nvchook.sys DEL C:\NORMAN\NUPD.SEM
After the file was executed, remember to enter:
C:\NORMAN\NVC\BIN\NRMORB.EXE /INSTALL
Finally another suggestion: In order to simply get rid of that dialog without checking for any possible update problems, select to reboot later and delete the zero-byte nupd.sem file in the Norman base directory. That'll learn it! ;)
The following message appears on startup:
"The installation or update of Norman Virus Control could not be completed due to an unexpected error..."
(This dialog might only have a reboot button and will annoy you by staying on top of other windows.)
First get rid of it: If you have any task list facility installed (like the wxtask widget for XCenter/eCenter running), kill the task called zlh.exe to make it shut up and disappear.
Then - like described above - check for remaining updates in either
the NVC directories or the OS2\BOOT directory. Check if NORMAN.LST is
remaining in the OS2\INSTALL directory (in most cases with this
message, there'll be none). If you checked all of the possible symptoms
from the paragraph above, you can bring up the Utilities program of
NVC. On the first tab called components, check to see if there's any entry with a state other than installed.
In my case, the internet update entry showed registration error.
With any errors like this or NVC errors that you're unable to resolve
by other means described in here, try to fix it by running the
"delnvc5.exe" program, which is contained in the NVC\BIN subdirectory
of the Norman base directory. It will allow you to select between
repair and remove. Obviously, you then select repair and click the
continue button. Next, click the finish button. Then reboot your
machine to see if the problem's gone.
Opening a task will result in a "phone ring"-like sound; then the following message appears:
"An unexpected error has occurred in Norman Virus Control Module: NVCOD.EXE Location: common.c Timestamp: ... Error Code: ... Error text: Invalid module Note the above information before contacting support."
(This applies to both the Norman WPS context menu entries scan floppy or scan hard disk as well as opening a task from the task folder to use it with the on-demand scanner.)
If you click OK, the on-demand scanner will appear and everything seems to be okay. But once you click the SCAN button, it might simply close and disappear without scanning anything. In my first attempt to circumvent the problem, I deleted both tasks from NVC's task subfolder and opened the task editor to recreate them manually: Scan hard drives was specified to use C: and D: along with scan into archives and so on, while scan floppy was limited to drive A: but using the same optional parameters. I saved the new tasks and then opened them with the on-demand scanner:
The same problem happened again.
I then opened a command window, changed to NVC's BIN directory and ran nvcod.exe from commandline using the additional parameter C:\* D:\* (without the quotes). Magic! The on-demand scanner appeared without showing any error message and clicking on SCAN started the scan process without problems. I'm not sure about the cause of this problem but I suppose it to be some invalid parameter saving format by the task editor or a simple bug in the on-demand scanner.
Latest info: The last internet update I ran (on June 11th) downloaded updates for both the on-demand scanner as well as the commandline version. The problems described above are now gone!
The scan process simply terminates, without any message
No scan results screen is displayed and the log file does not provide additional information. On my system this happened during the first scan of my freshly-installed eCS 1.1 while scanning the entire hard disk drive where eCS was installed to.
I repeated the scan and tried to see at which point it "crashed." It seemed to happen while scanning a .jar file (in case you don't know what a .jar file is: This is something like a ZIP file that contains java applets and/or classes). I then re-ran the on-demand scanner manually and told it to only scan the directory which contains the .jar file in question along with its subdirectories (if any). And success:
The scanner showed me a possible infection of the .jar file and finished correctly.
Again, I can't tell you the actual cause of the initial misbehavior but
I suppose it to be some resource (allocation) problem: During the scan
of thousands of files and while processing a large compressed file, the
scanner found something and - as I think - was unable to allocate the
resources
required to display its message... or so. No idea. Anyway: To see if the
same situation applies for you, simply take a look at your \TCPIP\JAVA
directory. If the file DDNSSGUI.JAR is "a lot larger" than 1056028 bytes you might still have the "infected GA version" which contains a "html exploit".
There's a fix for this available at the eCS downloads page which contains a "cleaned" version of the JAR file.
After logging into the customer area of www.ecomstation.com search for the TCPIP fixpaks. There should be an entry called "TCP/IP 4.3x fixpack UNG2206 DDNSSGUI.JAR". This contains both a "cleaned" version of the .JAR file along with a short readme. Simply replace your infected DDNSSGUI.JAR with the unpacked new version and you're done.
If this error appears in other circumstances, it might be worth trying to check at which point it happens and then manually scan a smaller amount of files (by limiting the scan to the directory in question). Another idea would be to switch the logfile settings into detailed mode which will result in including the names of each file that was scanned. Maybe this helps in narrowing down the search for the file that causes the trouble.
The NVC objects folder "behaves strange or erratic" and/or objects are missing or when opening the "tasks" subfolder, the WPS locks up during "collecting objects".
In my case, this was solved when I had un-installed Candyfolder and
Candybars! Initially, I was unable to find out what caused the problem.
Then at some point, I had no need for Candybars on that machine anymore
and removed its WPS classes... and oops! The problem I had experienced
for so long was gone!
Again, I can't tell you the real cause. It seems like the WPS classes
on that machine had some inconsistency, either caused by Candybarz,
Candyfolders, NVC, or by myself removing something in a wrong way...
anyway: I know that Candybarz is able to handle exceptions but don't
know if this is available for WPS folders as well as for programs and I
also can't tell you how to do it (as I now have already removed
Candybarz).
General information on NVC internet updates
As I described above, some problems are not just caused by internet updates but sometimes also seem to become solved by them: NVC updates - like most of Antivirus software updates - not only contain newer virus/malware signatures but also updated versions of executables and/or drivers (= the scanning engine parts). NVC provides a nice way to check what was actually retrieved by an update (as long as your machine isn't too fast). Simply run the Utilities program of NVC by selecting the corresponding entry in the WPS context menu or via the NVC program folder object. On the first page, you'll find the components list, which provides a column named current state. As the updater continues to work in the background, you'll see how the state of some entries might change. This might take a while - a minute or so depending on your systems speed and load. It will change from unpack to copying and then installed (the exact term might however differ in the English version, it's only "guesswork" I'm doing here). Depending on whether the updater "flags" a reboot or not, the final state of installed might only be reached after a reboot.
Good to know that this way of checking exists - it may help finding out what is contained in an internet update of NVC.
That's it for NUTS - I hope you're able to benefit from my experiences in order to solve some of your possible issues with NVC at least. If you've found other solutions for NVC-related problems in OS/2 or eCS don't hesitate to drop me a note. I'll be pleased to post them to our tips editor or even the Norman support staff... ;-)
Feature Index
editor@os2voice.org
< Previous Page | Newsletter Index | Next Page >
VOICE Home Page: http://www.os2voice.org