Software installation failures - McAfee Virus Scan

Posted on 2005-05-11
Medium Priority
Last Modified: 2012-06-27
The McAfee chat line help gave me ring around the rosy on this one.

I have had the McAfee firewall and the anti-virus program on my Windows 98 system since  last October with no problems.  Yesterday, when I downloaded the routine updates, System File Checker reported that 4 VXD files dated 2003 had been replaced by older versions dated 2001.

mcutil.vxd -->
vshinit.vxd -->
mckml.vxd -->
vshield.vxd -->

I think som other files had older versions substituted also.

The McAfee chat help people kept asking for data from my system, which is hard to get because the McAfee windows don't have the normal minimize button.  So, my system kept locking up.  Three technicians later I was told there was another AV program on the system and that I must uninstall McAfee and every third party utility and start over with only McAfee.

I tried to explain that Norton Anti Virus and Norton Live Update were long gone, but that I still use Norton Utilities.  I also mentioned that an inactive version of Zone Alarm was on the system.

It was like talking to the wall with the last technician.  My impression was that the advice was coming from a manual.

It doesn't make sense to me that I could be using McAfee for several months and then all of a sudden it decides to be incompatible with stuff that isn't even on the system now.

My parting words to the technician were something like "Thanks, but I must now find another AV program from another company that doesn't have so many compatibility problems.  Goodbye".

Using Control Panel I uninstalled McAfee Virus Scan but left the Personal Firewall Plus on the system.

But, when I tried to reinstall the software from the CD, it kept hanging up with "Script Error - Line 4654 - Char 7 - Error Invalid Procedure Call or Argument - Code 0 - URL mcp://M:\VSC\ENU\VSOINS.UI::install.htm

I downloaded and ran the Microsoft script patch JS56MEN.EXE which responded that MS VBscript 5.6 was installed.

That didn't help, so I tried something that has worked before --> Copying the entire contents of the CD to the Desktop and running from there.  My reasoning there is that a read only CD would reject creation of temporary files on it.

This time the error was not identified, but each time I tried to restart the system and try again it wiped out the contents of VSC\ENU, even after setting attributes to Read Only.

By this time I am down on McAfee, but would like to do the installation just to see whether it will do subsequent updates correctly.

All comments are welcome, but I plan to award the points to the clearest, most understandable narrative that doesn't list a bunch of URLs to other sites.  I know how to use Google myself.

Question by:sysandprog
  • 30
  • 26
  • 4
  • +5
LVL 25

Assisted Solution

InteractiveMind earned 80 total points
ID: 13980459
Hello sysandprog,

Just so that we can eliminate malware, have you ran HiJackThis? (Or something such as Ad-Aware?).

I appreciate that it's unlikely that malware is directly screwing up your AV, but ultimately, it could be causing you some hassle which is leading to these other programs.

LVL 25

Expert Comment

ID: 13980472
Sorry, by "which is leading to these other programs.", I mean: "which is leading to these other problems."   :-)

Author Comment

ID: 14050221
HiJackThis did not help.

There appears to be a problem with one of the *.INF files, but Microsoft's suggested method for tracking it down is downright silly.

There should be a program that would validate all *.DLL files, all *.INF files, all *.VXD files and so on.  As it stands now, a human is supposed to hunt and peck thousands of items without knowing their true purpose, or whether they belong on the system at all.

I find it downright depressing that a Dutch STUDENT could come up with a tool like HiJackThis but Bill Gates with all his billions could not, or more likely, WOULD not.
Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.


Assisted Solution

nep1 earned 80 total points
ID: 14065691
After uninstalling McAfee, delete all of it's files and folders, and then remove all of it's registry key's before re-installing.
If you can't find a link which shows you the files and reg-keys to delete, I'll see if I can help!
LVL 24

Expert Comment

by:Mohammed Hamada
ID: 14069057
Try download Microsoft .Net framework :-
and check when you install it again, if you get the same error or something has changed.

Not sure if it's this link:-

But try this one also :-

And Something else, Have you tried to restore to an earlier point? using the scan reg command, in case you restore to a point and didn't help.

Try downloading and using this fix on safe mode if you can boot to safe mode.

Good Luck

Assisted Solution

computerfixins earned 80 total points
ID: 14070284
Might want to try going to add/remove and selecting modify instead of reinstalling?  Do a complete install from modify then uninstall.  Then one more install :)

Try shutting down any uneeded apps that might be running via task manager, espicially anything hp releated , printer assitant, etc(seems to trash)  <--long shot o.O

Otherwise i'd go the manaul root.  that nep suggested :)

Also i've seen Mslaugh.exe teekids.exe aka lovesan do this exact thing(speaking from experince).

Maybe post your process list from hijackthis log ?


Assisted Solution

dlongan earned 80 total points
ID: 14071899
I have had in the past to "manually remove" Symantec and or McAfee to get it to re-install correctly.

The following link is from McAfee's KB on how to manually remove Virus Scan.


You might want to search the KB for more specific ideas:


I know Symantec has some utilities to help do manual removals not sure if McAfee does.
LVL 39

Expert Comment

ID: 14074340

I'm trying to decipher that error you received:

Script Error - Line 4654 - Char 7
Error Invalid Procedure Call or Argument
Code 0
URL mcp://M:\VSC\ENU\VSOINS.UI::install.htm

I assume from the path that your CD-Rom Drive is the letter M: ?

I must confess that, up until now, I hadn't encountered a URL:MCP:// protocol before, so I entered "url mcp://[drive:" into google.
The only apparently useful hit I got was this one:
where "cscheune" (Posted: Fri Jun 04, 2004 3:28 am) refers to "PROTOCOL" in reference to  a url protocol MCP://

The suggestions there all surround Windows XP, updating oleaut32.dll, and updating VBScript, so it's otherwise pretty useless.

My impression is that this protocol is something used by McAfee in a similar way to how Windows Help .CHM pages are called, eg:
After all, .CHM files allow you to open control panel applets and program .exe's from links, and this is facilitated through the activeX controls "hhctrl.ocx", "hhopen.ocx", etc which contain all the dialogs, icons, bitmaps, menu's and text strings to display Windows Help as intended.

Of course, there are some of the Windows security updates that patched up weakneses whereby "blah, blah, could compromise security, blah, blah" by utilising the functionality of Windows Help in a malicious manner.

It strikes me that the .HTM pages called from the McAfee CD are held in a compressed volume or even inside a .dll file, and unpacked when required.
That's obviously what you had considered when you referred to the "read-only" medium of the CD possibly preventing the creation of a temporary cache, and why you copied the CD to your hard drive.

I'm curious to know just what type of file M:\VSC\ENU\VSOINS.UI actually is.  Obviously a reference to "User Interface" with the "UI" file type I would think.
Open Regedit and do a search "Edit > Find (keys, values and data - non-case-sensitive)" on  URL:
Keep pressing F3 "Find next", and see if it lists a protocol that matches URL:MCP Protocol, although we don't know what MCP is an abbreviation of. ("URL:McAfee Counter-Productivity Protocol" perhaps :-)
Just wondering if a previous value in the "Shell\Open\Command" keys is telling it to do something different.

You may find it easier from Folder Options > File Types, but that doesn't list the ones that might be deliberately hidden using the "EditFlags" restriction in the registry to prevent them displaying there.

This all leads me to wonder whether the issue is right down to your Internet Security settings, especially in connection with ActiveX permissions.

Try setting your internet options > security settings to "default", and then test on the following link to see if ActiveX is enabled or not.


Another thing I would examine is the contents of the "C:\Windows\Downloaded Program Files" folder.  Right-Click on all items in there, and choose "Properties" to check the content and dependencies.  Removal is possible also from the Right-Click menu.  Cleaning out previously installed content from there might help with allowing a full and unimpeded installation.

I realise that this all sounds a bit "Hocus Pocus", but you did say that you would prefer to try and get it installed "just to see if whether it will do subsequent updates correctly".

My personal view is that any program that uses a non-native URL Protocol to view an .htm web page from some compiled archive on a CD and falters at that step is so badly written that I wouldn't persist with it.  There are more and more program installers that aren't sufficiently tested in Windows 98, and just blunder their way to forcing Windows XP .dll files onto your system when they are totally incompatible with Win98.
LVL 39

Expert Comment

ID: 14074405
This guy had the same problem (different .htm file), but without resolution - so you aren't alone:


Is "vsoins.ui" a FOLDER on the CD rather than a FILE perhaps?
LVL 39

Expert Comment

ID: 14074488
The VBScript patch that you installed is intended to tighten up things and prevent malicious
processes from using scripts on your system.  This MAY, in fact, be contributing to the problem.

"The patch addresses the vulnerability by carrying out proper input validation on the
affected JScript function".

"A flaw exists in the way by which the Windows Script Engine for JScript
processes information. An attacker could exploit the vulnerability by
constructing a Web page that, when visited by the user, would execute
code of the attacker’s choice with user privileges.
See Knowledge Base Article 814078".


That's precicely what McAfee is trying to do on your system as part of the installation routine.
The file "install.htm" probably has embedded code that maybe shows a licence agreement and
then launches the install routine from a button link.

I am sure that this security patch is Uninstallable, and it's a good update, but temporarily
turning off Active Scripting may help to get McAfee installed:


I believe that the Updates might also utilise such an .htm page
(perhaps by unpacking a page to the %TEMP% folder), so when you turn
Active Scripting back on, automatic update may fail with similar errors.

LVL 39

Expert Comment

ID: 14074533
Actually, all that update does is replace jscript.dll with version and updates
the registry, etc, to reflect the file version.  Not sure if it backs up the existing one first.

Strangely, the actual installer file to UPDATE Windows Scripting TO version 5.6 installs
jscript.dll version  So it appears that the patch knocks it BACKWARDS by
one or two versions.  Presumably version was the one with the holes in it.

Author Comment

ID: 14075805
Thanks for all the suggestions and comments.

Returned from one 400 mile round trip on Saturday the 21st and
 leaving in an hour for another 800 mile round trip in an hour or so.
Expect to return on Saturday the 4th.

Won't have time to dig into this until maybe Sunday the 5th.

Again, thanks for all your patience and contributions to EE.

I expect to reward everybody who participates by opening
follow-on point questions as necessary.


Author Comment

ID: 14127544
I am back.

Note I am on Windows 98, not ME or XP.

There is also a problem with *.INF files when called with SETUPX.  It may be related.  Or not.
LVL 39

Expert Comment

ID: 14127983
Are you being shown an error message referencing setupx.dll and a specific .inf file?

Are you running the setupx command from the command-line:

eg (chosen at random from MY registry and relates to UNinstall rather than Install - but just an example):

C:\WINDOWS\rundll.exe setupx.dll,InstallHinfSection DefaultUninstall 4

or are you running it from the Right-Click > "Install" menu option on the .inf file?

There may be version conflicts (or corruption) with Rundll.exe and setupx.dll
whereby the call to the resource named "InstallHinfSection" may not be available.
The exact error message might help to identify this possibility.

The "DefaultUninstall" string should be one of the section headers in the target
.inf file, ie. shdate.inf in this example, so that's another possibility - the wrong
version or badly written .inf file.

A general problem could be as indicated in the following Microsoft page, ie. the
wrong registry value in the file association for the .inf file type:


Here's a .reg script that would restore the default association without messing
up any custom ones that you might have created to allow "Edit in NotePad"
(or whatever), but will void the [Default] Action if it is set to an action that
is causing problems:



@="Setup Information"




@="C:\\WINDOWS\\rundll.exe setupx.dll,InstallHinfSection DefaultInstall 132 %1"


Author Comment

ID: 14137325
After seeing comments by BillDL on a question about
Symantec's NAV 2005  I decided to try the Free version
of the AVG anti-virus program by GriSoft from...


The main office of the company is in the Czech Republic
in Europe, but there are satellite offices in many

The download and installation went very well.  The
scan showed no virus activity.  There was a problem
in creating the RESCUE disk (set), so I tried to move
it to a CD with Nero.  The bootable phase messed up,
but I can tailor that to my requirements later.

All in all, I am pleased with AVG and down on both
McAfee and Symantec (Norton AV).  I see no point
in fooling any longer with either of these companies.
Apparently both companies expect ALL of their
customers to have very high speed connections.
HELP is terrible and interface is klutzy and not worth
the effort to solve.

The problem with the *.INF files (at the Control
Panel Add/Remove icon) continues, but will follow up
some of the ideas above by BillDL.

Author Comment

ID: 14140801
I have really asked two questions here, which is not fair to EE experts.
Also, I have not yet gone through the responses in detail.  However,
I still expect to reward participants as promised.  I have given up on
McAfee, and earlier on Symantec (Norton).

Apparently BillDL has provided the best insight on the *.INF file
issue.  Perhaps he would like me to open a question in one of the
other forums (like OS) at EE (with appropriate Cut/Paste from here)
so that points can be credited properly for his awards.

Anyway, here is how the *.INF problem shows up...

[Click] Add/Remove Programs
[Click] Windows Setup
[Response] "Rundll32"
     "An error has occurred..."
[Click] Close
[Response] "Rundll32"
    "This program has performed an illegal operation..."
[Click] Details
     "Rundll32 caused a general protection fault
     in module SETUPX.DLL at 0007:00005433"

To be on the safe side I restart the system at this point.

A search with Google brought up Microsoft's solution
which is a completely ridiculous hunt and peck method
for isolating the problem to a particular *.INF file.
LVL 39

Assisted Solution

BillDL earned 1680 total points
ID: 14144482
Hmmm.  Yes, I see what you mean about the laborious
"find the dates of the inf files" suggestion:
That seems to refer to the "Add New Hardware Wizard" though, and it
causes some dubiety between RunDll32.exe and RunDll.exe.

Clearly the file association with the .inf file type with regard to "Add/Remove
Programs" is through RunDll.exe and not RunDll32.exe.  This puzzles me,
and I intend to try and track the exact process used in the "Windows
Setup" dialog that could cause this.  Two immediate ideas come to mind:

1. Start Menu > Run > and type DRWATSON > click OK
    Right-Click on its icon in the System Tray and choose "Options".
    Defaults are to create DRWATSON.LOG files in %windir%\DRWATSON.
    Instructions = 50, Stack Frames = 100.  Open new windows in advanced
    view.  Click OK.
    Right-Click the icon again, and choose "Dr. Watson".  It will gather info for
    a snapshot, and you can use the File > Save As menu to name the file
    "Before_AddRemove.WLG".  Close the dialog and just let it run in the
    System Tray while you then try and replicate the error.
    The good thing about the .wlg files is that you can email them to others
    and they can open that snapshot in their own Dr. Watson to analyse.
    I'm no expert in Dr. Watson Log Files, but feel free to email yours to me.
    Email Address in my Profile.  Best to zip it up with Winzip in case it is
    identified as a script and stripped out by the ISP.

2. Extract Fresh copies of RunDll.exe and RunDll32.exe to the Windows folder
    using SFC in the "Extract one file from Installation CD" mode.
    On my Win98SE system, despite a lot of updates and installation of so many
    new software titles, both these files have remained as version 4.10.1998.
    That would eliminate the possibility of a version conflict or perhaps a WinME
    or Win95 file version having slipped in there and causing problems.
    My C:\Windows\System\SetupX.dll has also remained as the original Win98SE
    file version (4.10.2222), so extracting a fresh copy from the Windows CD with
    SFC would also be a good idea.  Using SFC updates the Version Verification
    Table, so that eliminates the possibility of the wrong versions being stored.

SetupX.dll is not a 32-bit file and, from what I can see, it references RunDLL.exe
rather than its 32-bit counterpart RunDLL32.exe.  I can only assume that it then calls
the 32-bit .dll in the GUI mode.

One thing is certain though.  It will look or the original "InstallSource" from the registry
and check the following .cab files found in that location:

precopy2.cab - contains a load of original .inf files including layout.inf, layout1.inf, and
layout2.inf which specify the source of all files originally installed, the destination install
to, as well as the original file sizes.

It probably then checks the key:
to see what optional components are already installed so that it can show the boxes
as ticked in "Windows Setup".

I assume that it must also check the keys:
SetupX\INF\OEM Name
to see what .INF files are already supposed to be installed.

Obviously it needs to know what files were backed up during updates of any
components, so it must check:
(This is the list shown when you type VCMUI from the Start Menu > Run option).
The backup folder is normally C:\WINDOWS\VCM.

I also assume that the folder C:\WINDOWS\INF\INFBACK would have to be
checked by setupx.

In all, it's a maze and very difficult to identify exactly where the fault is occurring.
IF you have set cusom fonts to display in your Windows dialogs and menu's, then
I recommend resetting these to standard again just to discount the possibility of
a corrupt font.  This is highly unlikely, as the whole Add/Remove Programs dialog
would be affected rather than just the "Windows Setup" tab.  Other lists would
probably also be affected.  Default font is MS Sans Serif.

Here's an alternative way to open the Add/Remove Programs Control Panel Applet
(c:\windows\system\APPWIZ.CPL) from a Start Menu > RUN command so that it
opens in the Windows Setup Tab.  Try it and see what happens:

rundll32.exe   shell32.dll,Control_RunDLL   appwiz.cpl,,2

If it fails with an error again, then it is to do with the "Searches for Installed Components"
process, and certainly points to:

1. Corrupt SetupX.dll file or associated files called
2. Corrupt or bad syntax registry entries accessed by SetupX.dll
3. One or more .inf files read are corrupt or have bad syntax.

The system files used by SetupX.dll are:

Kernel.dll or Kernel32.dll
User32.dll or User.exe
Gdi32.dll or Gdi.exe
Keyboard.drv, Keyboard.inf or Keyboard.sys

I'm not sure if you are aware of this, but the file "MINI.CAB" is the one unpacked
first during Windows 98 installation, and this sets up a basic Windows 3.1-type
environment so you have graphics, mouse use, keyboard use, and the basic fonts
for the setup billboards and dialogs.  The proper 32-bit file versions are later
installed after the fist boot.

Mini.CAB contains 16-bit versions of the following files that are not compatible with
Windows 98 in normal use.  The files that could cause problems, if left on the system,

When using SFC in Windows 98 FIRST Edition, it had a known problem due to the way
it searched the .CAB files and extracted the required file from the first .CAB file
containing it (MINI.CAB).  This resulted in the wrong vesions of the above files being
extracted BEFORE it was allowed to get to the .CAB file containing the proper version

This issue was apparently fixed in the SECOND Edition, so it isn't a concern UNLESS
you have ever extracted files using the DOS Extract command in FULL DOS
which MIGHT still behave in the same incorrect way.  Using the Extract command
in a DOS Box WITHIN Win98SE works correctly.

I can't recall if you are using Win98 or Win98SE, but if you have the First Edition AND
you have ever run SFC, then there is a possibility that you have bad file versions.

USER.EXE is a file that might have been updated from 4.10.1998 / 4.10.2222 to
any version up to maybe 4.10.2231 if you have ever installed the UNOFFICIAL
Win98 SP1 or 2 updates that roll up all the Windows updates into one.
IF your USER.EXE file version is 3.10, then that's the one from MINI.CAB.

Exactly the same issues as above apply to GDI.EXE.

KRNL386.EXE isn't one that is updated by those Unofficial Win98 SP1 and 2 updates.
The properly installed Win98 version should be 4.10.1998 (125 KB), and the bad one
from Mini.CAB (74 KB) will not show the Version tab at all when you check its properties.

If yours ARE the wrong versions, then extract the correct versions.

KRNL386.EXE - WIN98_45.CAB

Run the following command from a DOS box to extract the file, then run it again to get
the prompt to overwrite the file.  This lets you see the containing .CAB file:

EXTRACT /A x:\win98\BASE4.CAB krnl386.exe /L c:\windows\temp

Alternatively, try and extract directly to the correct folders after renaming
the files
(replace x:\ with the CD-Rom's drive letter or C:\Windows\Options\CABS\):

@echo off
set SYSFOLD=c:\windows\system
if exist %SYSFOLD%\user.exe ren %SYSFOLD%\user.exe %SYSFOLD%\user.old
EXTRACT /A x:\win98\BASE4.CAB user.exe /L %SYSFOLD%
if exist %SYSFOLD%\gdi.exe ren %SYSFOLD%\gdi.exe %SYSFOLD%\gdi.old
EXTRACT /A x:\win98\BASE4.CAB gdi.exe /L %SYSFOLD%
if exist %SYSFOLD%\krnl386.exe ren %SYSFOLD%\krnl386.exe %SYSFOLD%\krnl386.old
EXTRACT /A x:\win98\BASE4.CAB krnl386.exe /L %SYSFOLD%

Windows probably won't allow this, however.

Let me know if any of this is relevant to your problem.

Author Comment

ID: 14144878
My current versions are 4.10.1998 and 4.10.2222 (same as yours)
so I don't want to extract original copies at this time.

I did run the applet from the Start/Run as you suggested, and
got the same error.

I have Windows 98 SE

There were several transient failures earlier today that
pointed to something happening after completion of
AUTOEXEC.BAT but before the Windows password menu.
It acted like a driver was messing with the environment
variables to kill the SET entry of ...

TEMP=C:\WINDOWS\TEMP and replace it with all x
(exact same number of characters - weird) as seen
with the SET command at a DOS prompt after
Windows comes up.

I have a cleanup routine that purges that folder, so
maybe some driver insists that it be there.  Anyway,
I modified the cleanup routine to create it again
immediately after the purge.  

You can see the cleanup routine at...


At this point I suspect the culprit *.INF file is one
of the windows startup drivers.  

It is almost 3:30 AM, so must get to bed.
LVL 24

Expert Comment

by:Mohammed Hamada
ID: 14147740
Hello sysandprog
did you try what i suggested above?
give it a shot for both the http://freepctech.net/files/VXD_FIX.zip file and the .net framework download it again and restart to check if you'll have the same problem?
LVL 39

Assisted Solution

BillDL earned 1680 total points
ID: 14148360
I have just studied that batch file from your download link.
I have several immediate issues with it that would make me very
hesitant to use it on any of my Win98 systems:

1. The read_me_first.txt file tells the user that it will ONLY work by
extracting files from the installation CD, and not if the .CAB files are
on the hard drive.

Why then, does the batch file look for the required CAB files in the
default location (C:\Windows\Options\CABS) and extract files from them
if they exist there?

Those kind of oversights make me very nervous, as well as the fact
that that same readme file states:
"...rebuild your VMM32.DLL file...and will then update your Windows

Is "Revolution" (the author) seeking to repair a non-existent .DLL file,
or VMM32.VXD. I assume that this is a spelling mistake, but how many
syntax errors are in the .DAT file (yes, he called it DAT instead of BAT).

Assuming the logical, ie. fix the VMM32.VXD file (given the name
VXD_Fix.zip), then that batch file MIGHT repair the file VMM32.VXD, BUT
the author seems to cover himself by extracting the same files to two
different system folders.  Either he isn't sure what files should be in
what folder, or to cover all possible avenues.  having the same files in
different system folders CAN be problematic, or is just plain unnecessary.

That file is a monolithic .VXD file that is poulated with the required
VXD virtual device drivers for your system at the time Windows 98 is
installed, and dependent upon its configuration at that time.  The only
ways to ADD or freshen the VXD files packed into it are:

1. Programmatically in the way Windows or installer programs do
(see the "procedure" section on the following page:
2. Placing the VXD file in C:\Windows\System\VMM32 and rebooting.

The system will try and add the file in the VMM folder into VMM32.VXD
as the system is rebooted and, if it can't, it should still be able to
load the driver from the VMM folder because it looks there first.

There are MAJOR flaws in that batch file that make me wonder what
idiot wrote it:

VXD_FIX.DAT will now check your system to see if you need the VXD update.
if exist %winbootdir%\system\vflatd.vxd goto no

If vflatd.vxd is correctly installed and being used, it will either
already be packed inside VMM32.VXD or will be in the VMM folder.
It isn't supposed to be in the folder C:\Windows\System and I have
strong doubts that it would be loaded from there.

OK, so the batch file then extracts 7 .VXD files from the CD OR from
the CAB files on the hard drive, and dumps them into the SYSTEM
folder AS WELL AS the System\VMM32 folder.
(configmg.vxd, vcomm.vxd, vdmad.vxd, vdd.vxd, vmouse.vxd, ntkern.vxd,

OK, so these are arguably the CORE vxd files, but Windows
automatically packs a LOT more than that into VMM32.VXD right from
the outset, so there is NO WAY the author can possibly claim this
to be a FIX for VMM32.VXD.

To REALLY see what Windows .vxd files are contained in VMM32.VXD,
you can get a list from the registry by extracting the following
key to a .txt or .reg file:
and you could then do a FIND command from a batch file to search for
specific filenames.

It should be noted that my list contains 48 .vxd files, ALL of which
are Microsoft Windows files and not additional ones added by third
party installations.  NONE are duplicated in C:\Windows\System.

In THIS case in question, the .VXD files referenced are non-MS files
and belong to McAfee software.  They should be in the program folder
or, as is the usual with 3rd-party vxd files, in the folders:
C:\Windows\System\IOSUBSYS or C:\Windows\SYSTEM.

A MUCH better way of reinstalling the original .VXD files into the
VMM32.VXD files is from an .INI file as described on the following
page under the PROCEDURE heading:

This has a link for a download of the example files, and it would
take someone about 15 minutes to create a PROPER VMM32.VXD fix as
opposed to a half-baked batch file with more attention paid to
the ASCII logo at the start and finish than to the functionality or

Download Example:

Using the System File Checker

Q188186 - How the System File Checker Baseline Is Determined

Q264865 - System File Checker identified that the following file
may be corrupted


Please DON'T take this as a personal attack.  It is just that I
feel quite strongly that downloads that purport to be able to FIX
things, should be able to do so.

In this case, this VMM32.VXD "Fix" is really just a half-way effort
and nothing more.

"This program will update your Windows 98 Virtual Device Drivers".

No it won't.  It will knock 7 of them BACK to the versions that were
"installed" when Windows built the container for them, and may well
have been updated several times since then programmatically.
LVL 39

Expert Comment

ID: 14148409

If you DO go down the road of attempting to repair/rebuild your VMM32.VXD file AND
it proved successful, then I would urge to to run Windows Update again.
There are a few updates that need to add newer versions of .vxd files into
VMM32.VXD by dropping copies into the C:\Windows\System\VMM32 folder.

Update: http://support.microsoft.com/?kbid=256015
Updates IFSMGR.VXD to version in VMM32.VXD

Update: http://support.microsoft.com/?kbid=267304
Updates NTKERN.VXD to version 4.10.2223 in VMM32.VXD

Windows 98SE Shutdown Supplement
MIGHT Update CONFIGMG.VXD to version 4.10.2222 in VMM32.VXD if for some reason
an older one sneaked in there.

Author Comment

ID: 14149073
Will be going through your wonderful, caring responses in detail
as I get time.  In the meantime...

Sometimes looking for the cause of one problem reveals the
answer to another problem.  Here are entries from my fix diary...

20050605 Verified that if C:\WINDOWS\TEMP folder does not exist
                the first step of the Norton WinDoctor Wizard
                (Registry Doctor/Registry Integrity) will return an
                ERROR message without invalidating remaining steps.
20050605 Uninstalled McAfee Firewall and Security Center
20050602 Free GriSoft AVG Version 7 anti-virus installed

Also, I stumbled on another interesting tidbit that is probably
peculiar to Windows 98...

Coming into AUTOEXEC.BAT these environment variables are
already set...


However, if C:\WINDOWS\TEMP does not exist, one of the
STARTUP INF files (while drivers are loaded) substitutes
xxxxxxxxxxxxxxxxxxxx for TEMP=C:\WINDOWS\TEMP

However, this substitution is defeated if the above two
environment variables are hard coded in AUTOEXEC.BAT

I found a comment in that STARTUP INF that explains why.
If you want to see for yourself, do a FIND looking for
xxxxxxxxxx in the STARTUP*.INF files.

Another peculiar thing about Windows 98 is that
PATH folders are ADDED to some that already
exist when you specify them in AUTOEXEC.BAT and
they tend, then, to get redundant repetitions.  The
way around that is to first get rid of all incoming
PATH parameters by specifying a clearing entry of PATH=
with no folders specified.

Author Comment

ID: 14151165
Resolution of the General Protection Fault problem...

...which was giving the message...

"RUNDLL32 caused a general protection fault in module SETUPX.DLL"

Using a modified "hunt and peck" method (alphabetical rather than by date),
I isolated the bad INF file down to...

the file ---> LAYOUT1.INF

Removing the file resolves the problem.  I looked at it with text editors
and couldn't seen anything wrong with it.  However, there is an
associated LAYOUT1.PNF file which is unreadable.  Again, the other
two PNF files (LAYOUT.PNF and LAYOU2.PNF) are also unreadable, so
that isn't significant.

However, there may be something in the Registry that points to these
files, but I haven't had time to look yet.

Perhaps BillDL has some thoughts on what to do about the LAYOUT1.PNF
file.  Should it be fixed, found, salvaged or what?  Will the system
rebuild it automatically?  I have backups of it in several places.


As I mentioned earlier, the supposedly corrupt VXD files were probably
specific to McAfee.  I no longer plan to fiddle with McAfee.  Therefore,
unless I identify a common usage VXD file that has been corrupted, I
won't be trying any kind of fix.

Author Comment

ID: 14151173

Perhaps BillDL has some thoughts on what to do about the LAYOUT1.INF
file (and the associated LAYOU1.PNF file, of course.)

LVL 39

Assisted Solution

BillDL earned 1680 total points
ID: 14155977
Strangely enough, I was just looking through the Layout Layout1 and layout2.inf files,
and also at SETUPC.INF and SETUPPP.INF (which should be removed after installation).
The setuppp.inf file is the one you can modify and pack back into its cab file, or modify
as it is unpacked at the start of installation, so that you can change it to different type
of install where you aren't asked for the registration key.

Those 2 were the only .inf files that were found to contain the text xxxxxx

I didn't know how many x's were being written to the environment table to replace the
TEMP=C:\Windows\Temp, but I searched for .inf files containing about 6 of them.

There are 591 .PNF files found on my system, all within the C:\Windows\INF folder.
No other .PNF files exist outwith this folder, and there are none on the Windows CD.
.PNF files are referred to as "precompiled" INF files and Windows creates a PNF file for
each INF file supposedly to facilitate efficient processing.
If a PNF file does not exist for an .INF file, SETUP generates a new one.

Rename layout.pnf and reboot to see if Windows creates a new one.  If so, then do a
side-by-side binary comparison to see if the original was corrupt.

"Beyond Compare" by Scooter Software (along with its plugins) is a great utility that
creates Right-Click menu options (a) File or folder 1 - Set Left Side to Compare
(b) File or folder 2 - Compare with "File/Folder1", and then allows you to choose which
plugin to view the differences in.


If it transpires that Layout.inf is corrupt in some way and has therefore created
another corrupt .PNF file, then try extracting a new one from the CD:

extract /A X:\win98\BASE4.CAB layout.inf /L c:\windows\inf

Actually, you are probably better using SFC to extract layout.inf by name from the
Windows CD so that it correctly updates the verification table held as:

Just out of interest, have you run SFC recently?
If not, then perhaps a runthrough (using the "ignore" option first time around) might
give some idea of how many files that it THINKS are corrupt, wrong version, etc, etc.
DON'T believe everything it tells you though, because if files were introduced into
your system legitimately but weren't updated in Default.sfc, then it will assume them
to be bad.  You have to tell SFC to "update verification table" to correct this when it
finds questionable files.

The problem is that I DON'T think WINDOWS will automatically build a new layout.pnf
without you renaming layout.inf and layout.pnf and doing a dirty install back to the
C:\Windows folder again.

If you want to have a peek inside a file that is gobbledegook in a standard text editor,
then install the dll file PEEK.DLL which gives a Right-Click > "PEEK" option for ALL files,
and will extract as much textual content out to Notepad (wordpad if large) but won't
mess with the content of the file being peeked into:


Unzip and then right-click > install on the peek.inf file.  This registers the .dll and copies
peek.inf and peek.dll to C:\WINDOWS\SYSTEM\SHELLEXT.  It also creates an Add/Remove
entry for clean removal.

I can't see enough of the actual layout in layout.pnf to give me any clues as to whether,
when it is created from the related .inf file, it stores ONLY those settings relevant to your
current setup.  My opinion is that it will be the same file, but just converted into a better
and more efficient format or code to be read faster than trawling down through an .inf file
LVL 39

Assisted Solution

BillDL earned 1680 total points
ID: 14156001
Incidentally, have you ever used the
Windows 98/98SE "FileInfo.exe" Utility?

This utility provides information about virtually every file that
is included with Windows 98 and its intergrated version of
Internet Explorer, including file sizes, dates, installed location,
CAB file location, whether or not the file remains on the hard drive
after installation, and a short description of each file.

The required files be found on the Windows 98 SE CD in the folder:


as "Fileinfo.exe and its database file (win98.mfi).

Fileinfo.exe NEEDS the file win98.mfi to be in the same folder when
run or it will not work.  Additionally, if you try and run it from
the CD which is a "Read-Only" medium, it will issue the error

Run-time error '3051'
The Microsoft Jet database engine cannot open the file
It is already opened exclusively by another user or you need
permission to view its data.

Copy the two files to their own folder on a read/write drive and
remove the Read-Only attribute set against win98.mfi and
FileInfo.exe will be able to load the database properly.
LVL 39

Accepted Solution

BillDL earned 1680 total points
ID: 14156180
Just another thing that might be of use to you.
Use the EXTRACT command with the /D option to "VIEW" the contents
of the named .CAB file, and redirect output to a .txt file.
Use the /A switch to process ALL cab files in the stated directory STARTING
from the one you specify:

EXTRACT /A /D x:\win98\BASE4.CAB > c:\windows\desktop\cablist98se.txt

Results in a large file that views OK in WordPad as shown below:

Cabinet BASE4.CAB

04-23-1999 10:22:00p A---        68,871 drvspace.bin
04-23-1999 10:22:00p A---       272,206 ebd.cab

Cabinet BASE5.CAB

04-23-1999 10:22:00p A---        93,890 command.com
04-23-1999 10:22:00p A---         1,103 autoexec.ebd
etc, etc, etc

Cabinet NET7.CAB

04-23-1999 10:22:00p A---           407 networks
04-23-1999 10:22:00p A---        25,619 dimaint.386
etc, etc, etc

Where you see:
Cabinet WIN98_56.CAB
<nothing here>
Cabinet WIN98_57.CAB
it means that the cab file is spanned from 56 into 57.

The good thing is that you don't have to worry about whether
directory structures are listed or would be restored when one of the
Win98 cab files is extracted (ie. like the options from WinZip),
because none of them contain folders that need to be regenerated.
The files with no extension shown in the "NET7.CAB" above are script
files that aren't supposed to have extensions.  They aren't folders.
The layout is:
mm-dd-yyy hh:mm:sec  attribute  file_size filename.ext

Just some more info while I am looking at the .inf files.
LVL 39

Assisted Solution

BillDL earned 1680 total points
ID: 14156187
Oh yes, and to assist you with interpreting the setup .inf files, here are the destination
codes used to tell setup where the files should be placed:


14=Control Panel
28=Host Winboot
30=Boot drv root
31=Root of Boot drv Host
LVL 39

Assisted Solution

BillDL earned 1680 total points
ID: 14156220
And here's the reason that I suggested running SFC.  I had to find my original notes again:

The SFC baseline file (Default.sfc) maintains the tool's settings and
a profile of system files. The baseline contains the following
information for each file: Location, Source, Cyclical Redundancy
Checksum (CRC), Date/Time Stamp, Size and Version.

The SFC baseline for the retail version of Windows 98 comes populated
with Windows 98 file information. The baseline is backed up and
selectively updated during Windows 98 Setup.
Running SFC for the first time establishes a profile of the system.

The following files provide the SFC baseline with the default list of
files copied by Windows 98 Setup:

The following files provide SFC with the source for the copied files:


Windows 98 Setup copies the Default.sfc file to Default.sf0 and then
updates the baseline for files such as Vmm32.vxd that have changeable
properties. SFC updates the baseline with changes to the properties for
these files without noting the changes in its log file (Sfclog.txt).
If a file is missing, it is removed from the baseline.

The Sfcsync.txt file is a list of files to silently update in the SFC
baseline during Setup.
Sfcsync.txt is limited to the following locations:

Sfcsync.txt   Actual location
-----------   ---------------
10            Windows
11            Windows\System
12            Windows\System\Iosubsys
13            Windows\Command
22            Windows\System\Vmm32
The first time SFC runs, it creates a profile of the system. All of
the changes to the baseline are noted in the Sfclog.txt log file,
with the exception of missing files.

Missing files are silently removed from the baseline the first time
SFC runs, even if you enable notification for missing files. Files
that are removed after SFC runs for the first time are identified as
missing the next time SFC runs. You are prompted to restore the file
if SFC is configured to check for missing files.

Changed files are noted in the log file and you are notified if the
setting is enabled. A file is identified as changed if its date and
version information changes. Changed files are identified in the
Sfclog.txt file as "Updated" unless you enabled notification for
changed files and chose to restore the original file.

You are always notified of damaged files. A file is identified as damaged
if its date and version match, but the CRC value does not match the baseline.

You are not notified of files that are added to the baseline.
Files that are added to the baseline are noted in the log file as "Added."
LVL 39

Assisted Solution

BillDL earned 1680 total points
ID: 14156379
OK, here's the details of the sketchy notes that I always make in Notepad when I'm
looking at a problem.  I have a mind like a sieve and have to make them, or I forget
what I've considered or discounted.  Bear in mind that they are really just "findings"
rather than "advice" at this stage, but have a look through right to that last section
where it looks like I have discovered a possibility for the xxxxx's in the environment

Interesting Microsoft page here:
Relates to Windows ME, but MAY apply to Win98 also.

Brief summary:
When you run Msconfig, the following information dialog shows:
"Environment Variables were found in the legacy files Autoexec.bat
and/or Config.sys and the variables were moved to the Registry".
After you click the OK button, MSconfig functions normally. and
you usually won't see this again.
You MAY, however, see this each time you run MSconfig.
This may occur if Autoexec.bat or Config.sys dates have been
changed by third-party utilities or a software installation.
Some antivirus prog's or system utilities modify Autoexec.bat
or Config.sys at every restart.
This behavior may also occur if either Autoexec.bat or Config.sys
are "Read Only".

The implications of this are relevant when I began to wonder what
exactly is wring those changes to the environment table and
replacing portions with xxxxxxx's.

If something is modifying autoexec.bat or config.sys each time
windows starts, then the details are being written to the registry.

My environment variables (SET command in a DOS Box):

TEMP=C:\WINDOWS\TEMP <--------------- IO.SYS?
PROMPT=$p$g <------------------------ IO.SYS?
winbootdir=C:\WINDOWS <-------------- MSDOS.SYS/Registry?
PATH=C:\WINDOWS;C:\WINDOWS\COMMAND <- IO.SYS/Autoexec.bat/Config.sys
windir=C:\WINDOWS <------------------ MSDOS.SYS/Registry
BLASTER=A220 I5 D1 T4 P330 <--------- C:\Win\*.INF files/Drivers

So, where are they "SET" from so that you see these details when
you type the SET command in a DOS box within Windows?

I would also be curious to see what they are reported as when you
issue the SET command from Full DOS.

Remember here that, if you run the SET command within a DOS
session, the details and any changes applied to the environment
variables only apply to THAT session, and return to default in
any subsequent sessions.... UNLESS... you use WINSET.EXE.

Winset.exe modifies environment variables for Win98 global DOS
environment.  The usual mode of use is to create a batch file with
the appropriate WINSET commands in a batch file, and then stick a
shortcut to it in the Start Menu > Startup folder to eliminate the
need for autoexec.bat or to override it.

SET TEMP=C:\Windows\JUNK in autoexec.bat
would be replaced by
WINSET TEMP=C:\Windows\JUNK in the startup batch file.

Of course, as you will be aware, Windows 98 does not actually NEED
an autoexec.bat file.  It's just a bad habit of application writers
to drop entries into it, or maybe the application WILL have a need
to get settings from it when run in DOS.

For instance, Roxio Easy CD-Creator version 6 decides not only to
create its own ROXIOAUTOEXEC.BAT file in the root of the system drive,
but also to add a line in autoexec.bat declaring a path to it!!!
Why?? Easy CD-Creator doesn't run in DOS and should get ALL of its
"Path" settings from the registry key:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\App Paths.
On that subject, I have to wonder which idiot forced DirectX to create
its own registry key "APPPATHS" instead of using "App Paths".

Is there perhaps a C:\Windows\DOSSTART.BAT on your system?
How does it compare with autoexec.bat and config.sys?

Related Registry keys that IO.SYS looks at when booting:




"WinBootDir", "WinDir", "HostWinBootDir" = "C:\windows"


The file c:\windows\inf\SETUPC.INF seems to be the file that originally
created C:\MSDOS.SYS during the Win98 installation, hence the fact that
my file search found it to contain xxxxx's.


Damn, it looks like I found the culprit that is writing bad data to the
environment table.  This file shouldn't even be left on the hard drive
because it is a temporary setup file used in the original Win98
installation.  It just so happens that I was modifying it and had it on
my desktop.  Now, IF it is sitting in YOUR C:\Windows\INF folder????

Relevant section:


That resembles what's being written to your environment table.

Author Comment

ID: 14156882
I have used SFC from the beginning and don't like it because
there have been so many changes to the system that the
original files are most often no longer relevant.  But, still
I go through the motions...

My installation disk is from Hewlett Packard.  When I tried
to look it over in detail it grumbled back about password

Finally from a DOS prompt I used the command...


and used it as the replacement in C:\WINDOWS\INF

Then back to the Control Panel, Add/Remove thingy

and got the same error message

"RUNDLL32 caused a general protection fault in module SETUPX.DLL"

So, evidently there is original content in LAYOUT1.INF that is no longer
relevant to my system that has been modified many times.  After the
initial lines there is a large blank gap.  Then following that is an index
of C:\WINDOWS\OPTIONS\CABS files.  Then, after that there are
entries which may refer to fixed data positions on the hard drive for
system files (see ATTRIB).  Just guessing, because I doubt there are
that many system files on the hard drive.

If the last case is plausible, I can see where there might be a problem
if a DEFRAG operation somehow relocated a critical system file.

Unfortunately I have no idea how long this bug has been on the system.

Now I don't know how to proceed.  Searches with GOOGLE haven't turned
up anything useful.

Do you happen to know if the LAYOUT.INF, LAYOUT1.INF, AND LAYOUT2.INF
files are needed in ordinary daily operation?  Or, are they just required
for original system installation?  If that is the case, then if they aren't
working as intended that would interfere, probably, with installation of
CRITICAL UPDATES from Microsoft.


Author Comment

ID: 14157638
On taking a closer look, what I (jumped the gun) and thought might be
hard drive physical addresses are actually nominal sizes (in bytes) of
individual modules.

If the system attempts to validate such indexed sizes against actual
storage sizes and finds a discrepancy, maybe that would return a
general protection error.

Trying to run down by manual methods any such discrepancy is
virtually impossible.  It seems the only way would be to create
many copies of LAYOUT1.INF with each one having only some of
the table entries.  Then, each copy would be substituted in turn
to see if that produced the error.  It would take forever!

By the way - even if the error is cleared (by deleting the bad *.INF
module),  the corresponding error code is not cleared until the
next system restart.  This makes testing difficult and potentially
LVL 39

Expert Comment

ID: 14160502
Everything here sounds to me like you have a non-standard Win98 CD
(You said it was an HP one), and that somehow the Setup*.inf files
don't point to the correct .CAB files.

It COULD be that, like most of the Compaq Recovery CD's, they use
their own setup.inf files instead of the copy, copy1, and copy2.inf
files, and alternative versions of setuppp.inf, and the layout,
layout1 and layout2.inf files.

You DID refer earlier on specifically to SETUP.INF.  I don't have
such an inf file on MY win98se CD or on hard drive.

"If the system attempts to validate indexed sizes in the .INF files
against actual storage sizes, and finds a discrepancy, maybe that
would return a general protection error".

Not sure about this.  I would imaging that a SYNTAX error would
report something indicating that it was incorrect syntax rather
than a GPF.  Try it by changing something in Layout1.inf that is
easy to change back, eg.




LAYOUT*.INF files syntax:

For the topmost list of the .CAB files [SourceDisksNames]

Apparently <ID_Number> is always Zero.

The syntax for the listed files under [SourceDisksFiles] is:
<FileName.ext>=<Cab_Number>,<?>,<File_Size> (bytes)
I THINK the <?> would be used for a CD that contained sub-directories
and you would specify that first and move <CAB_Number> to the right.
It MIGHT be to specify the CD Number.

The Zero under <Cab_Number> means the file is loose in the "win98"
folder and not inside a .CAB file.

Note, this is the method of customising your own .inf files and
forcing setup to use the ones lying loose in the setup folder rather
than looking for files inside the cab files.  Setup SHOULD always use
a referenced file lying loose in the folder BEFORE diving into the CAB
file, but this can be further enforced by locating the references to
the target file, and changing the number of the cab file to a Zero as
with the Scandisk.exe line above.

At the start of setup, the file setuppp.inf is extracted from
Precopy2.cab to the TEMP setup folder (default is C:\WININST0.400)
and a recovery Uninstall folder (C:\UNINSTAL.000) is also created.
At this stage, you can crash out to DOS and EDIT setuppp.inf to
change settings including "ProductType=" number so you can install
without a CD-Key, or you can delete IE-related components to stop
the IE Integration for a skinny Win95-type install.

LAYOUT.INF (which has been unpacked to C:\WININSTO.400) references
setuppp.inf as  setuppp.inf=2,,17997  meaning it should be unpacked
from Cab File Number 2 (Precopy2.cab). If you copied all the .CAB
files to a folder on the hard drive, unpacked SETUPPP.INF in advance
to the folder along with the 3 x LAYOUT.INF files, and changed the
refernces in them to  setuppp.inf=0,,17997  , then setup would find
the loose layout files, and then expect to find setuppp.inf in the
"0" location which is "loose".  There are a lot of things you can
do when installing from a hard drive folder rather than the CD.

IF your HP setup CD DOES have alternative setup .inf files referenced
and loose in the source folder (or even the root) of the CD, then
what you are experiencing COULD be the result of this.

I can't recall if you actually copied your entire CD to a hard drive
folder and changed the "SourcePath", "CommandLine", and "OLSSrcPath"
StringValues in:
to reflect this change.

IF NOT, then I recommend that you try this.

There is a useful Windows 2000/XP DDK utility program to check
.INF files:
But I am NOT sure if there is such a utility designed for Windows 9x.

Even if the error is cleared by deleting the bad *.INF file, the error
code is not cleared until the next system restart.

There IS a method of bluffing the system into applying changes that
normally require a reboot, but without doing a restart all the way.
I THINK it was simply Ctrl + Alt + Del and then choose Shut Down, but
then Cancel when it shows the Shut-Down options dialog.  I think this
action goes further to allow changes that cannot be dynamically applied
to be written because of that Ctrl + Alt + Del stage as opposed to the
normal Start Menu > Shutdown method.

I'm not quite sure whether the layout*.inf files are required in
daily use by the computer after they were used during setup, but
they are likely used again if you change what windows components
are installed using Add/Remove Programs > Windows Setup.
From what I can see, the layout.inf files ARE accessed at
every boot.

One way to check, and that is to use the DOS DIR command with the
switch (/o-a) to list your .inf files by most recent ACCESS DATE
first and then append a list of the .pnf files after it using the
same criteria:

@echo off
echo. > c:\windows\desktop\infdates.txt
echo INF FILES >> c:\windows\desktop\infdates.txt
echo ========= >> c:\windows\desktop\infdates.txt
echo. >> c:\windows\desktop\infdates.txt
dir /a-d /o-a /4 c:\windows\inf\*.inf >> c:\windows\desktop\infdates.txt
echo. >> c:\windows\desktop\infdates.txt
echo PNF FILES >> c:\windows\desktop\infdates.txt
echo ========= >> c:\windows\desktop\infdates.txt
echo. >> c:\windows\desktop\infdates.txt
dir /a-d /o-a /4 c:\windows\inf\*.pnf >> c:\windows\desktop\infdates.txt

If you leave this until after midnight and reboot to run this, it will
allow you to see if the layout*.INF files are accessed at boot.

Layout will be as follows:

File Name, Ext, Size (Bytes), Allocated (Bytes), Date/Time Modified,
Date Accessed, Attribute.

In MY case, Layout.INF, Layout1.INF, and Layout2.inf were ALL
accessed today, even though I only actually opened layout.inf
for editing today and neither of the others.  Only Layout.PNF
and Layout1.PNF were accessed today.  I had Layout.PNF open
for editing, but not Layout1.PNF.

My Layout2.PNF was last ACCESSED on 1st May 2005, and that
corresponded with access to a LOT of the the other PNF files.
In fact, the vast majority of the listed PNF files were
ACCESSED on 1st May.

The majority of INF files listed are shown to have been last
ACCESSED on 31 May.

Unfortunately, I can't ascertain if the Layout.INF, Layout1.INF,
Layout2.INF and Layout.PNF or Layout1.PNF were ACCESSED on
1 May or 31 May when system changes were made to my system.

I did a file search for "Files CREATED" on those two dates
to see what system changes were done.

On 1st May I was having problems with my usb camera so I:
- Reinstalled Intel chipset drivers
- Reinstalled Intel Ultra ATA Storage Driver
- Reinstalled Intel Active Monitor
- Reinstalled Intel Application Accelerator
- reinstalled drivers for a digital camera
- Installed fixed version of Q891781 update
- it seems that other .INF files were created that day,
even though I don't think I installed the respective
Windows updates referenced by name Q833989, OE6 SP1
update Q837009, KB870669, and Scripting 5.6 Update.
- It seems that DirectX 8.1 was updated to DirectX 9.
I think this may have been an audio/video converter that
foisted this on me without telling me first.
- Updated Macromedia Flash from 7 to 10.

As expected, a correspondingly huge number of the .inf and
pnf files were also "MODIFIED" that same date.

On 31 May I:
Installed BitTornado.
Just about the same number of .inf and .pnf files show as being
MODIFIED that same date.

So, although inconclusive, it looks like MY system might access
ALL the Layout*.INF files on a daily basis, but only accesses the
respective .PNF files when changes are made.

If you have a look at the registry keys:

the sub-keys of:
Setup\SetupX\INF\OEM Name

You will see some pretty lengthy listings of the .inf files that were
installed by Windows and through the later installation of modems, etc
where setupx was involved in the installation process.

Windows keeps a note of what "optional" Windows components are
currently installed, and can thus show them as ticked in "Windows

Take an example of the CD-Player which IS installed on my system:

The following key sets C:\Windows\INF as the "DevicePath":
and C:\Windows\INF\OTHER is set as "OtherDevicePath" from there also.

Updates to windows program files and application components such as
dll's, etc, are all logged in the following keys:

HKEY_LOCAL_MACHINE\Software\Microsoft\Active Setup\Installed Components
HKEY_LOCAL_MACHINE\Software\Microsoft\Active Setup\ClsidFeature
HKEY_LOCAL_MACHINE\Software\Microsoft\Active Setup\FeatureComponentID
HKEY_LOCAL_MACHINE\Software\Microsoft\Advanced INF Setup

When the computer loads the registry, it first looks at system.dat,
and takes settings from the following keys:


Incidentally, going back to an earlier post of yours where you spoke
about your C:\Windows\TEMP folder, when I delete or rename MINE, it
is just recreated again at the next reboot.  I rebooted immediately,
because I have a lot of applications that use the default TEMP folder
and I didn't want any errors.  eg. CD-Writing app uses %TEMP%.
I must change this to something else.

Anyhow, I am rambling on with THEORIES and POSSIBILITIES rather than
trying to address YOUR queries.

Still thinking about it :-)

Author Comment

ID: 14175054
It took all day for my wife and I to install a new garbage disposal yesterday.
That prevented any responses from me.

Today I have been having vision problems related to hay fever.
That put me in bed most of the day.

Anyway, here are points for BillDLL for his unique diagnostic
solution for identifying bad INF files.  It completely outclasses
anything Microsoft has to offer...


Author Comment

ID: 14184537

You caught me in a typo where I wrote STARTUP.INF
instead of SETUP.INF in my post on June 5.

Here is the way that comment should have read...

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Also, I stumbled on another interesting tidbit that is probably
peculiar to Windows 98...

Coming into AUTOEXEC.BAT these environment variables are
already set...


However, if C:\WINDOWS\TEMP does not exist, one of the
SETUP INF files (while drivers are loaded) substitutes         <----- corrected
xxxxxxxxxxxxxxxxxxxx for TEMP=C:\WINDOWS\TEMP

However, this substitution is defeated if the above two
environment variables are hard coded in AUTOEXEC.BAT

I found a comment in that SETUP INF that explains why.    <----- corrected
If you want to see for yourself, do a FIND looking for
xxxxxxxxxx in the SETUP*.INF files.                                   <----- corrected

* * * * * * * * * * * * * * * * * * * * * * * * * * * *

It turned out to be in SETUPC.INF

Sorry for the confusion caused by my error.

Author Comment

ID: 14184881

I am going through your notes above as I get time and
understand them.  You have provided a wealth of information
that you can use in a book.  Unfortunately, MS officially kills
Windows 98 next year.

I have tried various modifications of LAYOUT1.INF,
including deleting whole sections.   What I have found
seems to indicate that the problem is not tied to individual
entries.  Instead, the system just doesn't like LAYOUT1.INF
to exist at all, regardless of content.

If that is the case, my guess is a problem in the Registry.

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

As an aside, for the record only, with no comment needed...

I have noted in the past that sometimes an empty folder
must be kept on the system for a certain feature to work.
Evidently, some features will not create a required folder,
but depend on it being there.

That was the case with the Norton Windows Doctor program
that I mentioned above.  It requires C:\WINDOWS\TEMP to
exist before it starts.

Now, I wonder about the McAfee anti-virus installation
trying to write temporary files back to the CD, which is
impossible.  Perhaps the installation code defaults to the
CD when a needed folder is not available on Drive C,
perhaps because of my aggressive cleanup routine that
I mentioned before.

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
LVL 39

Expert Comment

ID: 14194304
most of my commants ARE like books  :-)  I'm often not aware of it at the time,
because I type up notes as I investigate things offline, and the content never
looks as long when in Notepad, or MetaPad which has a good search and
replace, and optionally shows url's as hyperlinks.  I have replaced notepad
with metapad as the default web-page "source editor" (ie. Right-Click >
View Source) because of the way it highlights full url's.  Easy to grab the
download without clicking any "accept license" buttons or pages that begin
the download when opened.


[HKEY_LOCAL_MACHINE\Software\Microsoft\Internet Explorer\View Source Editor]

[HKEY_LOCAL_MACHINE\Software\Microsoft\Internet Explorer\View Source Editor\Editor Name]
@="\"c:\\program files\\metapad\\metapad.exe\""

You can also hack Notepad.exe's resources and set Metapad.exe to open instead
of wordpad.exe when a large text-based file is opened through notepad.
I'll give details some time if interested.

I like your theory about the required temp folder for McAfee.  It makes sense.

I have the reverse problem.
When I try to save an image from a web page (Right-Click > Save Picture As),
it often defaults back to C:\My Documents\My Pictures.  I try to avoid folders
with spaces in the path, so I always create new folders "My_Images",
"My_Music", etc, and set these folders in diferent applications as the default
"Save To" directory.
No matter how many times I remove the "My Pictures" folder from the following
registry keys, or reset "My Pictures" to "My_Images", it just keeps reinstating
the old setting:
HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders
HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders
HKLM\Software\Microsoft\Windows\CurrentVersion\explorer\Shell Folders
HKU\.DEFAULT\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders
HKU\.DEFAULT\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders

You know what I would be most curious to see?  An exported .reg file
from the keys:
(ONLY the settings right opposite "CurrentVersion" because that key will
export a massive file)
(Again, ONLY the values opposite "Setup").
Not all of it, and certainly without the product ID and CD-Key.
In particular, I would be interested to know what the values are.

Here's a batch file eg. "GetWin98SetupInfo.reg" to run WITHIN Windows
and creates a final report file "%TEMP%\Win98SetupInfo.txt".  It's very
longhand and disk intensive (I wrote it a LONG time ago when I was
learning computing) but it works OK and condenses the results to ONLY
those needed, by filtering out commonly found values that will relate
to other programs. There will be the odd superfluous "Version" line at
the end of the report, but I didn't know how to get rid of them when I
wrote the batch file. I've removed the commenting for brevity :-)

------------ start of text to copy (DON'T include this line) --------
@echo off
echo SUMMARY SETUP REPORT > %TEMP%\dirtyrep.txt
echo. >> %TEMP%\dirtyrep.txt
echo *** HKLM\Softw\MS\Win\CurrVer\Setup *** >> %TEMP%\dirtyrep.txt
echo. >> %TEMP%\dirtyrep.txt
start /wait regedit /e %TEMP%\tmpreg.txt HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Setup
type %TEMP%\tmpreg.txt | find /i "InstallPathType" >> %TEMP%\tmprep.txt
type %TEMP%\tmpreg.txt | find /i "SetupBinary" >> %TEMP%\tmprep.txt
type %TEMP%\tmpreg.txt | find /i "SourcePath" >> %TEMP%\tmprep.txt
type %TEMP%\tmpreg.txt | find /i "OLSSrcPath" >> %TEMP%\tmprep.txt
type %TEMP%\tmpreg.txt | find /i "Upgrade" >> %TEMP%\tmprep.txt
type %TEMP%\tmpreg.txt | find /i "CommandLine" >> %TEMP%\tmprep.txt
type %TEMP%\tmpreg.txt | find /i "SetupScratchDir" >> %TEMP%\tmprep.txt
type %TEMP%\tmpreg.txt | find /i "SetupTempDir" >> %TEMP%\tmprep.txt
type %TEMP%\tmpreg.txt | find /i "UninstallDir" >> %TEMP%\tmprep.txt
type %TEMP%\tmpreg.txt | find /i "BackupDir" >> %TEMP%\tmprep.txt
type %TEMP%\tmpreg.txt | find /i "MachineDir" >> %TEMP%\tmprep.txt
type %TEMP%\tmpreg.txt | find /i "BootHost" >> %TEMP%\tmprep.txt
type %TEMP%\tmpreg.txt | find /i "BootDir" >> %TEMP%\tmprep.txt
type %TEMP%\tmpreg.txt | find /i "WinDir" >> %TEMP%\tmprep.txt
type %TEMP%\tmpreg.txt | find /i "Old" >> %TEMP%\tmprep.txt
type %TEMP%\tmpreg.txt | find /i "SysDir" >> %TEMP%\tmprep.txt
type %TEMP%\tmpreg.txt | find /i "SharedDir" >> %TEMP%\tmprep.txt
type %TEMP%\tmpreg.txt | find /i "AppsDir" >> %TEMP%\tmprep.txt
type %TEMP%\tmpreg.txt | find /i "WinAdminDir" >> %TEMP%\tmprep.txt
type %TEMP%\tmpreg.txt | find /i "MemphisDetectedLastDrive" >> %TEMP%\tmprep.txt
type %TEMP%\tmpreg.txt | find /i "lastdrive" >> %TEMP%\tmprep.txt
type %TEMP%\tmprep.txt | find /i /V "[" >> %TEMP%\dirtyrep.txt
del %TEMP%\tmpreg.txt>nul
del %TEMP%\tmprep.txt>nul
echo. >> %TEMP%\dirtyrep.txt
echo *** HKLM\Softw\MS\Win\CurrVer *** >> %TEMP%\dirtyrep.txt
echo. >> %TEMP%\dirtyrep.txt
start /wait regedit /e %TEMP%\curkey.txt HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion
type %TEMP%\curkey.txt | find /i /V "[" >> %TEMP%\curver.txt
type %TEMP%\curver.txt | find /i "SystemRoot" >> %TEMP%\dirtyrep.txt
type %TEMP%\curver.txt | find /i "DevicePath" >> %TEMP%\dirtyrep.txt
type %TEMP%\curver.txt | find /i "BootCount" >> %TEMP%\dirtyrep.txt
type %TEMP%\curver.txt | find /i "ProductType" >> %TEMP%\dirtyrep.txt
type %TEMP%\curver.txt | find /i "InstallType" >> %TEMP%\dirtyrep.txt
type %TEMP%\curver.txt | find /i "ProgramFilesDir" >> %TEMP%\dirtyrep.txt
type %TEMP%\curver.txt | find /i "CommonFilesDir" >> %TEMP%\dirtyrep.txt
type %TEMP%\curver.txt | find /i "ProductName" >> %TEMP%\dirtyrep.txt
type %TEMP%\curver.txt | find /i "Version" >> %TEMP%\dirtyrep.txt
type %TEMP%\curver.txt | find /i "VersionNumber" >> %TEMP%\dirtyrep.txt
type %TEMP%\curver.txt | find /i "OldWinVer" >> %TEMP%\dirtyrep.txt
del %TEMP%\curkey.txt>nul
del %TEMP%\curver.txt>nul
type %TEMP%\dirtyrep.txt | find /i /v "Inno" > %TEMP%\filter1.txt
del %TEMP%\dirtyrep.txt>nul
type %TEMP%\filter1.txt | find /i /v "RegPath" > %TEMP%\filter2.txt
del %TEMP%\filter1.txt>nul
type %TEMP%\filter2.txt | find /i /v "PAPI" > %TEMP%\filter3.txt
del %TEMP%\filter2.txt>nul
type %TEMP%\filter3.txt | find /i /v "Country" > %TEMP%\filter4.txt
del %TEMP%\filter3.txt>nul
type %TEMP%\filter4.txt | find /i /v "Convers" > %TEMP%\filter5.txt
del %TEMP%\filter4.txt>nul
type %TEMP%\filter5.txt | find /i /v "Divers" > %TEMP%\filter6.txt
del %TEMP%\filter5.txt>nul
type %TEMP%\filter6.txt | find /i /v "OemInfo" > %TEMP%\filter7.txt
del %TEMP%\filter6.txt>nul
type %TEMP%\filter7.txt | find /i /v "win9xmig" > %TEMP%\filter8.txt
del %TEMP%\filter7.txt>nul
type %TEMP%\filter8.txt | find /i /v "Plus!" > %TEMP%\filter9.txt
del %TEMP%\filter8.txt>nul
type %TEMP%\filter9.txt | find /i /v "dword" > %TEMP%\filter10.txt
del %TEMP%\filter9.txt>nul
type %TEMP%\filter10.txt | find /i /v "description" > %TEMP%\filter11.txt
del %TEMP%\filter10.txt>nul
type %TEMP%\filter11.txt | find /i /v "Ieak" > %TEMP%\filter12.txt
del %TEMP%\filter11.txt>nul
type %TEMP%\filter12.txt | find /i /v "shell" > %TEMP%\filter13.txt
del %TEMP%\filter12.txt>nul
type %TEMP%\filter13.txt | find /i /v "internet" > %TEMP%\filter14.txt
del %TEMP%\filter13.txt>nul
type %TEMP%\filter14.txt | find /i /v "cmi" > %TEMP%\filter15.txt
del %TEMP%\filter14.txt>nul
type %TEMP%\filter15.txt | find /i /v ";" > %TEMP%\filter16.txt
del %TEMP%\filter15.txt>nul
type %TEMP%\filter16.txt | find /i /v "@" > %TEMP%\filter17.txt
del %TEMP%\filter16.txt>nul
type %TEMP%\filter17.txt | find /i /v "Display" > %TEMP%\filter18.txt
del %TEMP%\filter17.txt>nul
type %TEMP%\filter18.txt | find /i /v "Gold" > %TEMP%\filter19.txt
del %TEMP%\filter18.txt>nul
type %TEMP%\filter19.txt | find /i /v ".LOG" > %TEMP%\filter20.txt
del %TEMP%\filter19.txt>nul
type %TEMP%\filter20.txt | find /i /v "Major" > %TEMP%\filter21.txt
del %TEMP%\filter20.txt>nul
type %TEMP%\filter21.txt | find /i /v "Minor" > %TEMP%\filter22.txt
del %TEMP%\filter21.txt>nul
type %TEMP%\filter22.txt | find /i /v "\\Software\\" > %TEMP%\NoPath1.txt
del %TEMP%\filter22.txt>nul
type %TEMP%\NoPath1.txt | find /i /v "\\CurrentVersion\\" > %TEMP%\Report.txt
del %TEMP%\NoPath1.txt>nul
echo %TEMP%\Report.txt is ready
------------ end of text to copy (DON'T include this line) --------

If you want the fully commented version, just email me from the email
address in my profile.  The same goes for any of those handy batch
files or utilities I might have mentioned, or haven't YET mentioned.
Just ask.

In the meantime, I'm wondering whether that computer has an "HP-
branded" IO.SYS or something like that.  Remember that IO.SYS is
executed right at the start of the boot process.  It isn't editable in
notepad, but you CAN see a lot of the textual content using the
PEEK shell extension I provided the download link to earlier.

Meantime, I am examining setupx.dll to see if I can see any calls to
SETUPC.INF or related commands.

LVL 39

Expert Comment

ID: 14199658
I Can't recall if I suggested this before, but what happens when you use the
Start Menu > RUN field with the following command?

rundll32.exe shell32.dll,Control_RunDLL appwiz.cpl,,2

Out of curiosity, I used Sysinternals "RegMon" and left it monitoring the registry
accesses while I opened the Control Panel's Add/Remove Programs, and then the
"Windows Setup" tab.

Here's the salient parts of an extensive flurry of activity within the 4 or 5 seconds it
takes to do that.  It must amount to about 1,000 or so registry key
Open > Read > Close actions.

1. Checks start Menu Order (only if you access Control Panel from a the start menu)
2. Checks "Window Metrics" (check layout to present the control panel?)
3. Calls MAIN.CPL to verify mouse speed, etc.
3. Opens, reads, and closes every sub-folder of HKLM\Enum
4. Checks what "Application Events" are set in HKCU\AppEvents
5. Gets to the nitty-gritty and reads settings in the following keys:

HKEY_CLASSES_ROOT\.EXE and HKCU\exefile and also the "ContextMenuHandlers"
HKCR\CLSID\  (looks for specified Class Identifiers, and reports those "NOTFOUND"
where they don't exist.  There are so many that it's pretty impossible to go through them)

Checks to see if you are allowed to perform certain actions:


Checks the long list of known bad applications, presumably to prevent you
from installing them:


Verifies that "SHELL32.DLL", "SHLWAPI.DLL", and "MSVCRT.DLL" are correctly
registered OR maybe checks the versions.  Not sure.

Gets Win98 version details:

OpenKey      HKLM\Software\Microsoft\Windows\CurrentVersion

Checks some windows behavioural settings:

HKCU\Control Panel\Desktop\SmoothScroll and \Mouse

***** Opens the "Install/Uninstall" tab of Add/Remove Programs ***

Calls C:\WINDOWS\SYSTEM\APPWIZ.CPL through RunDLL32.exe.

Checks for the existence of the key:

(On mine it reports "NOTFOUND", but presumably it HAS to know if this exists
so it can list installed aplications).

Queries "SETUPX.DLL".  Not sure exactly what it is doing, but maybe just checking
that it is correctly registered and ready to go:

Rundll32 QueryValueEx 0xC1C90190\SETUPX.DLL SUCCESS "SETUPX.DLL"

It MIGHT actually be calling Setupx.dll to check the settings in the keys:
Catalog, Cert, and INF.
Checks for the existence of the key:


"EBD" refers to "Emergency Boot Disk", so I suppose it's preparing the details
should you then move across and click on the "Startup Disk" tab.  On my system,
the key that holds details of what .inf files to check for preparation of a boot floppy
is as follows, so "EBDPage" is reported as "NOTFOUND" in my registry because my key is:

Checks what Windows Updates, patches and other "Active Setup" installed
components are installed:

HKLM\Software\Microsoft\Active Setup
HKLM\Software\Microsoft\Active Setup\Installed Components\
HKLM\Software\Microsoft\Active Setup\Installed Components\

HKLM\Software\Microsoft\Internet Explorer
HKLM\Software\Microsoft\Internet Explorer\LPKInstalled
HKCU\Software\Microsoft\Internet Explorer\International

Checks what other non-Active Setup programs are installed.

(Reads the names of installed applications and their "UninstallString", but it still
would not appear to have reached the Windows Optional Components as it is
still on the "Install/Uninstall" tab)

Finally uses shell32.dll to display the list of installed components  using the class
identifier for "My Computer".

In summary, I CAN'T see where it specifically accesses the "Windows Setup" tab,
and it doesn't list any of the .INF files checked, because this was a "Registry"
monitoring utility that limits itself to just that.

Going back to the call to setupx.dll:

Rundll32 QueryValueEx 0xC1C90190\SETUPX.DLL SUCCESS "SETUPX.DLL"

Out of curiosity, I typed various permutations of that command (with commas and
spaces in different places) into a DOS box and also the Start Menu's "Run" field,
but it just dies with no feedback.  Presumably the correctly structured command
will issue an error code to say whether it has been successful in locating that
"Entry-Point" in setupx.dll.

Going back to your link in the other question you opened to pass on points,
the syntax was to be correct:


There isn't actually an Entry Point named QueryValueEx in the resources of setupx.dll
from what I can see, so I checked the functions in setupx.dll for any mentions of "query":


I tried the following command to see what would happen:

rundll32 setupx.dll,SURegQueryValueEx > c:\results.txt
rundll setupx.dll,SURegQueryValueEx > c:\results.txt

It ran without an error, but I have absolutely no idea what it is actually Querying
(ie. the parameters that should be at the end of the command such as a target file),
or how to get the results even if I did know.

Interestingly, the "install" command for the .INF file type should be shown in the
registry (HKCR\inffile) as RunDll.exe and not RunDll32.exe:

c:\windows\RunDLL.exe setupx.dll,InstallHinfSection 132 %1

where the numeric value 132 is derived from the sum of the following numbers,
and the default is 132 (128 + 4 - ie. reboot if necessary and show prompt):

0 - Either "System Provided" INF Or "Never reboot"
128 - Set default path of installation to the location of INF file
1 - Force Reboot in all cases
2 - Always prompt to reboot.
3 - Reboot if necessary NO prompting
4 - Reboot if necessary WITH prompt

Maybe I'm looking into this too deeply, or interpreting the RegMon results incorrectly,
when in fact it could be as simple as indicated here:


"Your setupx.dll error is usually the result of having deleted some empty
folders in Program Files that were placed there when Win Me was installed
that are used for optional components of Win Me. Then when the registry
cleaner was run it removed some necessary entries required for Add/Remove
Programs | Windows Setup to function because the target folders were no
longer present. You can avoid this happening in future by not deleting
such folders and similarly not deleting any values in the key


Gives a list from the VarLDID key, but that pertains to Windows ME.
I am going to compare it with a registry export from my Win98se system and will
report back with findings.


This poor guy also has problems with missing folders but existing  registry entries
referencing them, and vice versa.

I think it's going to be swine of a job knowing what all the default entries and matching
folders should be.  A dirty install might restore them, but your CD is a "Restore CD", isn't it?

Author Comment

ID: 14207029
All of the VXD files mentioned in the original question are now off the system.
They were all required only by McAfee.  Also, all mention of McAfeee has
been removed from the Registry.  So, any fix related to those VXD files
is now moot.  Also, since I no longer plan to use McAfee, I have no way
to test any of the other solutions regarding the anti-virus installation.

As promised, as I find any tools useful for other purposes, I will extract
the information from here and add my own interpretation for new points
award questions, even if I develop the final solution myself.  So far, BillDL
will get at least one additional points award, just for the tools that he has



Yes, the command line use of APPWIZ also failed with the same
General Protection Fault.  I ran it from a batch file after starting
REGMON.  I could see where it started, but REGMON generates
so many entries so fast that I couldn't tell where the error hit.
It does appear that LAYOUT1.INF completed, unless the processing
of table entries is in reverse order.

I have never used it, but I recall something about DEBUG being
used as a trace routine.  As you mentioned, REGMON only tracks
registry processing.  That is little help for application programs.

Back in legacy main frame days on IBM equipment we had a trace
routine that allowed us to step through a test, one line at a time.

By the way, do you happen to know the significance of the
NOTFOUND message?  I see it even though the module is on
the system in the designated folder.

I now suspect that messages like General Protection Fault may
be default messages when some module is missing that is
supposed to handle and error condition.

According to Dependency Walker, four support modules for
APPWIZ are missing on my computer...


Unfortunately, these modules may be required for XP or ME
but not for 98 SE.  There is no way to tell.  Perhaps you could
check to see if you have them.  I have seen comments via
GOOGLE saying that unless 98 SE clearly requires a module,
it shouldn't be added, no matter what Dependency Walker says.


Expert Comment

ID: 14208323
Interesting, when googling, asking jeeves, or searching the McAfee site,
the file mckml.vxd cannot be found. Only mckml.sys which seems to be related to Win2000.
After searching for the file version (, I could only get result's dating back to 2002
which were related to Zone-Alarm.

What version's of McAfee software was you using, and when did you first install Zone-Alarm?
If Zone-Alarm was inactactive, it might of been a good idea to of had it removed before continuing
This could possibly of been a compatibility issue, if both apps were updating together, Perhaps not.

I would like to hear more of the mckml.vxd file!

Author Comment

ID: 14208726
The lower case r (R) and the lower case n (N) together look like the
lower case m (M).  I may have had the typo in my original question.

Anyway, GOOGLE brings up many references to
m c k r n l . v x d   (without the spaces) as being
a McAfee anti-virus  file.  I didn't find anything
about it being used with Zone Alarm.

I have Zone Alarm installed and it hasn't given any indication
that it is missing any VXD files.

The McAfee virus scan was 2005 version 9.0
LVL 39

Expert Comment

ID: 14209428
If you install IE 6 in Windows 98, it installs a version of shlwapi.dll that contains
the internal resources to call two .dll files that will not exist in a Win98 installation.
This is explained quite well here (I've split the url over two lines):

In summation, in case that page disappears:

IE6 installs shlwapi.dll version 6.00.2800.xxxx and IE6 SP1 merely updates the
file.  This version will show in its properties as 6.00.2800.1612 (xpsp2.041207-1145).
In other words, it is an imposter belonging to Windows XP, and either the IE6 install
routine does not do sufficient version checking, OR IE6 NEEDS that file version to
actually function.  I suspect the latter, because I have tried numerous different
older versions of shlwapi.dll retrospectively in an IE6 in Win98 setup.  They aren't

This version of shlwapi.dll includes new functions for SHELL32.DLL and OLE32.DLL,
but I don't think that those new functions are terribly relevant until you see how
dll functions are interdependent on each other.

There are two internal resources in this version of shlwapi.dll that are unique to
Windows XP, and those are functions to call the files userenv.dll and apphelp.dll
that are never found in Windows 98.  On some peoples' systems, this shlwapi.dll
can cause problems anywhere from failure to boot, to general glitches like random
freeze-ups and error messages at unexpected times.  I noticed a few more freeze
ups and error messages after installing IE6 SP1.  The above URL references the
use of "Dependency Walker" to witness these extra functions to non-existent files.

Your scan of APPWIZ.CPL refers to missing AUTHZ.DLL, NTDSAPI.DLL, and
NTLANMAN.DLL.  My version (unchanged and native Win98se version 4.10.2222)
ONLY tells me about shlwapi.dll's dependency on the usual two dll's, namely
userenv.dll and apphelp.dll.  It makes NO mention of the others as yours does.

I would be very curious to see what version of appwiz.cpl is installed on your system.
I have exported the Dependency Walker report as a .csv file and opened in in Excel.
Here are columns B, E, and P copied out (full path to files cut back to filename only):

Module Name, File Size, File Version:
SHELL32.DLL, 1388816, 4.72.3812.600
OLE32.DLL, 790528, 4.71.2900.0
ADVAPI32.DLL, 65536,
APPWIZ.CPL, 72192,
COMCTL32.DLL, 548624, 5.81.4916.400
GDI32.DLL, 155648,
KERNEL32.DLL, 471040,
MSVCRT.DLL, 290869, 6.1.9359.0
SHLWAPI.DLL, 402432, 6.0.2800.1612
USER32.DLL, 69632,
CFGMGR32.DLL, 45056,
COMDLG32.DLL, 176128, 4.72.3510.2300
LZ32.DLL, 24576,
MLANG.DLL, 574976, 6.0.2800.1106
MPR.DLL, 57344,
MSI.DLL, 1930240, 2.0.2600.2
NTDLL.DLL, 20480,
OLEAUT32.DLL, 929792, 2.40.4518.0
RPCRT4.DLL, 339968, 4.71.2900.2
SETUPAPI.DLL, 409600, 5.0.1671.1
WINMM.DLL, 65536,

A good utility for browing different folders for specified file types, and quickly
checking the file versions is "Version Browser" by Karen Kenworthy.

You get a VERY long report if you save the dependency walker report as a .txt file,
but it is useful in generating a sorted list of "Known DLL's" from the registry key:
(Remember the standalone program MetaPad that I mentioned before?  Great for
viewing large .TXT files and maintaining unembellished ascii text when resaved).

Those extra 3 DLL's are NOT registered as "known" in MY registry, and do not exist in
any of my folders on this hard drive.  They cannot be extracted from any of the .CAB
files on my Win98SE CD either, so it is fair to assume that they are NOT native to
Win98se.  I checked a Windows ME CD, and the results are the same.

As you anticipated, however, my Windows XP Pro CD DOES contain these files.
The Win98 DOS EXPAND command doesn't seem to expand the files correctly
(ie. no property pages and are seen as non-32-bit) BUT the EXTRACT command
DOES because of the compression encoding used on them.

Version 4.90.3000 Size 79,872 bytes
(Same results in Dependency Walker as the WinSE version on MY system).

My Win98SE APPWIZ.CPL file:
version 4.10.2222 size 72,192 bytes.

Windows 98 First Edition APPWIZ.CPL:
Version 4.10.1998 Size 72,192 bytes

Windows 2000 Pro Versions from CD:

APPWIZ.CPL - 5.00.2134.1 Size 296,208 bytes
AUTHZ.DLL - Does NOT Exist
NTDSAPI.DLL - 5.00.2160.1 Size 57,616 bytes
NTLANMAN.DLL - 5.00.2157.1 Size 36,112 bytes

Dependency Walker on APPWIZ.CPL - same results as the Win98 version,
ie. UserEnv.dll and AppHelp.dll.

Versions expanded from the original Windows XP pro CD:

APPWIZ.CPL - 5.1.2600.0 (xpclient.010817-1148) Size 558,592 bytes
AUTHZ.DLL - 5.1.2600.0 (xpclient.010817-1148) Size 51,200 bytes
NTDSAPI.DLL - 5.1.2600.0 (xpclient.010817-1148) Size 64,512 bytes
NTLANMAN.DLL - 5.1.2600.0 (xpclient.010817-1148) Size 38,400 bytes.

Processed through Dependency Walker show that APPWIZ.DLL tries to link to the
following non-existent files:

Versions shown on my Windows XP SP2 computer are:

APPWIZ.CPL - 5.1.2600.2180 (xpsp_sp2_rtm.040803-2158) Size 552,960 bytes.
AUTHZ.DLL - 5.1.2600.2180 (xpsp_sp2_rtm.040803-2158) Size 56,832 bytes
NTDSAPI.DLL - 5.1.2600.2180 (xpsp_sp2_rtm.040803-2158) Size 67,072 bytes
NTLANMAN.DLL - 5.1.2600.2180 (xpsp_sp2_rtm.040803-2158) Size 43,520 bytes

Didn't run this one through Dependency Walker.

IF your APPWIZ.CPL file matches any of the above, I suggest that should be the
first file to extract from the Windows 98 CD.  Use Start Menu > RUN > SFC to extract
a copy so that it updates the file version table.

It would appear from my findings with Dependency Walker on the Windows XP
file version that there are other gremlins at work, and ALL of the referenced
DLL's should be checked to see if they are non-native versions.

You should be able to figure out exactly what .dll file is referencing those .dll's, and
then specifically check their versions and dependencies to get a picture of whether
this is ONE rogue dll or a family of wrong dll's that has been installed.

Also it's useful to know about the list of Shared DLL's and other KnownDLLs etc held in:

NOTE:  There are probably two "session manager" keys on your system.  One with a space,
and the other without a space.  The "SessionManager" one holds the details above
on my system.

Some software install routines these days are pretty bad in their version checking,
and just force XP file versions onto your system.  The result sometimes is a failed
boot when the routine forces it on you, and this aspect is really annoying.  I think
that developers just can't believe that so many people are still using Win98, or
are too lazy/don't know how to version check and ONLY install the appropriate
file versions for that OS version.

Personally, that's why I believe there are so many problems with the releases of
Symantec and other (possibly McAfee also) applications releases around 2003, when
installed in Windows 98.

Regarding the VXD file, there are a couple of places you can check first of all to see
if there are any mentions of MCKRNL.DLL:

(Still thinks that they might be there)

(Has been packed into VMM32.VXD by something by dropping it into the following
folder and then forcing a reboot: :\WINDOWS\SYSTEM\VMM32).

If there WAS some version conflict, then it MAY have backed up the file to:
C:\WINDOWS\SYSBCKUP or C:\WINDOWS\VCM.  The VCM folder contains the files
intercepted by the Version Conflict manager and backed up when being replaced.
Start Menu > RUN > and type VCMUI > OK to see the list and options.

You should ALSO be aware that Microsoft Plus! 98 installs MCKRN.VXD and also the
files MCKRNL.16.DLL, and MCKRNL32.DLL.  I've never had it installed, but your HP
CD could well have integrated it as part of the package.  Clearly it is still a component
of McAfee AntiVirus, and it is therefore highly likely to have been replaced by the
more recent McAfee version when you installed it.  Uninstalling McAfee AntiVirus could
easily have done any of the following:

(a) restored the old version by which time you had already uninstalled Plus! 98
(b) restored the registry's refence to the file, but not restored the file
(c) restored references to the file in other initialisation files and failed to reinstate the file.

Full list of Microsoft Plus! 98 files here:

Incidentally, I see you used "Ask Jeeves".  Have you ever typed in a few filthy and
invasive questions of Jeeves?  The canned responses are hilarious.
I sometimes buy a UK National Lottery ticket online, and they have a HELP function
that is quite clever.  You can probably get there by pasting the following URL in
your address bar:
or by going to the following page and clicking the "Help" link at the top left of the page:
Type in a few enquiring questions that you would like "Elvie" to answer about herself
and her personal preferences  :-)

Anyway, have a look at the APPWIZ.CPL and related .DLL's to see what is going on
in there.  I would be really interested to know what application forced XP versions.

Author Comment

ID: 14218045

You may not have noted that it was EE member (expert) nep1 who posted the
comment about the Ask Jeeves thingy.  I never use it.  Also, if you thought I
made that post their are other points he raised that I feel are now moot.

My version of SHLWAPI.DLL is 6.00.2800.1612, same as yours.  I have an old
backup version 6.00.2800.1400 but what is most peculiar is that Help/About
at the top of the screen shows version 6.00.2800.1106 - indicating a possible
registry entry mismatch somewhere.

My version of appwiz.cpl is 4.10.2222, same as yours.  So, there must be some
other glitch that is giving us different results from Dependency Walker.

I already had REGMON from SysInternals.  As I mentioned before, I tried it
and it didn't really help the analysis.

I downloaded FILEMON from SysInternals and have set up sophisticated
batch files and folders to control both products.  Again, FILEMON generates
so much garbage that it is difficult to make sense out of it.

Your substitute for WORDPAD is interesting and I may try it later.  In the
meantime I have been using a powerful editor/viewer that is part of a package
created years ago by a company that is no longer in business.

What I did learn is that the system processes the layout files in sequential

Yet, we know the bug has something to do with LAYOUT1.INF

That tells me that some entry in LAYOUT1.INF gets processed AFTER all
three INF files have been read.  My guess is that their contents are used
to build a table that is validated after the three INF files are long gone.

The scary thing to consider at this point is that there may be multiple
bad entries in LAYOUT1.INF and that would be almost impossible to run down.

I did learn the hard way that the error code is saved somewhere and triggered
on repeated testing so that processing the files is not in the same way as the
original.  That little nasty forces me to RESTART the system between every
test.  Bummer.

I don't like the Registry concept at all, just as I detest dynamic libraries.
If I had my way all CONTROL data would be frozen and could not be changed
by new after-market software installation.  And, viruses/spyware could not
change ROM CMOS.

Sure, our friend Bill G has come up with something that operates fast, but
at what cost in maintenance and debug time for the suffering user?

You may not have thought about it, but it now dawns on me that most of the
problems we face are a direct result of our not having source code available.
It is apparent that MS is so paranoid about the competition doing reverse
engineering that they have created a maintenance nightmare.  That is why
we are constantly admonished to restore the system from scratch.  Theoretically,
that would provide a common starting point, but every user has a different
system configuration.

Expert Comment

ID: 14222301
BillDL, thanks for the reply anyway! sysandprog, sorry if my post was not of any help.
I would of liked to have worked through both your post's in detail, but have run out of time!
In about 3 hours time, I'll be flying to my holiday destination :-) Can't wait... See you in 2 week.

Author Comment

ID: 14222728

Good luck on your vacation.  Recently I had back-to-back long distance trips by automobile.
One was to a grandson's formal high-cost wedding.  The other trip was to take one of the
wedding guests, our granddaughter, on a 3 day trip to visit the university where she will
be employed as a math professor this fall.  She and her new husband went to the justice
of the peace office to get married a few days before our grandson's wedding.  Upset his
bride no end.  Our granddaughter and her new husband will be separated by 500 miles on
their first jobs after getting their PhD degrees.  How about that?!?!

In the USA many of us our refugees in our own country, with our families scattered.

Author Comment

ID: 14222955

I am completely confused about the role that is played by LAYOUT.INF, LAYOUT1.INF,
and LAYOUT2.INF when called by appwiz.cpl.  My system shows a modification date
of 5/3/99.  The corresponding PNF files have a modification date of 8/10/01, which
probably dates back to an original installation of Windows 98.

Yet, we know that files are being added and removed on a continuous basis.  So,
there would be an obvious conflict on file size.

To satisfy my curiosity further, I extracted the entries from the LAYOUT1.INF into
a temporary file and sorted them, with the idea of manually comparing to the
corresponding files on the computer.  That turned out to be impossible, because
of the number of entries.  Also, there are 34 different file types (extensions),
including even .HTM and .HLP and .WAV, which seems absurd.

I did look at 3 types in more detail - .386, .ACM, and .AX with disturbing findings.

These two files are not on my system...


And these two files have modification dates later than the LAYOUT files...


My guess is that this pattern repeats many times over for LAYOUT1.INF but
their might not be a problem as long as the entry point and file size remained
the same.

I find this all quite irritating, because it tends to prevent the computer owner
from getting rid of original junk that is never used.  For example, I may have
modified some original .HTM or .HLP files, which would have changed the size.


Author Comment

ID: 14223016
Typo apology...

For some strange reason I sometimes type
"their" for "there" and vice-versa or
"our" for "are".


By the way...

Would it be any help for me to post the sorted entries
from my LAYOUT1.INF file?

Author Comment

ID: 14224133
There are only four files in C:\WINDOWS\SYSTEM\VMM32

IFSMGR.VXD    9/19/2000
IOS.VXD          4/23/1999
MRC12.VXD     4/23/1999
OEMMFIX.VXC 4/23/1999

There are quite a number of files in C:\WINDOWS\SYSBCKUP

Regarding version conflicts...

Running VCMUI brings up a blank screen, but there are four files

ACPI.SYS           7/23/01
PCI.VXD            7/23/01
USBHUB.SYS     7/23/01

LVL 39

Expert Comment

ID: 14228062
Whooops, it has just been you and I in here for so long that I didn't even
notice that the comment about Jeeves wasn't yours.  I had wondered
briefly why you had brought up the vxd subject again, but just assumed
it was curiosity about the vxd issue.

Sorry about the delay, I've been looking very deeply into the reason why
your Dependency Walker findings for shlwapi.dll show the extra 3 DLL's
that don't show in mine.  It has me baffled, because they are most certainly
Windows NT/2000/XP files.  All 3 are found in XP, whereas only one or the
other is found in NT/2000.

Process File: ntdsapi.dll
Process Name: NT5DS
Module that contains a set of COM interfaces used to access
the capabilities of directory services from different network
providers in a distributed computing environment.
The file is used to present a single set of directory service
interfaces for managing network resources.
ntdsapi.dll  Version: 5.1.2600.2180
(URL split over 2 lines)

LAN Manager.  The "Choose Computer" is a dialog provided by
NTLANMAN.DLL for Windows 2k/NT/XP to display the servers
and their computers.
ntlanman.dll  Version: 5.1.2600.2180

SpamPal - Discussion about a spam filtering file named
bayesian.dll and its dependencies.
I don't suppose that this utility program is involved?

I've also been studying the Windows 98/98se updates and patches
available from Windows update, and this brought me to the mention
of the "Help > About Internet Explorer" subject raised earlier.
Here's what mine says (the "Update Versions" is retrieved from the
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Internet Settings

Version: 6.0.2800.1106IS
Cipher Strength: 128-bit
Product ID: xxxxx-OEM-xxxxxxx-xxxxx
Update Versions: SP1; Q867282; Q837009; Q833989; Q891781; Q313829;
This is a customized version of Internet Explorer.

Take note of that Q867282 Update, I'll get to it in a moment.

I can't recall if the "customized version" line was added by me in
the registry.  I have had two other systems here running Win98se,
and I have tested out the unofficial Win98se SP1 and 2 updates on
them, but I can't remember if I installed the SP1 update on THIS
computer.   That might account for the "customized version" line in the
"About IE" box if I did.  It is retrieved from the key:

I refer to the Unofficial Win98se updates listed here:

Changelog and latest 2.0.1 update:

Author's warning note:
"Uninstallation needs Windows 98 SE CD-ROM. It also doesn't remove
all installed files. It only reverts back half of the installed files
with original 98 SE files. So, I don't recommend uninstallation of the
pack if you don't have any serious problems".

I wouldn't necessarily recommend it on your system anyway, given that
you have an HP OEM Win98 Install CD.

I have discovered the source of the shlwapi.dll file installed on my system
that shows its version as 6.00.2800.1612 (xpsp2.041207-1145).
It was installed by the Windows Update KB867282 which downloaded
as a temporary file during Windows Update as:
MS05-014: Cumulative security update for Internet Explorer:

Looking at the internal resources of the shlwapi.dll that this update installs,
not only does it link to the dll's showing when I run Dependency Walker
(apphelp.dll and userenv.dll), but also to the ones that show when YOU run
it (authz.dll, ntdsapi.dll, and ntlanman.dll).  This really puzzles me.

Because of the nature of these files, I had two theories that hinge on the
possibility of programs or applications previously installed, but now removed,
having left non-native or incompatible .dll's on your system:

1. An HP additional extra that has been installed from either the CD
or from any extra HP downloads you later installed, and this has
introduced a non-native version of a .dll file linked to shlwapi.dll.
In other words, it isn't shlwapi.dll that is showing up the links to
the missing AUTHZ.DLL, NTDSAPI.DLL, and NTLANMAN.DLL, but another
dll linked to by it.

2. Synchronising or Connectivity Application for Mobile Technology.

I checked out DCOM98 as a possible offender, given the nature of the technology,
but it does not install a different version of shlwapi.dll.  It DOES, however, install
rpcrt4.dll which seems to crop up with great regularity in google pages
concerning problems with ntdsapi.dll and ntlanman.dll.

As an aside, were you aware that Microsoft software coders seem to have a
lot of time on their hands to add to the bloatware of Windows by adding text
strings like this to DOSSETUP.BIN on the Windows 98 CD?
"Wassily Kandinsky was the great Russian painter who participated
in the Expressionist movement in Germany, taught at the Bauhaus,
and edited the Blue Rider Almanac".
I can't recall that being shown during Windows Setup!!!  :-)

Regarding your LAYOUT1.INF file.  What you are seeing isn't out of the ordinary,
although needless to say that there are loads of files listed in there that you will
probably never see.  Remember the sequence I mentioned a distance back up this
page about how the "Baseline" for the System File Checker (SFC) was created?

I will need to get back to you on this one as I really need some sleep, but basically
what happens is that the 3 LAYOUT.INF and 3 COPY.INF files really just act as the
index files to tell the process where to find the files on the CD, what size they are,
and where they should be copied.  They list ALL possible files that COULD be

The files that do the work are setuppp.inf and setupc.inf.  Remember that you then
go on to choose the install type (compact, typical, custom, or network), and the list
of required files is compiled.  The DETAILS for each file are retrieved from the layout
and copy files.  Note that setuppp.inf is copied as setup.inf and usually remains in
the INF folder.

You can actually stop setup from copying, or even looking for files to copy, by extracting
setuppp.inf to the folder containing the setup files if installing from a hard drive, and
selectively detete filenames from it.   You then modify the layout file and tell it that
setuppp.inf is loose rather than packed in a cab file.

(Using the full install Win95 OSR2 CD-ROM to Upgrade from Win95)

If you need to see the options selected at install, and the process involved, then
you should still find the file C:\SETUPLOG.TXT.

I will try and find my notes that detail the exact process step-by-step and indicate at
which point each of the files is accessed, created, or copied.

I have extracted all of the relevant .INF files to check through, but I wish there was
some way I could get copies of yours so I could do a side-by-side comparison and
look for differences.

I'll be back later with more.

Author Comment

ID: 14237937

Testing with FILEMON and REGMON from SYSINTERNALS seems to indicate that the
General Protection Fault occurs in Registry processing.  However, it is easier to
track the processing in the files.  I tried to slow the processing by substituting a
Ray Charles music piece for the Utopia Error.wav but it didn't seem to have any
effect, probably because of parallel processing.

One thing that the testing reveals is that the system has trouble locating the
actual location of the files and sometimes "goes hunting".  I was startled to see
an old file version being targeted in the backup folders that I created.  That might
explain some of the mysterious crashes that you mentioned and I have experienced.
Now I must consider either renaming backup entries or moving them to CD.

Also, I saw one file that has the same version and date as the original, but has a
different size.  My first reaction was that the file had spare space in it.  Of course,
one must worry about that 16/32 thingy, too.  I have some very old utilities on
my system and don't know how they store files.

If what I saw is a true picture of the processing it tells me that either the
Registry design is defective or my Registry has significant bugs, even though
I have used Registry cleaner programs.

It appears that resolution of the 16 bit versus 32 bit design is by way of the

I have been somewhat casual about the folder order in the PATH.  Now I see
it is significant.  For example, if C:\ is the last in the chain and C:\WINDOWS
is at the beginning, the DOS DIR /S command won't look in C:\WINDOWS

It may or may not be significant, but I have not been able to get REGSVR32
to work and have not had the time to track down the problem.


Author Comment

ID: 14237949

You posted from your IE Help/About for system versions.  Mine shows far more updates
from Microsoft, and I have tried to limit mine to mostly Critical Updates.  I suppose there
is the remote possibility that updates outside the USA are different.

Also, in an earlier post you asked if I had copied the original CD to the hard drive.  What
I have on my system is C:\WINDOWS\OPTIONS\CABS and have wondered if any of the
updates has messed with that.

By the way, in answer to your query many posts back, my CD is on drive M:\
LVL 39

Expert Comment

ID: 14240573
Taking your last point first, yes Windows Updates DOES mess with c:\windows\options\cabs.
I have partitions C, D, E, and F.  I have the win98, tools, and drivers folders from my Win98 CD
on the F:\ partition along with another 5 GB of essential folders containing things like:
Office 2000 - both CD's and service packs, Driver installer files for all my hardware, .REG scripts
for all occasions, IE 6 SP1, My Windows Update installer files, etc, etc.

I run setup from the folder on the F: partition after I format the C:\ drive, and my
C:\Windows\Options\CABS folder is NEVER populated.  Not sure if this is because of the setup
switches I usually use (setup /id /ie /im /is /iv /IW /nr), or simply because the source was
determined as the folder on my F: drive.

After running Windows update, OR after installing the selected updates that I downloaded from
the Corporate site (http://www.microsoft.com/windows98/downloads/corporate.asp), my CABS
folder becomes populated with loose dll's, vxd's, sys, inf, and exe files.  Looking at them, and
comparing them to the sub-keys of
it is clear that these files were dumped there by the respective windows updates.
Those sub-keys provide details of the version numbers of the files installed by each update,
but don't set the CABS folder as the source, or anything like that.  I have been hesitant to
delete these files from my CABS folder, even though I am tempted.  I do know that the updates
DON'T use the CABS folder to store the previous file versions as backups, because the files
in there match the current versions installed.  Of course, a lot of Windows updates are
uninstallable, so they aren't going to create backups as a matter of course.

Most of the Compaq computers I have seen that came preinstalled with Windows 98 and provide
a Recovery CD, also roll some essential Windows Updates into the original installation.  I am
quite sure that I am correct in saying that these computers are set up by running setup through
a batch script that installs the drivers DURING the installation, and that would mean dumping
loose files into the "install source" folder so that they are picked up from there rather than
setup having to hunt through the CAB files for the referenced files.

My reason for this assumption is the fact that in the root of the "OPTIONS" folder (mine is empty),
there are usually a couple of files named *oem* or *.oem.  Their structure is in the format of
a setup INF file.  They don't seem to control the full installation, but rather the latter stages
of the factory installation where files and settings are "branded" and unwanted settings and
files are removed.  From what I can see, these files are used when you use the recovery CD
to reinstall Windows, and it knows that the CABS folder is the original "Install Source".

Further to that, they also often add the extra sub-folders OLS, PWS, and TOUR to the CABS folder,
where these would normally be in the root of the CD.  In other words, the CABS folder is
used as the local replacement for the root of the Win98 CD.

It all sounds to me like you have some kind of mismatch between original OEM system file
versions and new ones from Windows Updates and subsequent software installations, and the
differing file sizes for the same file versions is slightly worrying.

If you have access to a Windows XP CD, then you can extract the file "dupfinder.ex_" from the
\Support\Tools\SUPPORT.CAB file as a standalone duplicate file finder in Win98.  It allows you
to set various options, and you can filter the results to show file sizes, versions, CRC info, etc.

I really don't know where you can go from here to try and restore the system to some kind
of normality.  It would be a pity if you had to reinstall from scratch, and it transpired that the
problem was isolated to only one or two bad lines in an .inf file or the registry, but on the
other hand it is becoming like the "needle in the haystack" hunt.  I have to say that I admire
your determination.  I sense that you are a bit like me in that you HATE having to give up on
something that is so annoying and COULD be deceptively simple in cause.  I do know that if
I had that computer here with me, that I wouldn't get any sleep until i found the problem.

I am tempted to ask admin if i can open a new question somewhere for the sole purposes of
allowing you to copy and paste the contents of the various setup inf files on a temporary
basis to allow me to copy and compare them, and then delete the question afterwards.
I really do want to see what differences there are on your system when compared to mine.

I will get back to you about this, because once again work beckons me to travel 15 miles to
work in rush-hour traffic, except that THEY are all going home, and I'm coming from there.
90 minutes to travel 15 miles some days into glasgow city centre!!! Shocking.
Be back about 2.30 or 3 am GMT to deliberate further :-)


Author Comment

ID: 14247007
We have people in our neighborhood who commute to The City and vicinity on a daily
basis.  100 miles.  2 hours each way.  On our recent visit to Charlotte, North Carolina
we noted the traffic there as being awful.  One of our freeways has turned into a
monster truck route, with people getting killed quite often.

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

I feel certain that my present computer problem is something simple.  Our diagnostic
techniques are different.  One could validate control files "until the cows come home"
and simply run out of time and energy.  My debugging technique is to look for symptoms
and try to follow the processing.  Unfortunately, Microsoft's paranoid design makes
this extremely difficult.  In any sensible design one should at least be able to identify
which module is failing, and why.

You may have missed my comment a few days ago that it appeared that LAYOUT1.INF
caused the failure JUST BY BEING THERE, even with nothing in it - as I tested by
deleting most of the content.

Yet, during the FILEMON runs it is apparent that the layout files process OK, in
sequence --> LAYOUT.INF --> LAYOUT1.INF --> LAYOUT2.INF  and then, sometime
after that the fault seems to appear in registry processing, where I can see the
Utopia Error.wav being called.  It doesn't make any sense to me that an error would
be triggered and passed forward for the system to deal with a number of steps later.

I made a half-hearted effort with the FIND command to see which files contain
references to LAYOUT1.INF but the result was far too many to check out.  I
thought that, perhaps, some file might have an additional phony call.

In the meantime I really must dig some more into the problem with REGSVR32
which I had never tried to use before.  If it is honked up, it appears that would
negatively impact all software installation from downloads.

Author Comment

ID: 14249360
A - L - E - R - T

Turns out I jumped the gun in blaming LAYOUT1.INF for the
General Protection Fault when using APPWIZ.CPL

Additional testing reveals that the LAYOUT files are processed
in sequence.  If LAYOUT1.INF is missing from the chain,
LAYOUT2.INF is not processed.  But, if LAYOUT2.INF
is the only one of the three that is not present, the General
Protection Fault will not occur.

Then, the application window will popup, but the SIZE of
each selected module will show as ZERO.  Evidently the
system is trying to determine the size for the table entries
when the error occurs.  Or, just before that phase.

Still more tests reveal that normal testing (but leaving out
LAYOUT2.INF) will have this sequence of operation...


...where the LAYOUT2.INF steps consist of many repeated
attemps to locate it.  After that, unfortunately, the FILEMON
program skips about 4000 steps before SETUPX arrives on
the scene.

When LAYOUT2.INF is back in the chain, the step with
SETUPX.DLL is never recorded before the ERROR hits.

At this point there is no way for me to tell whether or not
leaving out LAYOUT2.INF causes other INF files to be skipped
as well.

So far I still think the failure takes place during Registry
processing.  It is too bad there is no utility that combines
FILEMON and REGMON into one operation.

Unfortunately, in the past I have deleted things from the
hard drive without always being careful to go through
the uninstall process to make sure the Registry is clear.
For example, I deleted all of the games, yet I note that
some continue to be described under Windows HELP.

To sum up - it would have been futile and a waste of time
to provide a copy of LAYOUT1.INF for comparison.
LVL 39

Assisted Solution

BillDL earned 1680 total points
ID: 14251659
I tried to run FileMon and RegMon as close together as possible, launch the
"Windows Setup" tab, and then stop the logging in both utilities as fast
as I could, but it is a nightmare of spaghetti to plough through.

I would say that the regsvr32.exe error is one that definitely does need attention
or software applications aren't going to be able to register dll's and ocx's.
It is often called at reboot from the "RunOnce" key.
regsvr32 relies on being able to find the entry point to the target file.

regsvr32 [/u] [/s] [/n] [/i[:cmdline]] dllname

-u or /u - Unregister target file (calls internal function "DllUnregisterServer")
-s or /s - Silent (display no message boxes)
-c or /c - Console output
-i or /i - Call "DllInstall" internal function, passing it an optional [cmdline]
-n or /n - Do not call function "DllRegisterServer" (must be used with /i)

regsvr32.exe - Import table:

My current file version is 5.00.1641.1  (same as installed by the Micorosoft
Libraries update for Windows 98):
The original regsvr32.exe from the Win98se CD is 5.00.1586.1.


Don't know the significance of the "7" value in my registry.

>>> "Our diagnostic techniques are different...My debugging technique
is to look for symptoms and try to follow the processing". <<<

Yes, that's the unfortunate thing about considering a problem without having
access to it.  I am trying to ascertain the LIKELY causes of the given symptoms
if I were to alter something, but based on MY current setup.

Does DRWATSON intercept the error and take a snapshot, or does the fault prevent
Dr Watson from running?

Remember that a Win98 inf file has to have ("$CHICAGO$") in its header section
or it will not be recognised as a valid .inf file.

I wonder if those 70 blank lines between the last line of the
[DosAppVersion] section and the [SourceDisksNames] section
are there as a requirement to functionality in layout1.inf?

It's the same in the setuppp.inf file that should subsequently
be removed after installation.  There are large areas of white
space above and below the "ProductType=" line of the [data]
section.  I have a feeling that this was to make users think
the first lot of blank space was the end of the file, because
the "ProductType=" " value is the one that determines if it is
an aupgrade, oem, etc, and one type won't ask for the CD-Key.
Maybe they think we are stupid.

Here's the results of my investigation so far......

Systematic Approach to logging events that occur as "Windows Setup"
tab is opened.

Sysinternals FILEMON

1. Filemon.exe in any folder and first configured.
2. Place the following batch file in same folder:

@echo off
start filemon.exe
C:\WINDOWS\RUNDLL32.EXE shell32.dll,Control_RunDLL appwiz.cpl,,2

When run, it starts filemon.exe (as previously configured), and then
opens the "Windows Setup" tab of add/remove programs, but without
having to go through the start menu or my computer.  Accessing the
"Windows Setup" tab through either of these normal methods adds a
whole load of superfluous activity at the start of the log.

3. As soon as the "Windows Setup" has finished "searching for installed
components", I clicked "Cancel" and then stopped FileMon from logging
by clicking the "Capture" toolbar button.
4. File > Save As > anyfilename.log
5. Open logfile in Metapad (, and use the "Edit > Replace" function to
find all "tabs" ( \t ) and replace with comma ,

You can use MS Word Find & Replace.  Click the "More" button, then click
the "Special" button to show a list of possible characters to use.
For the tab character, use the ^t character, and replace with comma ,

For Wordpad, you can scroll over the space made by a tab, and then paste
this into the "Find What" field to use.  It seems to work on small files,
but Wordpad freezes up for me in large files.

6. Edit > Find > and find first occurrence of "APPWIZ"
7. Scroll back UPWARDS to top > Delete text
8. File > Save As > anyfilename.CSV
9. Close Metapad/Wordpad/Word
10. Double-Click the .csv file to open in Excel.
11. File > Save As > anyfilename.xls.
12. Create Headers on new top line > Data > Autofilter.

Now you have a file in which the columns can be selectively filtered to
unwanted ones only, and then deleted.

In MY case, I filtered the column of results to show ONLY "NOTFOUND" (I
refer to Column F of the spreadsheet, if your tab-delimited to
comma-separated conversion worked as intended).
These results clearly relate to Windows Optional Components that I chose
NOT to install.  These entries all relate to the "SEARCH" and "SEEK"
activity that comes after all the .INF files are "READ".  I refer here to
the actions in Column D of the spreadsheet.

The last .INF files to be read right before it starts "Searching" for files
are LAYOUT, LAYOUT1, and LAYOUT2.INF.  More about how these files are read
in a moment.  It does one "Disk Info" action, and then searches for files.

I really can't guess what the difference is between the "NOMORE" and
"NOTFOUND" result.  In my case, all the "NOMORE" results relate to files
like screensavers, background bitmaps, and themes that I never install, but
also includes files like the FAT32 converter, which i would have thought
should be "NOTFOUNDS" as I never install that either.  Strangely though,
included in the "NOMORE" list, is MS backup, which I DID install.

The "NOMORE" entries take up a HUGE chunk of my spreadsheet because of the
slimline custom installs I do, so I filter that column and then delete all
rows.  This leaves me with the "NOTFOUND" and "SUCCESS" results.  Very
similar to the "NOMORE" results, in that they are the files required by
optional components not installed.  Filter and delete all rows.

OK, now left with "SUCCESS", I immediately notice that if I filter
Column E to show ONLY LAYOUT1.INF, what I assume to be the access entry
points in the last column all show that the file seems to be split into
(1KB) 1,024 byte chunks and read in sequence.  All the other .INF files
are read in the same manner.

The .BAT file that I initially called FileMon and the "Windows Setup" tab
shows in my list of files read, but that is read in 32 byte chunks.

DLL's are read in 4,096 byte (4 KB) chunks, and .EXE files seem to be
read in a different way.

That's all interesting, but I'm not sure of the significance of this, or
whether it obtains the full file size, splits it into those sized chunks,
and then determines the entry points at those junctures to check the
integrity of the files.  I don't know.

It looks to me like the whole process (over in seconds) does the following:

1. Opens APPWIZ.CPL and calls Shell32.dll to display the results list.
2. Calls setupx.dll which in turn calls KRNL386.DLL, USER.EXE, COMMCTRL.DLL,
3. Opens each .INF files in C:\Windows\INF (but NOT in alphabetic) order,
   and then Reads each file in chunks (depending on the file size), then
   closes it. (see step 7 that seems to explain the order the inf files
   are located and read).
4. Right in the middle of all the .INF files, the process diverts from
   RunDLL32 that seems to have been in charge, over to WINOLDAP, and this
   finds, reads and closes C:\Win\Sys\Toolhelp.dll, vgafull.3gr, and
   winoa386.mod.  I have no files named "WINOLDAP*.*" on my system, but
   Winoldap.mod is a Windows 3.1 file that allows support for older prog's.
   Strangely, this appears as a "SUCCESS" despite absence of this file.
5. There are further instances of interruption away from .INF file reading,
   but it diverts to the "START" command and references MSI.DLL and
   SHLWAPI.DLL, and then later passes control to Kernel32.DLL which CLOSES
6. Control passes back to RunDLL32, and the last .INF files to be read are
   Layout, Layout1, and layout2.INF (in that order).
7. Now the process "Searches" for files, and seems to do so in the order
   that the files are listed in the .INF files read, AND in the SAME
   SEQUENCE as the .INF files were located and processed in step 3 above.

The .INF files don't seem to be read in the order that corresponds to the
numbered .CAB files containing these groups of files, but there DOES seem
to be a parallel with the order of the "Optional Components" listed in my
C:\Setuplog.txt file.  The 2nd last file types found and read in my FileMon
results are the .WAV files for the different "Themes".  These are listed in
my Setuplog.txt right down near the end also.

The very last "Optional Components" listed in my setuplog.txt file are:
"Web-Based Enterprise Mgmt"
"Web Publishing Wizard"
"Windows Scripting Host".
These seem to correspond with the last few .INF files read right before the
LAYOUT*.INF ones are read, ie. WBEM.INF, WPWIN98.INF, and WSH.INF respectively.

There are a couple of imposters between WSH.INF and LAYOUT1.INF, namely:

Winpopup.inf - installs winpopup applet
Shell3.inf - Registry entries for cursor schemes (CD only)
SWDir16.inf - Macromedia Shockwave Director
SWflsh16.inf - Shockwave Flash.

This is explained by a quick read at the comments in the header sections of
those .INF files that tells you they are treated differently:
"instead of SourceDisks* sections for file locations in the CABs".

So, everything is looking suspiciously like opening the "Windows Setup" tab
actually uses C:\SETUPLOG.TXT to determine its running order.

I can only assume that, in the event of a zealous disk cleanup, it then reverts
to inspecting SETUPLOG.OLD and, failing that, the registry keys.  Setuplog.old
is the backup of setuplog.txt created immediately you add or remove Windows
components, or existing versions of optional components are migrated to higher
versions during the installation of some other application.

It is also clear that the file sizes are updated in the new setuplog.txt file
that replaces the existing one.  I can also see mentions of "Resolved Conflict",
and assume that the version conflict manager (VCM) stepped in to resolve file
versions by backing the existing files up before replacing them.

Setuplog.txt contains section headers referencing the source of the files, eg:
[Windows 98 Second Edition CD-ROM]

One other important aspect in setuplog.txt is that it notates the fact that it
creates a new user.dat and system.dat with the .NEW extension, and presumably
thereafter backs up the existing ones, and renames the new ones correctly.
The respective file sizes of both these registry files is updated to reflect
the new content (either a reduction for removed lines after uninstalling
optional components, or vice-versa).

NOTE:  I used "Beyond Compare" for the side-by-side comparisons using the "File
Viewer" plugin.  Setuplog.txt and .old are binary or compressed, and utilities
like PEEK.DLL viewer won't show the correct formatting so you can see the
actual values.

Do YOU have C:\SETUPLOG.TXT and .OLD?  If so, try renaming them on the offchance
that they contain bad or corrupted syntax.

This then brings me to RegMon to see if I can draw any parallels with the
process of opening the "Windows Setup" tab.

Sysinternals REGMON

1. Configure and then start Regmon.exe from its own folder using:

@echo off
start regmon.exe
C:\WINDOWS\RUNDLL32.EXE shell32.dll,Control_RunDLL appwiz.cpl,,2

2. Stop logging as soon as "Windows Setup" has finished "searching for
installed components"
3. Save As anyfilename.log, open in Metapad and replace tabs with commas.
4. Find first occurrence of "APPWIZ", and delete all entries before this.
5. Save As > anyfilename.CSV and open in Excel.
6. Create Headers on new top line > Data > Autofilter.

Here's what I interpret as the main and relevant processes:

1. Checks to ensure that user is permitted to run applet
2. Reads entries in HKLM\Softw\MS\Win\CurrVer
3. Reads entries in HKLM\Softw\MS\Win\CurrVer\AppInstallPath if key exists
5. Reads entries in HKLM\Softw\MS\Win\CurrVer\Setup
6. Reads entries in HKLM\Softw\MS\Win\CurrVer\EBDPage if key exists
7. Reads entries in HKLM\Softw\MS\Active Setup\Installed Components\
8. Reads entries in HKLM\Softw\Microsoft\Internet Explorer
9. Reads entries in HKLM\Softw\Microsoft\Internet Explorer\LPKInstalled
   if key exists
10. Checks to see how to display list in applet
11. Checks there are no policies preventing actions
12. Checks again to determine how to display applet listing
13. Determines version of Windows installed.

Frankly I'm very surprised that the process doesn't look up any more
registry keys than it does to determine what Windows optional components
are installed.

I'm not sure if "AppInstallPath" in step 3 is a VALUE rather than a KEY,
and if this is an alias for ALL values relating to installed components
eg. "ProgramFilesPath", "OtherDevicePath", etc.  There is no such key
or value in my registry under "CurrentVersion".  Perhaps the function
reads the sub-keys like "CurrentVersion\App Paths" and
"Installer\Components", but I would have expected it to be more specific
had that been the case.

When it reads the HKLM\Softw\MS\Win\CurrentVersion key, I am not sure
if this extends to all of its SUB-KEYS or not, and the same applies to
step 5.
It would make more sense if it read the following key and sub-keys:

Step 7. {89820200-ECBD-11cf-8B85-00AA005B4395} refers to IE4 Desktop

Step 9.  No idea what "LPKInstalled" means or refers to.  Language Pack??

I am sure that the process HAS TO read the keys that tell it what
components are installed, and I am sure that the most important keys read

Look back up to the 12th last paragraph in the previous section where I
tried to interpret the results of FileMon.  I there deduced that the
INF files were read in a particular order as dictated by C:\Setuplog.txt.

Now compare this order to the optional components listed in the key:
There are some parallels, but the order doesn't seem to EXACTLY match
the order that the INF files were read in the FileMon results.


So far I have been unable to replicate your error.  I have tried:

1. Renamed setuplog.txt and setuplog.old
2. Renamed the registry key:
3. Step 1 and 2 together
4. Renamed HKLM\Softw\Microsoft\Windows\CurrVer\Setup\SetupX
5. Renamed the INF Folder
6. Renamed setup.inf and setupc.inf and their .pnf partners
7. Renamed layout, layout1, and layout2.inf and their .pnf partners
8. Created dummy layout*.inf and .pnf files with bad syntax
9. Created empty layout*.inf and .pnf files with bad syntax
10. Renamed HKLM\Softw\Microsoft\Windows\CurrVer\Setup\OptionalComponents

Step 10 hit the jackpot.  Although it opened the "Windows Setup" tab, it
was empty, so that key, sub-keys, and values are crucial.

I think this has narrowed it down to the key in step 5 being read to
determine the names of the .INF files to find and read.  So, there are
2 basic possibilities based on that assumption, but both present almost
impossible jobs to pin-point where the process is faltering:

(a) bad syntax in registry, or mismatch with respective .INF file
(b) bad syntax in one or more .INF files.

The process of opening, reading, and closing the .INF files runs
so fast that it is virtually impossible to debug.

I wish I knew of a utility that could check the syntax of an .INF
file in the same way as html code checkers analyze a coded page for
unclosed tags, etc.

The best I could do is the following batch file (test.bat).
Copy test.bat to the C:\Windows\INF folder and then just open a DOS
Window and navigate to the INF folder.  Type the command
test <filename.inf>
to produce a report that will be named "<filename.inf>_SyntaxCheck.txt"
in the same folder.  It WON'T run in Full DOS, and it doesn't work
if you drag and drop the .inf file onto test.bat, because that uses
the fully qualified path.

Unfortunately this simple batch file can't test for missing commas,
= signs, matched open and close " ", etc.  It's the best I could think
up for this purpose.

I suppose you could easily run a DIR command:
DIR /b *.INF > InfList.bat
to get a filename only list of the INF files, and then paste the prefix
CALL test
at the start of each line to turn it into a batch file that resembles:

@echo off
call test copy.inf
call test copy1.inf
call test copy2.inf
call test subase.inf
call test layout.inf
call test layout1.inf
call test layout2.inf

to test a bunch of .INF files at once from any folder, but that would be
very disk intensive.  You would also have to remove the EXIT from the
tail end of TEST.BAT so that control returns to InfList.bat to process
the next file in the list, and InfList.bat MUST use the CALL command or
control won't be returned to it.

@echo off
:: TEST.BATCH - Tests .INF files for common syntax errors
echo       INF Files Tested for Common Syntax Errors > SyntaxErrors.txt
echo. >> SyntaxErrors.txt
echo Empty Fields mean no syntax errors. >> SyntaxErrors.txt
echo. >> SyntaxErrors.txt
echo BEGIN %1 >> SyntaxErrors.txt
echo ============================================== >> SyntaxErrors.txt
echo. >> SyntaxErrors.txt
echo No Opening Square Brackets >> SyntaxErrors.txt
echo -------------------------- >> SyntaxErrors.txt
type %1 | find /i "]" > closesqbrackets.txt
type closesqbrackets.txt | find /i /v "[" >> SyntaxErrors.txt
del closesqbrackets.txt>nul
echo. >> SyntaxErrors.txt
echo No Closing Square Brackets >> SyntaxErrors.txt
echo -------------------------- >> SyntaxErrors.txt
type %1 | find /i "[" > opensqbrackets.txt
type opensqbrackets.txt | find /i /v "]" >> SyntaxErrors.txt
del opensqbrackets.txt>nul
echo. >> SyntaxErrors.txt
echo Chicago In Header? (Should see it below)  >> SyntaxErrors.txt
echo ---------------------------------------- >> SyntaxErrors.txt
type %1 | find /i "CHICAGO" >> SyntaxErrors.txt
echo. >> SyntaxErrors.txt
echo No Start Dollar Symbol  >> SyntaxErrors.txt
echo ---------------------- >> SyntaxErrors.txt
type %1 | find /i "O$" > nochicago.txt
type nochicago.txt | find /i /v "$C" >> SyntaxErrors.txt
del nochicago.txt>nul
echo. >> SyntaxErrors.txt
echo No End Dollar Symbol  >> SyntaxErrors.txt
echo -------------------- >> SyntaxErrors.txt
type %1 | find /i "$C" > nochicago.txt
type nochicago.txt | find /i /v "O$" >> SyntaxErrors.txt
del nochicago.txt>nul
echo. >> SyntaxErrors.txt
echo No Comma After 'HKLM'  >> SyntaxErrors.txt
echo --------------------- >> SyntaxErrors.txt
type %1 | find "HKLM" > badLMhiveleader.txt
type badLMhiveleader.txt | find /v "HKLM," >> SyntaxErrors.txt
del badLMhiveleader.txt
echo. >> SyntaxErrors.txt
echo No Comma After 'HKCU'  >> SyntaxErrors.txt
echo --------------------- >> SyntaxErrors.txt
type %1 | find "HKCU" > badCUhiveleader.txt
type badCUhiveleader.txt | find /v "HKCU," >> SyntaxErrors.txt
del badCUhiveleader.txt
echo. >> SyntaxErrors.txt
echo No Comma After 'HKCR'  >> SyntaxErrors.txt
echo --------------------- >> SyntaxErrors.txt
type %1 | find "HKCR" > badCRhiveleader.txt
type badCRhiveleader.txt | find /v "HKCR," >> SyntaxErrors.txt
del badCRhiveleader.txt
echo. >> SyntaxErrors.txt
echo Inspect Variables for Open and Close '%%' >> SyntaxErrors.txt
echo NOTE - Not All Variables have both '%%' >> SyntaxErrors.txt
echo ---------------------------------------------- >> SyntaxErrors.txt
type %1 | find "%%" >> SyntaxErrors.txt
echo. >> SyntaxErrors.txt
echo ============================================== >> SyntaxErrors.txt
echo END OF %1 >> SyntaxErrors.txt
echo ============================================== >> SyntaxErrors.txt
ren SyntaxErrors.txt %1_SyntaxCheck.txt

I am wondering if there would be a way to run similar tests on registry
exports from the apparently relevant keys, but I feel that any actual syntax
errors would surely be picked up at the scanreg stage during boot.

Have you tried running REGCLEAN?  I know you said before that you had
used registry diagnostics/checkers, but RegClean.exe was written by the
Microsoft team and contains itself to removing redundant data that it
knows shouldn't be there, or that it finds orphaned.

RegClean has yet to screw up any of my Win98 systems, but that's not
a guarantee.  It's downfall is the incredibly stupid naming convention for
the backup .REG files it creates when you "FIX" what it finds.  The filenames
would be impossible to interpret if you had to merge the data back to the
registry from Full DOS, so I hacked the .exe to create a DOS compliant
filename to reflect the Date only.

Example default filename:  "Undo ABCDEF 20050604 101456.Reg"
ABCDEF = the ComputerName from the registry
20050604 = yyyymmdd
101456 = the time as held in the system.

Example of new hacked filename: "040605.reg"
where name comprises ddmmyy.


1. RegClean version 4.1a, build 7364.1

2. Resource Hacker:
Help File

(a) Install Resource Hacker and run it.  File > Open > RegClean.exe
(b) Navigate to the "StringTable" section > "1794" > "1033"
(c) Existing values in Right-Pane:

28696,       "Undo %s "
28697,       "%Y%m%d %H%M%S"

Modify to:

28696,       ""
28697,       "%d%m%y"

(d) Click"Compile Script" button.  File Menu > Save.
(e) Backup of original is saved as "RegClean_original.exe"

RegClean scans the following areas of the registry:

Component Categories
File Type Identifiers (File Extensions)
File Handlers (Shell ProgID's)
Class Identifiers (CLSID's)
Interface Identifiers
Software entries
Application Identifiers
Programmatic Identifiers
Type Library Identifiers

and tries to remove redundant or mismatching entries.

LVL 39

Expert Comment

ID: 14251673

Under the "FURTHER TESTING" section, I stated:

"I think this has narrowed it down to the key in step 5 being read to
determine the names of the .INF files to find and read".

This should refer to "Step 10", ie. the renamed
LVL 39

Expert Comment

ID: 14251681
I apologise if there are discoveries made, and then I later qualify them
as being unimportant or not relevant.  The notes were made as an
ongoing process, and I sometimes forget to correct my earlier assumptions.

Author Comment

ID: 14254421
LVL 39

Expert Comment

ID: 14256479
Thank you, sysandprog.  You just can't keep doing that  ;-)
LVL 20

Expert Comment

ID: 14256704

PLEASE award the points here. I notified a Moderator to take care of the points in the other question


Author Comment

ID: 14260312

This is NOT a single question.  It has developed into a multi-method approach
to several problems I had been having.  It never should have been posted in
this topic area in the first place.  By all that is fair, each of these problems
should have been addressed in a separate question in one of the other topic areas,
as appropriate.  However, because of the admitted inherent flaws in the EE
architecture, NETMINDER suggested that I keep it here, which I have done.

However,  BillDL was the ONLY one who ever showed ANY interest in helping me.

Now, you insist that I close out the question without showing the answer at EE.
That is fine with me.  I can send it to BillDL by email, if that is what you want.


Last week I was about 1 microsecond away from giving up in taking out an old
apple tree stump resulting from a recent storm.  My quite dull pruning saw kept
binding.  At the last instant it started cutting.  A few minutes later the stump was

I had a similar response when the suits got into the act on this terribly
difficult problem.  Just as I was about to blow a fuse, I calmed down long
enough to make one last test, using the powerful tools you helped me develop.

Apparently they don't want to see the answer posted at EE, but I can send
it to you by email, if you want.



Author Comment

ID: 14291271
LVL 39

Expert Comment

ID: 14291345
Hi, sysandprog.  I've been working long hours, and neglected to post a
follow-up comment here a few days ago.

I reckon this would be a good juncture to summarise how this question
developed, just for anyone who may happen upon it and wonder what
the previous few comments are all about.

Initially, it started out as an issue where a McAfee application went
wonky, but attempts to reinstall it failed to work and issued a script
error.  There was also the suggestion that perhaps different versions of
some .VXD files may be related.

The initial suggestions were all good and valid ones, and centred around
theories of potential virus or spyware activity, problems with the Windows
scripting support, or residual files and registry entries interfering with the

At a fairly early stage, the question author (sysandprog) introduced a new
observation:  "There appears to be a problem with one of the *.INF files",
but at that stage the significance wasn't immediately apparent until sysandprog
qualified it by stating "There is also a problem with *.INF files when called
with SETUPX.DLL that may be related".

That's where the question steered sharply towards investigating setupx.dll and
its potential relationship with the install problem.  From that point onwards, it was
only really myself and sysandprog working our way through this specific issue.
It became apparent that the "INF" file problem was indeed a connected problem,
and ultimately it has been traced to differing dates/versions of one or more inf
files called by setupx.dll.

It's always a difficult choice for experts with a good suggestion to offer, but
they know that it would lead the question away off on another tangent, to
interrupt the flow by posting the suggestion.  I would say that most would
monitor the progress, and offer the suggestion when it appeared that current
avenues were becoming less relevant to the problem.

So, given the initial problem posed, I reckon few of us would ever have guessed
where it would have ended up.


Author Comment

ID: 14358814
Although the problem is only partially solved, this thread is far too long and far too old.
I have and will take up special aspects in other questions.

As it stands now, the most likely cause of McAfee anti-virus not installing properly
is that ...

1. There is some problem with DLL registration in REGSVR32. and
2. McAfee installation must need a missing TEMP folder.  When it can't
find it, the installation tries to create temporary files on the CD.

McAfee insists on using script and default IE tools settings that no other
company requires.  Also, it can't handle automatic dial-up.  My impression
is that they ASSUME every customer will have a high-speed always-on

I have no idea why McAfee dropped back to older versions of the VXD files,
and am no longer interested in finding out the reason.  

I am giving up on all McAfee products permanently, for the reasons stated.

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

The problem with the General Protection Fault when trying to look at
CONTROL PANEL --> Add/Remove Programs --> Windows Setup
came back with the error message about RUNDLL32 triggering the
error in SETUPX.  BillDL correctly observed the discontinuity between
the 32-bit RUNDLL32 and the 16-bit SETUPX.  He went on to state
that the 16-bit RUNDLL would be the more likely culprit.  Since both
versions are on the system and are being used, it is likely that there
is some sort of coordination between them.  Microsoft's Dependency
Walker program only works for 32-bit files, so it is no help.  The one
thing it did indirectly reveal is that some of its claimed missing files
are really needed only for Windows XP and are not even wanted on
Windows 98, and might even be harmful.

Anyway, I have used Eudora for email for several years ...

I managed to track the error back to something happening in
WAB9X50.INF which works with the address book.  I deleted all
references to the MS Outlook Express email program some time
ago, and may have honked something up.  Renaming WAB9X50.INF
to WAB9X50.SAV stops the error and allows the directory to come
up, with only the Address Book entry missing.  I can live with that
for now.

BillDL gets most of the points here, because he "hung in there"
and provided a wealth of invaluable tools and correct ideas, plus
incredible support when I was "down and out".


Expert Comment

ID: 14359538
Thanks :-) Just letting you know that my 2 week holiday was fantastic and I wish I was still in Cyprus!

I look forward to reading through and learning some new tricks from within this post when I have time...

Happy commenting!
LVL 39

Expert Comment

ID: 14360229
Thank you, sysandprog.  It's been a great learning curve for all of us -
a kind of discovery as we progressed through each comment.

I've been looking into this wab9x50.inf issue since you first mentioned
it.  Yes, I'm still puzzled by the problem :-)
Clearly, it is named in reference to
WAB = Windows Address Book
9x = Windows 9x
50 = Internet Explorer and Outlook Express 5.0 as installed by Windows 98 and 98SE.

It is contained in the Precopy2.cab file in the "win98" folder of the Win98 and 98SE
CD's along with oe9x50.inf and all the other .inf files that are unpacked to the
temporary setup folder in the early stages of installation, and thereafter to the
c:\windows\INF folder.

The strange thing is that there are many superfluous files unpacked during installation
which are later deleted if they are not needed during installation, but wab9x50.inf is
one of those that IS NOT deleted, and is copied regardless of whether you actually
choose to install the Windows Address Book via a "custom install".  It also persists
if you DO install Address Book, and then subsequently choose to uninstall it using
Add/Remove Programs > Windows Setup.

In much the same way, "Online Services" is focibly installed despite specifically deselecting
it as an optional component, and folders are created for CHAT and some other optional
components that you choose not to install.

A quick inspection of the files c:\setuplog.old (the backup of the original setuplog.txt when
a reinstall is done) and setuplog.txt BOTH tell me that I did NOT choose to install the Windows
Address Book.  The line

"C&ustom "=1

tells me that it was a custom installation, and the lines

"Internet Tools"=0
"Microsoft Chat 2.5"=0
"Outlook Express"=0
"Address Book"=0

all show that I deselected them as optional components.
Incidentally, that's the point where "Online Services" always gets installed whether you like it
or not, because the 0 is changed to a 1 to force it into your installed components along with:

"America Online"=1
"AT&T WorldNet Service"=1
"Prodigy Internet"=1

The reason I never install Address Book at this stage is that it is an option when I usually then
installed IE 5.01 and OE 5.01 from setup files.  In my case, and with this current installation, I
had installed version 5.01 before I updated to IE6 SP1.

During installation, setuplog.txt logs that the files "9xmig.dll" are accessed from firstly the
temporary setup folder, and then from the program folder:
c:\program files\outlook express.  It seems to specifically check for version differences of
Address Book (WAB5.0) and Outlook Express (OE5.0) to determine whether to update
any pre-existing components.  At least, that's my interpretation of these processes.
The files iemigrat.dll (IE), dxmigr.dll (DirectX), and nmmigrat.dll (NetMeeting) are also accessed
presumably to determine whether the process has to "migrate" to a newer version of these

This "migration check" process appears to take place after the setup files are unpacked to the
temporary setup folder, but before they are then copied to their respective system or program
folders.  The vast majority of files copied at the start are .inf files to the c:\windows\INF folder.

The file copy actions should be seen logged in setuplog.txt as:

where the "17" refers to c:\windows\INF, and I believe the following numbers are the file dates
as stored by the computer. ie.
23 April 1999 22:22:00 in the case of Windows 98SE.

The only reasons I can think of that the file WAB9x50.INF has been isolated as the problem one are:

1. A mismatch with values in any of the files: setuplog.txt, setupc.inf, setup.inf (seems to be copied
from setupc.inf and created during installation), layout.inf, layout1.inf, or layout2.inf.

2. the introduction of an older version of an .inf file that improperly references another file.

INF files are often backed up, and a quick look in C:\Windows\INF\INFBACK will reveal an extensive
number of .inf files that have been superseded by newer .inf files in the INF parent folder.  A side-
by-side comparison of eg. SETUP.INF which exists in both of these folders on my computer shows
very substantial differences, and the consequences of somehow swapping them, or overwriting
the newer with the old is a legitimate concern if my observations are correct.

WAB9x50.INF is not one of the files that exists in my "infback" folder, but I have to start wondering
whether the differences between one in the INF folder and another in the INFBACK folder would be
substantial enough to cause a serious error in the present scenario such that renaming that file
was the only way to prevent the error.

I believe that the only way to test this theory would be to do a dirty install of windows right back
over itself and reinstall the Windows Address Book.

Perhaps we will never get to the bottom of this, but the passage (if you'll excuse the pun) has been
an interesting one.

Thank you again, sysandprog.


Author Comment

ID: 14460137
The final resolution is here ...


I tracked it down to a one line entry in WAB9X50.INF


Featured Post

Upgrade your Question Security!

Add Premium security features to your question to ensure its privacy or anonymity. Learn more about your ability to control Question Security today.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

With User Account Control (UAC) enabled in Windows 7, one needs to open an elevated Command Prompt in order to run scripts under administrative privileges. Although the elevated Command Prompt accomplishes the task, the question How to run as script…
In real business world data are crucial and sometimes data are shared among different information systems. Hence, an agreeable file transfer protocol need to be established.
Simple Linear Regression
Six Sigma Control Plans

840 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question