At VMware, PLoP, USB flash and no chipset storage controller
If no disk signature is being provided by the IoGetBootDiskInformation() function, then at least one of:
- You don't have any disks
- None of the disks' signatures match those that NTLDR passed
- NTLDR didn't pass any disk signatures (highly unlikely)
My suspicion would be that your USB hub is not installed, either. This could be due to a lack of a CDDB entry for the parent of the hub. Perhaps a future version of WaitBt could list the device tree; it'd be messy, though. Perhaps it could verify that there are no disks in order to distinguish between the first and second possibilities given in the list above.
...does it loop forever ? Or it gives up after 10 tries and eventually finishes to boot till desktop ?
I thought this version wouldn't do anything but wait 10 seconds (i.e. i thought it would be a tweaked version of wait10.sys which doesn't require a CDDB entry).
This version doesn't require a CDDB entry. It tries to find the boot disk 10 times, with 1 second in between each attempt. If it fails, you have 10 seconds to see the output and then you'll likely get a STOP 0x7B.
Having had a look at the source code I understand this version does more than just wait. I believe this version tries to find a disk whose MBR signature matches what was passed by NTLDR (original waitbt.sys behaviour), but it tries at most 10 times waiting 1 second between tries. Then it gives up, and doesn't loop forever. Shao, could you confirm ?
This seems to suggest that NTDTECT.COM didn't pass any signature to NTLDR, because it couldn't detect any HDD.
I doubt that this is the case. I would guess that Plop's USB boot INT 0x13 hook does HDD emulation, so the disk signature should be available.
At least it seems that waiting 10 seconds was a good thing to make sure that WinVBlock backing disk was available
I doubt that this is the case. I believe that WinVBlock will look for the backing disk while it is disk.sys
' turn for its devices to be initialized. This is because the MBR will be read from each disk as each disk is initialized. The first read (or write) is when WinVBlock looks for the backing disk. If the USB disk is initialized after the WinVBlock virtual disk, it won't be available as the backing disk. However, WaitBt ought to help to ensure that at least the uninitialized
USB disk is available by the time it's DISK.SYS' turn... It's just "who goes first?" and that might be alphabetical order or first-come, first-served, or who knows...
I don't quite understand why Microsoft insist that IoGetBootDiskInformation be called in a Reinitialize callback rather than directly in the DriverEntry routine.
Because re-initialize routines are guaranteed to happen after DISK.SYS gets a turn, which means that disks (if any) should be available.
The article you mention along with some testing is responsible for my earlier correction regarding the function's behaviour.
But the fact that I don't understand why isn't really important...I just noticed that your driver doesn't follow this design rule, is it important at all ? Can it help solve problems (e.g. avoid getting hung in a forever loop ?)
The WaitBt Registry offering causes this driver to be invoked after DISK.SYS gets its turn. That should be good enough. To be honest, I forgot to use a re-initialize routine and that ought to be in a future version, certainly.
Just a reminder that WaitBt can only help with USB booting at this time. It won't help with booting from an image file on a USB disk using WinVBlock, since that likely requires changes to WinVBlock's backing-disk-search.