Software installation failures - McAfee Virus Scan

Posted on 2005-05-11
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
    LVL 25

    Assisted Solution

    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

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

    Author Comment

    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.
    LVL 4

    Assisted Solution

    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 23

    Expert Comment

    by:Mohammed Hamada
    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
    LVL 7

    Assisted Solution

    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 ?

    LVL 8

    Assisted Solution

    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.|897277873&sliceID=&docID=KC.KB_nai22603&url=kb/kb_nai22603.xml&dialogID=13857178&docType=DOC_KnowledgeBase&iterationID=1&docName=Solution%20ID%20nai22603%20-%20Manually%20uninstalling%20VirusScan%206.0%20(Retail)

    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 38

    Expert Comment


    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 38

    Expert Comment

    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 38

    Expert Comment

    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:;en-us;154036

    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 38

    Expert Comment

    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.
    LVL 5

    Author Comment

    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.

    LVL 5

    Author Comment

    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 38

    Expert Comment

    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"

    LVL 5

    Author Comment

    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.
    LVL 5

    Author Comment

    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 38

    Assisted Solution

    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: - 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,
    are USER.EXE, GDI.EXE, and KRNL386.EXE.

    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.

    USER.EXE - WIN98_46.CAB
    GDI.EXE -  WIN98_45.CAB
    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%
    set SYSFOLD=

    Windows probably won't allow this, however.

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

    Author Comment

    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 23

    Expert Comment

    by:Mohammed Hamada
    Hello sysandprog
    did you try what i suggested above?
    give it a shot for both the file and the .net framework download it again and restart to check if you'll have the same problem?
    LVL 38

    Assisted Solution

    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, 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 38

    Expert Comment


    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.

    Updates IFSMGR.VXD to version in VMM32.VXD

    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.
    LVL 5

    Author Comment

    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.
    LVL 5

    Author Comment

    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.
    LVL 5

    Author Comment


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

    LVL 38

    Assisted Solution

    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 38

    Assisted Solution

    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 38

    Accepted Solution

    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

    Cabinet BASE5.CAB

    04-23-1999 10:22:00p A---        93,890
    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 38

    Assisted Solution

    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 38

    Assisted Solution

    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 38

    Assisted Solution

    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.
    LVL 5

    Author Comment

    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.

    LVL 5

    Author Comment

    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 38

    Expert Comment

    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 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 ( 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 :-)
    LVL 5

    Author Comment

    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...
    LVL 5

    Author Comment


    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.
    LVL 5

    Author Comment


    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 38

    Expert Comment

    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 38

    Expert Comment

    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:;EN-US;q164787&


    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?
    LVL 5

    Author Comment

    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.

    LVL 4

    Expert Comment

    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!
    LVL 5

    Author Comment

    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 38

    Expert Comment

    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
    VERSION.DLL, 24576,
    WINMM.DLL, 65536,
    WINSPOOL.DRV, 23040,

    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.

    Windows ME APPWIZ.CPL:
    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.
    LVL 5

    Author Comment


    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
    order - LAYOUT.INF -->  LAYOUT1.INF -->  LAYOUT2.INF

    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.
    LVL 4

    Expert Comment

    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.
    LVL 5

    Author Comment


    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.
    LVL 5

    Author Comment


    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...

    VPMTD.386 and KSBAR.AX

    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.

    LVL 5

    Author Comment

    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?
    LVL 5

    Author Comment

    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
    VPOWERD.VXD 7/23/01

    LVL 38

    Expert Comment

    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.
    LVL 5

    Author Comment


    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.

    LVL 5

    Author Comment


    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 38

    Expert Comment

    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 (, 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 :-)

    LVL 5

    Author Comment

    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.
    LVL 5

    Author Comment

    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 38

    Assisted Solution

    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,
       and SHLWAPI.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
       MSI.DLL and START.EXE.
    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
    4. Calls SETUPX.DLL
    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 38

    Expert Comment


    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 38

    Expert Comment

    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.
    LVL 5

    Author Comment

    LVL 38

    Expert Comment

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

    Expert Comment


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

    EE PE
    LVL 5

    Author Comment


    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.


    LVL 5

    Author Comment

    LVL 38

    Expert Comment

    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.

    LVL 5

    Author Comment

    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".

    LVL 4

    Expert Comment

    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 38

    Expert Comment

    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 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.

    LVL 5

    Author Comment

    The final resolution is here ...

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


    Featured Post

    How to run any project with ease

    Manage projects of all sizes how you want. Great for personal to-do lists, project milestones, team priorities and launch plans.
    - Combine task lists, docs, spreadsheets, and chat in one
    - View and edit from mobile/offline
    - Cut down on emails

    Join & Write a Comment

    Introduction: Recently, I got a requirement to zip all files individually with batch file script in Windows OS. I don't know much about scripting, but I searched Google and found a lot of examples and websites to complete my task. Finally, I was ab…
    A short article about problems I had with the new location API and permissions in Marshmallow
    An introduction to basic programming syntax in Java by creating a simple program. Viewers can follow the tutorial as they create their first class in Java. Definitions and explanations about each element are given to help prepare viewers for future …
    In this fifth video of the Xpdf series, we discuss and demonstrate the PDFdetach utility, which is able to list and, more importantly, extract attachments that are embedded in PDF files. It does this via a command line interface, making it suitable …

    730 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

    Need Help in Real-Time?

    Connect with top rated Experts

    16 Experts available now in Live!

    Get 1:1 Help Now