195 replies to this topic

[Sha0]

But then you mentioned it is possible to boot without any disk whatsoever...
...
So how can it work at all, without any fixed disk ?

I wasn't talking about booting, I was talking about IoGetBootDiskInformation(). I'm sorry to confuse, but was honestly correcting an earlier statement regarding that function. Please remember the cause of STOP 0x7B (same post).

...could you post a compiled version of this modified driver, together with the required registry entries ?

Ok. Attached is version 0.0.0.4, with source code. You just need a Services entry for it. I also recommend using the /SOS switch in BOOT.INI, so you can see messages.

--- Attachment removed due to newer version. 29 downloads at time of removal. ---

[Doodoo]

Ok. Attached is version 0.0.0.4, with source code. You just need a Services entry for it. I also recommend using the /SOS switch in BOOT.INI, so you can see messages.

Brilliant !!
That should be an extremely simple yet very useful test to try for anyone who's having the infamous BSOD 7B....

[cdob]

Attached is version 0.0.0.4
so you can see messages.

Thanks. Booting does work, no 7B.

At VMware, PLoP, USB flash and no chipset storage controller

Disk signature(s) not provided!
Failed 10 times.

@all
What's the experience at real hardware?

[dara]

Brilliant !!
That should be an extremely simple yet very useful test to try for anyone who's having the infamous BSOD 7B....

Hi Doodoo

do you have any chance to update your instructions in post1 with the waitbt.sys how to install it

regards
dara

[Doodoo]

What's the experience at real hardware?

I haven't had a chance to try it yet, but your report suggests it is indeed trying to identify the boot disk signature.... But it's not clear to me, 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).

do you have any chance to update your instructions in post1 with the waitbt.sys how to install it

I don't really plan to update anything in the first post... This is not meant to be a tutorial, but I appreciate it might be beneficial to point to a few key posts in the thread... I'll think about it.
As far as installing waitbt.sys is concerned, it couldn't be easier. Just copy waitbt.sys in system32/drivers, then merge the services entry in the registry, that's it !!!

If you can't boot at all your XP, then you'll have to add the registry entry offline, but it's hardly more difficult: from an external OS, open regedit, do "load hive", point to windows/system32/config/system in your offline XP, then merge the registry entry (modify it to point to the loaded hive instead of SYSTEM), eventually do "unload hive" and you're done !

[Doodoo]

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).

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 ?

There is one detail I don't understand, though:

At VMware, PLoP, USB flash and no chipset storage controller

Disk signature(s) not provided!
Failed 10 times.

This seems to suggest that NTDTECT.COM didn't pass any signature to NTLDR, because it couldn't detect any HDD. And for a good reason: there is no storage controller.
Cdob, could you confirm with the debug build of NTDETECT.COM that it doesn't consider the USB flash drive as an HDD ?
But then how is the arc path resolved ? How is it possible to boot successfully in this case ? At least it seems that waiting 10 seconds was a good thing to make sure that WinVBlock backing disk was available

[Doodoo]

Shao, just another (quite) technical question. I was looking at Microsoft documentation on IoGetBootDiskInformation and I noticed the following:

IoGetBootDiskInformation can be called only by a boot driver. This driver should call IoGetBootDiskInformation in a Reinitialize callback routine that the driver registers by calling the IoRegisterBootDriverReinitialization routine.

where the Reinitiliaze description says:

The Reinitialize routine continues driver and device initialization after the driver's DriverEntry routine returns.

I don't quite understand why Microsoft insist that IoGetBootDiskInformation be called in a Reinitialize callback rather than directly in the DriverEntry routine. 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 ?)

[Sha0]

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 ?

Confirmed above.

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.

[cdob]

confirm with the debug build of NTDETECT.COM

http://www.microsoft...19-6fcc821fb5fc <POSready2009_CD.iso>\Utilities\USB\usbntd.chk

Result one message

Enumerating Interrupt 13 disk found on this system:
DriceSelect-MaxCylinders-SectorsPerTrack-MaxHeads-NumvberDrives
0080h-0-0-63-254

DescriptionVerifying Bootable Devices

My suspicion would be that your USB hub is not installed, either.

USBhub is loaded as System Bus Extender, waitbt as Base.

If it fails, you have 10 seconds to see the output and then you'll likely get a STOP 0x7B.

Or does boot at given example.
Waiting helps to avoid 0x7b.

[Sha0]

USBhub is loaded as System Bus Extender, waitbt as Base.

Yes but I meant the device. The driver's DriverEntry is invoked in your case, but I was suggesting that its AddDevice isn't; that a USB hub device isn't available, possibly as a result of a parent device not being installed/driven.

[Doodoo]

Or does boot at given example.

This is what really puzzles me... As Shao said, the message "Disk signature(s) not provided!" suggests that

• 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)

First possibility is ruled out by the output from NTDETECT.COM. Only last two possibilities are allowed. Possibly a refined version of the driver with more debug messages would allow to decide ?
Anyway, how is it possible to boot at all in this case ? How is the arc path resolved ?

Also, the following makes sense:

I was suggesting that (...) a USB hub device isn't available, possibly as a result of a parent device not being installed/driven.

but how can that be the case for as long as 10 seconds, but eventually you still manage to boot ?

[cdob]

How is the arc path resolved ?

multi(0)disk(0)rdisk(0)partition(1)

[HKEY_LOCAL_MACHINE\SYSTEM\Setup]
"SystemPartition"="\\Device\\Harddisk0\\DP(1)0-0+1"

Anyway, how is it possible to boot at all in this case ?

Drivers are active and devices are available.

Function IoGetBootDiskInformation seems to be optional, not required to boot.
ubdrvgd.sys calls IoRegisterBootDriverReinitialization.

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

[Doodoo]

[HKEY_LOCAL_MACHINE\SYSTEM\Setup]
"SystemPartition"="\\Device\\Harddisk0\\DP(1)0-0+1"

I have never come across this before... What is it for ? How does it work ?

Function IoGetBootDiskInformation seems to be optional, not required to boot.

Yes your test is the perfect example... No signature match, and yet you can boot !!!

ubdrvgd.sys calls IoRegisterBootDriverReinitialization.

How do you know USBoot DriveGuard calls this function ? Can we know all the functions it calls and have a guess of what it does ? (in theory it's only meant to be a filter driver, i.e. make removable disks appear as fixed; in my case I strongly suspect it only changed the timing of things so that my BSOD 7B disappeared. At first I thought it was doing more than that.... in hindsight it was probably doing nothing but wait...)

[Icecube]

How do you know USBoot DriveGuard calls this function ? Can we know all the functions it calls and have a guess of what it does ? (in theory it's only meant to be a filter driver, i.e. make removable disks appear as fixed; in my case I strongly suspect it only changed the timing of things so that my BSOD 7B disappeared. At first I thought it was doing more than that.... in hindsight it was probably doing nothing but wait...)

Download Explorer Suite:

Created by Daniel Pistelli, a freeware suite of tools including a PE editor called CFF Explorer and a process viewer. The PE editor has full support for PE32/64. Special fields description and modification (.NET supported), utilities, rebuilder, hex editor, import adder, signature scanner, signature manager, extension support, scripting, disassembler, dependency walker etc. First PE editor with support for .NET internal structures. Resource Editor (Windows Vista icons supported) capable of handling .NET manifest resources. The suite is available for x86, x64 and Itanium.

- Explorer Suite (Multi-Platform Version, Recommended)
- Explorer Suite (x86 Version)
- CFF Explorer (x86 Version, stand-alone, Zip Archive)

- CFF Explorer Extensions Repository

The CFF Explorer was designed to make PE editing as easy as possible, but without losing sight on the portable executable's internal structure. This application includes a series of tools which might help not only reverse engineers but also programmers. It offers a multi-file environment and a switchable interface.

http://www.ntcore.com/exsuite.php

- Load the driver in CFF Explorer
- Import Directory ==> ntoskrnl.exe ==> find all function calls the driver makes to ntoskrnl.exe

[Doodoo]

Download Explorer Suite:
- Load the driver in CFF Explorer
- Import Directory ==> ntoskrnl.exe ==> find all function calls the driver makes to ntoskrnl.exe

Many thanks !! That's quite a nifty tool !!!

[Doodoo]

After some time to digest all this information, I have a few more questions:

This bit seems to suggest that WaitBt introduces a delay before disk.sys is loaded:

However, WaitBt ought to help to ensure that at least the uninitialized USB disk is available by the time it's DISK.SYS' turn...

but this bit explicitly says the contrary:

The WaitBt Registry offering causes this driver to be invoked after DISK.SYS gets its turn. That should be good enough.

As usual, I appreciate that both statements could be perfectly correct, and that there could be no contradiction whatsoever... Only my misunderstanding of the details leads me to think there is !

Also, I've been thinking about this:

Because re-initialize routines are guaranteed to happen after DISK.SYS gets a turn, which means that disks (if any) should be available.(...)

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, to avoid the situation where the physical disk is not available when the virtual one is required.

At last I've been trying to put this statement:

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,

into perspective with Wimb's observations (on Win7, so things might be a bit different, but still....):

http://reboot.pro/98...post__p__126761

Previously I had only BSOD 7B for booting Win7 VHD as WinVBlock FILEDISK,
but using waitbt then these problems completely disappeared.

Can we draw any conclusions from the fact, that in spite of expectations, WaitBt does help when booting from an image file on a USB disk ?
Perhaps something is not quite happening in the order we think it is ? Maybe this could give us a clue:

http://reboot.pro/98...post__p__126715

When I add waibt Service then the Windows 7 Logo apears and stays 20 seconds on screen before continuing and then boots OK.

In fact, I have also carried out my own experiments and have found the following very surprising results:

• I added waitbt.sys to a Win7 installed in a VHD. This VHD (on internal HDD, not on USB) is then loaded with bootmgr and Win7 native VHD driver, using the /sos option. Surprisingly, waitbt.sys told me "Disk signature(s) not provided!" and waited 20 seconds....
• So I tried the same with a "normal" Win7, i.e. flat files on HDD (not in a VHD container). Same result: "Disk signature(s) not provided!" and 20 seconds wait....

Is something different on Win7 compared to XP that would explain this behaviour ?
Can we make any clever use of Win7 native VHD driver together with a refined version of waitbt.sys to get a more detailed understanding of the timing ?

[Sha0]

This bit seems to suggest that WaitBt introduces a delay before disk.sys is loaded...
...
but this bit explicitly says the contrary...
...

Sorry to confuse. DISK.SYS has at least (possibly no more than) two turns.

strings c:\windows\system32\drivers\disk.sys | findstr Reinit

So (as a potential example):

• WinVBlock provides boot disk
  
• USB hub; no children yet
  
• Disk.sys probes WinVBlock MBR. WinVBlock has no backing disk so fails
  
• Disk.sys registers for re-initialization
  
• WaitBt waits for the boot disk, but none is found. In the meanwhile, USB hub provides USB disk
  
• Disk.sys re-initializes and drives the USB disk
  
• All driver re-initialization complete. Time to open the boot ARC name. BSOD 0x7B

Is it conceivable that WinVBlock's backing-disk-search could be part of a re-initialize routine ?

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. 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).

In other words, the idea would be to wait that all physical disks are available, before any virtual disk is provided, to avoid the situation where the physical disk is not available when the virtual one is required.

Again, it's too late for certain scenarios.

Can we draw any conclusions from the fact, that in spite of expectations, WaitBt does help when booting from an image file on a USB disk ?

I don't know much about Windows 7's processes.

I added waitbt.sys to a Win7...using the /sos option. Surprisingly, waitbt.sys told me "Disk signature(s) not provided!" and waited 20 seconds...

I do not know if IoGetBootDiskInformation behaviour has changed for Windows 7. Tt might very well have, as the mode WaitBt uses expects MBR disks whereas Windows 7 supports GPT disks (which usually do have an MBR, but the behaviour could still be different than XP).

Can we make any clever use of Win7 native VHD driver together with a refined version of waitbt.sys to get a more detailed understanding of the timing ?

Timing is everything. If there was time, I'd use WinDbg to step through the boot process and further document the timing of the relevant events. Each debugging session requires a VM with for a particular scenario. I don't really have the resources to keep all of these scenarios at-the-ready, so it costs time to swap between environments (such as Recovery Console, XP via image file, XP via USB disk, etc.). Sorry. Maybe later.

[Doodoo]

Sorry to confuse.

Please don't apologize... I'm happy to be confused a few times when I learn a lot along the way!

If the order goes (...) then we get a STOP 0x7B.
If the order goes (...) then we are ok.

This is crystal clear, make perfect sense.

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. It's only upon the MBR probe (when disk.sys is examining partitions) that the backing disk is required.

In this case is it conceivable that WinVBlock be given two opportunities to find the backing disk ? First time early, second time late in the re-initialize routine?

E.g. your initial scenario which ends up as BSOD 7B could go as :

• WinVBlock provides boot disk
• USB hub; no children yet
• Disk.sys probes WinVBlock MBR. WinVBlock has no backing disk so fails
• Disk.sys registers for re-initialization
• WaitBt waits for the boot disk, but none is found. In the meanwhile, USB hub provides USB disk
• Disk.sys re-initializes and drives the USB disk
• WinVBlock looks for a backing disk again (if it hasn't already found it). Now finds it
• All driver re-initialization complete. Time to open the boot ARC name. OK !

Possibly, WinVBlock could be a bit more clever, e.g. take a first snapshot of the USB hub children when it's loaded. Then take another snapshot of the USB hub children in the re-initialize routine. If any difference is found it might help searching for the backing disk again otherwise it's useless.
Am I talking complete non-sense ?

[Sha0]

In this case is it conceivable that WinVBlock be given two opportunities to find the backing disk ? First time early, second time late in the re-initialize routine?

No.

WinVBlock doesn't look for the backing disk during DriverEntry nor would it during a Reinitialize routine. That's because those are "driver code paths" and their code ought to be universal to the driver, not to a particular device (such as a disk).

A WinVBlock disk looks for its backing disk when a SCSI read/write request comes in. This is a "device code path" and would be performed "by the disk device." For example, 8 GRUB4DOS sector-mapped disks could each want to find their backing disk. Each will get their turn. This strategy means that the backing disk is searched for as late as possible... If someone wants to read data from our disk, at that point we have little choice but to go looking for the data on the backing disk, else error.

We need to report our devices as soon as possible because Windows is trying to establish boot devices.

...take a first snapshot of the USB hub children when it's loaded. Then take another snapshot of the USB hub children in the re-initialize routine.

Absolutely not. WinVBlock ought not to know anything about USB hubs. Suppose there are 100 types of "hub," including USB (FireWire would be just one additional example). It'd be silly to inspect each of these types and we'd need to add code any time someone invents a new type. Even more extreme than that is: Every device is potentially a "bus" device and can be the parent of a disk device! If we follow your suggestion through, we are essentially re-implementing the entire Windows PnP system, complete with "knowing" what makes a "disk" a disk. That's currently the purpose of the CDDB and .INF files. No way.

The Right Way would appear to be: Have a helper driver which blocks the query on a USB hub from completing until its children are found. Since Microsoft obviously has their source code, they were able to implement this blocking right into their modified USB hub driver. Ultimately, the issue is specific to MS' USB hub driver, so it doesn't seem right to work around it in WinVBlock...

That doesn't mean that there aren't general improvements that can be made. However, suppose we come up with a strategy such as, "ensure WinVBlock disks are initialized after any other kind of disk." What happens when someone else reproduces the same strategy?

[Doodoo]

With the latest version of WaitBt, I've been inspired to try a couple more experiments. Shao, as you pointed out, WaitBt will not help booting from an IMG from USB with WinVBlock, it will only help booting from flat files.
Nevertheless, I have on purpose, tried to boot on IMG from USB, because the messages produced by WaitBt, and more importantly, the order in which they appear, is incredibly useful to understand what is going on.

First experiment: I'm booting XP from IMG on USB, no iastor.sys is installed
Here is how it goes:  P1010262.JPG   223.2K   22 downloads  P1010263.JPG   259.23K   25 downloads  P1010264.JPG   333.01K   26 downloads

As expected, WaitBt doesn't help for the reasons explained earlier:
http://reboot.pro/14...post__p__125950

If you are booting a filed-backed disk from an image file with GRUB4DOS, the boot and system disk signatures will be from the image file and the USB disk doesn't enter into ARC name relevance at all. After realizing that this is really the nature of your original challenge, I believe the simple answer is that the USB disk is not available by the time WinVBlock goes looking for it.

http://reboot.pro/14...post__p__126054

Well it just occurred to me that WaitBt won't help here because it's not its fault that the boot disk is not available, it's WinVBlock's. If the USB disk wasn't available when WinVBlock went looking for it, then the disk becomes a "dud".

Second experiment: I'm booting XP from IMG on USB, with a CDDB entry for iastor.sys is in the registry, but iastor.sys has been replaced with wait10.sys [Shao, would you mind attaching this driver in the original post again ? To me that is a different driver from WaitBt, and is useful in its own right - A new build which waits without a CDDB entry might be useful too, if I dare ask]
Here is now what happens:  P1010272.JPG   254.44K   27 downloads  P1010267.JPG   218.87K   7 downloads
As already reported in this post, the system can now boot. What you don't see on the screen capture is that there is initially a 10 second wait before WaitBt reports that the first disk has arrived.

Third experiment: I'm booting XP from IMG on USB, no iastor.sys is installed, but USBoot DriveGuard has been installed.
Now the following happens:  P1010269.JPG   210.11K   22 downloads  P1010267.JPG   218.87K   7 downloads
Again, as already reported in my very first post, the system can also boot.

The interesting thing however, is that although DriveGuard is loaded fairly late ("Group"="PNP Filter"), it somehow has the same effect as Wait10 which is loaded fairly early ("Group"="SCSI Miniport")
This looks fairly interesting to me, and might provide some insight on what DriveGuard really does:

• does it only wait ? (because USBoot is not activated properly, see message "initialisation failed" on screen capture). I've just realised it might be interesting to run my second experiment again, where iastor.sys (a.k.a. wait10.sys) is set in "Group"="PNP Filter".
• does it actually do more than that ? I am now tempted to think so.... But then what does it do that WaitBt doesn 't, and which is critical ? Has it somehow any means to make sure that WinVBlock backing disk is available when it goes looking for it ? Or does it happen to work by chance, because of a "lucky" timing of events ?

[maanu]

we should not forget the FUNDAMENTAL purpose of DriveGuard , which is , to make EVERY attached removeable drive (flash drive) as FIXED disk . but i am not sure how it can effect 0x007B , may be it does not wait for the core windows usb drivers ,and uses its OWN driver to initialize the usb drive ?

as i reported earlier , i have been using the properly installed DriveGuard on my img file , and the img boots ok on completely new hardware from usb . and my img have seen at least 30+ different computers ,notebooks etc with success.

[Sha0]

First experiment: I'm booting XP from IMG on USB, no iastor.sys is installed
Here is how it goes...

This one bothers me. The USB disk should show up before WaitBt gives up, not immediately afterwards. Perhaps there is a WaitBt bug where the delay isn't actually giving much of a chance for other threads to execute.

Shao, would you mind attaching this driver in the original post again ? To me that is a different driver from WaitBt, and is useful in its own right - A new build which waits without a CDDB entry might be useful too, if I dare ask

Well it seems that you still have one, but I'd rather that it wasn't used. Whatever you wish to use it for, I think that should be taken care of by WaitBt. If that means giving WaitBt the previous Wait10 behaviour as a user option, so be it.

The interesting thing however, is that although DriveGuard is loaded fairly late ("Group"="PNP Filter"),

Maybe it filters the request "tell me your children" on the USB hub and prevents the request from completing until there are some children. That seems like something a "PNP Filter" might do. Or maybe as maanu says, it only makes "removable" into "fixed." Maybe the author could tell us. Maybe the author would rather make some money and rather that we not probe at its workings.

it somehow has the same effect as Wait10 which is loaded fairly early ("Group"="SCSI Miniport")

"Same effect" being what, that the USB disk arrives before the WinVBlock disk? Maybe printing text to the LightBlueScreenOfLife is enough of a delay.

...But then what does it do that WaitBt doesn 't, and which is critical ? Has it somehow any means to make sure that WinVBlock backing disk is available when it goes looking for it ? Or does it happen to work by chance, because of a "lucky" timing of events ?[/list]

Could it be that it looks like this?:

• USB driver initialized
  
• No USB disks
  
• Wait10 delays 10 seconds. In another thread, USB disks are found
  
• WinVBlock is initialized
  
• Disk.sys is initialized
  
  • USB disk is initialized
    
  • WinVBlock disk is initialized. Backing disk is found
• Reinitialize routines are run (as WaitBt uses)

Wait10 delays things earlier than WaitBt, that's for certain. What order did you have it at?

[Doodoo]

we should not forget the FUNDAMENTAL purpose of DriveGuard , which is , to make EVERY attached removeable drive (flash drive) as FIXED disk .

I totally agree... but for some reason, this feature (making removeable devices seen as fixed) may have important side effects, although I don't quite understand why. See my very first post:

At last, it is worth mentioning that USBoot also doesn't require that the XP IMG has prior knowledge of the target USB device. Even worse, it explicitly deletes (see step IX) any entries for non-present USB devices (such as previsouly encountered USB sticks). This also seem like a very desirable feature, as the IMG can be copied from device to device without worrying at all. I don't quite understand why, but it is explained in this tutorial that installing dummydisk.sys would allow it:

Particularly, "dummydisk.sys" has been able to filter ON-THE-FLY the install of all NEW (so never previously recognized) and pre-partitioned USB Flash Drives without the need to PRE-RECOGNIZE them

Can someone try to explain why ? dummydisk.sys is only meant to make removeable devices seen as fixed. How does it play a role in pre-recognising or not the devices ? Unfortunately I have tried installing dummydisk.sys.... but it always gives me a BSOD (I mean on each and every single computer) when installed in an IMG...

but i am not sure how it can effect 0x007B

Neither am I.... However (when USBoot is not properly activated) it seems that it is not the ultimate solution as it does not always work for booting an IMG file. My current guesses as to why it can affect BSODs 7B are:

• pure luck, because it affects timing in a favourable way
• some non-advertised effect (other than making removable devices seen as fixed)

as i reported earlier , i have been using the properly installed DriveGuard on my img file , and the img boots ok on completely new hardware from usb . and my img have seen at least 30+ different computers ,notebooks etc with success.

Very interesting indeed.... So relevant question is: does making removable drives appear as fixed have important side effects, as far as timing and as far as booting from IMG is concerned ?
Out of curiosity, do you get BSOD 7B with the same IMG, when DriveGuard is NOT properly activated ? In other words, does "USBoot activation" has an obvious effect ?

[wimb]

The succes of what maanu reports should may be not attributed to DriveGuard,
but can be due to the learning process on 30 computers, so that all drivers smoothley load and can do their work.

[Doodoo]

This one bothers me. The USB disk should show up before WaitBt gives up, not immediately afterwards. Perhaps there is a WaitBt bug where the delay isn't actually giving much of a chance for other threads to execute.

Hmmm would that also be consitent with the behaviour I have seen when booting Win7 from VHD, in spite of the registry settings which suggests that the VHD driver is a boot driver ? But at the same time, Wimb's experiment show that the USB disk shows up sometime while WaitBt is waiting...

Well it seems that you still have one, but I'd rather that it wasn't used. Whatever you wish to use it for, I think that should be taken care of by WaitBt. If that means giving WaitBt the previous Wait10 behaviour as a user option, so be it.

Fair enough, I appreciate and respect that. Eventually everything should be taken care of by WaitBt, but for now, I find that Wait10 is useful, to experiment, and introduce a delay at any point during the boot process.

Maybe it filters the request "tell me your children" on the USB hub and prevents the request from completing until there are some children. That seems like something a "PNP Filter" might do.

Is this something you could guess, by looking at which functions DriveGuard calls ?

Or maybe as maanu says, it only makes "removable" into "fixed." Maybe the author could tell us. Maybe the author would rather make some money and rather that we not probe at its workings.

Wonko seems to have been in contact with him, and says the author is a nice chap. He might effectively provide some useful information if asked ?

"Same effect" being what, that the USB disk arrives before the WinVBlock disk? Maybe printing text to the LightBlueScreenOfLife is enough of a delay.

Yes same effect is a very relative concept. I only meant the sequence of events (as reported by WaitBt) is the same, and that I can eventually boot.

Could it be that it looks like this? (...)
Wait10 delays things earlier than WaitBt, that's for certain. What order did you have it at?

I have replaced iastor.sys with wait10.sys so I suppose the order you have suggested is correct (wait10 is in group "SCSI Miniport)