dencorso

Well... don't look now, but... well, I guess... not exactly. Aham. I do think jaclaz actually meant precisely what the left-side emoticon does, without the right-side one ever being seen (but instead presumed). However, since I'm thinking about it, to complicate things somewhat more, it could end-up not with a frightened expression, but with a big smile like this: or even with an angel-face such as this (which is also very appropriate right here): <ducks />

More info here: Reboot Competition: The smallest Win7 PE bootdisk

In 12 frames? No, not just nice: *fantabulous* robot dance!!!

Bear in mind that the issue with USBHUB20.SYS is *very* specific: it requires one to actually remove a USB 2.0 hub to manifest the BSOD, and then, if one hits <Enter> two or three times (IIRR), one does get back to the desktop and can restart all right, or even continue to work (although the OS is not necessarily safe to be used after recovering from a BSOD). The Win 9x/ME and 2k USB stack is peculiar, because it's bifurcated: even if the physical connectors/ports are the same (which they can perfectly be), the OS treats USB 1.x and USB 2.0 communications as two separate things (while Win XP and higher adopt a unified USB view). So one must have a hub, it must be a 2.0 hub and it must have actually been detected as a 2.0 hub on that particular insertion (sometimes USB 2.0 devices are not detected as 2.0, for some random reason). These three factors one can check using USBVIEW. At this point one inserts at least one USB 2.0 mass storage device, lets the system read it, then safely remove the device, letting the hub stay. The hub itself is not a mass storage device, so it cannot be stopped or ejected, before removal. So after letting the hub remain for at least 20 seconds after safe removal of the mass storage device, one may grab the hub and remove it. Then the BSOD happens. If, instead of removing just the mass storage device, then waiting, then removing the hub one removes the hub with the mass storage device still connected to it, the BSOD also happens. But if one never removes the hub, one'll never see the BSOD. Sorry, this description became long-winded, but I want to make it clear how to test for this BSOD. And, of course, if one doesn't have a VIA USB 2.0 controller, then there's nothing to test.

Always put your health first. You will get to it someday Do you mean USBHUB20.SYS? I don't think so. There sure is a usbhub.sys 5.00.2195.6689 (USB 1.x) but I don't think that version of usbhub20.sys was ever released.

Well, AFAIK, Win2k SP4 has v. 5.0.2195.6655 and KB829759 has v. 5.0.2195.6824, but there should be plenty more with lower numbers... But let's let people test v. 5.0.2195.5605 some more, before starting that hunt...

I have to report that, despite my best efforts, I've been utterly unable to elicit a BSOD from Usbhub20.sys v. 5.0.2195.5605. Rest assured that the hub I used is not seen as a Composite Device, but simpliy as a "Generic USB Hub" (USB 2.0, High Speed) from Alcor Micro (VID=0x058F; PID=0x6254).

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. As far as I remember, one has to insert a true USB 2.0 hub, then plug one or more USB 2.0 devices to it, then remove them. Then, if and when one removes the hub, and only then, presto: instant BSOD! I've only had 1st hand experience with hubs, to reproduce this particular BSOD, although Tihiy did mention controllers, too. The hub I used, and still use is one like this (care because there are USB 1.x and USB 2.0 versions of it, and only the USB 2.0 causes the BSOD):

Sure. As soon as I reboot into 98SE, which means later today. I've already put the Usbhub20.sys v. 5.0.2195.5605 in place for the test, though.

The fact that VIA's USBHUB20.SYS is versioned as 4.90.3000.11 is suggestive it might be 9x/ME universal. However, remembering that VIA and Intel use the UHCI standard for USB 1.x while all the other manufacturers use OHCI, I'd say the most relevant tests should be with non-VIA and non-Intel USB controller chips. And I do think we should concentrate on it, before engaging in a hunt for other versions. It's too bad I only have VIA based machines and USB add-on cards (except for my NEC USB 3.0 card, but that's another thing entirely, since I've not yet even got my 98SE to detect it).

AFAIK, the MS's USBHUB20.SYS v. 5.0.2195.6891is the troublesome one. What previous versions did you find? I *think* that VIA's USBHUB20.SYS v. 4.90.3000.11 is universal and might be used for all users, while MS's USBHUB20.SYS v. 5.0.2195.6891 is not. So, one compromise solution would be to install VIA's USBHUB20.SYS v. 4.90.3000.11 for everybody, regardless and forget about it. However, I think that some select users experienced enough to be able to substitute back the USBHUB20.SYS for the one they already know works in their systems should test this approach. Of course, those testers must be running non-VIA machines, for this test to be useful. These are my 2 ¢.

One example is KB2724197: MS blabing mumbo-jumbo about 'security', but said nothing that it would impact EMS availabilty on NTVDM. Well, the previous "security" update, KB2707511 already caused NTVDM to crash on opening a pipe, an issue that hasn't been fixed. Since security updates are cumulative, KB2724197 must have both issues. Now, ain't those latest updates really awesome? Just to yet again point out that maybe two rollbacks may be in order, not just one... KB2633171 being the last non-flawed krnl set. I can't believe that Microsoft hasn't been very helpful remedying the issue of EMS not working for 16-bit apps under Windows XP as I personally believe that the important of the 16-bit Windows subsystem is increasingly deprecated. True enough. BTW, if you really need EMS, EMS Magic seems to be the way to go...

One example is: KB2724197 MS blabing mumbo-jumbo about 'security', but said nothing that it would impact EMS availabilty on NTVDM. Well, the previous "security" update, KB2707511 already caused NTVDM to crash on opening a pipe, an issue that hasn't been fixed. Since security updates are cumulative, KB2724197 must have both issues. Now, ain't those latest updates really awesome? Just to yet again point out that maybe two rollbacks may be in order, not just one... KB2633171 being the last non-flawed krnl set.

Rest assured it won't be locked... we at MSFN don't frown on old threads reactivated for good reasons. BTW, it's good to have you around again, welcome back!

He sure does! Santana - Singing winds, crying beasts. http://www.youtube.com/watch?v=frntiiyoreg

Digital Identity Management Service (DIMS)!!! No google didn't return that to me either. That sure is very advanced google-fu...

Try RLoew's backup site address. It seems the main address is still down due to that awful Hurricane Sandy.

Indeed. The version you found sounds much better (it's the original studio version, IIRR). Great find, thanks!

Yes. In KB273017 (use MDGx's Microsoft Support HotFix Request Form to get it).

@jaclaz: With all due respect, it's too bad I didn't have anyone to bet with at the time, because if I had, I'd have bet you would reply precisely: ... I saw that coming the moment I hit "Add Reply" to send my message that said: Thanks for showing my crystall ball is working OK, right now, after so long!

ELP - Jerusalem Neither Blake nor Parry could possibly ever dream it might sound half as good as this in fact does! http://www.youtube.com/watch?v=q8ECoRfh_is

Many do that, yes... then again, here I fully agree with jaclaz:

Probably VCache explosion... Try adding this to system.ini (if there isn't a [vcache] section, create one): [vcache] MaxFileCache=393216

Or use MDGx's Microsoft Support HotFix Request Form

[off topic] @snoopy55: No I wasn't trying to be funny. You see, even if it was clear to me that you meant "not English" by "foreign language" and my reply is consistent with that understanding, and despite the fact that, way too many moons ago, when I actually lived in the US, I did hear "foreign language" meaning "ununderstandable" numerous times, I had actually forgotten "foreign language" can actually have this latter meaning, so it eluded myself completely that that was what you meant, and hence I did express my perplexity at your comment. Sorry. I should have thought about it longer before posting that reply, and perhaps it would have dawned on me what your comment was intended to mean. Then again, you failed to realize many of those replying to you, me included, are *not* native speakers of English, no matter whether we can express ourselves well in it or not, so that, in fact, for us at least, English actually *is* a foreign language... MSFN is actually a truly international forum that uses English as the common communication language! [/off topic] And, BTW, since I didn't say it before, welcome to MSFN!