LoneCrusader

Aha! Only bad thing is now I'm going to have to dig around through all those files and see if there are any versions later than 5.0.2195.5605 but before 5.0.2195.6891.

Always put your health first. You will get to it someday Do you mean USBHUB20.SYS?

Hmmm... This is HIGHLY speculative. No idea whether this would be the case or not! Any chance that such a device would be treated as a "Composite Device?" If so, there may or may not be differences in behavior now that changes have been made to NUSB, etc. Under Win98SE and Win2K, composite devices use USBHUB.SYS (or USBHUB20.SYS for USB2). Under WinME and WinXP, composite devices use USBCCGP.SYS. Now that the Windows ME USB1.1 stack and ME-style USB.INF (with use of USBCCGP.SYS) has been implemented, such devices MAY not depend on USBHUB20.SYS anymore. So the bug may not even exist at all so long as one has a complete collection of the latest unofficial USB updates. Someone who knows more about this than me please chime in...

I tend to prefer using the MS stack if the older versions don't have the bugs with VIA chipsets, but I agree the other option should be tested and considered as well. I have the same problem you do regarding UHCI/OHCI so I can't help with testing the second option. All of my hardware is Intel based with UHCI USB 1.1 controllers. (And man, has it been a pain for a project currently in development that I've been involved in. )

I found USBHUB20.SYS v.5.0.2195.5605 inside this package (issued for Q319973). There may be others, but I'll have to look through all of the many, many packages I downloaded again. Maybe someone can test that version and see if it has the same bugs as the later one... My next question was going to be whether or not the VIA USB2 stack works for all other chipsets, and if so, suggest using it instead. Similar to your suggestion.

Since the older machine still works, you might try one last thing. Put the HDD back in the older machine. Boot into Safe Mode. Go into the Device Manager and remove anything and everything that is listed there. Then Shut Down and try the HDD in the new machine again. If any older drivers are causing problems, this should correct it. If it doesn't, then you should be able to reconnect the HDD to the older machine again and let it redetect devices.

You said you moved the HDD from another computer... I'm assuming you have data/programs on it that you wished to save? If not, I recommend a clean installation of 95B, just in case there are any old settings/drivers/files left over from the previous machine that may be causing errors.

Good point about add-in cards. I wasn't thinking. Driver files interdependent on one another may not be able to interact with each other if renamed. Often they have internal references to one another. Theoretically one might be able to Hex them all and change the names internally and externally, but that would also have to be proven in practice. Another angle: (dencorso please comment on this, you seem to be the most informed member about this) Do we know 100% for sure that ALL versions of the MS USBHUB20.SYS cause errors/do not work with VIA controllers? Or is it just the version used by NUSB? Earlier versions of the MS USBHUB20.SYS driver exist (I tracked them down trying (unsuccessfully) to find the oldest possible versions of a USB2 stack to load on Win95). I can provide a link if someone can test.

No problem. Let us know if the patch works for you!

Renaming the VIA driver files may result in them not being able to properly interact with one another. I can't say that for certain, but I have a feeling it isn't a good idea. I started to suggest having them install to a different folder than the MS files, say SYSTEM32\DRIVERS\VIAUSB2 instead of just \DRIVERS, but that may break their ability to interact with other files in the \DRIVERS directory. I believe WDMCHECK will report missing functions from files that are not in the same folder as the file being checked... I would think that moving the VIA data to a separate INF file would be sufficient. I don't know of any situations where two different branded USB2 controllers would exist in the same system, but maybe I'm wrong...

You will need to use WinZip, WinRar, 7-Zip, etc, to extract the file from inside the HotFix on another computer. MS HotFixes are usually "Self-Extracting Executables" and can be opened with archiving programs.

VCACHE.VXD is merged into VMM32.VXD along with several other VXD's during the second phase of SETUP, so you won't find the file after that. All MS HotFixes require Windows to run. Pretty useless when you can't boot to Windows to begin with. That's why I created FIX95CPU to install the updated CPU fixes. In order to update your VCACHE.VXD, you will need to manually extract VCACHE.OSR (it contains two VCACHE files, one for 95/95A and one for 95B/95C) from the HotFix file I linked, rename it to VCACHE.VXD, and manually place it in your WINDOWS\SYSTEM\VMM32 folder. The Boot Image of an .ISO is not visible without tools for viewing/extracting/editing etc. FIX95CPU.ISO contains a boot image of the FIX95CPU floppy, with DUN14-95.EXE added to the "normal" part of the ISO for convenience. I wish you success in your endeavor, but in my personal experience, if you want to use more than 512MB of RAM, you will need RLoew's RAM Limitation Patch. Several users here report success using up to ~1.5GB with the tweaks you have been experimenting with, but those tweaks never worked on any of my systems. (Also, many of those users are using 98SE, which may handle the larger RAM amounts better than standard 95B/C can.) The patch has a DEMO version that runs for 10 minutes. You might try downloading it and see if it cures your problem.

I have been unable to find any solution to this issue. The Icon bug is an obvious cosmetic flaw, and, I noticed that several strings pertaining to CONFIG.SYS that are present in the 98SE SYSDM.CPL have been removed from the ME SYSDM.CPL. It is unknown at this time whether this would cause further problems for users who need special CONFIG.SYS setups or use it to load drivers, but I suspect further problems may lie hidden. There may be a way to make the 98SE version function in the same manner, but I have not managed to find it. I have tried various changes to the .INF files involved, trying to force an automated install, but nothing has worked.

It's normal for Setup to extract its driver (and other) files from the .CABs, that's how all versions of Windows 9x install... The X:\WIN95 reference must be something unique to your setup, because there are no such references in FIX95CPU. It sounds like the PATH to your CDROM drive (or .ISO mounted as CDROM) has been changed since the first round of Setup. Maybe with more details I could be of more help...

Probably a good idea to update VCACHE.VXD as well. Even 95B comes with VCACHE.VXD v4.00.950. The updated VCACHE.VXD v4.00.1111 for 95 B/C OSR2.x in Q194827 is 2x the size of the old 95/95A version. Q194827.EXE

Always check MDGx's site for HotFixes. He has a good percentage of them linked or archived. Q256015 (sometimes they will be renamed to "Q+ the KB#" rather than the original "KB# + (locale) + (5, 8, or M for 95/98/ME)" Which version of 98 are you using? First Edition or Second Edition? If Second Edition, there is a later version of the file involved in this fix...

Is this something that will pop up repeatedly or only the first time after downloading. Just curious. It's interesting to me that for versions of Adobe Reader one must download the later versions sequentially ex: v6.0.1 ---> v.6.0.2 ---> v6.0.3 and so on but for Adobe Flash Player it is recommended that you completely uninstall the old version before upgrading to the latest compatible version. No problem. You will only see the warning during the install, never again. Yes, it would be nice if the various patches for Adobe Reader v6.0.x would have been combined or if they had issued a complete v6.0.6 installer.

Here's a ZIP with both versions of Flash Payer 9.0.289.0. I archived it some time ago. fp9289.zip - 2.8 Mb EDIT: Here's the easy way to get Java 6u7. MDGx - AddOns - Java Follow the link/instructions in this section:

TIA = Thanks In Advance

I have extracted the contents of the Windows ME MSBACKUP package and compared all of the files inside to the versions in the 98SE .CABs. All of the files are the same, so differences in the MSBACKUP tool cannot be causing the error. I'm in the process of installing 98SE without the Backup tool and will test the ME SYSDM.CPL with that install to see if I get the "other" weird icon. EDIT: I have done further experimenting and I have had some interesting results. Without the Backup tool installed. I get the same Icon (19 SETUX/SETUPAPI) that PROBLEMCHYLD does. HOWEVER, ONLY devices installed AFTER updating SYSDM.CPL get messed up Icons. If the devices were already installed while using the 98SE version, their Icons remain correct. But, NOT ALL devices installed after updating SYSDM.CPL get messed up Icons. Only some. @PC Tested the special version I sent you again. On my machine it does NOT have the "not centered" bug. It should be good to go for your special case.

You might not, we do: jaclaz

At this point we don't even know if the OP HAS an nVidia card..

HT setting doesn't matter. I always leave it enabled on my machines because I multi-boot with other systems that can use HT; and even Win95 has no issues with it. You should also reduce your RAM to 512MB or less until you get everything installed properly. It's possible to use more, but I've never had any luck using more than that without RLoew's RAM patch. There are ways of doing so, but they should be left for experimentation once the installation is complete.

Get THIS and THIS. (Last Intel Chipset Utility for 98SE/ME and Intel Graphics Driver for an 865GLC Motherboard). Report your results. I have seen cases where OEM's will somehow "slightly" modify hardware just enough so that the original manufacturer's drivers do not work properly. Maybe that's why the Intel graphics drivers you downloaded already aren't working.

Ok... Back to the Icon problem. I examined the NTMAP.INF and USBNTMAP.INF files that are part of NUSB because I remember there being references to Tape Devices in them. I was correct, there are references to tape devices. However, the only "Icon" that is set by either of these files is a normal disk drive icon, Icon #9 in SETUPX/SETUPAPI. So, these files are not responsible for the problem. (Thought this was the case anyhow, but wanted to rule it out.) Since the registry entries associated with Tape Devices do not affect the 98SE version of SYSDM.CPL, I think we should concentrate on seeing if there is anything handled differently under ME for these devices before we try to fix it by removing/changing 98SE settings. I think our next step should be to examine the Windows ME settings for the same devices and see if anything is handled differently. We should see if all of the same INF's and other drivers are present under Windows ME, and see if Windows ME's Backup tool is different. If any of these items are different or expect different conditions, we may need to try backporting some other settings, files, or both in order for the ME SYSDM.CPL to respond properly.