Location of configmg.vxd
dave xnet
my 98se system is working fine. I had recently applied the
so-called "unofficial service pack". The system is stable.
http://exuberant.ms11.net/98sesp.html
I started looking around out of interest and I found I had two
versions of this file, one in windows\system and one in
windows\system\vmm32.
The one in vmm32 is 125,593 bytes, verson 4.10.2225
while the one in system is 125,057 bytes, version 4.10.2222
Msinfo32 says that the configmg.vxd in \windows\system\vmm32
is active. At least that's the newer one.
Why do I have a copy in windows\system ?
On the otherhand there are a load of VXD's that only
live in \windows\system
What is the rule, in general, of how/where these vxd's
live?
Thanks for any info.
Dave
glee
http://www.helpwithwindows.com/techfiles/vmm32.html
Your "unofficial service pack" apparently installed an updated one in the
Windows\System\Vmm32 folder. There is no reason whatever for there to be one in the
Windows\System folder, and I suggest you delete it.
<quote>
....there may come a time, when one of the *.vxd files built into vmm32.vxd needs to
be updated, and Win9x provides a very simple means for this. Each system has a
\Windows\system\vmm32 directory. Any *.vxd file in this directory will be
automatically loaded and used during Win9X startup, instead of the one in the
vmm32.vxd file if it exists in both places. In other words files in this directory
take precedence over same files within vmm32.vxd.
</quote>
I suggest you read the entire web page I linked above.
--
Glen Ventura, MS MVP Shell/User, A+
http://dts-l.org/goodpost.htm
"dave xnet" <davexn...@ETEyahoo.com> wrote in message
news:4d8u02lt3t361t1kq...@4ax.com...
dave xnet
wrote:
>See:
>http://www.helpwithwindows.com/techfiles/vmm32.html
>
>Your "unofficial service pack" apparently installed an updated one in the
>Windows\System\Vmm32 folder. There is no reason whatever for there to be one in the
>Windows\System folder, and I suggest you delete it.
>
><quote>
>....there may come a time, when one of the *.vxd files built into vmm32.vxd needs to
>be updated, and Win9x provides a very simple means for this. Each system has a
>\Windows\system\vmm32 directory. Any *.vxd file in this directory will be
>automatically loaded and used during Win9X startup, instead of the one in the
>vmm32.vxd file if it exists in both places. In other words files in this directory
>take precedence over same files within vmm32.vxd.
></quote>
>
>I suggest you read the entire web page I linked above.
Thaks for the info.
At one time I actually knew this stuff. But not having touched,
98se for 3 years, and a short, unfortunate, episode with WINME,
I've been using XP almost exclusively.
I've forgotten all this good 9x stuff!
Dave
dave xnet
wrote:
>See:
>http://www.helpwithwindows.com/techfiles/vmm32.html
>
>Your "unofficial service pack" apparently installed an updated one in the
>Windows\System\Vmm32 folder. There is no reason whatever for there to be one in the
>Windows\System folder, and I suggest you delete it.
>
><quote>
>....there may come a time, when one of the *.vxd files built into vmm32.vxd needs to
>be updated, and Win9x provides a very simple means for this. Each system has a
>\Windows\system\vmm32 directory. Any *.vxd file in this directory will be
>automatically loaded and used during Win9X startup, instead of the one in the
>vmm32.vxd file if it exists in both places. In other words files in this directory
>take precedence over same files within vmm32.vxd.
></quote>
>
>I suggest you read the entire web page I linked above.
glee,
I read the page, but unless I misunderstood, something
doesn't jive. For example,
if I use the device manager to display the driver details of
system device/system board,
it quite clearly says it's using
c:\windows\system\configmg.vxd version 4.10.2222
even though I have a newer version in
windows\system\vmm32\configmg.vxd
Some other factor at play?
Dave
glee
Yeah, that's odd. As I understand it and as the web page describes, the version in
the Vmm32 folder should be the one being loaded at startup, as files in that folder
are loaded during the boot process. A version of the file in the System folder
should not be loaded, unless I also misunderstand.
Try this....rename the version in the System folder, to configmg.vx_, then reboot,
and check the version number shown in that same location in Device Manager.
dave xnet
wrote:
>> I read the page, but unless I misunderstood, something
>> doesn't jive. For example,
>> if I use the device manager to display the driver details of
>> system device/system board,
>> it quite clearly says it's using
>> c:\windows\system\configmg.vxd version 4.10.2222
>> even though I have a newer version in
>> windows\system\vmm32\configmg.vxd
>>
>> Some other factor at play?
>> Dave
>
>Yeah, that's odd. As I understand it and as the web page describes, the version in
>the Vmm32 folder should be the one being loaded at startup, as files in that folder
>are loaded during the boot process. A version of the file in the System folder
>should not be loaded, unless I also misunderstand.
>
>Try this....rename the version in the System folder, to configmg.vx_, then reboot,
>and check the version number shown in that same location in Device Manager.
using the one in the vmm32 folder after the rename.
Of course, I'm now going to check all of the vmm32 vxd
for duplicates like this just in case there's more...
Thanks for your help, it does seem most peculiar
that it works this way.
Dave
Lee
applied the entire VXD fix suite of seven vxd files to your machine
without your knowledge or permission. So what else did it do?
In my early days of 98 I often recommended the vxd fix, but NOT using
hot patch sources for the files like the unofficial patch does...
According to the VXD fix these two files must be located in the System
folder and not the Vmm32 folder:
vdd.vxd
vflatd.vxd
The above files won't work when placed in the Vmm32 folder, but 5 these
will:
configmg.vxd
ntkern.vxd
vcomm.vxd
vdmad.vxd
vmouse.vxd
Apparently, you've stumbled upon the default location behavior for
configmg.vxd as first loading from the System folder if there, then the
Vmm32 folder if there, and if not in either location then from the
'combined' Vmm32.vxd file itself? BTW, in the process of combining the
Vmm32.vxd file at windows installation time (first reboot), the
configmg.vxd file should have been deleted from the System folder which
means something went wrong when that was supposed to happen.
glee
news:1141892908.5...@p10g2000cwp.googlegroups.com...
> Do a google search for 'vxdfix' and find that the unofficial patch has
> applied the entire VXD fix suite of seven vxd files to your machine
> without your knowledge or permission. So what else did it do?
>
> In my early days of 98 I often recommended the vxd fix, but NOT using
> hot patch sources for the files like the unofficial patch does...
>
> According to the VXD fix these two files must be located in the System
> folder and not the Vmm32 folder:
> vdd.vxd
> vflatd.vxd
Not according to this:
How to Repair the Vmm32.vxd:
http://www.easydesksoftware.com/news/news10.htm
<quote>
The file names are vdd.vxd, vflatd.vxd, and biosxlat.vxd. You can extract
each file, one at a time to the Windows\System\Vmm32 folder. This folder is
used when a vxd file needs to be added to the Vmm32.vxd file; instead of
trying to have Wininit.ini try to add the file to the Vmm32.vxd file and
risk corrupting the file, the new file can be placed here. If a file is
listed in the Vmm32Files Registry Key, Windows looks inside the Vmm32.vxd
file and in the Windows\System\Vmm32 folder for it.
</quote>
Description of the Windows 95 Startup Process:
http://support.microsoft.com/kb/q174018/
<quote>
The real-mode virtual device driver loader checks for duplicate virtual
device drivers (VxDs) in the Windows\System\Vmm32 folder and the Vmm32.vxd
file. If a VxD exists in both the Windows\System\Vmm32 folder and the
Vmm32.vxd file, the duplicate VxD is "marked" in the Vmm32.vxd file so that
it is not loaded.
</quote>
--
Glen Ventura, MS MVP Shell/User, A+
>
dave xnet
Well I found another one.
ios.vxd - What's the proper location ? I take it this is NOT
part of vmm32.vxd.
I had this on my system:
ios.vxd in options\cabs 2223
ios.vxd in iosubsys 2223
ios.vxd in system\vmm32 2225
I looked in device manager primary IDE controller
driver details and saw that the version in options\cabs was
loaded. I renamed this file and rebooted. Now, the iosubsys was
being used. I renamed this and rebooted. Now the ios.vxd in vmm32
was being used, which is the newest.
But doesn't this file really belong in iosubsys?
Does it matter?
Dave
PCR
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\VMM32Files
...So, it isn't one of the files in my VMM32.vxd.
Other than an older version in an Installation .cab, I find IOS.vxd to be ONLY in the folder C:\WINDOWS\SYSTEM\VMM32. It is version 4.10.2222. You apparently have updated beyond that.
It shows up in Device Manager as a driver for the Floppy & Hard Disk Controllers. I always thought it did that by virtue of it's inclusion in the folder C:\WINDOWS\SYSTEM\VMM32. However, by your experience, I guess it could be in any auto-run location, & it will install itself properly.
BUT...
| I had this on my system:
| ios.vxd in options\cabs 2223
| ios.vxd in iosubsys 2223
| ios.vxd in system\vmm32 2225
...I DOUBT the one in options\cabs could have installed. That isn't an auto-install location! You mean... C:\Windows\Options\Cabs? Those are just backups in there, with a purpose. Pointing SFC (System File Checker) to that folder for the purpose of retrieving a backup-- will get the one in the root & not go into a .cab for an older version.
--
Thanks or Good Luck,
There may be humor in this post, and,
Naturally, you will not sue,
should things get worse after this,
PCR
pcr...@netzero.net
"dave xnet" <davexn...@ETEyahoo.com> wrote in message news:b62112lmopvre0nfq...@4ax.com...
glee
(the one in Options\Cabs is a storage copy, not one that loads).
I have no idea how you got a copy in the iosubsys folder.
"dave xnet" <davexn...@ETEyahoo.com> wrote in message
news:b62112lmopvre0nfq...@4ax.com...
Lee
about 'repairing' the Vmm32.vxd file, they are two entirely different
concepts and methods, although the first paragraphs by Roy Lehrer in
the article link you posted speaks directly to the VXD fix as a bogus
fix and the need for it as a, and I quote, 'rumor'. Three paragraphs
under the title 'Rumor' deal exclusively with the Vxd fix, too bad the
link explaining it further is now dead. So is the link to the same
type of info in my post here:
http://groups.google.com/group/microsoft.public.win98.gen_discussion/browse_thread/thread/17cc722d66d3ce6e/9ada04028f909a9b?&hl=en#9ada04028f909a9b
I know which vxd files loaded from where by observing the parentheses
or lack of them around the vxd filename in the Driver file details box
of the Device Mangler. Believe me, the original Vxd fix had put the
files in the wrong place, I corrected that error in my Vxdfix.inf file
and collaborated to help create the Vxd fix for Win95 as well. No
where can I now find the info explaining the issue or my cohort's
vxdfix.exe and/or vxdfix95.exe files. I begged off the project when
the 95 version couldn't be done within the same inf file as that needed
by 98, the reason this is so is because 95 needs only 6 files and from
within an inf file there can not be any discriminating choices made
between two 9x operating systems. My cohart then decided instead of
issuing two inf files, to release two self-extracting executables where
my inf method just got the files from the users installation CD.
In the end, you are quoting Roy to me and as far as I'm concerned Roy
is all wet. AND his repair of the Vmm32.vxd file method didn't work
for me, instead it crashed me hopelessly and only a clean reinstall got
me going again. Perhaps if I'd defeated scanreg it might have worked,
perhaps the method does work for 95 and Roy just showed us how to do it
in 98 without ever actually having done it on this platform, I've never
gone back to try it again to find out. I do know I'm no dummy, I still
couldn't get it to work, and it cost me dearly.
There is another rumor that the Vmm32.vxd file is custom built
depending on your own hardware, yet inside 98 installation inf files I
see hard coded proof that the same vxd files are ALWAYS included in the
'build' of the Vmm32.vxd file - who am I to believe? I think my eyes
first. My own experiances second, anything I read on the internet way
at the back of the pack, and anything by Roy rates dead last since I
know the Vxd fix WORKS. My vxdfix.inf is removable via Add/Remove
Programs list so anyone can see what effects the vxd fix actually has
or doesn't have, which is why I wrote it that way.
As to the KB info quoted, we already have found out that the
configmg.vxd file loads from at least two folders in direct opposition
to the article. Dave is now claiming ios.vxd loads from three
different folders, again, in opposition to the article. My own eyes
give me the third strike and I must then dismiss the article as 'fluff'
to entertain the masses with. Perhaps if they had taken the time to
flesh it out some more with real word details instead of just a cursory
pass at what really happens, I would believe more MS articles. In my
experiance (#2 believability rating) this is sadly typical of MS...
I don't think we have an issue other than what exactly is the vxd fix?
That's where 7 vxd files that should not have been included into the
building of the Vmm32.vxd file were and for some unknown reason, if you
place the uncompacted files into the proper places and let Win98 load
them in uncompacted form directly - they work much better. Whenever
you place an uncompacted vxd file to be loaded in that form instead of
using the one inside the Vmm32.vxd, you have applied the vxd fix.
Delete the file and the vxd fix has been removed, it's that simple.
Why those exact 7 files? Dunno.
for Dave...
Anytime a file shows up in Options\Cabs folder and you didn't put it in
there manually, you can blame an update, hot fix or some program
installation. In Dave's case we can blame the unofficial service pack
which was written wrong to the point that the higher versioned ios.vxd
(I'm guessing that's what 2225 is) wasn't placed properly which allowed
the old one to load. I can only guess that it belongs in the Vmm32
folder because that's where my 4.10.2222 one is by default and I
haven't monkyied with it at all. It does matter where it is because
it's location determines which one gets used. In this specific case it
appears that you can place it in the Iosubsys folder and that folder
has preferential loading hierarchy over the Vmm32 folder but each file
MUST be taken on a case by case basis and not just dumped into the
Vmm32 folder as written up in the MS article (and followed wrongly by
the author of the unofficial patch). I don't know where this
preferential loading hierarchy comes from, it may be a registry entry
since the unofficial patch was able to make it load from Options\Cabs
folder somehow and that is NOT standard at all. Best of luck with that
unoffical service pack - I can't speak enough on how horrible it is.
You might want to look at your System.ini file settings, it used to do
crazy things in there as well.
dave xnet
Lee,
thanks for the info. I decided to try the unofficial patch because
of my frustration with the problem I reported here:
http://groups.google.com/group/microsoft.public.win98.gen_discussion/msg/254dd607cccd1d83?hl=en&
Turns out, the patch did not solve it, and I ended up finding the
solution myself, too many folders at the root level.
Something I've not seen documented anywhere.
Thing is, I'm not really sure what the state of the VxD
mess was before the patch. Some of it could already
existed.
As well as configmg and ios, I also had older versions of
vmouse and vcomm being loaded, even though a newer
one existed on the system.
In my very first post, I mentioned seeing something in
msinfo32 regarding the load path. But this is unreliable,
device manager driver details seems to be the truth.
It would be great if there was a tool that displayed
all the loaded version info in one, convenient display.
Are all the "replacement vxd's" off of the CD version 2222 ?
At least that would be one way of identifying files I may
have in either vmm32 or system that were added as part
of the "vmmfix" I did many years ago. Seems that
you actually support the "fix". I did too, at the time.
I "thought" the system seemed more stable after doing it,
but so many others pooh-pooh it - I wonder what the
truth actually is.
I found this on speedguide.net
http://www.speedguide.net/read_articles.php?id=170
Is this the missing article you were referring to?
It's called the " Windows 98 Drivers Bug "
(scroll down).
Thanks for the warning regarding the unofficial patch.
It seems to be a living project, every month or two
there's a new version. It just seemed a convenient
way of getting updates that are generally not available.
(AT least without contacting M$)
My system seems no less stable since applying it,
now that I've ensured the newest vxd's are actually
loaded.
Dave
glee
No, I haven't confused them. I am aware of the differences, and posted the links I
did to inform the OP of the procedure as it is supposed to be used according to
Microsoft's own documentation, to repair the vmm32.vxd, and to explain quite briefly
what other uses the procedure have been put to, for better or worse. The link
describes them somewhat, as you noted.
I do not know which method (if either) was used by the so-called "service pack" the
OP installed. It appears to have put some of the files in just plain wrong
locations, so I am guessing it does not follow either of the procedures exactly.
I'm afraid I take issue with more than just what the vxd fix is. I am aware of what
the one you refer to as the Vxd Fix, and also of the procedure described in my link
for repairing the monolithic file. For the most part, I don't consider the Vxd Fix a
"fix" in most situations, and certainly not necessary in nearly all situations. I
don't have time to rehash it and go "point by point" to your reply right now.....I
have a lot of work to do and this is really rather old news at this point......no
offense intended.
I am interested in the problems you had with the rebuilding method, and why you had
to load certain files from another location. If I ever have the time to waste, I
will install 98 fresh somewhere and go through it all again to see what issues I
find this time....it's been a very long time since I have messed with this issue; in
fact, IIRC it was when I was using Win95, not 98.
So, stay tuned and I may be back when I am not working.....if that *ever* happens!
--
Glen Ventura, MS MVP Shell/User, A+
"Lee" <mel...@my-deja.com> wrote in message
news:1141969618.0...@j52g2000cwj.googlegroups.com...
Lee
dave xnet wrote:
<snip>
> Lee,
> thanks for the info. I decided to try the unofficial patch because
> of my frustration with the problem I reported here:
> http://groups.google.com/group/microsoft.public.win98.gen_discussion/msg/254dd607cccd1d83?hl=en&
> Turns out, the patch did not solve it, and I ended up finding the
> solution myself, too many folders at the root level.
> Something I've not seen documented anywhere.
> Thing is, I'm not really sure what the state of the VxD
> mess was before the patch. Some of it could already
> existed.
>
> As well as configmg and ios, I also had older versions of
> vmouse and vcomm being loaded, even though a newer
> one existed on the system.
> In my very first post, I mentioned seeing something in
> msinfo32 regarding the load path. But this is unreliable,
> device manager driver details seems to be the truth.
Exactly, the loading behavior seems to be built in somehow and it seems
that it can be different for each file of interest too. Only by
manually ferreting it all out can we count it.
> It would be great if there was a tool that displayed
> all the loaded version info in one, convenient display.
>
> Are all the "replacement vxd's" off of the CD version 2222 ?
Yes they are all version 4.10.2222 for Win98se here.
> At least that would be one way of identifying files I may
> have in either vmm32 or system that were added as part
> of the "vmmfix" I did many years ago. Seems that
> you actually support the "fix". I did too, at the time.
> I "thought" the system seemed more stable after doing it,
> but so many others pooh-pooh it - I wonder what the
> truth actually is.
That is exactly why I wrote my vxdfix.inf file to be removable via
Add/Remove Programs and yet be reinstalled by finding it in the
Windows\INF folder to once again right click and choose Install. At
one time it was a Godsend to me, but back then I was still installing
Windows directly from the CD instead of having the cab files on my hard
drive and installing from the cab files folder, which I firmly believe
may be the root cause for the vxd fix to have worked in the first
place. Every CD installation I ever did had a strange behavior bug in
it at some point, but I've never had that when installed from the hard
drive.
>
> I found this on speedguide.net
> http://www.speedguide.net/read_articles.php?id=170
> Is this the missing article you were referring to?
> It's called the " Windows 98 Drivers Bug "
> (scroll down).
Yes exactly, thanks so much for taking the time to find it, I've
updated my links to it.
>
> Thanks for the warning regarding the unofficial patch.
> It seems to be a living project, every month or two
> there's a new version. It just seemed a convenient
> way of getting updates that are generally not available.
> (AT least without contacting M$)
> My system seems no less stable since applying it,
> now that I've ensured the newest vxd's are actually
> loaded.
>
> Dave
>
I've noticed that the author of that update has been modifying it with
every release, I've got one archived that sets swap file use for
conservative, I'm sure he got some backlash on that one. And so the
product is bound to improve some over time, but I still can't go for
hot patch file replacement willy-nilly. I agree about those hot patch
files needing to be more easily available which is why I archive the
unofficial update. The files inside are extractable using WinZip. See
also:
http://www.mdgx.com/
http://erpman1.tripod.com/index.html
Best of luck Dave.
<snip>
Lee
glee wrote:
> Hi Lee,
> No, I haven't confused them. I am aware of the differences, and posted the links I
> did to inform the OP of the procedure as it is supposed to be used according to
> Microsoft's own documentation, to repair the vmm32.vxd, and to explain quite briefly
> what other uses the procedure have been put to, for better or worse. The link
> describes them somewhat, as you noted.
>
> I do not know which method (if either) was used by the so-called "service pack" the
> OP installed. It appears to have put some of the files in just plain wrong
> locations, so I am guessing it does not follow either of the procedures exactly.
Agreed. The unofficial service pack quite plainly has a section that
shows the famous 7 files of the vxd fix being shuttled to the vmm32
folder, which in my terminology is at least trying to apply the vxd
fix. Except that it uses every available hot patch file to do this
with, which is where I take great exception to it. I'm pretty sure it
does not do any attempt at rebuilding the Vmm32.vxd file but watch this
space, you never know what the author might do in a future(past?)
incarnation of it.
>
> I'm afraid I take issue with more than just what the vxd fix is. I am aware of what
> the one you refer to as the Vxd Fix, and also of the procedure described in my link
> for repairing the monolithic file. For the most part, I don't consider the Vxd Fix a
> "fix" in most situations, and certainly not necessary in nearly all situations. I
> don't have time to rehash it and go "point by point" to your reply right now.....I
> have a lot of work to do and this is really rather old news at this point......no
> offense intended.
None taken I assure you. I respect and understand your position fully
and being in favor of the vxd fix as something to try when problems
crop up, I even share your tiredness of this very old issue and the
lack of time and interest to fully resolve it. My use of the term vxd
fix is quite loose, expanded as loose as it can get in fact, and a
subject to debate another day is fine with me.
>
> I am interested in the problems you had with the rebuilding method, and why you had
> to load certain files from another location. If I ever have the time to waste, I
> will install 98 fresh somewhere and go through it all again to see what issues I
> find this time....it's been a very long time since I have messed with this issue; in
> fact, IIRC it was when I was using Win95, not 98.
This is where the confusion is? I did not "load certain files from
another location" when rebuilding the Vmm32.vxd file, I followed the
article's instructions to the tee. Where you quoted the article to me
as also containing the biosxlat.vxd file is where I was illustrating
the vxdfix file location snafu and NOT the rebuilding article at all.
I was never referring to the rebuilding article until you posted to me
"not accorrding to this". Then I assumed you did not even know about
the vxd fix or problems with it's file locations and thought that I was
trying to get Dave's vmm32.vxd file rebuilt using the vxd fix. It may
turn out that at least for 98 the file location issue may be in fact a
problem with the rebuilding of the vmm32.vxd file, just a funny hunch
I'm suffering from at the moment, maybe it will pass.
As to my problems with rebuilding the Vmm32.vxd file, I had gone to
email with an OP with that problem. He was able (so he says) to
rebuild his to some extent but that it was missing a couple files
(hmmm...). I doubted him and decided to give it a whirl here. I had
no problems doing what the article says to do but when I rebooted to
complete the process allowing wininit to rebuild the file, it didn't
and I crashed and burned with no vmm32.vxd file to boot with. No
problem I thought, I'll just do an over the top reinstall - well that
didn't work believe it or not. Like a dummy, I had not tucked away a
copy of the old Vmm32.vxd file which would have saved the day, I'm
sure. And doing that is probably in the article or at least should be.
I can only blame myself for the reinstallation hassles of all my
programs due to the lack of a backup Vmm32.vxd file. I think the next
time I try it, I'll start with Win95 as it is not running scanreg which
may have some part to play in my vmm32.vxd rebuilding problem. And
perhaps this problem with scanreg only shows up when it is poised to do
a backup of the registry at the next boot? And this all happened in my
early days when I wasn't as through as I would be today, so all I can
really remember clearly about the event is that it didn't work and the
week long hassles of hunting up all my goodies to reinstall.
>
> So, stay tuned and I may be back when I am not working.....if that *ever* happens!
> --
> Glen Ventura, MS MVP Shell/User, A+
> http://dts-l.org/goodpost.htm
>
<snip>
You are preaching to the choir now...and amen.
mae
And they were placed here:
C:\WINDOWS\SYSBCKUP\CONFIGMG.VXD - is the orig
C:\WINDOWS\SYSTEM\VMM32\CONFIGMG.VXD - is the update
C:\WINDOWS\OPTIONS\CABS\CONFIGMG.VXD - is the update
From your other post re: folder.htt:
For basic windows media you can choose properties - preview; but not for
mp3.
I remember vaguely, from long ago, some problems with media player after
modifying.
--
mae
"dave xnet" <davexn...@ETEyahoo.com> wrote in message
news:4d8u02lt3t361t1kq...@4ax.com...