LoneCrusader

It's up to you guys. I've stated my case, and I maintain that if moved, the thread will quickly become irrelevant to 9x. But it looks like I'm outvoted.

Actually I had never really thought about it. I would think that this is more a "hardware" issue than a "software" one. Maybe rloew could give a definite answer... I know he has run 95 on SATA drives with his patch, and I have run 95 on P4/IDE ATA100 boards so I doubt there is actually a "software" limitation here, unless logically it would be the upper limits of IDE BUS speed.

Glad you got it straightened out.

There's another misunderstanding/miscommunication going on here. The VIA drivers you are referring to are for the internal USB 2.0 Hardware (hubs & ports) ONLY. VIA (or any other USB2.0 manufacturer) does NOT provide external USB Device support. NUSB provides BOTH USB2.0 hardware AND USB external device support. You MIGHT try this, to rule out issues from other sources and issues with the Microsoft USB2.0 drivers on VIA systems that seem to affect some users. (See the NUSB and USP threads for more info). Do a clean install of 98SE as previously described. Remove all USB and Unknowns from the Device Manager. Install NUSB 3.5. Once that is done, go into Safe Mode and remove all the USB Devices again, and then manually replace these files in the WINDOWS\SYSTEM32\DRIVERS and WINDOWS\OPTIONS\CABS folders. USBPORT.SYS USBHUB20.SYS USBEHCI.SYS With the ones from this package: VIA_USB2_V270p1-L-M When you reboot, be sure to direct any file requests to C:\WINDOWS\OPTIONS\CABS and NOT the 98SE CD. If you get any "Keep newer file?" prompts on THOSE THREE FILES ONLY, say NO. (The VIA files have an older versioning scheme than the Microsoft ones so are treated as "older" by Windows.)

True, I should have clarified that. I usually do not install more than 512MB of RAM until I have reached that point.

I SERIOUSLY doubt that NUSB is the root cause of your troubles. For the record, NUSB extracts copies of all the "new" files it installs to C:\WINDOWS\OPTIONS\CABS so if any files are requested during driver installation, the installer should be directed there. The version of EXPLORER you are using is irrelevant. If you had a "Network Adapter" show up during the installation of USB devices, then you must not have disabled it in the BIOS. If you insist on claiming that NUSB is the cause and refuse to entertain the possibility that the Sound Card and/or its drivers may be the problem, then there's not much more we can do to help you. If you want "no frills" external USB Drive support, you can check out RLoew's USB Storage Drivers. Scroll down to "USB" and download "USB.ZIP."

I don't know why the system would suddenly start behaving like that. Something else must have been altered or corrupted somewhere along the line. I'm suspicious of that point you noted about how the "Boot Sector" had been modified... I think that the filesystem may have been adversely affected by having to move the drive around so much and/or having to mount it under different OS'es. Sometimes that can cause "glitches" due to different methods of handling; I've seen odd behavior on FAT32 partitions that I had shared between 98SE, XP, and Linux before. At this point I don't know what else to try. If you ever want to take a crack at it again with a fresh Windows 95 install then I'll be glad to help you any way I can.

I think he got the "Safe Mode" point from one of my posts in another thread. I told him to remove all instances of his USB HDD in Safe Mode (because installed devices not currently connected don't show up in Normal Mode, but do in Safe Mode.) This is the order that I use when setting up a new system; it may be no better or worse than anyone else's here. REMOVE ALL add in cards (except Video of course) and DISABLE ALL onboard Audio, LAN, Modem, etc in the BIOS. Install Windows 98SE. Install DirectX 9.0C. Install Motherboard Chipset Drivers. Install Video Card Drivers. Install IE6SP1. Install WMP7.1 (or WMP9 if you prefer, or ignore this step if you don't use WMP). Install NUSB. Install any other Official or "Unofficial" Updates you plan to use at this point. In my case RLoew's RAM Limitation Patch for example. (As you can see I prefer to update various pieces of the OS BEFORE introducing 3rd party software/drivers as much as possible) Install Sound Card (insert add on card or re-enable onboard in the BIOS, whichever you're going to use). Install Sound Card Drivers. Install/enable LAN card..... and continue the process. Installing/Enabling new devices one at a time decreases the chances for conflicts and allows you to pinpoint where & when issues arise.

Ok, things are looking up. I believe we have successfully removed the Demo RAM patch and XUSBSUPP. There should not be any more files left with .O20 extensions, and you should remove any remaining files we have used/altered such as VMM32.ERR, and leave only a backup copy of the 2005 VMM32.VXD, named VMM32.ORI. (Be sure to use that name, as XUSBSUPP uses the .O20 extension, and the RAM patch uses .BAK, so .ORI leaves us with an extension that will not be altered, deleted, or overwritten by any update.) Does the computer still hang now that we have reached this step, or have we stopped that? Now, as you encountered errors while the HDD was still in the "new" machine, and had to transplant it again, it is probably a good idea to go into Safe Mode and remove all of the devices from the Device Manager again to ensure that no devices detected on the "new" machine are still present. Then Reboot, and allow the machine to install drivers for the older hardware. If you get any prompts about missing files, try manually directing the installer to C:\WINDOWS\OPTIONS\CABS or C:\WINDOWS\SYSTEM, if the required files are still not found, try other "logical" locations under C:\WINDOWS. If any are still not found, make note of what files they are and what device was requesting them if possible. Hopefully this will correct the MS-DOS Mode issue and get you back to where you were. Let me know the results. I must go soon for tonight though, as I have to work in the morning.

I do have some ideas about the other issues you're having, but we need to get "back to where we were" so to speak before they can be addressed. If the things we're doing don't fix it, the MS-DOS mode may be caused by all of the devices being removed and/or drivers not being reloaded. Also, if the HDD is in the "new" computer, then BIOS settings with regard to the SATA ports on your motherboard might cause it. Also, the loading of EMM386.EXE may be contributing to you not being able to access Normal Mode with the Demo RAM patch on the new machine. (I will leave that for others more knowledgeable to comment on, but I remember seeing others describe issues with it.) Note all of this is conjectural at the moment.

Ok, is the hard drive currently in the "new" computer or the "old" computer? I'm so confused... It needs to be back in the old computer in order to get everything straightened out. Once that's done, then you can make another good backup and we can try again if you want to. Having the HDD in the new computer for this has been a disaster. Right now we need to get all traces of XUSBSUPP and the Demo RAM patch removed. (I'm going to assume that the VMM.VXD was from the RAM patch judging by its date. Delete it.) Did the Uninstall of XUSBSUPP from Add/Remove programs work properly after you had done the manual part? (It should have asked you to restart?) So now you should have: C:\WINDOWS\SYSTEM\VMM32.VXD dated 2005, VCACHE.VXD extracted from the HotFix, and there should NOT be any VMM.VXD under C:\WINDOWS\SYSTEM\VMM32\ Does all that check out?

Ok, I don't know how these things have gotten "derranged" from their original configuration, but it may explain why you had problems with XUSBSUPP. From the dates of the files, it looks like the VMM32 and VMM files still on your system were the "patched" copies used by the Demo RAM patch. I don't know how these files remained there if you had it uninstalled it when you first ran XUSBSUPP, but nonetheless they remained. The RAM patch must be removed from the system first, as XUSBSUPP will update files patched by the RAM patch, and break the RAM patch. (And apparently itself in the process.) Copy VMM32.O20 and VMM.O20 from your backup to your Windows 95 machine. See if VMM.O20 has a "Version" Tab under Properties. (Note this only shows under 9x, .VXD files' Version Tab doesn't work under XP.) If it doesn't then you can simply delete it. If it does, then tell me the file version. Now, under your other OS, rename the current VMM32.VXD dated 11/27/12 to VMM32.ERR and replace it with the VMM32.O20 dated 7/5/05 from your backup. EDIT: Also delete any VCACHE.VXD, VCACHE.BAK, or VCACHE.xxx files and replace it with a copy of the one from the HotFix that we directed you to when we started work on this. See if this stops the hangups and the MS-DOS mode issues. Second EDIT: If VMM.O20 from the backup, and VMM.VXD currently on your machine do NOT have Version Tabs under 95, then Delete BOTH of them. (Note VMM.VXD not VMM32.VXD, VMM32.VXD will NEVER have a Version Tab.)

Did you uninstall the Demo RAM patch BEFORE you tried to install XUSBSUPP?

The OP, shae, is a frequent visitor to our 9x section. In his original post, he mentions Win9x. (Emphasis mine.) That's why I have taken the position that I did. Different strokes for different folks I guess.

Ok, that's fine. The ones that I referred to in \VMM32 "IF any ... are there" would only be there in the event that they had been updated since the original installation was done. Otherwise they are already packed into VMM32.VXD. What's the version number of the VMM.O20 that was present? It's the only one that falls into this category it seems. Interesting, had you updated this file before?

I disagree.. if the original intent of the thread was to categorize SATA to IDE adapters that work under 9x, then I don't think it should be moved from the 9x forum, as it would be much harder for 9x users to find, and some may never know about it. Also it would quickly become filled with non-working or irrelevant things with regard to 9x. If others post in the thread that aren't interested in 9x, then they could be referred to or have their posts split to the Hardware section. This is kind of like my "in"famous Bootable DVD thread - it could belong to the Bootable CD\DVD forum where it originally started, but my goals and all methods used were specific to DOS/Win9x so I felt that it was better here...

IMO, you should always install NUSB and any other Operating System updates BEFORE you attempt to install add on (or even onboard) cards. Are you using a USB Keyboard or Mouse? If so these count as USB Devices and must be removed also. See this thread (applies more directly to the USP, but applies to NUSB as well). EDIT: And DO NOT! use USB20DRV.EXE.

No problem. CONFIG.SYS is not altered by XUSBSUPP, so it's fine to leave as-is. Good idea to back up the entire drive.

Ok, here is a step by step, directory by directory list of instructions for removing XUSBSUPP from an unbootable machine. *BE ABSOLUTELY CERTAIN THAT YOU LEAVE ALL OF THE FILES WITH AN .O20 EXTENSION AND ONLY RENAME COPIES OF THEM!* 1.) In the root C:\ folder: Be sure AUTOEXEC.BAT is blank unless your system had any previous specific settings in it. If these lines are present, delete them: 2.) In the C:\WINDOWS folder: Delete: VFWWDM32.DLL 3.) In the C:\WINDOWS\INF folder: Delete: USB.INF IMAGE.INF NODRIVER.INF Copy & Rename the Copy: NODRIVER.020 to NODRIVER.INF 4.) In the C:\WINDOWS\SYSTEM folder: Delete: RPLCLDR.EXE (If exists.) DEVLIB.EXE (If exists.) UHCD.SYS USBD.SYS USBHUB.SYS OPENHCI.SYS USBCAMD.SYS IMAGECLS.SYS VFWWDM.DRV CONAGENT.EXE KERNEL32.DLL KRNL386.EXE MSGSRV32.EXE REDIRECT.MOD SPOOLSS.DLL WINOA386.MOD Copy & Rename the Copy: CONAGENT.020 to CONAGENT.EXE KERNEL32.020 to KERNEL32.DLL KRNL386.020 to KRNL386.EXE MSGSRV32.020 to MSGSRV32.EXE REDIRECT.020 to REDIRECT.MOD SPOOLSS.020 to SPOOLSS.DLL WINOA386.020 to WINOA386.MOD Rename: VMM32.VXD to VMM32.BAD (Can be deleted once all of this is successful.) ***Important!!! Copy & Rename the Copy: VMM32.O20 to VMM32.VXD BE ABSOLUTELY SURE TO LEAVE VMM32.O20! (I also advise making an extra backup copy of the good VMM32.O20, say VMM32.ORI) 5.) In the C:\WINDOWS\SYSTEM\VMM32 folder: Delete: NTKERN.VXD VMM.VXD VMCPD.VXD VTD.VXD VXDLDR.VXD VPICD.VXD VCOND.VXD VWIN32.VXD IF there are any of the above files in this folder with a .O20 extension, Copy them and Rename the Copy back to .VXD. 6.) When you boot the 95 installation again, it will error, saying it can't find NTKERN.VXD. Ignore this and press a key to continue. 7.) If any Driver Instalalation dialogs appear, cancel them. When the machine is booted, go into the Device Manager and remove any USB devices still showing. 8.) Then go under Add/Remove Programs and Remove "USB Supplement to OSR2." This will get rid of the extra .O20 files but they MUST be there for the uninstaller or this uninstall can destroy your system. It will also get rid of the NTKERN error message. I hope this will recover your system back to the status quo ante-XUSBSUPP.. lol

Ok, it's probably irrelevant anyhow. MSDUN (I believe) and XUSBSUPP (I know) copy all of their files to the required locations when installed anyhow, so "Skipping" the redundant file copies called by the various .INF's should not affect the machine. Yes, I certainly hope we can recover the system, especially since you can't do a reinstall. EXTRACT can be run from DOS, but VMM32.VXD is "built" during installation. The VMM32.VXD inside the .CAB files is only a "starter" file. Other .VXD's are combined with it during the second phase of SETUP. XUSBSUPP makes backups of all the files it changes/updates, so I believe it is possible to recover, but I will have to test it before we take a chance with your system.

Probably. Do you have a Dial-Up Modem in the new machine? (Or the old one?) It's OK, I'm just worried now about helping you recover your system. I've never encountered this problem, or anything similar, using the USBSUPP packages. I have seen something similar when using the 95 Unofficial Service Pack (mentioned previously in the thread), which rendered one of my test machines unbootable. I made sure that XUSBSUPP would "uninstall" properly before I released it, but that only works if you are able to boot into Windows. I didn't anticipate running into this... I will have to set up a test VM and install XUSBSUPP, try to "uninstall" it manually, and then make a list of what changes need to be made.

Yikes! I meant for you to install XUSBSUPP with the HDD in the old computer, and make sure it was OK there before trying it in the new one. Maybe I wasn't clear... I don't know why you would be seeing anything related to MSDUN, I've never encountered that before. It is completely unrelated to USB and shares no common files. Now we will need to get XUSBSUPP uninstalled to get rid of the VMM32.VXD error... but if you can't boot to Normal or Safe Mode, it's going to be a real pain, probably requiring several Deletes & Renames from pure DOS.

All of the required files are already provided by NUSB. Using files from Windows ME will NOT work, as many files from ME require some small modification to work under 98SE. NUSB extracts copies of all the required files to the proper location when installed. There is no need to copy anything else from any other source, although copies are placed in \WINDOWS\OPTIONS\CABS by the installer if they are needed for some reason. The correct .INF to use when installing the drive should be USBSTOR.INF, and then it will in turn use USBNTMAP.INF as well. In order to reinstall the drive, you may need to go into Safe Mode and remove all instances of the drive, both under "Storage devices" and "Universal Serial Bus controllers." You may encounter issues with drives that while formatted to FAT32, may be marked in their partition type as "Hidden FAT32." See this thread. (Some info therein is dated now; do not apply the HotFix suggested by dencorso, as it applied to an older version of NUSB.)

While I don't believe the search should be abandoned, I was able to track down this mysterious 8.1.0.28 version. And it is Windows 2K/XP only. So the Lenovo page is incorrect in claiming 9x compatibility, with that version at least. Release Notes Version 8.1.0.28 A package claiming to be a "Beta" version of the 2200 drivers seems to also be 2K/XP only. Beta Package

The 3.6 version includes a file (SYSDM.CPL) from Windows ME that has been determined to have strange effects on 98SE systems. There is an entire thread devoted to this with my (and others') unsuccessful attempts to pinpoint and correct problems. Also, some contents of that particular file, pertaining to CONFIG.SYS (used under 95/98/98SE but eliminated under ME) have been removed that were present in the 98SE version. The effect of this (or lack thereof) has yet to be determined.