dencorso

Works wonderfully! Have been testing the 32-bit build (in Win 8.1) for about 3h now, and work it does! Thanks a whole lot! You do rock!

Avoid the chinese patch in any machine intended for serious use: it was then and still remains now unstable and unreliable.

@NoelC: When and if you find a little spare time, would you please be so kind as to also compile the x86 version of VersInfoEx v. 1.0.3 (I, for one, have been using your released compilation of the x64 v. 1.0.3 on 7 SP1, since you posted it, and it works flawlessly!)? It'd sure be a nice X-mas gift to the community and, in particular, to those who need, by some reason, use Win 7 SP1 or 8.1 x86. Thanks in advance!

Ditto!

Ipswitch's WS-FTP LE, perhaps?

Many among us use either bit-by-bit images or straightforward clones as backup. It's a sound and fool-proof strategy, when used right.

Here, side-by-side, for easy reference...

I'm glad it worked, and you've got a satisfactory result! And thanks for the interesting journey you've got us into: I, for one, learned a lot from it.

Both the Eee PC 900 and 701 series have an infamous setting in the BIOS Setup: Advanced Tab, called "OS Installation"... When set to "Start" it forces all USB connectors to operate as if they were USB 1.1, whereas when set to "Finished", the USB connectors work as USB 2.0... the result is it's much faster to install XP SP3 on it with "OS Installation" set to "Finished", and, in fact, keep it always on "Finished", despite Asus explicit instructions to the contrary. Now, is that a misleading setting or what? And, BTW, nowhere in the documentations it's said, even in passing, that "OS Installation" is related in any way to the maximum USB mode. Go figure!

Do you mean Stephen Hewitt's Windows Enabler v. 1.1 ?

Please do enlighten me some more: are you talking about free or paid AVG?

No, I haven't ever. As I said, I only tried one file at a time. In fact, it never crossed my mind to do so, else I sure would have.

Well, the A7V600-X uses a VIA chipset, which southbridge it VT8237, and it includes onchip both the VT6103 10/100 Fast Ethernet and the VT6212 USB 2.0 controller. So, for all purposes, anyone using the VT8237 is actually using a VT6212 USB 2.0 controller. N.B.: According to my notes, I've always tested one new file at a time, so my issues with the USBPORT.SYS may stem from this fact. @LoneCrusader: Please consider that board is great for XP. In fact, if you manage to find one at a reasonable price, a Gulftown hyperthreaded 6-core i7-9xx would make Win XP Pro SP3 fly on it like a rocket !!!

@PROBLEMCHYLD: Well, the association between the need for USBHUB20.SYS 4.90.3000.11 is pretty solid, by now, so it's one of the few facts we know for sure. Besides the user you mentioned (and of whom I was not aware), xRayer, myself and at least one more user (I don't quite remember who) were able to reproduce the issue. It's pretty solid. The issues associated with USBPORT.SYS are less well defined. But I'm convinced they must be hardware-dependent in some way. If it were very generalized, you'd have had much more people having issues with the U98SESP3 than you've actually have. That is a sure fact.

Yes.

Maybe because it expects IE6 and you actually have IE6 SP1?

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!

This post elsewhere presents Coreinfo data (which is misinterpreted there) for a Dell Dimension 5150 unable to run 8.1. Here's the relevant part: Intel(R) Pentium(R) Pentium D 820 CPU @ 2.80GHzIntel64 Family 15 Model 4 Stepping 7, GenuineIntel CX16 * Supports CMPXCHG16B instruction LAHF-SAHF * Supports LAHF/SAHF instructions in 64-bit mode PREFETCHW - Supports PREFETCHW instruction The Pentium D 820 processor is a Smithfield, from May 2005 and Jody's Xeon is an Irwindale (from Sep 2005), both being derived from the Prescott architecture. This barackets the inclusion of the PREFETCHW instruction as having happened between very late 2005 and late 2008.

Glad you got it working! Great! IIRR, even the 2k USBPORT.SYS is unusable under 9x, except from the very early versions. The first to post about that was Tihiy (<link>), way back when.

Thanks a lot, LoneCrusader! You rock! My post about the results you've provided is on this thread, just to provide a link for it, without disturbing too much your thread.

LoneCrusader has kindly run Coreinfo 3.31 on his 4-core Bloomfield i7 (Nehalem microarchitecture) and attached the results here. Here is an extract of the relevant results for this thread's discussion: Intel(R) Core(TM) i7 - 930 @ 2.80GHzx86 Family 6 Model 26 Stepping 5, GenuineIntel X64 * Supports 64-bit mode NX * Supports no-execute page protection PAE * Supports > 32-bit physical addresses SSE2 * Supports Streaming SIMD Extensions 2 CX16 * Supports CMPXCHG16B instruction LAHF-SAHF * Supports LAHF/SAHF instructions in 64-bit mode PREFETCHW * Supports PREFETCHW instruction I think it's safe to infer that all Nehalem and later intell processors can run 8.1 and 10. Which means those prcessors that cannot should have been launched before late 2008. This is a good start to identify when PREFETCHW was 1st included in the intel instruction set.

It's a very comprehensive console processor diagnostic program by the famous Mark Russinovich, from sysinternals (now owned by MS...). This is a link to the download page. There is no install, you download it, extract from the zip and run it from the directory of your choice. Like all their other command-line programs, on the first run it presents a box with their standard freeware licence. After you agree to it, it never bothers you again.

It seems to me that Intel processors that are unable to run 8.1 and 10 lack PREFETCHW, which all multicore AMD processors do include, whereas most multicore AMDs that are unable to run 8.1 and 10 lack CMPXCHG16b, instead. However, at this point, this is little more than just a guess. I know for sure all Athlon XPs cannot run even 8.0, because they lack SSE2, among other things, but not all Athlon 64 X2 and later AMD processors are able to run 8.1 or 10 but all seem to be able to run 8.0...

Well, while I've been unable to help you in this case, you may be able to shed some more light on another issue we've been 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 3.31 (on XP or 2k) on it? It is standalone, and should be run from a cmd box, like this: coreinfo > bloominfo.txt Then colect the txt, zip and attach it, please. Sorry for the bother, but I really think it may help us understand a little more about the instruction changes on intel architecture.

Thanks a lot, Jody! You rock! Mystery solved: lack of PREFETCHW !!! This post (which cannot be not quite exact) from the thread I linked to at intel did suggest as much. It seems that it actually was the last of the instructions in question to be added by intel to its processors, but it sure was added earlier than Broadwell, despite the reference, because my i7-3770K (an Ivy Bridge) does support it and, in fact, if 8.1 and 10 required at least Haswells or Broadwells, the flop would have been way much bigger than what we have witnessed.