Just to illustrate the effect of waitbt on booting XP from USB partition of Hitachi USB Harddisk
Thanks!
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" ?
Well in that "era," WinVBlock would report the disk after
Disk.sys has already had its turn, then all
Reinitialize routines would be complete, so "7B time" would arrive and not find the boot volume... Given a few more seconds, perhaps it
would, as the newly-reported disk would provide a partition, which would then provide a volume.
For now I have found some information on VHD, possibly useful...
Thanks!
Here is an interesting sequence of pictures for booting XP as WinVBlock FILEDISK on USB Hitachi harddisk.
Seems like "learning" happened.
...in theory WaitBt cannot help in this scenario (booting from WinVBlock FILEDISK)
Race conditions are the worst. You have a "main" thread which follows a specific order. That thread is the one which eventually can cause
STOP 0x7B. Then you have other threads which run independently of the state of the "main" thread.
An example of such a thread would be a thread which eventually reports and installs USB devices on a USB bus. Remember what XP Embedded does: Moves that into the "main" thread by waiting.
USBSTOR Hitachi does not arrive at all in case #1 and the result is BSOD 7B
If it does not arrive within 10 seconds, my guess would be that the devices and/or some of their ancestors cannot be installed due to a lack of
CDDB associations or because the appropriate drivers were not set to boot-start. Perhaps after booting successfully on the other hardware, these things were established.
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.
And it has nothing to do with
IASTOR.SYS.
Yes, but couldn't it be precisely because booting on your Quad Core computer installs iaStor, that timing is different when you return to the Dual Core laptop, which miraculously gets everything to work ?
If WaitBt didn't help for the USB disk to arrive, it would not have arrived. Chances are, in my opinion, that a simple, successful boot established some USB details which happen to apply to the first hardware.
The results are:
...
timeout caused by wait10.sys is working good.
I did not see the USB disk arrive at all in #1. Did it actually happen later on, outside of the time when the screen-shot was taken? If so, then WaitBt
did help it to arrive, just the same as
Wait10. Regardless of that status, if it came after the WinVBlock disk, that's unlucky.
Excellent ! So even when iastor is properly installed, the WinVBlock disk turns up before that provided by usbstor ?
This is not the case on my Dell laptop... it would appear that your laptop is even more troublesome than mine
If USB devices are populated by a thread other than the "main" thread, you cannot, in general, determine their arrival time; it's
independent of the arrival time of devices on the "main" thread. (Disclaimer: Other than that it's
not really independent. The complexity of thread scheduling and the state of the system should make it
effectively independent, or at
least unpredictable.)
This would also show that installing mass storage drivers helps, but is not a panacea: there is no guarantee that it will make everything work !
Helps what? It's possible that
IASTOR purposefully stalls things "until at least one storage controller (of any kind) is found." Who knows? All I'm confident of is that mass storage drivers unrelated to USB are not
required in order to boot from USB.
"IASTOR guarantees a successful USB boot" != "IASTOR is required for a successful USB boot"
"WAITBT guarantees a successful USB boot" != "WAITBT is required for a successful USB boot"