LoneCrusader

No problem, glad you have solved the issue. Did you happen to test whether or not a specific one of those files causes this, or did you just replace them all at once? I actually need to try and find a system to run some tests of my own on this scenario. I went ahead and slipstreamed those files in my slipstream project, but I hadn't had any issues as I don't have that particular hardware. I wonder, if this issue only presents itself if you UPDATE the files, or whether it still surfaces if those files were ALREADY present when the driver was first installed...

I have a feeling this is an example of where the "latest" available files may not necessarily be the "best" available files. See this quote from MDGx regarding Q242937 / 269601USA8.EXE: I'll wager that you have included that HotFix in your USP. Try rolling back the versions of those files to the 98SE originals.

@erpdude8 I was wondering where you found CONFIGMG.VXD v4.00.1113 that is contained in your USP? I have been unable to turn up any KB articles or HotFixes that mention this particular version or what it was supposed to address I have found CONFIGMG.VXD v4.00.1112 in the PCCARD Update (IIRC ) as well as on the Windows 95C CDROM, and I have found documentation that a v4.00.1114 exists in the Q282901 HotFix that no one seems to have, or be able to find, except Petr, who apparently had it at one time, but he has now disappeared

Indeed, I have a Wdmstub.sys file in version 5.00.006. Working with the earlier version did not check, because Wdmstub.sys version 5.00.006 is installed by Maximus Decim Native USB 3.5. WDMSTUB.SYS does exist inside NUSB 3.5, but it is not used. It is not required unless one uses the Win2K USBSTOR.SYS. NUSB 3.5 still contains the WinME USBSTOR.SYS.

Regarding the VIA USB2 Controllers Issue - My suggestion on how to handle this would be to create a SFX installer package that contains the latest VIA USB2 stack, along with an INF, say "USB2VIA.INF" that contains ONLY the information for VIA USB 2 devices. You could take the USB2.INF from NUSB3.5 and simply edit out the information for all manufacturers except VIA, and see that this INF has a later timestamp than the one in NUSB. Then, when installed, this INF should be detected as an "Updated" Driver for the VIA hardware, rather than the older timestamped USB2.INF from NUSB. Care will have to be taken as to where the USB2VIA.INF pulls its driver files from though, as the VIA USB2 stack files have the same name as the Win2K files...

I'm glad to hear you're up and running at USB2.0 speeds. I'm not sure what you mean by this however Do you mean the drivers you just installed, or do you mean a Mass Storage Device driver?

I haven't heard of Xeno86 patched VCACHE.VXD, so I'm obviously not using it. I'm also not using rloew's patch either. In any case, SP3 shouldn't make assumption about what may be installed, and should just leave MaxPhysPage as-is. In that case I guess I've been using it; however, the MaxPhysPage setting still crashes the computer I'm current;y working on. Since this subject has come up, I feel that it is worth mentioning here that any fiddling with MaxPhysPage and such settings in regard to RAM ALWAYS produced unstable and unpredictable results on my systems. I tried several years back to change these settings in order to use 1.5GB of RAM. It never worked, period. I know some have had success in this area, but I believe it is very much a "YMMV" issue, and I agree that a Service Pack should not change these settings. This is one of the main things that makes me "not a fan" of unofficial Service Packs.

If you find a source for these we need to create some sort of "archive" to preserve them. I have often searched for some older versions that still have Windows 95 Support, to no avail. At least I still have a drivers disc for the cards I use in 95...

Glad to hear it!

Never fear, lol, almost all (95%+) of my hardware is Intel Chipset based. We will get to the bottom of this! I thought you said you had Intel USB 2.0 Drivers, because you asked if you should uninstall them when you first asked about NUSB? If your Intel USB2 driver package works like the one I have, when you run the "installer" it doesn't really install anything. All it does is extract itself to C:\WINDOWS\DRIVERS\. This is, shall we say, less than helpful. If it extracted itself to C:\WINDOWS\INF\, it would be useful, but I digress. Go into your Device Manager and see if your USB2 hubs are properly recognized. If they show up as unknown devices, remove them, and reboot. When asked for the location of the driver, point the installer to C:\WINDOWS\DRIVERS\ or wherever your package has extracted itself.

I have not personally used that particular package, but I have many other packages and updates created by R. Loew. You can rely on anything he distributes to be high quality. This, combined with your Intel USB2 drivers you mentioned before, may be a working alternate solution if you are unable to localize NUSB.

I figured that you had probably checked. I was in the process of pulling that breakdown out of my slipstream notes when you posted, and once I had gone to the trouble of extracting it, I thought I would go ahead and post it, it may be of future use. Myself having never checked for other language versions, I figured sorbit4 could give it a shot...

I've never used it, so I don't know. BenoitRen might know more about it, I believe I've seen him mention that utility before...

You can try requesting the HotFixes through MDGx's HotFix Request Form. Just enter the MSKB article numbers that I provided and when you're redirected to Microsoft you can choose other languages if they are still available.

All versions of NUSB depend to some extent on Windows ME. As dencorso said, some files may never display any errors or messages, so their localization may not matter. NUSB 3.3 doesn't use the ME USB 1.1 drivers, but still uses USBSTOR, USBNTMAP, etc.

Here is a breakdown of the files in NUSB 3.5 and where they are collected from. Files that have been edited, downversioned, or otherwise changed are under (MODIFIED) sections. If a section is not marked (MODIFIED) or (UNMODIFIED) then the files from that update source are UNMODIFIED. Windows 98SE CABS (MODIFIED) NODRIVER.INF Friday, April 23, 1999 10:22:00 PM 242975USA8.EXE (MODIFIED) HOTPLUG.DLL 4.10.2224 SYSTRAY.EXE 4.10.2224 NTMAP.INF Monday, November 08, 1999 10:14:26 AM 242975USA8.EXE (UNMODIFIED) 1394.INF Wednesday, October 13, 1999 10:00:12 AM HARDWARE.HLP Monday, August 02, 1999 1:16:06 PM NTMAPHLP.PDR 4.10.2223 Q268064.EXE 1394BUS.SYS 4.10.2226 267304USA8.EXE NTMAP.SYS 4.10.2227 284837USA8.EXE OHCI1394.SYS 4.10.2228 311430USA8.EXE SBP2PORT.SYS 4.10.2227 239696USA8.EXE IOS.VXD 4.10.2225 IE4SHL95.CAB (MODIFIED) EXPLORER.EXE 4.72.3612.1700 Windows ME CABS (MODIFIED) USB.INF Thursday, June 08, 2000 5:00:00 PM DISKTSD.VXD 4.90.3000 USBMPHLP.PDR 4.90.3000 USBNTMAP.INF Thursday, June 08, 2000 5:00:00 PM USBSTOR.INF Thursday, June 08, 2000 5:00:00 PM Windows ME CABS (UNMODIFIED) OPENHCI.SYS 4.90.3000.1 UHCD.SYS 4.90.3000.1 USBD.SYS 4.90.3000.1 USBAUTH.SYS 4.90.3000.1 USBNTMAP.SYS 4.90.3000 USBSTOR.SYS 4.90.3000.1 Windows ME Q278289 (ME278289.EXE) USBHUB.SYS 4.90.3002.1 Windows ME Q304708 (ME304708.EXE) (MODIFIED) CDVSD.VXD 4.90.3003 Windows2000-Q319973 (USB2.ZIP) (MODIFIED) USB2.INF Tuesday, May 07, 2002 4:52:12 PM Windows2000-Q319973 (USB2.ZIP) (UNMODIFIED) USBPORT.SYS 5.00.2195.5652 Windows2000-KB838989-x86-ENU.EXE USBEHCI.SYS 5.00.2195.6882 USBHUB20.SYS 5.00.2195.6891 WindowsXP-KB945436-x86-ENU.EXE USBCCGP.SYS 5.1.2600.5585 291362USA8.EXE USER.EXE 4.10.2231 USER32.DLL 4.10.2231 UNKNOWN SOURCES / UNKNOWN IF OTHER LANGUAGES EXIST QFECHECK.EXE QFECHECK.HLP USBU2A.SYS WDMSTUB.SYS

Yes. Uninstall ALL USB devices, USB 2.0 and USB 1.1 both. NUSB3.5 adds the Windows ME USB 1.1 stack to 98SE which in turn allows greater functionality with composite devices, etc.

Alternate Link:

Looks like these are the correct offsets. Checked and they are listed as being the same offsets despite different file sizes in 3 different language versions at Dr. Hoiby's website. English German Russian name : explorer.exe size : 204288 version : 4.0.0.950 //------------ Offset 0x0C496 : 01 -> 11 Offset 0x0E6CF : 01 -> 11 Offset 0x1E86F : 01 -> 11 If you are uncertain, you could take a look at the English version and compare some of the surrounding bytes at those offsets to see if they are the same. English version and others downloadable from Dr. Hoiby at the link above. Here's a direct link for the English version.

What version of EXPLORER.EXE are you using? The 95-Shell version (4.00.95x) or the version installed by the Desktop Update (4.72.3612.17xx)? The links to the text file instructions at Dr Hoiby's website are a bit deranged and unclear. (For example, the link supposedly for 95A instructions goes to instructions for 98FE EXPLORER v4.72.3110.1) If you tell us what version you're using, we can sort it out. I started a text file containing specific instructions for each version during my slipstream project but I'm not sure where it is at the moment.

Tested with 95C OSR2.5 with all official USB updates installed (USB Updates contain a major KERNEL32 version change) And using the last KERNEL32.DLL for Windows 95, v4.03.1216. When I get a chance I will test again on an installation without USB (=v4.00.1112) Tested on Pre-USB OSR2. Result is the same. EDIT - Added Pre-USB 95 test results.

Nostalgic? No, because I still use Windows 98SE every day. And plan to keep doing so. And anything now or in the future that can't be done on 98SE will be done in Linux.

PROBLEMCHYLD, as you know, I am not a fan of unofficial Service Packs to begin with, as I like to pick and choose my updates. I know you have made a great effort with this, and made a lot of progress in making each update "optional," and all of us are grateful to anyone who spends their time working on things for the OS'es that we all love. So, for what it's worth, one "project author" to another, my advice is to finalize Service Pack 3 WITHOUT KernelEx and RP9. Sooner or later, you must be able to reach a "final build" of your service pack and be finished and happy with it, or you will be working on it forever. We all hope that further development of updates, KEX, and RP will continue, and if this is the case, you will be having to update your package every time some new advancement or workaround is discovered. SP3 needs to be a "milestone" rather than a "cure-all." For those who wish to install it, it can be the first step to having an updated system, and it certainly is a big step in the right direction. If these other packages are added, then a potential user could end up having an OLDER version of KEX or RP installed than whatever the current build is. As long as development has not ceased for good on these packages, then they should remain independent. If their development ceases permanently, I could possibly see adding them as an options.

You might be surprised what hardware works with Windows 9x Have a look at boards using the Intel 865 and 875 chipsets for example. See the last table on this page, and you should also look at these relevant threads: Compatible Hardware with Windows 9x Day-to-day running Win 9x/ME with > 1 GiB RAM Welcome, and good luck!

A few months before Windows Update went down for 9x systems, I visited it and tried to download all of the "recommended" updates for 95 OSR2, 98SE, and ME. I can't say for sure if I got everything, as I was just downloading packages, not actually performing the updates at the moment. But I have it backed up somewhere. Maybe I'll make a list of it if I can find the time...