133 replies to this topic

[Sha0]

Doodoo's and cdob's and others' discussion in this thread led to the development of something that might help with booting from USB for Windows XP or Windows Server 2003.

This "driver" will print messages about when storage devices arrive, and will stall the boot process for 1 second if the boot disk signature cannot be retrieved, up to a maximum of 10 attempts.

It might be nice to see these messages, so use the /SOS switch in your BOOT.INI. If you are booting from a USB disk and have been encountering a Blue Screen of Death with error code STOP 0x0000007B, you might observe that by using this driver, the USB disk arrives after WaitBt has stalled the boot process at least once.

So version 0.0.0.5 is attached. (121 downloads at time of removal.)
So version 0.0.0.7 is attached. (6 downloads at time of removal.)
So version 0.0.0.8 is attached:  waitbt-0.0.0.8.zip   184.78KB   175 downloads

[wimb]

Hi Sha0,

Thanks for making new version of waitbt32.sys

I have tried new version of waitbt in booting XP Image as WinVBlock FILEDISK.

I used my AMD Athlon to prepare and to boot first the XP Image file on Hitachi USB-harddisk (everything OK)
I did use the required USB registry tweaks but did not make use of UsbBootWatcher (Service is not installed)

Then I tried my troublesome laptop with Intel Dual Core that normally will give BSOD 7B for booting from USB

waitbt presents partition and volume arrived messages.
Then I get the disk signature message for 10 attempts and finally it ends with BSOD 7B

So waitbt is working but was not yet able to solve the BSOD 7B problem.
but anyway I have useful test condition.

On the same laptop I can boot this XP Image as WinVBlock RAMDISK (boot OK)

More results tomorrow ...

[Sha0]

waitbt presents partition and volume arrived messages.
Then I get the disk signature message for 10 attempts and finally it ends with BSOD 7B

D'oh! Which partitions and volumes arrive? Can you tell if they are related to the USB mass storage you are trying to boot?

Oh wait a minute, you said WinVBlock file-backed disk... That is likely a bug in WinVBlock. WaitBt should help for booting from USB (directly). After the WinVBlock bug is fixed, it might help with that, too.

[Doodoo]

Oh wait a minute, you said WinVBlock file-backed disk... That is likely a bug in WinVBlock. WaitBt should help for booting from USB (directly). After the WinVBlock bug is fixed, it might help with that, too.

Ok, here is my first experiment. Not exactly along your guidelines, for at least two reasons:

• I'm booting XP from an IMG file, with WinVBlock, i.e. I'm not booting flat files, where WaitBt should help.
• I'm booting XP on a computer which doesn't give a BSOD 7B anyway.... But the sequence of events might still be informative.

So here is what happens:  P1010223.JPG   180.63KB   64 downloads
I will try the very same on the Dell computer which gives me BSODs 7B all the time as soon as possible and will post a similar report...

[Doodoo]

Second experiment now, not exactly along your guidelines for at least 2 reasons:

• I'm booting Win7 and not XP
• I'm not booting from USB but from the internal HDD (IDE, not SATA)

So here is first what happens when I boot directly from flat files:  P1010215.JPG   171.82KB   46 downloads

Next step, not exactly along your guidelines for a third reason:
3. I'm not booting from flat files, but from a VHD, using Win7 internal driver.

Here is what happens now:  P1010218.JPG   172.91KB   47 downloads  P1010217.JPG   176.42KB   43 downloads
Note that although WaitBt cannot identify the boot volume, it still boots successfully !

This last example looks interesting to me.... It might give some insight on the timing of events when booting an IMG with WinVBlock, and give us a clue as to why it sometimes doesn't work...

[maanu]

i dont understand , in your last pic you posted , waitbt is mantioning , that :" maximum failed attempts reached ," it but then from nowhere, there comes the right disc arrived , and windows avoid 0x00007B

but before that i have seen , that vhdhub has also arrived .

did you use the latest reg tweak wimb mentioned , from chinese friend of mine ?

try that one too with combination of waitbt on this win7 native VHD and see , it might behave difference.

by the way , what is the test result on your wife's Dell ,which loves 0x7B ?
does waitbt took care of it on win7 and xp ?

[wimb]

D'oh! Which partitions and volumes arrive? Can you tell if they are related to the USB mass storage you are trying to boot?

Oh wait a minute, you said WinVBlock file-backed disk... That is likely a bug in WinVBlock. WaitBt should help for booting from USB (directly). After the WinVBlock bug is fixed, it might help with that, too.

I don't have yet such nice pictiures of the booting process as Doodoo presents,
and the messages rapidly disappear, so that I cannot give such details right now.
It would be nice if such details would occur in the bootlog, but that records only the loading of drivers.

I did fresh install of XP on HDD partition and then restored it to USB harddisk partition.
In this way I follow exactly your proposal to test the effect of waitbt32.sys

Booting from USB on the Athlon desktop and on the troublesome Intel Dual Core laptop went OK,
where I tested with and without using the waitbt32.sys driver. In all cases boot OK without BSOD 7B
That is unfortunate for the experiment, since I cannot test in this way the effect of waitbt32.sys driver.

I think waiting 10 sec is may be too short.
May be you can use interfalls of 3 sec resulting for 10 attempts in 30 sec timeout,
which was set by fujianabc as timeout in case of booting Windows 7 from USB

Hopefully, Doodoo has more luck with his troublesome hardware.

@Doodoo
Thanks for the interesting ScreenShots. We can learn a lot again ...

[Doodoo]

waitbt is mantioning , that :" maximum failed attempts reached ," it but then from nowhere, there comes the right disc arrived , and windows avoid 0x00007B

Yes that's not exactly what I expected.... which is why it is interesting !
To be honest, I can't explain why this happens, but I'm just a guinea pig... I carry out experiments, and leave the intellectual work to someone else

did you use the latest reg tweak wimb mentioned , from chinese friend of mine ?

No I didn't use that tweak, I suppose it would defeat the purpose.
This tweak relies on a win7 specific feature, and WaitBt is supposed to provide something similar in XP.
But you're right, I will try it, see what happens !

by the way , what is the test result on your wife's Dell ,which loves 0x7B ?

I won't have the answer to that question before a couple of days. But I would expect a BSOD 7B anyway when booting an IMG (similarly to Wimb's results), because that's a USB/WinVBlock problem. I have never tried to boot flat files (because that's a real pain a USB stick), but I think it's worth a try !

[Doodoo]

the messages rapidly disappear, so that I cannot give such details right now.
It would be nice if such details would occur in the bootlog, but that records only the loading of drivers.

Yes i was having the same issue to read the messages... Which is why I took pictures in the end !
But anyway to report results on the forum, I suppose there is no other choice, because how could we dump a log file, on the very disk which we are trying to establish ?

Booting from USB on the Athlon desktop and on the troublesome Intel Dual Core laptop went OK,
where I tested with and without using the waitbt32.sys driver. In all cases boot OK without BSOD 7B
That is unfortunate for the experiment, since I cannot test in this way the effect of waitbt32.sys driver.

Yes it looks like now the problem is to produce a BSOD 7B !! I have never tried from flat files, but always from IMG, so I might have the same problem as you.
I suppose one way to produce a BSOD 7B and properly test WaitBt is (e.g.) to try to boot on a computer which requires iastor.sys, but without installing iastor.sys.... Or more generally to disable all storage drivers, except usbstor.sys indeed.

[wimb]

I suppose one way to produce a BSOD 7B and properly test WaitBt is (e.g.) to try to boot on a computer which requires iastor.sys, but without installing iastor.sys.... Or more generally to disable all storage drivers, except usbstor.sys indeed.

YES, It works Thanks Doodoo for advise in experiment

waitbt32.sys is working and prevents BSOD 7B for XP booting from USB partition - Thanks Sha0

On my troublesome laptop with Intel Dual Core I got the following results:

- Without iastor.sys I get BSOD 7B for booting XP from USB partition
- Without iastor.sys and after adding waitbt32.sys driver then booting is OK (no BSOD 7B anymore)

(BTW UsbBootWatcher service was not installed, but need to be installed to preserve Group and Start settings of USB drivers)

After booting then iastor.sys driver is needed to see internal harddisk of laptop
The missing iastor.sys driver was auto installed from the \WINDOWS\DriverPacks store (with C+M+P+L) made by KTD option

So everything works GOOD this way

[Doodoo]

Without iastor.sys and after adding waitbt32.sys driver then booting is OK (no BSOD 7B anymore)

Great news indeed ! Thanks for the testing, wimb !
And great work Shao once again !!!!

This should convince everyone that storage drivers (such as iastor.sys) are not needed to boot from USB (which is what you'd expect). They are only required to see the internal HDD.
The other good news is that with WaitBt, you don't have to continuously update HKLM_systemdst_iaStor.reg in your tools; in the worst case users will not be able to see the HDD, but they will at least be able to boot !

BTW UsbBootWatcher service was not installed

Experts could give more details, but I think UsbBootWatcher doesn't help booting whatsoever. It only ensures that the USB drivers remain in "boot start" as opposed to "automatic start"
So in your case, absence of UsbBootWatcher is not incompatible with a successful boot ... but it may not boot well forever (till you insert a new USB device and Windows resets the drivers to "automatic start")

[wimb]

The XP Image file booted as WinVBlock FILEDISK was formatted with NTFS Compression.
Could it be that uncompressing the drivers is taking already too much time and being responsible for subsequent BSOD 7B ?

I will repeat tomorrow the experiment without using compression for NTFS
and then see if waitbt32.sys can work as well for the case of WinVBlock FILEDISK

[Doodoo]

Could it be that uncompressing the drivers is taking already too much time and being responsible for subsequent BSOD 7B ?

Perhaps it plays a role since timing seems to be the root cause of the problem when booting an image file; so it's worth trying !
But my current understanding is that there is a more fundamental problem which WaitBt cannot solve

http://reboot.pro/14...post__p__126888

WinVBlock reports its disks as available right away. It's only upon the MBR probe (when disk.sys is examining partitions) that the backing disk is required.

So even if the USB disk is "available," if the order goes:

• Disk.sys drives WinVBlock disk
• Disk.sys probes WinVBlock MBR
• Disk.sys drives USB disk
• Disk.sys probe USB disk MBR

Then we get a STOP 0x7B. If the order goes:

• Disk.sys drives USB disk
• Disk.sys probe USB disk MBR
• Disk.sys drives WinVBlock disk
• Disk.sys probes WinVBlock MBR

Then we are ok. Since a WinVBlock disk is more likely to be reported before a USB disk, the former order is unfortunately more likely (first come, first-served).

Shao is the expert when it comes to this kind of problems... He might provide more details or simply correct me if I'm wrong !

[Sha0]

Ok, here is my first experiment. Not exactly along your guidelines, for at least two reasons:

• I'm booting XP from an IMG file, with WinVBlock, i.e. I'm not booting flat files, where WaitBt should help.
• I'm booting XP on a computer which doesn't give a BSOD 7B anyway.... But the sequence of events might still be informative.

To be honest, this WaitBt version has given me an idea for what needs to happen in WinVBlock. I think that WinVBlock needs to find backing disks before reporting sector-mapped/file-backed disks. That will avoid a "dud". I wasn't sure about the timing before, but I think WinVBlock could use the same Reinitialize and stall logic as WaitBt to provide enough time for the late disk to arrive, for its partitions to arrive, for its volumes to arrive.

So here is what happens...

Getting feedback and screen-shots like this really make it a joy to develop!

Second experiment now...

Getting feedback and screen-shots like this really make it a joy to develop!

Next step...I'm not booting from flat files, but from a VHD, using Win7 internal driver.
...
Note that although WaitBt cannot identify the boot volume, it still boots successfully !

This last example looks interesting to me....

Well WaitBt is not required for Windows 7. Interestingly, your screen-shot says 6.1.

But anyway, what that says to me is: The VHD driver is not a boot driver! Why? Because it should have had "turns" in between each WaitBt pause and we should have seen the VHD arrivals sooner. The fact that they are happening only after WaitBt has given up suggests that this driver is only being invoked after boot drivers have finished their reinitialization routines.

In XP/2003, this was roughly when a STOP 0x7B would come along. In this Windows version, it would seem that there is a new stage before STOP 0x7B, where a driver like the VHD driver is invoked. This makes perfect sense! For example, see my notes above about when WinVBlock should provide a disk! About the same time!

It might give some insight on the timing of events when booting an IMG with WinVBlock, and give us a clue as to why it sometimes doesn't work...

It's very useful information you've captured. Perhaps you can examine the VHD driver's Registry entries and suggest when it looks like the driver is invoked.

i dont understand...but then from nowhere, there comes the right disc arrived , and windows avoid 0x00007B

See above regarding "new stage" before STOP 0x7B.

I don't have yet such nice pictiures of the booting process

Oh well. Your testing and reporting are still no less valuable feedback!

I think waiting 10 sec is may be too short.

I don't think so. That's a good while for a USB hub to find its children. Imagine if you had to wait that long after plugging in a USB device before hearing the "USB device arrival" sound or the system tray notification balloon. No way!

May be you can use interfalls of 3 sec resulting for 10 attempts in 30 sec timeout,
which was set by fujianabc as timeout in case of booting Windows 7 from USB

Well, a future version of WaitBt could read your choice from the Registry. Let's make that a to-do item, then.

To be honest, I can't explain why this happens, but I'm just a guinea pig... I carry out experiments, and leave the...work to someone else

...I would expect a BSOD 7B anyway when booting an IMG (similarly to Wimb's results), because that's a USB/WinVBlock problem.

'Tis. See above.

Yes i was having the same issue to read the messages...how could we dump a log file, on the very disk which we are trying to establish ?

Do you mean right before booting? I did not wish to delay a successful boot just so a user could have time to read messages. But if you are meaning right before a STOP 0x7B, it is supposed to delay it by 10 seconds. If it doesn't, then there's a problem.

YES, It works Thanks Doodoo for advise in experiment

waitbt32.sys is working and prevents BSOD 7B for XP booting from USB partition - Thanks Sha0
...
So everything works GOOD this way

Excellent!

Great news indeed ! Thanks for the testing, wimb !
And great work Shao once again !!!!

This should convince everyone that storage drivers (such as iastor.sys) are not needed to boot from USB (which is what you'd expect). They are only required to see the internal HDD.

The XP Image file booted as WinVBlock FILEDISK was formatted with NTFS Compression.
Could it be that uncompressing the drivers is taking already too much time and being responsible for subsequent BSOD 7B ?

Nope. Whether the volume has compression or not doesn't have any influence over the volume being symbolically linked to the ARC path. Remember that a STOP 0x7B is due to Windows trying to open the ARC path specified in BOOT.INI. If the link exists and its target can be opened, no STOP 0x7B. Any compressed files would not yet be accessed.

But my current understanding is that there is a more fundamental problem which WaitBt cannot solve

You are exactly right. See above.

What a treat from all of you, today!

[maanu]

Shao

receive me congratulations ,your hard work and feedback from Doodoo and WIMB made it happen.

i really like your approach about getting winvblock at the same stage ,where VHD driver gets invoked. it is just amazing .
btw i understand , that waitBT will wait 10 seconds for the device to become active , and ASAP the drive is available ,it wont wait anymore and will skip waiting ?

i guess we all should hold our breath for the updated winvblock then ,but anyhow whatever you think is good enough for us greedy guys

[Sha0]

i really like your approach about getting winvblock at the same stage ,where VHD driver gets invoked. it is just amazing .

I hope it'll work, once implemented.

btw i understand , that waitBT will wait 10 seconds for the device to become active , and ASAP the drive is available ,it wont wait anymore and will skip waiting ?

True. In fact, it might skip waiting too soon... The function which calls STOP 0x7B wants a volume, but WaitBt will stop waiting once IoGetBootDiskInformation() returns valid information, which is tied to a disk (I think). This might need refinement.

i guess we all should hold our breath for the updated winvblock then ,but anyhow whatever you think is good enough for us greedy guys

[Doodoo]

I think that WinVBlock needs to find backing disks before reporting sector-mapped/file-backed disks. That will avoid a "dud".

That makes perfect sense, but...

I think WinVBlock could use the same Reinitialize and stall logic as WaitBt to provide enough time for the late disk to arrive, for its partitions to arrive, for its volumes to arrive.

I thought this strategy was not entirely satisfying, according to this:

http://reboot.pro/14...post__p__126888

Is it conceivable that WinVBlock's backing-disk-search could be part of a re-initialize routine ?
In other words, the idea would be to wait that all physical disks are available, before any virtual disk is provided

Unfortunately, I don't think so. There was a period in WinVBlock's history when it did this, but it turns out to be too late for Windows XP/2003 Setup/Recovery Console. WinVBlock reports its disks as available right away.

Or is it not exactly the same strategy that we are talking about ?

Getting feedback and screen-shots like this really make it a joy to develop!

Be carreful... You might soon be inundated with screen-shots, to motivate you to update WinVBlock sooner rather than later ....

But anyway, what that says to me is: The VHD driver is not a boot driver! (...) Perhaps you can examine the VHD driver's Registry entries and suggest when it looks like the driver is invoked.

That is also how I interpret the results... But yet that is not quite what the registry seems to suggest:

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\vdrvroot]

"Start"=dword:00000000

"DisplayName"="Microsoft Virtual Drive Enumerator Driver"

"Group"="Boot Bus Extender"



[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\vhdmp]

"Start"=dword:00000003

"Group"="SCSI miniport"

or is Start=3 for vhdmp is agreement with what you're saying ?

I did not wish to delay a successful boot just so a user could have time to read messages. But if you are meaning right before a STOP 0x7B, it is supposed to delay it by 10 seconds. If it doesn't, then there's a problem.

It makes perfect sense, and there is no problem... That's exactly how it works !

What a treat from all of you, today!

And what a treat from you yesterday !

[Sha0]

That makes perfect sense, but...
I thought this strategy was not entirely satisfying, according to this
Or is it not exactly the same strategy that we are talking about ?

Correct, again! When WinVBlock did this before, the Recovery Console (which is fast-moving, apparently) yielded STOP 0x7B when the boot disk was provided after disk.sys; in a re-initialization routine. So your suggestion had actually been implemented at one point, then subsequently "de-implemented."

However! Now that it's [hopefully] generally understood that timing plays a factor, WinVBlock could go this route again and deliberately stall "7B time" until things are ready. This "waiting game" doesn't feel right to me, but hey, it obviously is right: iSCSI does it. Windows 7 does it. WaitBt does it ().

Be carreful... You might soon be inundated with screen-shots, to motivate you to update WinVBlock sooner rather than later ....

Well there's something satisfying about seeing one's work put to good use.

That is also how I interpret the results... But yet that is not quite what the registry seems to suggest...

Hmm... Perhaps you could venture a step further... In Windows 7's Device Manager, I believe that the Properties for the VHD disk will have Details where you might be able to observe the disk name, as seen in your screen-shot. When you find it, please look for the Service value and we will then know which of these two services actually produces the disk. Oh wait a minute, that'll be Disk... Never mind. Disk.sys will provide the FDO but we need to know which of these two you've given in your post provide the PDO. Hmm...

or is Start=3 for vhdmp is agreement with what you're saying ?

Maybe you could try [temporarily] disabling each of these to find out more?

[wimb]

Just to illustrate the effect of waitbt on booting XP from USB partition of Hitachi USB Harddisk

First Boot ======== After Reboot
=

The iaStor driver needed to see internal drive of laptop is installed after First Boot.
Laptop Harddisk arrives on Reboot

[Doodoo]

Just to illustrate the effect of waitbt on booting XP from USB partition of Hitachi USB Harddisk

First screen capture really is interesting
This is where the effect of WaitBt is critical, as it stalls the boot process till the USB disk arrives !

[Doodoo]

did you use the latest reg tweak wimb mentioned , from chinese friend of mine ?
try that one too with combination of waitbt on this win7 native VHD and see , it might behave difference.

I have set PollBootPartitionTimeout to 30000, but it doesn't make a blind bit of difference: it behaves as in this post, where the VHD boot disk appears only after WaitBt has given up.
This might also be an interesting detail, to understand how it all works !

[Doodoo]

WinVBlock could go this route again and deliberately stall "7B time" until things are ready.

Do you mean that this strategy, initially not working for Windows XP/2003 Setup/Recovery Console, would be expected to work when combined with stall "7B time" ?

Hmm... Perhaps you could venture a step further... In Windows 7's Device Manager, I believe that the Properties for the VHD disk will have Details (...) Disk.sys will provide the FDO but we need to know which of these two you've given in your post provide the PDO.

I will have a look. For now I have found some information on VHD, possibly useful for you (not terribly informative for me, as I don't understand the details)
http://msdn.microsof...v=vs.85%29.aspx

• VDrvRoot.sys - Root virtual drive enumerator.
• Vhdmp.sys - VHD parser and dependency property provider.

[wimb]

Here is an interesting sequence of pictures for booting XP as WinVBlock FILEDISK on USB Hitachi harddisk.
AMD Athlon desktop was used to prepare Mini XP Image file on USB (iaStor driver was added).

1. Intel Dual Core laptop giving BSOD 7B
2. Intel i3 Quad Core desktop - Boot OK
3. Same Intel Dual Core laptop now booting OK
4. Same Intel Dual Core laptop after Reboot

Apparently after succesful booting on Intel Quad Core which also needs iaStor driver,
then booting on Dual Core laptop is going OK

===== 1 ====== ===== 2 ====== ===== 3 ====== ===== 4 ======
= = =

Quite Interesting.

[Doodoo]

Here is an interesting sequence of pictures for booting XP as WinVBlock FILEDISK on USB Hitachi harddisk.

Interesting indeed, but in theory WaitBt cannot help in this scenario (booting from WinVBlock FILEDISK)
In practise, your examples #2, #3 and #4 might happen to work by chance, because WaitBt changes the timing of events and usbstor reports a disk before winvblock reports its own.
On the other hand in example #1, winvblock reports its disk before usbstor and you get a BSOD 7B. This looks remarkably similar to what I have reported here (first experiment)

To give us more insight, please could you try this: download USBoot: http://www.usboot.or...e.php?fileId=15
Extract, and right click install on usbdrvgrd.inf.
If you can boot on computer #1 it might be one more small piece of evidence that DriveGuard does something critical...or possibly nothing but only alters timing and gets everything to work out of luck !

[wimb]

USBSTOR Hitachi does not arrive at all in case #1 and the result is BSOD 7B

On booting on Quad Core then iaStor is used (properly installed) for the first time.

Returning in picture #3 to the Dual Core laptop (which also requires iaStor for internal harddisk)
then booting XP as WinVBlock FILEDISK on USB is going OK.
USBSTOR Hitachi is found now.