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:

As explained here, this has been working very well for me, till I tried to boot on a fussy Dell laptop which gave me the usual BSOD 7B. In fact even booting from RAM would not work:

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.

This is where I decided tro try the USBoot package for the first time... And it worked flawlessly on the same Dell laptop.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.

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

then everything would work as expected

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)

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:

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

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...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

This may be the main reason: one fixed disk is required at system.This fixed drive can be used at booting or not.

Assumption:Windows dosn't detect a single fixed hard disk at boot.Well, this can't be true, something has to be broken, let's call a stop to avoid further damage.Again, that's a assumption based on previous reports.

If you are booting from a file-backed disk whose backing disk is USB storage, then iaStor.sys (for Intel AHCI/SATA storage adapters) will not be required at all.

A STOP 0x7B is thrown when the boot volume cannot be mounted. The volume typically corresponds to a single partition on a single boot disk, but RAID disk configurations and dynamic Windows volumes are also possible. A 0x7B is not thrown for a reason like "iaStor is referenced in the Registry, but not loaded," unless iaStor drives the storage adapter for the disk with the boot volume. In your USB scenario, iaStor could be referenced as a boot-start driver and could be missing from your image altogether, but it wouldn't have any impact on whether or not you get a 0x7B.

If a driver is associated with a device purely through a CriticalDeviceDatabase entry, that could be considered "critically driving" the storage adapter, but the storage adapter has not undergone a proper installation with an .INF file. It would be reasonable to find the device called "PCI Device" in Device Manager until the device has been properly installed. I see this every day.

Something else I've seen are different versions of iaStor being capable of driving different storage adapters. If you do:

dir /a /s /b c:\iastor.sys

While booted from your image, how many iaStor.sys copies turn up?

Another thing to keep in mind is that iaStor seems to be a very common driver for Dell and HP computers. As Intel provides newer storage adapters, the .INF files (and wimb's scripts or .REG imports) will have to be updated with the newer PnP device IDs.

Here is my guess about how the USBoot stuff works:

It ensures the common drivers required for driving USB storage are set to boot start.

It ensures that certain CDDB entries for driving USB storage are present.

It might even go so far as to actively monitor these items and "fix" them if they are "broken" by any process. A normal USB device installation will "break" things, since certain USB drivers will be reset to non-boot-start drivers by Microsoft's .INF files.

Hell yeah, I couldn't agree more. I've spent so much time on it, I would have commited suicide if I hadn't cracked it.

2. you may want to experiment with the batch by cdob AND his "enlarged" Usbootwatcher.conf

I'm not sure I understand what you mean here. Usbootwatcher is already installed and configured by Wimb's tools, what more do you have in mind ? As far as USB services are concerned, Wimb's tools used to configure a few registry keys differently compared to USBoot (see here), but now Wimb has changed it and it's all configured in the same way.

3. if you have problems with dummydisk.sys, just ask, it is usually very easy to install it. But there may be something that you simply missed (or overwrite or whatever given the great number of tests you made )

You make a good point here. Given the huge number of trials and combinations I have tried, it was likely I got something wrong. But I've just tried again, the procedure I'm following is well known and relatively idiot-proof I believe.One thing I should mention is that I haven't tried in a "regular" XP, I mean, properly installed on a physical drive. Almost certainly that would work. But when I install dummy.sys in my IMG (i.e. in a virtual container with WinVBlock driver), it gives me almost instantaneously at boot a BSOD 0x69, IO1_INITIALISATION_FAILED. Anyone can confirm?

This may be the main reason: one fixed disk is required at system. This fixed drive can be used at booting or not.

Assumption:Windows dosn't detect a single fixed hard disk at boot.Well, this can't be true, something has to be broken, let's call a stop to avoid further damage.

That is also my understanding. Hence the BSOD 7B when drivers for the internal HDD are not installed, although the internal HDD is not critical at all in this scenario (boot from USB). This would also confirm a few reports that the USBoot stuff didn't work (at least in the early days, I don't know today), when no internal HDD was connected at all (which, seen from far enough, is almost the same thing as having an internal HDD but no drivers for it).

Which hardware do you use?

XP was originally installed in an IMG on a NC10 notebook (Intel Atom based). The Dell laptop is a Latitude 4300, with ICH9 controller.

Help, a Dell and USB booting. Yes, some Dell are famous for strange USB behaviour.

Just to mention, that amongst my numerous experiments, I attempted to install XP in an IMG directly on the Dell laptop, using this procedure. Everything went well the the point where "Windows is starting" at the end of txt-mode setup, and it would greet me with a black screen and stop. That was with the latest WinVBlock driver, I also tried with Firadisk 1.30, same result.

If you are booting from a file-backed disk whose backing disk is USB storage, then iaStor.sys (for Intel AHCI/SATA storage adapters) will not be required at all.

I couldn't agree more. USBoot is the perfect example. It seems to be working 100% for everyone, and yet it does not mess with any special drivers such as iastor. I think installing iastor is a bit of a tweak, to improve the chances of seeing an internal HDD, and hence to reduce the chances of a BSOD 7B, but it is not the ultimate remedy.

A 0x7B is not thrown for a reason like "iaStor is referenced in the Registry, but not loaded

Not loaded, do you mean, e.g. because it is not found in "system32/drivers" ?

If a driver is associated with a device purely through a CriticalDeviceDatabase entry, that could be considered "critically driving" the storage adapter, but the storage adapter has not undergone a proper installation with an .INF file. It would be reasonable to find the device called "PCI Device" in Device Manager until the device has been properly installed. I see this every day.

In my case, e.g. when I managed to boot with wimb's tools in combination with DriveGuard, the device was properly appearing in "RAID and SCSI controllers", but was reported as not working properly. Hitting "update driver" would (surprisingly for me) ask to locate "iastor.sys", which is, as expected, found in system32/drivers. So it really looks like the only reason why the driver was not working properly was the missing entry in CriticalDeviceDatabase.

Something else I've seen are different versions of iaStor being capable of driving different storage adapters. If you do:

dir /a /s /b c:\iastor.sys

While booted from your image, how many iaStor.sys copies turn up?

I haven't tried it yet, but I would expect only 2 copies. One in system32/drivers, and one in C:\IMG_XP\makebt\IASTOR\winall\Driver which is irrelevant.

As Intel provides newer storage adapters, the .INF files (and wimb's scripts or .REG imports) will have to be updated with the newer PnP device IDs.

That is exactly the reason why I think it's worth trying to understand how to fix the whole problem, without storage adapter drivers. This is the USBoot approach, which is perfectly future-proof, as it doesn't need updating in any shape or form.

Here is my guess about how the USBoot stuff works:

It ensures the common drivers required for driving USB storage are set to boot start.

It ensures that certain CDDB entries for driving USB storage are present.

It might even go so far as to actively monitor these items and "fix" them if they are "broken" by any process. A normal USB device installation will "break" things, since certain USB drivers will be reset to non-boot-start drivers by Microsoft's .INF files.

This is exactly what UsbBootWatcher does, doesn't it ? In USBoot world, this is also known as USBoot ServiceGuard, but I think from this point of view Wimb's tools are doing exactly the same thing.

strange, but you are correctAfter installing the ubdrvgd.inf I don’t have a BSOD Just to be sure, I did rename the ubdrvgd.sys and after this I have the BSOD (after rename to original no BSOD)

So the ubdrvgd.inf in combinatione with the wim img_xp_22 is working for me on 99% of the hardwareWithout the ubdrvgd.inf its working for 60% on the hardware

I should stress, that the way DriveGuard is installed, i.e. simply by clicking "install" on the INF file, is a shortcut, and that USBoot does not need to be properly activated first (with the challenge code, etc...).

For that reason, DriveGuard isn't entirely working: at each and every boot it complains about an "invalid license", and removable storage still appears as removable (not as fixed, which is supposed to be DriveGuard's effect, presumably when properly activated). Nevertheless, it must be doing a little something, which improves the bootability. My guess is that it somehow instructs XP that internal HDD drivers are not critical when booting from USB, which prevents any BSOD 7B.

That is also my understanding. Hence the BSOD 7B when drivers for the internal HDD are not installed, although the internal HDD is not critical at all in this scenario (boot from USB).

No. If you are not booting from the internal HDD, you do not need the driver for the storage adapter for the internal HDD, as the following tried to explain:

If you are booting from a file-backed disk whose backing disk is USB storage, then iaStor.sys (for Intel AHCI/SATA storage adapters) will not be required at all.

A STOP 0x7B is thrown when the boot volume cannot be mounted. The volume typically corresponds to a single partition on a single boot disk, but RAID disk configurations and dynamic Windows volumes are also possible. A 0x7B is not thrown for a reason like "iaStor is referenced in the Registry, but not loaded," unless iaStor drives the storage adapter for the disk with the boot volume. In your USB scenario, iaStor could be referenced as a boot-start driver and could be missing from your image altogether, but it wouldn't have any impact on whether or not you get a 0x7B.

This would also confirm a few reports that the USBoot stuff didn't work (at least in the early days, I don't know today), when no internal HDD was connected at all (which, seen from far enough, is almost the same thing as having an internal HDD but no drivers for it).

I disagree.

Just to mention, that amongst my numerous experiments, I attempted to install XP in an IMG directly on the Dell laptop, using this procedure. Everything went well the the point where "Windows is starting" at the end of txt-mode setup, and it would greet me with a black screen and stop. That was with the latest WinVBlock driver, I also tried with Firadisk 1.30, same result.

What was on the black screen, anything? Did you notice if the video mode switched?

I couldn't agree more. USBoot is the perfect example. It seems to be working 100% for everyone, and yet it does not mess with any special drivers such as iastor. I think installing iastor is a bit of a tweak, to improve the chances of seeing an internal HDD, and hence to reduce the chances of a BSOD 7B, but it is not the ultimate remedy.

No. Again, if you are not booting from the internal HDD, then iaStor has nothing to do with a STOP 0x7B. It doesn't reduce any chances of anything.

Having iaStor ready to drive internal HDDs by having it installed along with CDDB entries increases the chance of your ability to access the internal HDD.

Not loaded, do you mean, e.g. because it is not found in "system32/drivers" ?

Exactly. It can be missing from that directory or from your entire image and it still won't have anything to do with your ability to successfully boot from USB.

In my case, e.g. when I managed to boot with wimb's tools in combination with DriveGuard, the device was properly appearing in "RAID and SCSI controllers", but was reported as not working properly. Hitting "update driver" would (surprisingly for me) ask to locate "iastor.sys", which is, as expected, found in system32/drivers. So it really looks like the only reason why the driver was not working properly was the missing entry in CriticalDeviceDatabase.

That certainly seems intuitive.

That is exactly the reason why I think it's worth trying to understand how to fix the whole problem, without storage adapter drivers. This is the USBoot approach, which is perfectly future-proof, as it doesn't need updating in any shape or form.

I think you're mixing things up a bit. Booting from USB has nothing to do with internal HDD storage adapters. So you have two subjects, in my opinion:

Booting from USB and how USBoot works and how to achieve its functionality through alternative means.

Being able to access the internal HDD(s) on a USB-booted computer.

I don't think the two should be mushed together, as they can be discussed independently of one another.

I can't find any link right now, but in the historical threads where booting from USB was investigated, there are also a number of reports that iastor.sys helps avoiding the famous BSOD 7B.My belief, is that it is not required as such (you REALLY DO NOT need iastor.sys to boot from USB), it only avoids the BSOD 7B because XP (or Win 7) insists on having an internal HDD, which it can't see if iastor.sys is not installed. Read again cdob's message

Assumption:Windows dosn't detect a single fixed hard disk at boot.Well, this can't be true, something has to be broken, let's call a stop to avoid further damage.Again, that's a assumption based on previous reports.

Also, my belief is that USBoot DriveGuard somehow tells XP that the USB drive it is booting from can be considered as an internal HDD, and therefore just keeps it happy. In other words DriveGuard makes sure that you REALLY DO NOT need iastor.sys (nor any other -present or future- storage device driver) to boot from USB, which is what you'd expect. Does it make sense ?

So you have two subjects, in my opinion:

Booting from USB and how USBoot works and how to achieve its functionality through alternative means.

Being able to access the internal HDD(s) on a USB-booted computer.

Yes two subjects, but if XP insists on having an internal HDD, you need to achieve goal #2 in order to (possibly) achieve #1.

What was on the black screen, anything? Did you notice if the video mode switched?

Just plain black screen. Nothing. No text. Nothing but dark black screen. I don't remember to have seen the screen flicker at all, but on a LCD display it's not as obvious as on good old CRT.

You're preaching to the converted This has also been my understanding from day one.Nevertheless, if you read wim'b tutorial in details, here is what you can find:

I don't know Windows 7's requirements.

I can't find any link right now, but in the historical threads where booting from USB was investigated, there are also a number of reports that iastor.sys helps avoiding the famous BSOD 7B.

They're wrong or I'm wrong.

My belief, is that it is not required as such (you REALLY DO NOT need iastor.sys to boot from USB), it only avoids the BSOD 7B because XP (or Win 7) insists on having an internal HDD, which it can't see if iastor.sys is not installed.

Nope. I already said what a STOP 0x7B was for. It's for the boot volume. That has nothing to do with disks, except that a volume usually happens to be found on a disk! The following doesn't make sense:

...
if (fixed_disk_count == 0) {
/* We have no disks, so we can&#39;t have any volumes. */
stop_7b();
}
...

Because that mixes up disks and volumes. You could potentially have a volume without any fixed disks. Consider BartPE booted via SMB. There aren't any disks, fixed, removable, none! BartPE from a CD can be the same! The volume on the CD is found.

Also, my belief is that USBoot DriveGuard somehow tells XP that the USB drive it is booting from can be considered as an internal HDD, and therefore just keeps it happy. In other words DriveGuard makes sure that you REALLY DO NOT need iastor.sys (nor any other -present or future- storage device driver) to boot from USB, which is what you'd expect. Does it make sense ?

No. STOP 0x7B cares about the boot volume, not fixed disks.

Yes two subjects, but if XP insists on having an internal HDD, you need to achieve goal #2 in order to (possibly) achieve #1.

It doesn't.

Just plain black screen. Nothing. No text. Nothing but dark black screen. I don't remember to have seen the screen flicker at all, but on a LCD display it's not as obvious as on good old CRT.

Shao, Thanks a lot for all the information you provide. As you may have guessed, all this matter is bordering (or a touch beyond) my understanding. Pardon me if I'm a bit thick sometimes, but I like to think naive questions are sometimes very useful to make some progress. I really don't pretend to do anything else than sticking a finger in the air, and guessing what's happening.

If I may, let me ask a few more questions:

I already said what a STOP 0x7B was for. It's for the boot volume. That has nothing to do with disks, except that a volume usually happens to be found on a disk!

That is an important difference. Something that was not obvious to me, as I don't really master the terminology nor the concepts behind disks, volumes, partitions, etc...Now, with my original IMG (tweaked with Wimb's tools) I get a BSOD 7B on the Dell laptop. Just add that to the registry (and only that)

and suddenly it works great !! How do you explain that ? This extra entry in CDDB is totally irrelevant for the boot Volume (which is on USB). How can I get a BSOD in one case, and not in the other one ?

The following doesn't make sense:

...
if (fixed_disk_count == 0) {
/* We have no disks, so we can&#39;t have any volumes. */
stop_7b();
}
...

Even I, now understand why this doesn't make sense. But would it be the first time that something not making any sense is implemented by Microsoft ? I appreciate it might be a very difficult task, but do you have any idea how we could test if the above code is somehow implemented in XP ?

At last, starting from an IMG which results in BSOD 7B, I can get it to work successfully:

either by injecting iastor.sys for my specific controller (that is, by adding the registry key above)

or by installing USBoot DriveGuard

As already mentioned, I'm not alone to report that DriveGuard increases the bootability a lot. Do you have any ideas as to what DriveGuard really does ??

I appreciate it might be a very difficult task, but do you have any idea how we could test if the above code is somehow implemented in XP ?

In fact that's easy peasy.... I shall try the following, and I invite anyone with 5 spare minutes to do the same:

start from an IMG which would normally boot from USB on a given computer

disconnect all internal HDDs (IDE or SATA)

try to boot.

If we get 100% BSOD we will have (almost) proven that XP insists on having an internal HDD.Anything less than that, and we will not have proven anything, but the question will then be: why would you get any BSOD 7B without internal HDD whereas everything works fine with internal HDD ?With 0% BSOD then we will have (almost) proven that XP does not insist on having an internal HDD

I'm not anywhere near as deep as you two into the matter, but i ran into a similar puzzeling problem some years ago, when a program would only show icons when an HDD was present and without one, it would fail.
Turned out that the presence of a HDD caused drivers to install and registry settings to be made, that were needed by the program.
Once i made the required registry entries during build, the icons showed up even without a HDD present.

Might be, that some posts about the improving qulities of the iastore driver, are just missing or wrong registry entries.

sometimes after reboot you got BSOD 07B, because the registry entry for [HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\USBSTOR]hast changed back its Value for "start" from 0 to 3. To disable that behavior klick right on that key USBSTOR, permissions and deny for System to have the right to change the value "start" .

Presumably there is a registry key to control this ? This would make UsbBootWatcher obsolete, if nobody is allowed to change the "start" value.... Or is it more subtle ?

If you use a USB Stick, it is shown as removable device direct beside floppy diskand no harddisk is shown at all. Thats leads to the behavior, that you cant update your XP direct from Microsoft, because update is searching for a harddisk.

The first in a list of funny things when no internal HDD is recognised

I succeed also to boot XP SP1 from USB harddisk with my Siemens D1607 motherboard with Athlon 3200-64.But it showes a behavior that I know from former times with my P4C800-E:Only if a harddisk is PRESENT it boots.

PS: On my Siemens 1607 motherboard with Athlon3200-64 I cant until now overcome the behavior, that a harddisk must be present at boottime from USB.I did so many changes but this stays always the same. I disabled the Idecontroller and this was no problem for the USB drive. But while rebooing from USB drive it crashes again, until I enable the IDEcontroller again.

In XP there is a switch in device manager for the USB device to set it as removable or non removable. First: optimized for remove and the second optimized for power ( I dont know the english names exakt, because I have german XP)

The [...] key is the special [...] hardwareID of your USB device.The HardwareID is build as USBSTOR#Diskv(8)p(16)r(4) where for v(8) you have to put 8 digits (for me WDC_____ ) as the vendor of device16 digits (for me WD1600BB-00FTA0_ ) for device and 4 digits (for me 15.0 ) for versions number.

There have been 2 different BSODs: One, because the USB harddisk is shown as second device, and 2. that XP has a problem to connect to an harddisk, that is disabled in Bios.He told me the trick, to set atapi.sys to start=1 in registry.Now, always the USB external harddisk is shown as first harddisk because its driver usbstor.sys loads earlier than atapi.sys.

I really don't pretend to do anything else than sticking a finger in the air, and guessing what's happening.

Alternatively, you could attach WinDbg to a booting system and step through the whole booting process.

That is an important difference. Something that was not obvious to me, as I don't really master the terminology nor the concepts behind disks, volumes, partitions, etc...

In addition to terminology, please observe the classes at the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\ key. You might observe disk drives to be {4D36E967-E325-11CE-BFC1-08002BE10318} and storage volumes to be {71A27CDD-812A-11D0-BEC7-08002BE2092F}.

Now, with my original IMG (tweaked with Wimb's tools) I get a BSOD 7B on the Dell laptop. Just add that to the registry (and only that)

and suddenly it works great !! How do you explain that ? This extra entry in CDDB is totally irrelevant for the boot Volume (which is on USB). How can I get a BSOD in one case, and not in the other one ?

Here are two guesses:

You start to boot from your USB HDD pre-kernel, but you finish booting from the internal HDD post-kernel. That is, you accomplish the "XP Kansas City Shuffle" by accident. An easy experiment would be to backup the internal HDD's MBR, then put zeroes in the internal HDD's MBR, then see if you can still boot from USB with your iaStor injection.

The presence of iaStor as a boot driver is changing the timing of events and giving enough time for the volume on the USB storage to become available before the boot volume is looked-for. An easy experiment would be to leave your iaStor CDDB entry injected but to replace iaStor.sys with the wait10.sys attached to this post. All it does is wait 10 seconds. You should do this experiment on whatever computer has the VEN_8086&DEV_282A because otherwise the CDDB entry will not be relevant and will not invoke the driver.

do you have any idea how we could test if the above code is somehow implemented in XP ?

So there are some experiments. I could certainly be wrong, so I'd enjoy learning if that's the case.

At last, starting from an IMG which results in BSOD 7B, I can get it to work successfully:

either by injecting iastor.sys for my specific controller (that is, by adding the registry key above)

or by installing USBoot DriveGuard

As already mentioned, I'm not alone to report that DriveGuard increases the bootability a lot. Do you have any ideas as to what DriveGuard really does ??

Not really. I haven't used it.

In fact that's easy peasy.... I shall try the following, and I invite anyone with 5 spare minutes to do the same:

start from an IMG which would normally boot from USB on a given computer

disconnect all internal HDDs (IDE or SATA)

try to boot.

If we get 100% BSOD we will have (almost) proven that XP insists on having an internal HDD.Anything less than that, and we will not have proven anything, but the question will then be: why would you get any BSOD 7B without internal HDD whereas everything works fine with internal HDD ?

I guess this is a slightly different experiment (full versus PE) than the two BartPE scenarios I detailed, above.

--- Attachment removed due to newer version. 18 downloads at time of removal. ---

However the absence of a PS/2 keyboard seems to prevent the system from building a functioning driver stack for the system volume.

Signed: Tim again

So as unexpected as it sounds, USB keyboards and mouses might also cause BSOD 7B....I don't understand the details, but as the log file shows, the USBoot.org package does something spcific with mouses and keyboards....

What Microsoft Windows Embedded Standard 2009 has to do with Windows XP / Windows Server 2003, I have no idea. What Windows version are you interested in? Have you no interest in trying the wait10.sys driver I wrote today for you?

What Microsoft Windows Embedded Standard 2009 has to do with Windows XP / Windows Server 2003, I have no idea. What Windows version are you interested in? Have you no interest in trying the wait10.sys driver I wrote today for you?

Don't get mad at me, Shao... It's a fact that I mix many things together, which have nothing to do together. I'm just trying to learn, but the amount of information to digest is phenomenal.I am sorry I didn't explicitly express any interest in your suggestion... But rest assured I will give it a try As far as the first suggestion is concerned (backing up the MBR and wiping it with 0s), although it's a fairly safe procesure, I don't want to take the risk... This Dell laptop is my wife's laptop from work and I really don't want to mess anything...But no doubt I will try the wait10.sys. I am very keen to understand how we can improve the bootability on USB, and I'd be happy to contribure in making Wimb's tools a tiny bit better

For the record what jaclaz wrote - no matter whether you trust him or not is NOT so slightly different:

If I posted this:http://www.911cd.net...o...19056&st=51it means that at the time (I'm getting old and forgetful ) I was convinced of some "interaction" between PS/2 keyboard and USB booting, or maybe better phrased as a conflict between USB keyboard and USb booting.

A possible explanation: at boot time:

a PS/2 keyboard is searched

if it is not found, a USB one is searched and this searching creates the 0x0000007b USB boot error

Which is much more a question than an actual answer.

The 0x0000007b STOP CODE has a text which is "UNACCESSABLE BOOT DEVICE" so THAT is the problem, as Sha0 correctly pointed out.

Problem is that Microsoft has a tradition for:

having meaningless or completely unrrelated to actual problem error messages

a never ending capability of messing things up, BOTH in the actual OS AND in the documentation

An early example is this one:http://support.micro...kb/125933/en-usYou get a 0x0000007b in NT 3.5 IF you installed on a machine with an IDE CD-ROM AND it was Slave to a Master IDE hard disk AND you remove the CD drive.What is the proposed first thing to do?Check for bootsector Virus And the actual remedy?Uninstall the ATAPI.SYS driver which was by mistake used instead of ATDISK.SYS (but evidently workked allright UNTIL the CD-ROM drive was present also to drive the IDE Master hard disk )Then:

Change the jumper configuration on the hard disk from Master to Stand-alone.

I may be getting old and forgetful , but really don't remember having seen an IDE drive with a "Stand-alone" jumper

The example was chosen not only for it's historical value (please raise a hand anyone that has actually worked a whole year on a NT 3.51 OS ) but because it shows how it is possible that something gets mixed up, and EXPECIALLY if on the same BUS.

This is completely crazy, absolutely "stoopid" and actually not really "every-day-happening", BUT it is a possibility.

In other words, it seems to me like we are in the realm of the "common sense advice" point #f4:

once the suggested steps have been tried and gave no result, your ideas are welcome, in other words we try to troubleshoot in a "logical" way, as in the famous Sherlock Holmes saying "when you have excluded the impossible, whatever remains, however improbable, must be the truth", but we like beforehand to exclude the possible, the common, the probable, and this approach solves problems in a MUCH faster way in a large amount of cases.

As I see it we cannot find a satisfying theory explaining the issue at hand by merely taking here and there bits and pieces (which are anyway welcome ) we need to do (unfortunately a lot of ) tests aimed to EXCLUDE the possible before excluding the impossible and (still unfortunately) due to past experience, we cannot tag as "impossible" even quite a lot of things that make no or very little sense (remember we are talking of doing non-standard things in a closed source, mostly UNdocumented proprietary OS, reknown for having the queerest possible issues) .

NTLDR captures at least the MBR signature of the disk with the boot volume. It might capture every disk's MBR signature, but I haven't tested for that. Anyway, the fact that you can call IoGetBootDiskInformation() and only from a boot driver readily demonstrates this; since you're a boot driver, there might not yet be any disks, and yet you can query the MBR signature for the disk we are supposed to boot. (EDIT: This isn't quite true. Please see this post.) Also available is the MBR signature for the disk with the system volume (NTLDR, NTDETECT.COM, BOOT.INI, NTBOOTDD.SYS).

Post-kernel:

Boot drivers are initialized. Some of these will be storage adapter drivers, such as WinVBlock or iaStor.

Whenever the PnP Manager is alerted to the presence of a PnP device, it attempts to find a driver for that device. If a device is found and has already been properly installed, then the associated driver is requested to drive the device. If the device has not already been properly installed (via an .INF file), the CriticalDeviceDatabase is checked for an associated driver. If such a CDDB entry is found, then the associated driver is requested to drive the device. If there is no CDDB entry for the device, it becomes an Unknown Device.

Thus, for example, when the PCI bus tells the PnP Manager that there is an VEN_8086&DEV_282A, we check if the device has been properly installed. If it hasn't been, we look for a CDDB entry for it. If we find a CDDB entry that associates the device with the iaStor driver, we ask iaStor to drive the device.

Just as the PCI driver will provide devices on a PCI bus, a storage adapter will provide disks on the storage adapter's "bus." These disk devices typically have Compatible IDs which include GenDisk. There should always be a CDDB entry which associates GenDisk devices with the disk service. After all, disks are commonly pretty critical towards finding volumes.

Later, there is a function which looks at every device which is a disk (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceClasses\{53f56307-b6bf-11d0-94f2-00a0c91efb8b}) and examines the MBR of each in order to determine the ARC name(s) for the disk(s). You can see USB flash storage devices under that key, as well as fixed disks. Only that GUID ({53f56307-b6bf-11d0-94f2-00a0c91efb8b}) is checked by the function which assigns ARC names. These ARC names will be populated into the \ArcNames\ "directory" in the object namespace. An ARC name will be created for each partition.

Later, a function is called which will try to open the \ArcName\arc_name symbolic link in the object namespace, where arc_name is the ARC name specified in the BOOT.INI choice. For example, multi(0)disk(0)rdisk(0)partition(1) is a common ARC name. If this open operation fails, that is when STOP 0x7B happens. As you can see from using WinObj, each ARC name is a symbolic link as detailed in the previous paragraph.

If you then follow those symbolic links and look in, for example, the \Device\Harddisk0\ "directory," you will see that each partition in there is also a symbolic link. For example, Partition1 might be a symbolic link to the \Device\HarddiskVolume1 device. Then you can do:

strings \windows\system32\drivers\ftdisk.sys | findstr /i harddisk

And you will find out who is responsible for those devices. Now search for ftdisk in \Windows\Inf\Machine.inf.

%Root\FTDISK.DeviceDesc% = FTDISK_DRV, Root\FTDISK ; 'Volume' bus

Putting all of this together, a STOP 0x7B is thrown when the ARC name specified by BOOT.INI does not resolve to a volume that can be opened. There are lots of dependencies: storage adapters, disks, volumes.

But how a storage adapter that is unrelated to the boot volume can have any impact on one's ability to get past a STOP 0x7B, I am sticking to my guesses for now.

Until now I added CriticalDeviceDatabase entries derived from iaAHCI.inf for Intel AHCI Controller (ending on cc_0106)Your results mean that I have to add additionally the CDDB entries derived from iaStor.inf for Intel RAID Controller (ending on cc_0104)

In fact I need to update and add CDDB entries for all these hwids for iaStor.sys