In spite of what the title says, I might actually ask more questions in this post than I will give answers.... But hopefully that will shed some light on a few things and will help understand what is really going on.
First things first, let me describe again what my problem is (or was...). For a little while, I have been using wimb's latest tools to create universal XP image, and then boot them from a USB flash disk. In a few words here is what I do:
- Install XP to a disk IMG (see details here), including WinVBlock driver
- Tweak the IMG with wimb's USB_XP_Fix.exe
- Copy the IMG to a USB flash disk, and boot it directly with GRUB4DOS.
- boot IMG from file = BSOD 7B
- boot IMG from RAM = ok till the point where you get to windows desktop, and then everything hangs, no mouse, no keyboard, no response.
For some time I've been trying to understand what USBoot does so well, but it turns out to be way beyond my limited understanding. I've been comparing the registry hives, between USBoot and USB_XP_Fix.exe but could not find anything obvious (more details here for the curious ones). With a fairly high level of abstraction, USBoot goes through the following steps wich, I thought, were part of the mystery, as they significantly differ from those implemented by USB_XP_Fix.exe.
Processing step VII: Installation of all available drivers of classes "USB" and "1394" Processing step VIII: Installation of all available drivers of critical classes (excluding class "SCSIAdapter") but only generic ones for classes "System", "Keyboard" and "Mouse" Processing step IX: Removal of information concerning non present devices Processing step X: Reinstallation of present devices of class USB Processing step XI: Reinstallation of present devices of class SYSTEM preferring generic device IDs
At some point I started mixing some steps from USBoot (the scripts are fairly flexible, you can enable and disable stuff pretty much as you like) and USB_XP_Fix.exe. To the point that, after a gigazillion experiments, I discovered if I go through the following steps:
- start from a clean IMG
- Boot it (from HDD), and install USBoot DriveGuard (no need to actually activate USBoot with the challenge code: only right click on ubdrvgd.inf, do install, and that's it)
- Tweak the IMG with USB_XP_Fix.exe, and copy it on a USB flash disk
So that my BSOD 7B problem was fixed But I still didn't really understand why it was fixed... Out of curiousity it would be nice to know if the above procedure also fixes the problem for some of you (if not for all hardware, at least on some)
So I started investigating a bit more... I was able to boot my IMG from USB, great. But I couldn't see the laptop's internal HDD. At first I didn't pay too much attention, because it wasn't visible either with the USBoot IMG. And for a good reason: USBoot doesn't even try to install iastor.sys. But the high success rate that everyone is having with this package seems to be convicing evidence that iastor.sys isn't required at all to avoid BSOD 7B.
Nevertheless, upon closer inspection, the driver was showing as not properly working (exclamation mark in device manager )
But if I manually updated the driver and pointed to iastor.sys, then everything would be back in order and the HDD would appear, as expected.... That was really strange, given that everything related to iastor.sys is supposed to be taken care of in Wimb's package (and in exactly the same way as is found in many posts).
So I dug a bit deeper. I ran SaveHWIDs.exe and discovered that the laptop's ICH9 controller was identified with VEN_8086&DEV_282A, which does not appear in the registry tweaks implemented by Wim'b tools (but again, as found in many places). So I decided to try the following:
- start from an IMG on USB, tweaked with USB_XP_Fix.exe (which would give a BSOD 7B)
- inject the driver for this device in my IMG (which, in fact, only creates a new entry for VEN_8086&DEV_282A in CriticalDeviceDatabase)
Although I now understand how to fix the problem, this actually raises quite a few questions (probably because I don'tknow all the details of windows internal mechanics):
- Although VEN_8086&DEV_282A appears in iastor.inf, it is not listed in the (fairly common) registry tweaks iastor.reg. Same for a few other devices. I am pretty convinced there is a good reason, but then can someone try to explain why ?
- Also, this device driver is for the internal HDD, which is not critical when booting from USB. For some reason, XP seems to believe it is critical, and therefore throws a BSOD 7B.... But then everything works without the proper driver when USBoot DriveGuard is installed.... It is pure speculation, but is it possible that DriveGuard is just a bit more clever, and prevents any BSOD when non-critical drivers are missing ? This would seem like a very future proof solution, as the whole thing is garanteed to work, even on very new hardware, for which XP drivers may not even exist....
- At last, it is worth mentioning that USBoot also doesn't require that the XP IMG has prior knowledge of the target USB device. Even worse, it explicitly deletes (see step IX) any entries for non-present USB devices (such as previsouly encountered USB sticks). This also seem like a very desirable feature, as the IMG can be copied from device to device without worrying at all. I don't quite understand why, but it is explained in this tutorial that installing dummydisk.sys would allow it:
Can someone try to explain why ? dummydisk.sys is only meant to make removeable devices seen as fixed. How does it play a role in pre-recognising or not the devices ? Unfortunately I have tried installing dummydisk.sys.... but it always gives me a BSOD (I mean on each and every single computer) when installed in an IMG...
Particularly, "dummydisk.sys" has been able to filter ON-THE-FLY the install of all NEW (so never previously recognized) and pre-partitioned USB Flash Drives without the need to PRE-RECOGNIZE them
Phhew... I've been a bit long but hopefully this long tale will help a few people who have problems, and give great ideas to other people who know how to implement stuff