Software installation failures - McAfee Virus Scan

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

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.

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:-
http://www.asp.net/download-1.1.aspx?tabindex=0&tabid=1

But try this one also :-
http://www.microsoft.com/downloads/details.aspx?FamilyId=D7158DEE-A83F-4E21-B05A-009D06457787&displaylang=en

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.
http://freepctech.net/files/VXD_FIX.zip

Good Luck

sysandprog

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:
http://forums.mcafeehelp.com/viewtopic.php?p=130974
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:
mk:@MSITStore:C:\WINDOWS\Help\windows.chm::/default.htm.
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.

http://us.mcafee.com/root/dev/CheckActiveX.htm

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.

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

http://forums.techguy.org/showthread.php?t=209214

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

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

http://www.microsoft.com/technet/security/bulletin/MS03-008.mspx

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:

http://support.microsoft.com/default.aspx?scid=kb;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.

Actually, all that update does is replace jscript.dll with version 5.6.0.8513 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 5.6.0.8825.  So it appears that the patch knocks it BACKWARDS by
one or two versions.  Presumably version 5.6.0.8825 was the one with the holes in it.

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.

sysandprog

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.

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
C:\WINDOWS\SYSTEM\Shellext\shdate.inf

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:

http://support.microsoft.com/kb/q145810/

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:

REGEDIT4

[HKEY_CLASSES_ROOT\.inf]
@="inffile"

[HKEY_CLASSES_ROOT\inffile]
@="Setup Information"
"EditFlags"=hex:00,00,00,00

[HKEY_CLASSES_ROOT\inffile\DefaultIcon]
@="shell32.dll,-151"

[HKEY_CLASSES_ROOT\inffile\shell]
@=""

[HKEY_CLASSES_ROOT\inffile\shell\install]
@="&Install"

[HKEY_CLASSES_ROOT\inffile\shell\install\command]
@="C:\\WINDOWS\\rundll.exe setupx.dll,InstallHinfSection DefaultInstall 132 %1"

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

http://free.grisoft.com/

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

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.

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] CONTROL PANEL
[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
[Response]
     "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.

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

http://home.ntelos.net/~write/purgeall.txt

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.

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

sysandprog

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

Update: http://support.microsoft.com/?kbid=256015
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Setup\
Updates\W98.SE\UPD256015
Updates IFSMGR.VXD to version 4.10.0.2223 in VMM32.VXD

Update: http://support.microsoft.com/?kbid=267304
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Setup\Updates\
W98.SE\UPD267304
Updates NTKERN.VXD to version 4.10.2223 in VMM32.VXD

Windows 98SE Shutdown Supplement
http://www.microsoft.com/windows98/downloads/contents/WURecommended/
S_WUFeatured/Win98SE/Default.asp
MIGHT Update CONFIGMG.VXD to version 4.10.2222 in VMM32.VXD if for some reason
an older one sneaked in there.

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

TMP=C:\WINDOWS\TEMP
TEMP=C:\WINDOWS\TEMP

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.

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.

Correction...

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

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

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

EXTRACT C:\WINDOWS\OPTIONS\CABS\PRECOPY2.CAB   LAYOUT1.INF

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.

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

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.

scandisk.exe=0,,143818
drvspace.bin=1,,68871
command.com=1,,93890

to

scandisk.exe=0,,,,,,,,,,143818
drvspace.bin=========1,,68871

LAYOUT*.INF files syntax:

For the topmost list of the .CAB files [SourceDisksNames]
<Cab_Number>=<"SourceCD_VolLabel">,<CabFile_Name>,<ID_Number>

Apparently <ID_Number> is always Zero.

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

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

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

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

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

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

I can't recall if you actually copied your entire CD to a hard drive
folder and changed the "SourcePath", "CommandLine", and "OLSSrcPath"
StringValues in:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Setup
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:
http://msdn.microsoft.com/library/en-us/ddtools/hh/ddtools/
ChkInf_46e6897b-fc17-405a-8e68-4b1aa8d6bf44.xml.asp
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
EXIT

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:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\
Setup\SetupX\Catalogs
the sub-keys of:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\
Setup\SetupX\Cert
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\
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
Setup".
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Setup\
OptionalComponents

Take an example of the CD-Player which IS installed on my system:
[HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Setup\
OptionalComponents\CDPlayer]
"INF"="mmopt.inf"
"Section"="CDPlayer"
"Installed"="1"

The following key sets C:\Windows\INF as the "DevicePath":
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion
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
HKEY_LOCAL_MACHINE\Software\Microsoft\Updates
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\
Setup\Updates
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\
Setup\Migration

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

HKEY_LOCAL_MACHINE\Enum
HKEY_LOCAL_MACHINE\Config
HKEY_CURRENT_CONFIG\all 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 :-)

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

https://www.experts-exchange.com/questions/21451632/Points-for-BillDL-for-unique-diagnosis-of-General-Protection-Fault.html

BillDL...

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

TMP=C:\WINDOWS\TEMP
TEMP=C:\WINDOWS\TEMP

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.

BillDL...

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.

Whatever.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

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.

REGEDIT4

[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:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion
(ONLY the settings right opposite "CurrentVersion" because that key will
export a massive file)
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Setup
(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.
echo.
echo %TEMP%\Report.txt is ready
echo.
exit
------------ 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.

Bill

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:

HKLM\Software\Microsoft\Windows\CurrentVersion\Setup
HKLM\Software\Microsoft\Windows\CurrentVersion\Setup\SharedDir
HKLM\Software\Microsoft\Windows\CurrentVersion\Explorer\ShellExecuteHooks
HKLM\Software\Microsoft\Windows\CurrentVersion\URL\Prefixes
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:

HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer
HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer
HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\RestrictRun

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

HKLM\System\CurrentControlSet\Control\SessionManager\CheckBadApps400

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
HKLM\Software\Microsoft\Windows\CurrentVersion\SubVersionNumber
HKLM\Software\Microsoft\Windows\CurrentVersion\ServicePackNumber

Checks some windows behavioural settings:

HKLM\Software\Microsoft\Windows\CurrentVersion\Explorer\Performance
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:

HKLM\Software\Microsoft\Windows\CurrentVersion\AppInstallPath
(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:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Setup\SetupX\
Catalog, Cert, and INF.
      
Checks for the existence of the key:

HKLM\Software\Microsoft\Windows\CurrentVersion\Setup\EBDPage

"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:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Setup\EBD

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\
{89820200-ECBD-11CF-8B85-00AA005B4383}
HKLM\Software\Microsoft\Active Setup\Installed Components\
{89820200-ECBD-11CF-8B85-00AA005B4383}\Locale

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.

HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall
(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:
http://support.microsoft.com/default.aspx?scid=KB;EN-US;q164787&

RUNDLL.EXE SETUPX.DLL,InstallHinfSection 132 C:\WINDOWS\INF\SHELL.INF

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

SUREGQUERYVALUE
SUREGQUERYVALUEEX
SUREGQUERYVALUE16

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:

http://www.windowsforumz.com/Setup-Rundll32-dll-error-ftopict415794.html

>>>
"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
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup\VarLDID".
<<<

http://www.computing.net/windowsme/wwwboard/forum/45453.html
http://www.computing.net/windowsme/wwwboard/forum/17859.html

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.

http://forums.tomcoyote.org/lofiversion/index.php/t19111.html

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?

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

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

BillDL...

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

APPHELP.DLL, AUTHZ.DLL, NTDSAPI.DLL, and NTLANMAN.DLL

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.

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 (3.0.0.118), 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
further.
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!

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

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):
http://www.computer-help.net/Email-Pages/
Internet-Explorer-6-is-BIG-PROBLEM-for-Windows-98-or-ME.htm

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

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, 4.80.0.1675
APPWIZ.CPL, 72192, 4.10.0.2222
COMCTL32.DLL, 548624, 5.81.4916.400
GDI32.DLL, 155648, 4.10.0.1998
KERNEL32.DLL, 471040, 4.10.0.2222
MSVCRT.DLL, 290869, 6.1.9359.0
SHLWAPI.DLL, 402432, 6.0.2800.1612
USER32.DLL, 69632, 4.10.0.2222
CFGMGR32.DLL, 45056, 4.10.0.1998
COMDLG32.DLL, 176128, 4.72.3510.2300
LZ32.DLL, 24576, 4.10.0.1998
MLANG.DLL, 574976, 6.0.2800.1106
MPR.DLL, 57344, 4.10.0.1998
MSI.DLL, 1930240, 2.0.2600.2
NTDLL.DLL, 20480, 4.10.0.1998
OLEAUT32.DLL, 929792, 2.40.4518.0
RPCRT4.DLL, 339968, 4.71.2900.2
SETUPAPI.DLL, 409600, 5.0.1671.1
VERSION.DLL, 24576, 4.10.0.1998
WINMM.DLL, 65536, 4.3.0.1998
WINSPOOL.DRV, 23040, 4.90.0.3000

A good utility for browing different folders for specified file types, and quickly
checking the file versions is "Version Browser" by Karen Kenworthy.
http://www.karenware.com/powertools/powertools.asp
http://www.karenware.com/powertools/ptbrowse.asp

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:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SessionManager\KnownDLLs.
(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:
DUSER.DLL
UXTHEME.DLL
APPHELP.DLL ***
MSGINA.DLL
USERENV.DLL
WINSTA.DLL

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:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\SharedDLLs
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SessionManager\CheckVerDLLs
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SessionManager\Known16DLLs
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SessionManager\WarnVerDLLs
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\InstalledFiles

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:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SessionManager\KnownVxDs
(Still thinks that they might be there)

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\VMM32Files
(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:
http://support.microsoft.com/default.aspx?scid=kb%3Ben-us%3B187863

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:
https://help.national-lottery.co.uk/ihs/ihs.do
or by going to the following page and clicking the "Help" link at the top left of the page:
http://www.national-lottery.co.uk/player/p/home/home.do
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.

BillDL...

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.

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.

nep1...

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.

BillDL...

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

KSTVTUNE.AX and KSWDMCAP.AX

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.

Typo apology...

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

Whatever.

By the way...

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

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
in C:\WINDOWS\VCM

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

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)
http://www.dlldump.com/cgi-bin/testwrap/
downloadcounts.cgi?rt=count&path=dllfiles/N/ntdsapi.dll

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
http://www.dlldump.com/cgi-bin/testwrap/
downloadcounts.cgi?rt=count&path=dllfiles/N/ntlanman.dll

SpamPal - Discussion about a spam filtering file named
bayesian.dll and its dependencies.
http://www.spampalforums.org/phpBB2/viewtopic.php?t=6888
I don't suppose that this utility program is involved?
http://www.spampal.org/

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
key:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Internet Settings
"MinorVersion"=

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:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion
"IeakHelpString"=

I refer to the Unofficial Win98se updates listed here:
http://exuberant.ms11.net/

Changelog and latest 2.0.1 update:
http://exuberant.ms11.net/98sesp.html
http://www.msfn.org/board/index.php?showtopic=30818
http://www.msfn.org/board/index.php?showtopic=46399

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:
IE6.0sp1-KB867282-Windows-98-ME-x86-ENU.exe
MS05-014: Cumulative security update for Internet Explorer:
http://support.microsoft.com/kb/867282

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,
(http://www.microsoft.com/downloads/details.aspx?
FamilyID=08b1ac1b-7a11-43e8-b59d-0867f9bdda66&DisplayLang=en)
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
installed.

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.

http://www.oreilly.com/catalog/win9x/chapter/ch10.html
http://www.itechs-systems.com/pages/tipsinfo.htm
(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.

BillDL...

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
WINOLDAPP (WINOA386).

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.

BillDL...

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:\

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

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

After running Windows update, OR after installing the selected updates that I downloaded from
the Corporate site (http://www.microsoft.com/windows98/downloads/corporate.asp), my CABS
folder becomes populated with loose dll's, vxd's, sys, inf, and exe files.  Looking at them, and
comparing them to the sub-keys of
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Setup\Updates
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 :-)

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.

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

SETUPX --> LAYOUT --> LAYOUT1 --> LAYOUT2 --> SETUPX

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

Correction:

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
HKLM\Softw\Microsoft\Windows\CurrVer\Setup\OptionalComponents
key.

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.

BillDL - Points here...

https://www.experts-exchange.com/questions/21463595/BillDL-points-General-Protection-Fault-test-parameter.html

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

sysandprog,

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

Venabili
EE PE

Venabili...

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.

BillDL...

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

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.

sysandprog

Working...

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

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.

Bill

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

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

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!

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

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

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

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

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

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

"C&ustom "=1

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

"Internet Tools"=0
"Microsoft Chat 2.5"=0
"NetMeeting"=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
"CompuServe"=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
components.

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:
:
oe9x50.inf=17,,9879,45760
:
:
wab9x50.inf=17,,9879,45760
etc

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.

The final resolution is here ...

https://www.experts-exchange.com/questions/21470490/Windows-98-SE-RUNDLL32-SETUPX-General-Protection-Fault.html

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