32 replies to this topic

[Agent_Smith]

I'm having a strange problem... I have a brand new motherboard (P8H67-MLX w/ UEFI Bios), and for some reason my windows 7 USB boot simply will not load with AHCI or RAID enabled. The strange thing is that I have plenty of other Intel machines using Intel AHCI (including the machine I built it on).

I figured that maybe the driver was out of date (it was only one revision behind), so I downloaded the newest iastor.sys and replaced it on my win7 USB. Still, no dice.

I looked at the iaAHCI.inf that I originally built the USB install with, and it was basically same as the updated one. There are no additional device ID's listed, so I'm really perplexed as to why this will not work..

Any ideas?

[MedEvil]

Please define "simply will not load".

[cdob]

In addition:
How do you prepare windows 7 USB boot device?

Which iastor version do you use?

Which overall hardwares do you use?
Which CPUs do you use?

Try Bootable Windows USB Stack
http://reboot.pro/98...post__p__127410

[Doodoo]

I looked at the iaAHCI.inf that I originally built the USB install with, and it was basically same as the updated one. There are no additional device ID's listed, so I'm really perplexed as to why this will not work..

That is a good idea, but may not be sufficient...
Have you checked that iaStor.inf is also the same ?

To be absolutely sure, I would try booting your new system from HDD, then run SaveHWIDs.exe
Look for the HardwareID of your SATA controller. Then look in the SYSTEM hive of the Win7 you're trying to boot from USB. If there is no corresponding CriticalDeviceDatabase entry, which instructs Win7 to drive the hardware with iastor.sys then create it.... And it may (or still may not) work. For more info, you may want to read http://reboot.pro/14130/ and more specifically this post

In fact, iastor.sys is not needed at all to boot from USB. It will only allow you to see the internal HDD, but it is not required as such to boot.
You may as well not care about iastor.sys and CriticalDeviceDatabase entries, and simply try to install Shao's waitbt.sys (instructions to install here)

Please define "simply will not load".

Actually that is indeed the first thing to ask. All I have said is irrelevant if "will not load" doesn't mean "stops with a BSOD 7B"

[Agent_Smith]

That is a good idea, but may not be sufficient...
Have you checked that iaStor.inf is also the same ?

To be absolutely sure, I would try booting your new system from HDD, then run SaveHWIDs.exe
Look for the HardwareID of your SATA controller. Then look in the SYSTEM hive of the Win7 you're trying to boot from USB. If there is no corresponding CriticalDeviceDatabase entry, which instructs Win7 to drive the hardware with iastor.sys then create it.... And it may (or still may not) work. For more info, you may want to read http://reboot.pro/14130/ and more specifically this post

In fact, iastor.sys is not needed at all to boot from USB. It will only allow you to see the internal HDD, but it is not required as such to boot.
You may as well not care about iastor.sys and CriticalDeviceDatabase entries, and simply try to install Shao's waitbt.sys (instructions to install here)


Actually that is indeed the first thing to ask. All I have said is irrelevant if "will not load" doesn't mean "stops with a BSOD 7B"

Sorry .. it is in fact a stop 7B.

As far as whether the iastor is needed, I have found that if the system can't find a driver for at least one storage controller, you get a stop 7B. I have tested this by disabling all storage controllers - you get an stop 7b every time. In regards to the post you referenced, by Sha0 is definitely incorrect in that respect. You NEED windows to find a driver for at least one storage controller (even if it has no drives attached).

I've wondered if there exists a dummy storage controller. It wouldn't be a big deal to install the correct drivers upon booting if I could in fact get it to boot.

I do not have Windows currently installed in the system I'm testing (I'm probably going to do that tomorrow), so I can't see what HWID's its using. I looked at the newest intel RST drivers, and the HWID's in that iaahci.inf are not any different than the ones I already have in the critical device database. The inf file's are practically identical, so I figured the new iastor.sys would do the job.

It obviously didn't do the trick, and I can't think of anything else I should need to do... Maybe Win7 is restoring the changed driver with a copy from WinSxS or some driver cache????

I will double check the device ID tomorrow when my dvd-rom is slated to arrive (and I can then install windows).

What would be really nice is if there was some dummy storage controller driver that precluded the need to have a storage controller detected on boot..

Edited by Agent_Smith, 28 April 2011 - 08:43 PM.

[cdob]

You NEED windows to find a driver for at least one storage controller (even if it has no drives attached).

I'm booting XP without chipset storage controller from USB, of course USB mass storage drivers are loaded.

You don't need to load iastor.sys.
If it's a timing issue, iastor.sys loading may work around at some machines.
And may fail at a new fast machine.
Again: which hardware do you use?

Why did manufacturer define a timeout at USB Windows 7 Embedded booting?
PollBootPartitionTimeout

To ensure that the system can properly boot from a flash device, this setting changes the PollBootPartitionTimeout registry key value. This registry key is used to control how long the kernel waits for PnP to surface the boot disk before it stops with bugcheck code 0x7B.

[Agent_Smith]

Ok.. here is a nice catch (thanks for posting the link btw).. the original poster was right.. The usbdrvgrd.inf/sys in the USBoot package works great. No STOP x7B. I was able to load without a storage controller... Looks like a PNP filter driver, probably makes it seem like there is a storage controller attached.

It looks like I was missing the needed HWID in the critical device database though... Not sure how I missed it the first time..

I will post this in the karyonix thread. I think this is invaluable.. This will literally prevent most of my STOP 7B errors on computers with weird controllers. I'm surprised it hasn't gotten more press around here.

EDIT FOR LINK:
http://www.usboot.or...e.php?fileId=15

Download this, extract, and right click install on usbdrvgrd.inf.

Edited by Agent_Smith, 28 April 2011 - 09:04 PM.

[Agent_Smith]

I'm booting XP without chipset storage controller from USB, of course USB mass storage drivers are loaded.

You don't need to load iastor.sys.
If it's a timing issue, iastor.sys loading may work around at some machines.
And may fail at a new fast machine.
Again: which hardware do you use?

Why did manufacturer define a timeout at USB Windows 7 Embedded booting?
PollBootPartitionTimeout

Do you have an IDE controller? More than one SATA controller? You don't specifically need iastor, but if its your ONLY storage controller and you don't have the driver load you get a STOP 7B.

As far as Windows 7 embedded, you can pretty much bet it was designed not to operate the same way... simply because it usually won't boot from a storage controller, but rather from a flash drive of some kind.

Now, I'm not sure how you built your usb bootable Win XP or Win 7. Its entirely possible that you did something somwhere along the lines that eliminates a STOP 7B if you don't have a storage controller. I followed Karyonix's method for Win 7 booting, and I can guarantee you that unless you have addressed this problem in some other way YOU WILL STOP 7B if you do not have a single storage controller driver loaded. If you look around, a bunch of other people report the same problem when their build can't find a storage controller. It is certainly not isolated to my build.

If you found another way around this, I would love to know what you did differently in your build. As of right now, the USBoot driver in the post above is the only thing I've seen to fix this issue.

EDIT:
Maybe the information in the above tutorial is too stale... If such problems have been solved, would anyone be willing to make a new tutorial?

Edited by Agent_Smith, 28 April 2011 - 09:37 PM.

[cdob]

Do you have an IDE controller? More than one SATA controller?

Neither a IDE controller (disabled in BIOS), no SATA controller exist, no SCSI controller.

usbdrvgrd does delay booting: no timing BSOD 0x7b

As far as Windows 7 embedded

Registry settings works at default Windows 7 drivers, no embedded drivers involved.

If you look around, a bunch of other people report the same problem when their build can't find a storage controller. It is certainly not isolated to my build.

Timing issue is difficult do detect.
Yes, storage driver loading work around true error.

If you found another way around this

Your OS manufacturer uses the timing work around.

A third time: which hardware do you use?

[Agent_Smith]

Neither a IDE controller (disabled in BIOS), no SATA controller exist, no SCSI controller.

usbdrvgrd does delay booting: no timing BSOD 0x7b


Registry settings works at default Windows 7 drivers, no embedded drivers involved.


Timing issue is difficult do detect.
Yes, storage driver loading work around true error.

Your OS manufacturer uses the timing work around.

A third time: which hardware do you use?

Well its meant to be a mobile USB booting Windows for me.. I use it on pretty much everything. I don't just use it on one computer. The oldest computer I have is at my house, and that is an 8 year old Athlon build. It has the same effect when I have no storage drivers to load... and this is a pretty slow computer.

I'm not saying it isn't a timing issue... but I think a better way to put it then is: "there is no way the computer is going to NOT STOP 7B unless there is a storage driver to load that will slow it down." From everything I've seen, this isn't a hit or miss type of thing. Its basically a "miss" every time.

Maybe if you have a P3 or something ancient, maybe it will boot then... but if a first gen Athlon 64 is too quick to boot via USB without a STOP 7B, then almost anything remotely modern will boot without a BSOD.

Obviously something else needs to be done, or a BSOD will occur without a storage driver... this seems to be the default behavior on everything I tested. It sounds though like you have a registry tweak to delay the timing (alleviating the problem), and I would much rather have that then add another driver to the mix. Would you care to post the modification needed? If it works effectively, it really should be included or mentioned in all the build tutorials. Otherwise, from my experience, you are pretty much guaranteed a BSOD. From what I can see in this particular forum, most people using the tutorials are experiencing this and are also unaware of the solution..

Edited by Agent_Smith, 28 April 2011 - 10:33 PM.

[Doodoo]

I have found that if the system can't find a driver for at least one storage controller, you get a stop 7B

Most people (including myself) have been convinced of this for a long time... But I have now changed my mind, and I think Shao is right. Storage drivers are not required as such, they sometimes happen to resolve BSOD 7B problems because they change the timing of everything.

Ok.. here is a nice catch (thanks for posting the link btw).. the original poster was right.. The usbdrvgrd.inf/sys in the USBoot package works great. No STOP x7B. I was able to load without a storage controller... Looks like a PNP filter driver, probably makes it seem like there is a storage controller attached.

The great news is that USBoot DriveGuard seems to also work on Win7 although it was only designed for XP !
But for several weeks (if not months) I've been trying to get some insight about it... Without any success. Nobody seems to know what it really does. When installed with a right click on the INF file, without properly activating USBoot, it looks like it doesn't do anything (at least the advertised effect (makes removable media appear as fixed) is not enabled), but only changes timing. I have no evidence of this though, and I might be wrong.

I followed Karyonix's method for Win 7 booting, and I can guarantee you that unless you have addressed this problem in some other way YOU WILL STOP 7B if you do not have a single storage controller driver loaded.

Have you tried (without storage controller driver) to install Shao's waitbt.sys ? (instructions to install here)
I wouldn't be surprised if you were able to boot... If you are, then we will know it's only about timing...

[Agent_Smith]

Most people (including myself) have been convinced of this for a long time... But I have now changed my mind, and I think Shao is right. Storage drivers are not required as such, they sometimes happen to resolve BSOD 7B problems because they change the timing of everything.


The great news is that USBoot DriveGuard seems to also work on Win7 although it was only designed for XP !
But for several weeks (if not months) I've been trying to get some insight about it... Without any success. Nobody seems to know what it really does. When installed with a right click on the INF file, without properly activating USBoot, it looks like it doesn't do anything, but only changes timing. I have no evidence of this though, and I might be wrong.


Have you tried (without storage controller driver) to install Shao's waitbt.sys ? (instructions to install here)
I wouldn't be surprised if you were able to boot... If you are, then we will know it's only about timing...

Well, I'm guessing someone more determined than I has probably spent a lot of time diagnosing this type of issue... and if the consensus is that it is a timing issue, then I would be inclined to believe it. I don't think its really mutually exclusive though, as I've said I STOP 7B every-single-time that I don't have any storage drivers. The way I see it is that you DO need to load a storage driver, OR something else to delay or change the timing (if it is indeed a timing issue).

Maybe USBoot's ubdrvgd.sys works simply because it delays the timing a bit (cdob suggested this in his post). It does take like 10-15 seconds to display the error text. Its quite possible its not actually doing anything. I don't know.

I'll see if I can try waitbt.sys, but I'm a little backlogged with the computer referenced in the post. I have to wrap it up by Monday...

Personally, I wish there was a better way to log exactly what was going on. Maybe there is and I just don't know it. Linux can give you a pretty detailed output on what exactly is happening, but I don't know if such a thing exists for Windows. It would really take out all of the guessing.

Edited by Agent_Smith, 29 April 2011 - 02:05 PM.

[Doodoo]

if the consensus is that it is a timing issue, then I would be inclined to believe it.

All BSODs 7B do not have the same root cause. Every single case is unique, and the only convincing evidence that your case is related to timing is to load a driver, which is known to not do anything but wait...
A very simple experiment is, with a system which doesn't boot without iastor.sys but boots with it, to copy wait10.sys in system32/drivers and rename it iastor.sys (see details in this post)

I don't think its really mutually exclusive though, as I've said I STOP 7B every-single-time that I don't have any storage drivers.

The fact that you get a consistent behaviour without any storage drivers is not incompatible with a possible timing issue. Timing seems to be very repeatable on a given hardware.
At least in some cases, timing really is the critical point. Waitbt has made the difference for me. cdob also reported the same:

http://reboot.pro/14...post__p__126524

Cross check:
waitbt start=4: BSOD 0x7b
waitbt start=0: does boot
Yes, waitbt makes the difference.

Personally, I wish there was a better way to log exactly what was going on.

I couln't agree more. It is not terribly helpful, but what you can try is this:

bcdedit /set sos on

bcdedit /set bootlog on

[Agent_Smith]

Yeah, I'm aware a stop 7b can occur when the boot volume isn't detected for a various number of reasons.. In this case, 10 seconds of waiting appears to make the difference (at least I think so)..

The tutorials really should be updated to reflect this though. It looks like this is a major cause of a lot of STOP 7B's.

I actually had another STOP 7B issue: I tried updating to the newest driverpack chipset drivers, and THAT gave me a STOP 7b across most intel hardware too. It boots to the VHD normally, but unfortunately refuses to USB boot after that. All the usb registry modifications I've made are intact strangely enough.. I think one of the USB drivers supplied by intel is causing some sort of issue as well, but it is such a PITA to track down which one and why...

I've bypassed the problem by just not updating the chipset drivers with the WAIK DISM tool... Its not like they are really necessary anyway..

Anyways, I'm just glad I found this quasi-fix for the timing problem.. It saves me a lot of headaches.. Thanks again!

[cdob]

It sounds though like you have a registry tweak

http://reboot.pro/14186/page__view__findpost__p__127772

[Sha0]

I'm having a strange problem... for some reason my windows 7 USB boot simply will not load with AHCI or RAID enabled.
...
I downloaded the newest iastor.sys and replaced it on my win7 USB. Still, no dice.
...
Any ideas?

Sorry .. it is in fact a stop 7B.

As far as whether the iastor is needed, I have found that if the system can't find a driver for at least one storage controller, you get a stop 7B.
...
I've wondered if there exists a dummy storage controller. It wouldn't be a big deal to install the correct drivers upon booting if I could in fact get it to boot.
...
What would be really nice is if there was some dummy storage controller driver that precluded the need to have a storage controller detected on boot..

...probably makes it seem like there is a storage controller attached.

...You don't specifically need iastor, but if its your ONLY storage controller and you don't have the driver load you get a STOP 7B.
...
Its entirely possible that you did something somwhere along the lines that eliminates a STOP 7B if you don't have a storage controller. I followed Karyonix's method for Win 7 booting, and I can guarantee you that unless you have addressed this problem in some other way YOU WILL STOP 7B if you do not have a single storage controller driver loaded. If you look around, a bunch of other people report the same problem when their build can't find a storage controller. It is certainly not isolated to my build.

If you found another way around this, I would love to know what you did differently...

...
It has the same effect when I have no storage drivers to load... and this is a pretty slow computer.

I'm not saying it isn't a timing issue... but I think a better way to put it then is: "there is no way the computer is going to NOT STOP 7B unless there is a storage driver to load that will slow it down."
...
Obviously something else needs to be done, or a BSOD will occur without a storage driver...

...if the consensus is that it is a timing issue, then I would be inclined to believe it. I don't think its really mutually exclusive though, as I've said I STOP 7B every-single-time that I don't have any storage drivers. The way I see it is that you DO need to load a storage driver, OR something else to delay or change the timing (if it is indeed a timing issue).
...
...I don't know.

Anyways, I'm just glad I found this quasi-fix for the timing problem.. It saves me a lot of headaches.. Thanks again!

Why is it that during all of this discussion, you do not consider USBSTOR.SYS to be a storage driver? Please explain how USBSTOR.SYS and IASTOR.SYS might be different.

...

    ok = FALSE;

    while (StorageDriver) {

        if (StorageDriver != UsbStor) {

            ok = TRUE;

            break;

          }

        StorageDriver = StorageDriver->Next;

      }

    if (!ok) {

        /*

         * We have no storage driver or only

         * have the USB storage driver.  No way!

         */

        BugCheck(0x7B);

      }

...

[Agent_Smith]

Thanks.. It looks like the active changes are:

reg.exe add HKLM\SYSTEM\CurrentControlSet\Control\PnP /f /v PollBootPartitionTimeout /t REG_DWORD /d 30000
reg.exe add HKLM\SYSTEM\CurrentControlSet\Control\ /f /v BootDriverFlags /t REG_DWORD /d 0x6

I will give this a shot and see how it turns out..

Edited by Agent_Smith, 02 May 2011 - 07:02 PM.

[Agent_Smith]

Why is it that during all of this discussion, you do not consider USBSTOR.SYS to be a storage driver? Please explain how USBSTOR.SYS and IASTOR.SYS might be different.

...

    ok = FALSE;

    while (StorageDriver) {

        if (StorageDriver != UsbStor) {

            ok = TRUE;

            break;

          }

        StorageDriver = StorageDriver->Next;

      }

    if (!ok) {

        /*

         * We have no storage driver or only

         * have the USB storage driver.  No way!

         */

        BugCheck(0x7B);

      }

...

I don't think I ever said that USBSTOR wasn't a storage driver... All I was doing was affirming the observation that unless the driver for the onboard storage was loaded, you 7B... I really wasn't opposed to it being an issue of needing more time for Windows to access the USB volume.. Its just that regardless of the cause, not loading another storage driver makes it not work... If you don't implement another fix, you WILL 7B without another storage driver.

Obviously there are a few fixes in this thread for this, but I don't think many people are using them. It was completely not present in the tutorials AFAIK. This means everyone else who follows the tutorials like I did will have the exact same problem.

I didn't mean any disrespect when I said you were wrong - its just that its hard to deny a causal link between the two conditions when it can be experimentally repeated with almost perfect success. So while it in fact may be a timing problem, it doesn't preclude the notion that without additional changes no other storage drivers (other than USBSTOR obviously) will result in a 7B.

Just so I don't come off ungrateful, I think the work everyone did to come up with solutions to this matter was very impressive, and a great service to the community... The only thing that I was in fact trying to state throughout this thread was that a correction was required. All I was doing was arguing against notions to the contrary.

[Doodoo]

regardless of the cause, not loading another storage driver makes it not work... If you don't implement another fix, you WILL 7B without another storage driver.

What you're saying is sensible but I think you're taking the wrong end of the stick. On some machines, not loading another storage driver might work. On the other hand, loading another storage driver is not garanteed to work... it just happens to work, at least for the bunch of people who tried it. Perhaps on a very fast machine loading another storage driver will be so quick that the USB device still won't be ready and you'll get the BSOD 7B anyway.

Obviously there are a few fixes in this thread for this, but I don't think many people are using them. It was completely not present in the tutorials AFAIK. This means everyone else who follows the tutorials like I did will have the exact same problem.

Yes you're right, in all tutorials (that I know of) about booting from USB (including Karyonix's which I think you are using) there is no mention that "timing is critical". At most, there is a mention that loading storage drivers helps avoiding a BSOD 7B:

http://reboot.pro/9830/

Windows 7 boots perfect from USB-HDD on machine (ASUS MoBo with AMD Athlon 64 X2) where Windows 7 was previously installed,but booting with Windows 7 from USB-HDD if connected to laptop (Intel Pentium DualCore, IASTOR needed for HDD),then BSOD 7B occurred due to missing IASTOR driver and missing IASTOR registry settings for Control\CriticalDeviceDatabase and Services\iaStor. Adding to running Windows 7 the given HKLM_SYSTEM_iaStor.reg registry tweak and adding the files for iaStor driver solved the problem.

its hard to deny a causal link between the two conditions when it can be experimentally repeated with almost perfect success.

Yes on a given machine, I also have found that things seem to be extremely repeatable. But I think the causal link would only be (almost) established if things would be perfectly repeatable from hardware to hardware (as opposed to "repeatable from boot to boot on the same hardware").

I think the work everyone did to come up with solutions to this matter was very impressive, and a great service to the community...

I think Shao should get all the credits. He has been instrumental in providing a detailed understanding of the problem and spent valuable time writing specific test drivers ! cdob should not be forgotten... By the way he has just provided a new solution (for Win7):

http://reboot.pro/14...772#entry127772

It would be extremely interesting to know if this works, when you don't install any storage driver (other than usbstor.sys obviously)
Perhaps this kind of solution (specific to Win7) could be the base of a new add-on (replacement of UsbBootWatcher ?) to provide the same functionality on XP ?

The only thing that I was in fact trying to state throughout this thread was that a correction was required.

Agreed, maybe it wouldn't hurt to make it more clear in the various tutorials that "timing is critical". And also that "loading storage drivers" may help, but again is not garanteed to work.
But I suppose nobody can blame people who originally came up with the USB booting method, for always having storage drivers available on their test machine, so that they (by chance) never saw the problem...In fact "moving to a different hardware" is now our problem as opposed to their original "booting from USB" problem.

[Doodoo]

[Deleted] Duplicate post.

[Sha0]

I don't think I ever said that USBSTOR wasn't a storage driver...

I'm sorry. I took it as implied...

...if the system can't find a driver for at least one storage controller, you get a stop 7B.
...
...a dummy storage controller...
...
...if there was some dummy storage controller driver that precluded the need to have a storage controller detected on boot..

...like there is a storage controller attached.

...if its your ONLY storage controller...
...
...a STOP 7B if you don't have a storage controller...if you do not have a single storage controller driver loaded....the same problem when...can't find a storage controller.

...
...when I have no storage drivers to load...
...
unless there is a storage driver to load that will slow it down."
...
...a BSOD will occur without a storage driver...

...as I've said I STOP 7B every-single-time that I don't have any storage drivers...you DO need to load a storage driver...

Do you understand how that might read as though you do not consider USBSTOR.SYS to be a storage controller driver?

In reading your discussion, I would assume that you did have USBSTOR.SYS loading at boot time, right? Is that "a single storage controller driver loaded"?

All I was doing was affirming the observation that unless the driver for the onboard storage was loaded, you 7B...

Aha. "Onboard". Very well. So now, a different form of the same request: Please explain what might make USBSTOR.SYS different than an "onboard" storage controller driver (such as IASTOR.SYS).

I really wasn't opposed to it being an issue of needing more time for Windows to access the USB volume..

...the post you referenced...is definitely incorrect in that respect. You NEED windows to find a driver for at least one storage controller (even if it has no drives attached).

BUT, who cares? Live and learn. That's why, in the referenced post:

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

Hence the request for you to explain what might distinguish USBSTOR.SYS from an "onboard" storage controller driver.

...you WILL 7B without another storage driver.

Ok. "Another". I get it. Just like the previously shared pseudo-code:

...

...

    ok = FALSE;

    while (StorageDriver) {

        if (StorageDriver != UsbStor) {

            ok = TRUE;

            break;

          }

        StorageDriver = StorageDriver->Next;

      }

    if (!ok) {

        /*

         * We have no storage driver or only

         * have the USB storage driver.  No way!

         */

        BugCheck(0x7B);

      }

...

This pseudo-code pretends to look at a linked list of all storage drivers and checks each one to find out if it is USBSTOR.SYS. If it finds one that isn't, then everything is ok.

In other words, "you WILL 7B without another storage driver."

Do you suppose that there might be code like this in Windows?

...its hard to deny a causal link between the two conditions when it can be experimentally repeated with almost perfect success.

Absolutely agreed. But if we exclude the possibility that Windows is magical and that if we actually took the time to trace through every step of the boot process using WinDbg, then even if we don't take the time to do that, we can at least try to theorize about why this might be the case.

So what was/is your theory, if you please?

I might have stepped through the boot process hundreds of times while developing WinVBlock, but I haven't provided any direct evidence that "it's all about timing." I cannot disassemble or reverse engineer Windows because that would be a violation of my End-User License Agreement!... So I'm stuck with guessing.

So what's your guess?

Here's a current theory, which has not been validated:

• During boot-up, when the PnP Manager asks the USB hub for its children, the hub reports no children. PnP Manager moves on.
• Later^*, the USB hub driver has a poll event where it polls for USB devices and finds them, including your USB mass storage device. This mass storage device is queued for device installation (being driven by a driver).
  
• If "later^*" occurs before DISK.SYS is asked to drive all devices it should drive, then we are able to boot from the USB storage.
• If "later^*" occurs after DISK.SYS is asked to drive all devices it should drive, then we are unable to boot from the USB storage.

Here is [possibly] weak supporting evidence of that theory, from a Microsoft web-page:

...
During the post-boot phase, the USB hub driver (USBHUB.SYS) was modified to require (wait for) the UFD boot storage device to be initialized.
...

Do you have a different theory you'd like to share? The more perspectives there are available, the greater the number of angles to approach the challenge.

[Agent_Smith]

What you're saying is sensible but I think you're taking the wrong end of the stick. On some machines, not loading another storage driver might work. On the other hand, loading another storage driver is not garanteed to work... it just happens to work, at least for the bunch of people who tried it. Perhaps on a very fast machine loading another storage driver will be so quick that the USB device still won't be ready and you'll get the BSOD 7B anyway.

I think a better way to put it is to say that I'm working from the OTHER end of the stick. I came into this thread only analyzing the results... and while what you say may in fact be true, it hasn't happened yet for me. I haven't encountered a machine that was "too fast" when a storage driver is loaded. I also haven't encountered a computer that was "slow enough" to load from USB when there was no other storage driver present. I must've 7B'ed on different about 15-20 computers in my testing over the last month through experimentation (although some for different reasons).. but some pretty obvious patterns emerged, and I could make my build 7B BSOD on purpose pretty easily.

I guess what I'm trying to say is that while I didn't understand why it was happening per say, it was obvious what conditions would definitely produce failure... and this is why I've been so adamant. In this case, real world results are probably the most important thing... To be honest, I don't care as much about they "why" as much as I care about being able to use it universally.

Yes you're right, in all tutorials (that I know of) about booting from USB (including Karyonix's which I think you are using) there is no mention that "timing is critical". At most, there is a mention that loading storage drivers helps avoiding a BSOD 7B:

http://reboot.pro/9830/

As you saw, I mentioned it in the karyonix thread... Hopefully what was discussed here will help others.

Yes on a given machine, I also have found that things seem to be extremely repeatable. But I think the causal link would only be (almost) established if things would be perfectly repeatable from hardware to hardware (as opposed to "repeatable from boot to boot on the same hardware").

While most people use it on one computer, I've been actively using it in production on quite a lot of computers... I use it for everything from virus removal, data recovery, and a few other random purposes... both at my FT job and freelance practice. What I've been trying to saying is that the issue has repeated without fail in the same situation across a pretty wide range of computers. Again, I've only been analyzing the results of my own experience.

I think Shao should get all the credits. He has been instrumental in providing a detailed understanding of the problem and spent valuable time writing specific test drivers ! cdob should not be forgotten... By the way he has just provided a new solution (for Win7):

http://reboot.pro/14...772#entry127772

Next week after I clear my backlog, I'm going to give this a try. A registry entry is probably the easiest solution to implement, and can be easily added to the scripts I made for making new builds (based on the information from this site). Again, I'm grateful for all the time people spent on fixing these issues and developing these very novel ways of adapting windows to our needs.

It would be extremely interesting to know if this works, when you don't install any storage driver (other than usbstor.sys obviously)
Perhaps this kind of solution (specific to Win7) could be the base of a new add-on (replacement of UsbBootWatcher ?) to provide the same functionality on XP ?


Agreed, maybe it wouldn't hurt to make it more clear in the various tutorials that "timing is critical". And also that "loading storage drivers" may help, but again is not garanteed to work.
But I suppose nobody can blame people who originally came up with the USB booting method, for always having storage drivers available on their test machine, so that they (by chance) never saw the problem...In fact "moving to a different hardware" is now our problem as opposed to their original "booting from USB" problem.

Yes, I'm encouraged that this might greatly improve things. People wouldn't have to worry about changes to the USB service entries in the registry anymore. I personally changed the .inf files, but I always thought this was a bit of an ugly hack...

[Agent_Smith]

I'm sorry. I took it as implied...

Do you understand how that might read as though you do not consider USBSTOR.SYS to be a storage controller driver?

In reading your discussion, I would assume that you did have USBSTOR.SYS loading at boot time, right? Is that "a single storage controller driver loaded"?

Aha. "Onboard". Very well. So now, a different form of the same request: Please explain what might make USBSTOR.SYS different than an "onboard" storage controller driver (such as IASTOR.SYS).

You see, to me, you are looking at this from a very different perspective. I don't think any of us truly knows the detailed step by step operation that Windows takes when starting up. If we did, then we wouldn't have needed to take such a trial and error approach.

I could take it a step further from what you are saying... I could say, what is the difference between loading a storage controller driver and any other driver. Its not like we need them to load from the USB disk. Hell, we are already loading drivers off the disk its saying is inaccessible. It doesn't make any sense at face value.

The only thing I know for sure, is that the presence of a storage driver like IASTOR (other than USBSTOR) has a 100% correlation between whether I boot or not on at least 10-15 systems. I don't really care about USBSTOR that much since its a constant. It always loads. Something like IASTOR, on the other hand, is not constant... That makes it a variable... and again, this variable has a 100% correlation with whether I boot.

So, my point is, in the discussion - I see no reason to even bring up USBSTOR. Yes, it is A storage driver. It is A driver... but its not what is changing and causing me not to boot. It is the presence of other drivers... Other storage drivers. I don't think anyone in this thread was ever under the impression that USBSTOR wasn't a storage driver...

To be perfectly honest, I did not know for sure that something to the effect of that pseudo code did not exist. I have no idea what is in the USBSTOR driver. As far as I knew, maybe there is a flag that is set in memory. Maybe microsoft doesn't want me to boot from USB. Who the hell knows?

It didn't really matter in terms of getting my build to boot, to be perfectly honest. All I know is that without (another) storage driver, or some other fix, it didn't work. Luckily, there are other alternatives... from my count, there looks like 3 viable alternative solution, including your driver that waits ten seconds...

Absolutely agreed. But if we exclude the possibility that Windows is magical and that if we actually took the time to trace through every step of the boot process using WinDbg, then even if we don't take the time to do that, we can at least try to theorize about why this might be the case.

So what was/is your theory, if you please?

I might have stepped through the boot process hundreds of times while developing WinVBlock, but I haven't provided any direct evidence that "it's all about timing." I cannot disassemble or reverse engineer Windows because that would be a violation of my End-User License Agreement!... So I'm stuck with guessing.

So what's your guess?

Well, I'm probably way off, but if it is a timing issue, Well... Do you know when you update a driver in device manager? It sort of blinks out for a second when its being re-initialized. Like with a VGA adapter, where the screen goes black as its updated - I'm thinking that when the storage driver for the boot volume is loaded, it makes the volume inaccessible for a little while as the USB device is re-initialized. On a SATA hard drive, its probably a very quick process... but USB devices always seem slower to re-initialize, or reconnect, at least more so than other devices. With no other devices to load, Windows tries to proceed but can't find the boot volume because its still being initialized.

Maybe if windows has cached the other storage drivers in memory, then it can load them while the USB storage device is reinitialized. This is just a random guess, and its probably wrong.

Here's a current theory, which has not been validated:

• During boot-up, when the PnP Manager asks the USB hub for its children, the hub reports no children. PnP Manager moves on.
• Later^*, the USB hub driver has a poll event where it polls for USB devices and finds them, including your USB mass storage device. This mass storage device is queued for device installation (being driven by a driver).
  
• If "later^*" occurs before DISK.SYS is asked to drive all devices it should drive, then we are able to boot from the USB storage.
• If "later^*" occurs after DISK.SYS is asked to drive all devices it should drive, then we are unable to boot from the USB storage.

Here is [possibly] weak supporting evidence of that theory, from a Microsoft web-page:


Do you have a different theory you'd like to share? The more perspectives there are available, the greater the number of angles to approach the challenge.

Well, wouldn't USBSTOR always install before since disk.sys since we specify it as a SCSI miniport device? If it finds a USB storage device before this point, wouldn't if HAVE to load before disk.sys. I would have thought windows would be hardcoded to make sure all storage drivers are loaded before trying to load the disks..

Edited by Agent_Smith, 03 May 2011 - 12:52 AM.

[Agent_Smith]

Thanks.. It looks like the active changes are:

reg.exe add HKLM\SYSTEM\CurrentControlSet\Control\PnP /f /v PollBootPartitionTimeout /t REG_DWORD /d 30000
reg.exe add HKLM\SYSTEM\CurrentControlSet\Control\ /f /v BootDriverFlags /t REG_DWORD /d 0x6

I will give this a shot and see how it turns out..

I can vouch that this worked for two systems where I disabled all other storage controllers..

EDIT:
I also tested the waitbt.sys, and it also works without any storage controllers...

So, it looks like all three measures will buy enough time for whatever it is that is happening..

Edited by Agent_Smith, 03 May 2011 - 05:35 AM.

[Doodoo]

I think a better way to put it is to say that I'm working from the OTHER end of the stick.

Fair enough, your different perspective is at least as valuable as mine ! There is so much I still need to learn myself, I wouldn't dare say I know the truth and anyone else is wrong.

and while what you say may in fact be true, it hasn't happened yet for me. I haven't encountered a machine that was "too fast" when a storage driver is loaded. I also haven't encountered a computer that was "slow enough" to load from USB when there was no other storage driver present.

I think your experience is incredibly valuable and useful. You mentioned you had BSOD 7B on 15-20 computers which is a whole lot more than most people on this forum ever use... I only have at hand 3 or 4 different machines, which are not even all really mine... However the fact that you haven't yet seen a machine that is "too fast" or one that is "slow enough" doesn't mean it will never happen in the future. And this leads to the next step:

To be honest, I don't care as much about they "why" as much as I care about being able to use it universally.

Your pragmatic approach is perfectly fine. But caring about "universality" is in itself is a good enough reason to try to understand the root cause of the problem, in order to come up with a solution which is known to be future-proof, and not just a tweak which "happens to work today, but may not work tomorrow"

What I've been trying to saying is that the issue has repeated without fail in the same situation across a pretty wide range of computers. Again, I've only been analyzing the results of my own experience.

Till we have absolutely irrefutable evidence, all we can do is speculate that this or that is happening. Any hypothesis can (within limits of reason) be thought to be true, as long as a counter example is not found (i.e. a BSOD 7B is not seen).

The only thing I know for sure, is that the presence of a storage driver like IASTOR (other than USBSTOR) has a 100% correlation between whether I boot or not on at least 10-15 systems. I don't really care about USBSTOR that much since its a constant. It always loads. Something like IASTOR, on the other hand, is not constant... That makes it a variable... and again, this variable has a 100% correlation with whether I boot.

As I already said, 10-15 systems is an awful lot. And I believe your 100% correlation means a lot in this case.
I also have found that loading IASTOR solved my problems 100% of the time, but that was only on 4 or 5 different machines, from friends or relatives.

I also tested the waitbt.sys, and it also works without any storage controllers...
So, it looks like all three measures will buy enough time for whatever it is that is happening..

It is obviously very time consuming, but if you can check that all three solutions behave the same 100% on many machines (the more the better !), that will be very informative ! As long as we don't find a counter-example, we cannot rule out the fact that is purely down to timing...

In fact there might be a fourth option (at least for XP):

During the post-boot phase, the USB hub driver (USBHUB.SYS) was modified to require (wait for) the UFD boot storage device to be initialized.

You can try to replace the standard usbhub.sys file with the version from XP Embedded SP3 (from http://iorboaz.blogs...ndows-2003.html) or from the Feature Pack 2.
This has also given me 100% success, but that was only on 4-5 different machines. If you have the time, it would be interesting to test on many more !
But anyway for Win7 I don't know if in there is also a variant of usbhub.sys to be taken from Win7 Embedded.