LoneCrusader

I don't get it : http://www.msfn.org/board/topic/91336-usb-20-stack-for-win98me/#entry617413 and following ... jaclaz I can only assume that Tihiy never was aware of or tested 6127 when he made that post. That specific version was never mentioned in the thread by anyone. I had to do a significant amount of digging to find it myself, as it was buried in an old list of post-SP3 2K Hotfixes and apparently it was superseded because of some issue with it, IIRC. But it does work like the previous 5652. Apparently you're the lucky one if you're able to use 6657-6941 without problems. No one else has reported success with any version greater than 5652 that I am aware of, other than my 6127 report. I've run the same experiment with all of the USBPORT.SYS versions multiple times now on multiple machines. Every time, all versions later than 6127 cause BSOD's when I plug in a USB Flash Drive. I wonder if there is something different in the methodology used. Did you originally install your USB2 controllers using the later USBPORT.SYS versions? Or, did you manually update it after installing them with the older NUSB version? If the former, are you able to do the latter and still not get a BSOD? This issue mentioned by Tihiy is precisely the one due to USBHUB20.SYS v. 5.0.2195.6891 and VIA chipsets. While one can recover from the BSOD, the only sensible thing to do at that point is to restart or shutdown the machine. With time passing, I got convinced at least some of the issues with USBPORT.SYS occur only on machines using AMD processors with VIA southbridges (as is the case of my Asus A7V600-X with an Athlon XP 3000+). That seems to explain the difference in the results obtained by xRayer, Tihiy and myself vs. those observed by LoneCrusader and ProblemChyld. Intel machines apparently are much more forgiving than AMD/VIA, regarding whatever changed in USBPORT.SYS. Of course, these are just my 2¢... N.B.: I never tested v. 5.0.2195.6127, so I cannot say anything about it. Unfortunately, my 98SE machine is out of commission (and belly-up) at the moment, so, for the time being, I cannot volunteer to actually test it. Sorry! I've seen BSOD's when trying to remove a USB2 device from the Device Manager under Normal Mode as well. The best thing to do is remove or disable them in Safe Mode when necessary and avoid the problem. If this thread keeps going like it is, I may have to get you to move it into the 9x forum, lol.

Windows 98 (or later) USB drivers of any kind will not work under Windows 95, period. They depend on WDM functions that simply do not exist under 95. No amount of INF tweaking or wishful thinking will fix that. Trust me, I have tried. The only way to solve this is to backport several files from 98 to work under 95, thus creating a Hybrid system. rloew managed it, but unless he wants to further explore the issue I wouldn't get my hopes up.

I have found two versions that work. The original that is used in NUSB version 5.0.2195.5652, and one other comes from Q811011, version 5.0.2195.6127. Versions 5.0.2195.6657 and up all cause a BSOD on device connect. I don't know if any versions exist between 6127 and 6657; if anyone here knows of any please let me know.

You're welcome. I may have also solved this bizarre issue. It seems to have been caused by a BIOS setting, "USB Storage Function" which one would logically assume should be set to "Enabled" based on the less-than-informative BIOS Help text "Enable Legacy USB Storage Function." I set it to "Disabled" just to see if it made any difference and the issue seems to have disappeared. Strange... EDIT: Probably more informative in our 9x forum, but I also attempted to use some XP USB files under 98SE before I found the above. They did NOT work. USBEHCI.SYS would not load even though it wasn't missing any imports. USBPORT.SYS and USBHUB.SYS are missing several imports.

I downloaded the files you linked and examined them. I will update my INF's with the new devices soon. The ME USB1 stack should be equivalent to the 2K stack. ME was actually released after 2K. Yes, 2K saw updates for a longer period but probably any changes were specific to 2K issues while the ME stack was specifically designed for the 9x codebase. I also think it's significant that only one USB1 driver file out of the ME stack had a HotFix issued, while virtually all of the USB1 stack under 95, 98, and 98SE saw multiple HotFixes issued. I believe PROBLEMCHYLD's Service Pack uses all of the 2K USB1 stack if you want to experiment there though... I may have found a cause for the problem on my system. Check your BIOS for a setting to Enable/Disable "USB Storage Function". Set it to DISABLED and check to see if the problem still exists. My BIOS gives less-than-helpful text "Enable USB Legacy Storage Support" which one would logically assume should be turned on; but turning it off seems to have solved the problem on my machine.

I see. Here's the output. Hopefully it will shed some light on the issue you're investigating. i7_930.zip

Only the 3 USB2 driver stack files are common to both 98SE and 2K on my testing machine, so the problem must lie within them. I'm also using the ME USB1 stack files under 98SE as you are, but these files are all different under 2K. I have already ruled out the storage driver by the fact that it does not enumerate devices when they are connected, it only takes over once this is done by the controller driver. Also I ruled it out by testing with the ME USBSTOR.SYS, rloew's generic USB driver for 98, and with rloew's RLUSB9X, all of which behave the same. I haven't tested USB1 functionality with the USB2 controllers disabled, but this would defeat the purpose anyway. Well, while I've been unable to help you in this case, you may be able to shed some more light in another issue we've benn investigating... In case I'm correct, your machine has a i7-930 processor, which is a Bloomfield, a very early i7. Would you please be so kind as to run coreinfo (on XP or 2k) on it? Sure. What is coreinfo? lol

Unfortunately that's the only one I know of that is confirmed. And even that being said, I have never tested it. We only have RetroOS's old post about using it successfully, and no reports of it not working. The ME version of this file is actually known to not work under 98SE, but I assume that is because it is missing a WDM function. Very odd that the ME version is missing a function while the XP version is not, but I digress. This problem lies somewhere within the 3 USB2 driver stack files USBPORT.SYS, USBEHCI.SYS, and USBHUB20.SYS. We can narrow it down to those 3 files because the same issue is present under both 2K and 98SE when using them (actually seems to be worse under 2K). If I had to hazard a guess, I would say that the issue lies somewhere in the "device connect notification" subsystem; or there is some kind of "timing" fault with newer controllers. But I'm no programmer and have no idea how to debug the drivers.

I was hoping for a solution that fixes the native Windows 2000 files rather than having to use XP files. Those of us running Windows 98SE/ME depend on being able to use the 2K files, the XP ones won't work under 9x. Thanks anyway though!

Hello my Win2K friends! I have encountered a strange problem where USB2 storage devices are not automatically being recognized when they are plugged in. I have to manually "Scan for hardware changes" in the Device Manager in order for the USB drive to be detected. And then, the system seems to lock up before the drive is mounted and the driver installation sequence never completes. Unplugging the drive at this point will unlock the system, but an empty "ghost" Removable Disk is then mounted in EXPLORER. I originally discovered this problem while running under Windows 98SE using the Windows 2000 USB2 drivers. I found that I had to manually Refresh the Device Manager there to get the USB drive detected, and once detected, access and file transfers are ridiculously slow. Nothing I tried seemed to fix this, so I decided to install Windows 2000 and see if the problem still persisted there. It actually seems to be worse under 2K than under 98SE... The problem does not exist under XP SP3. System specs: Gigabyte GA-EX58-UD5 motherboard Core I7 2.8GHz CPU 4GB RAM NVidia GeForce 7950GT 512MB video card all onboard devices disabled in BIOS except USB Windows 2000 SP4+UR1 clean install with no other modifications whatsoever Any ideas?

Good advice, but note that Windows 2000, like 98, does not use USBCCGP.SYS natively like Windows XP and ME. In order to have it used under 2K some slight INF modding would be necessary. Compare the original 98SE/ME or 2K/XP USB.INF's for more info. Also there's this from Microsoft. Maybe more helpful... Also if I remember correctly (I've never dug into it, just read about it), there were actually 9x-compatible MTP drivers "provided" from Microsoft, but they were all left in a state requiring command line operation. No GUI was provided or any way to facilitate using the drivers with the existing GUI (EXPLORER, mounting devices, etc). So I imagine that at least this state exists for 2K as well, if not further developed.

Glad the new package is working. Odd behavior with the USB2 hub, I had a similar problem with Windows 95 on an ICH8 machine a little while back. One of the USB1 controllers would cause Windows 95 to hang up solid, triggering a continuous system Speaker alarm from the motherboard until powered down or reset. Disabling this specific controller allowed everything else to work normally. The exact same PID number controller works fine with 95 on a different motherboard. I've not worked out any solution for the detection failure/slow transfer issue yet. We may need to try using later versions of the 2K USB2 driver files if available. I know there was some mention before that later versions caused BSOD's, but if one of the later versions fixes the current problem it might help narrow down what to fix. If you want to upload the newer package somewhere or link to it I will examine it to see if it contains any devices I have not already covered. It's not hard to create an INF set for 9x or any other OS, just very tedious and time consuming. Should be even easier for XP when the time comes, since the NT INF structure will not have to be completely restructured as it must be for 9x.

Here's the new NUSB35CZ, let me know if you have any problems with it. Unfortunately I don't know very much about the ASD either, rloew mentioned once before that I should check for it when I was having some problems. It looks like we're going to need rloew's help to sort out these USB problems.

I downloaded the old NUSB 3.3d Czech package from MDGx and compared it to the 3.5 English package along with the files you sent. Apparently there is also a localized IOS.VXD and a couple of other INF's but I have them now from the 3.3d package. I will need an original USB.INF from Czech Windows 98SE, and if you have localized versions of USB2.INF and USBSTOR.INF I will need them to include as well. I have everything ready to pack into a new installer once I have those INFs localized and fixed. A clean install might be helpful, but once the new NUSB files are in place I doubt that any leftovers from older versions are "different enough" to cause USB devices not to work at all. I discovered that the Automatic Skip Driver agent (ASD) had been triggered during my 98SE install on the X58 system, so it may be causing some problems. No further information yet. I had hoped that your problem would be similar but it seems to be different. X58 still includes USB1 and I can get USB disk access by Refreshing the Device Manager, but you have no USB1 and Refresh doesn't work. Here's the screenshot anyway.

I may have just encountered this issue on an X58 Chipset system. Try opening the Device Manager and clicking "Refresh" while a USB Drive is connected. It worked for me to detect the device, but file transfers are running ridiculously slow, like less than half the speed of USB1.1...

You may need to add more lines for GCDROM.SYS specifying which SATA controllers to probe for drives, especially if your SATA CD drive is not on the primary SATA controller. See the Examples section here. (I personally find this very annoying, I wish I knew how to alter the code so that it would automatically scan more than one controller by default...) Beyond that I'm not sure how to proceed. More information about your system and what methods you are using might help. Maybe some others members will join the conversation...

You will have to integrate it into whatever you are using to boot the system in order to run SETUP. This means you have to add it to your Boot Disk if you are using a Floppy, or you will have to extract the boot image of the 98SE CDROM and modify it like a floppy with a tool such as WinImage, and then burn a new Windows 98SE CD using the modified boot image. You use GCDROM.SYS by adding it to the CONFIG.SYS file. See the line already there referencing OAKCDROM.SYS for reference (the Microsoft-provided file that works for virtually every IDE PATA optical drive but not SATA). You can add a line for GCDROM.SYS after OAKCDROM.SYS and that way OAKCDROM.SYS will be loaded first for any drive that it does work with, and if it fails, then GCDROM.SYS will be loaded instead. If you are not familiar with creating your own Bootable CD's, modifying Floppies, or editing CONFIG.SYS, it might be best to read up some on this before you dive into this. I'm sure some other members can offer better insight, instructions, and links on this than I can. PS - I got your PM, but this is best discussed here on the open forum where others can help as well.

Interesting. The problem may lie deeper then, if USBD.SYS and the other files were present and your USB2 still doesn't work... You can manually install NUSB once extracted by right clicking "_nusb.inf" and choose Install.

I use and recommend NUSB 3.5. I believe NUSB 3.6 only adds SYSDM.CPL from Windows ME, which does allow USB Storage devices to be auto-installed without prompting for a driver (behavior like XP and later), but it also has some cosmetic flaws when used under 98SE. ("Windows Millennium Edition" shown in various places instead of "Windows 98"; a bizarre icon overlay bug on USB controllers in the Device Manager; "System Restore" controls being shown; and possibly other undiscovered issues) I tried some while ago to correct some of these but there are no "resource editors" which will properly handle the file since it is an NE executable. I made some progress but never fixed all of the issues. I think my last modified version ended up in PROBLEMCHYLD's Unofficial Service Pack. If you want to upload the CZ version files for NUSB 3.5 or 3.6 somewhere I will try to repack them when I get a chance. I've never repacked NUSB but if I can repack the original 95 USBSUPP, it shouldn't be too hard.

A G41 chipset system could work, but there are several factors that determine the level of 98SE compatibility. Since your system is a "prefab" OEM-branded one, Dell may or may not have made tweaks or other modifications to the motherboard BIOS that can cause conflicts and other oddities when trying to run an unsupported operating system. I have seen an Intel-branded DG41TY board that would not work with 98SE whatsoever unless it was installed with ACPI disabled (SETUP /p i). However third-party G41 boards by manufacturers such as Gigabyte, MSI, etc may never show any of these issues. Based on my experience so far I recommend avoiding any motherboard not running an AWARD BIOS, but there is no way to find out for sure whether a system will work with 98SE or not without trial and error. You will need a DOS SATA CDROM Driver such as GCDROM.SYS to access the Windows 98SE CD, or you will need to copy the SETUP files to a folder on the hard drive using a different machine. With no IDE, you can check whether or not your BIOS can set the SATA Controllers to Legacy IDE mode. If not, you will need rloew's SATA Patch. With more than 512MB of RAM, you will need to experiment with the various RAM tweaks floating around; or, you will need rloew's RAM Patch as well. I recommend the RAM patch as the tweaks never worked for me.

The Windows ME USB1 stack is a slight improvement over the 98SE version. I actually proposed that NUSB be updated to include it so that USBCCGP.SYS would be available to 98SE, based on a report by another member that he was able to get a newer "USB Composite" device to work under 98SE by adding this file from XP. (The ME version of this file is apparently bugged and 98SE/2K do not use it while ME/XP do). There is no benefit to using the 2K USBSTOR.SYS over the ME version. The ME version has no problems and does not require WDMSTUB.SYS like the 2K version does. Only the 3 USB2 driver files are needed from 2K. Apparently the problem here is that USBD.SYS, a USB1 driver file, is also required by the USB2 driver stack. On a USB2-controller only system, USBD.SYS (along with some other files) is not being copied to the system and therefore not fulfilling the requirements on the USB2 stack. These files just need to be in their proper places, they do not have to be manually "linked." Look through the USB.INF CopyFiles sections and copy all of the files to their proper locations. For example put USBD.SYS, USHBUB.SYS, UHCD.SYS, and OPENHCI.SYS in WINDOWS\SYSTEM32\DRIVERS and SYSTRAY.EXE, HOTPLUG.DLL and USBUI.DLL in WINDOWS\SYSTEM and so on. If you are using Intel then you most likely do have UHCI controllers, not OHCI.

Sounds like the USB issues are related to the lack of USB1 files discussed in the "modern motherboards" thread. I didn't release an updated USB.INF for the newer systems, simply because at least 2 different INFs would be required depending on what configuration the user has. -One handling method is required if one is using the standard 98SE USB1 driver stack and/or NUSB 3.3 or earlier. -A different method is needed if one is using the ME USB1 stack (+XP USBCCGP.SYS) with 98SE (NUSB 3.5 or later). Which version of the USB1 stack and/or NUSB are you using? However neither of these INF methods would directly address the lack of USB1 driver files on a USB2-controller only system. You may need to copy all of the files referenced in the Copy sections of USB.INF to their appropriate locations on your system if they are not already present. If this helps, it may be necessary to merge USB.INF and USB2.INF for future setups on such systems. If not, I'm not sure how to proceed. EDIT: It may also be worth noting that I have seen unexplainable problems with USB2 controllers and drivers on certain "newer" systems before. I have an Intel DP43TF ICH10 motherboard that absolutely will not even boot 98SE if a USB2 driver is present. This is both with and without ACPI enabled. If I remove the USB2 driver, 98SE will boot and work. But if I put it back, it refuses to boot again. This behavior is the same with both the Microsoft 2K USB2 stack and with the OrangeWare USB2 stack. However, a Gigabyte GA-EP45-UD3LR ICH10 board does not have this problem.

You're welcome! I'll be looking forward to your report. Please do post it in my INF thread so I can keep track of all the reports and testing related to the project in one place. I know what you meant about removing the older INF since you are upgrading but for the record my INF's are completely cumulative and should cover the older P3x chipsets as well; so no data or functionality for the older system would be lost by using the newer files. Please let me know if you see any VID&PID combinations that do not exist in one of my INFs, whether they are older or newer.

More than a guess.I preloaded USBD.SYS on my Z87 so I didn't see this problem but I was missing SYSTRAY and HOTPLUG which is also missing from the USB2.INF File. By "preload" do you mean just copying the file to the system so it is present or does it need to actually get "loaded" by NTKERN along with one of the USB2 drivers? I have debated merging USB.INF and USB2.INF before. I decided against it then but it may be time to reconsider since one could do this and set it up to copy all necessary files by default to avoid the issue at hand.

@ragnargd, xrayer Here you go, thanks for the interest and prompting me to finish! Here's an updated version that handles all devices up to the Intel Chipset Identification Utility version 9.4.0.1017. It requires different handling than the original package described here; see the README inside. I will leave all of the older links intact because the older version is still fine unless you need support for an ICH10 or later chipset. Please post any test results, bug reports, or comments here.