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!