Jump to content











Photo
- - - - -

WaitBt for USB Booting


  • Please log in to reply
132 replies to this topic

#26 Doodoo

Doodoo

    Frequent Member

  • Advanced user
  • 344 posts

Posted 06 May 2011 - 12:45 PM

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.

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 ?
I am tempted to think in this case it is just a matter of luck, because once again, WaitBt cannot help in this scenario (only the messages are useful, but WaitBt cannot alter timing to make things right if they are wrong)
Again, this looks remarkably similar to what happened to me when I tried booting from an IMG file on the fussy Dell laptop:

http://reboot.pro/14...post__p__125335

Now, with my original IMG (tweaked with Wimb's tools) I get a BSOD 7B on the Dell laptop. Just add that to the registry (and only that)


[HKEY_LOCAL_MACHINE\systemdst\ControlSet001\Control\CriticalDeviceDatabase\PCI#VEN_8086&DEV_282A]

"ClassGUID"="{4D36E97B-E325-11CE-BFC1-08002BE10318}"

"Service"="iaStor"

and suddenly it works great !!

Please could you try three simple things on your Dual Core laptop, without booting on the Quad Core computer first ?
1. Try DriveGuard as explained above.
2. Install iastor.sys, i.e. make sure there is a CDDB entry for your controller.
3. Install wait10.sys (attached). - Just rename it iastor.sys and replace the file in #2

NB: these 3 experiments are independent: try 1 alone or 2 alone, or 3 alone (not 1 then 1+2).

Attached Files



#27 wimb

wimb

    Gold Member

  • Developer
  • 2281 posts
  •  
    Netherlands

Posted 06 May 2011 - 04:07 PM

Please could you try three simple things on your Dual Core laptop, without booting on the Quad Core computer first ?
1. Try DriveGuard as explained above.
2. Install iastor.sys, i.e. make sure there is a CDDB entry for your controller.
3. Install wait10.sys (attached). - Just rename it iastor.sys and replace the file in #2

The results are:

1. DriveGuard - BSOD 7B
2. iaStor - BSOD 7B
3. wait10.sys - Boot from USB OK - laptop harddisk remains invisible in My Computer

timeout caused by wait10.sys is working good.

:cheers:

#28 Doodoo

Doodoo

    Frequent Member

  • Advanced user
  • 344 posts

Posted 06 May 2011 - 04:18 PM

The results are (...)

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 :cheers:

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 !
Also the good news is that DriveGuard doesn't seem to be the ultimate solution.... so it's probably not worth spending too much time figuring out what it does.

timeout caused by wait10.sys is working good.

That is very good news !! :cheers:
I suppose that will also provide very useful feedback to Shao, so that he can come up with improvements of WinVBlock and/or WaitBt !!

#29 Sha0

Sha0

    WinVBlock Dev

  • Developer
  • 1682 posts
  • Location:reboot.pro Forums
  • Interests:Booting
  •  
    Canada

Posted 07 May 2011 - 08:06 AM

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. :unsure:

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 :ermm:

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. :smiling9:

"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"
  • karyonix likes this

#30 wimb

wimb

    Gold Member

  • Developer
  • 2281 posts
  •  
    Netherlands

Posted 07 May 2011 - 09:13 AM

It's possible that IASTOR purposefully stalls things "until at least one storage controller (of any kind) is found."


I have indeed the feeling that IASTOR stalls things until it is satisfied.
The succes of the learning process on the Quad Core gives me the feeling that
IASTOR is then more easily satisfied when booting on the Dual Core so that USBSTOR can do its work.

#31 wimb

wimb

    Gold Member

  • Developer
  • 2281 posts
  •  
    Netherlands

Posted 07 May 2011 - 11:21 AM

The timeout of wait10.sys is occurring before the waitbt messages appear about disk, partition and volume arrived.
It seems to me that such timeout at that moment is useful.

It might be a good idea to built-in the functionality of wait10.sys in the waitbt32.sys driver,
so that we combine both effects which have proven to work.

:smiling9:

#32 Doodoo

Doodoo

    Frequent Member

  • Advanced user
  • 344 posts

Posted 07 May 2011 - 12:08 PM

1. DriveGuard - BSOD 7B

Wimb, inspired by the reported success of maanu, could you try properly activating USBoot, see if that makes a difference ?
The tricky bit is that USBoot can only be enabled in a live system, so you have to boot your IMG without disturbing the experiment... E.g. booting on your Quad Core laptop to activate USBoot would make the experiment useless, because we know you will always boot on the Dual Core after that...
Perhaps you can boot the IMG on the Dual Core laptop, but from HDD (make sure you still get a BSOD when booting from USB after that) ? Then activate USBoot (it is a bit of a pain to be honnest, you have to create an account on usboot.org, then use the challenge code), and skip all options in Phase1. At last install DriveGuard and try booting again !

#33 Doodoo

Doodoo

    Frequent Member

  • Advanced user
  • 344 posts

Posted 07 May 2011 - 07:12 PM

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.

(...)

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.

Yes that sounds very plausible to me.
To take this kind of problem out of the equation, would it be sensible to e.g. install XP into an IMG directly on the troublesome laptop and try experimenting again on USB ? Presumably this would make sure that when the IMG is moved to USB, all devices along the path to the USB HDD are properly installed ?

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. :loleverybody:

I'm sorry if I didn't use the right words... iastor doesn't help, and we all agree it is not even required at all. It just happens to change timing, and probably by a matter of luck, avoids BSOD 7B.

"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"

Absolutely.

#34 wimb

wimb

    Gold Member

  • Developer
  • 2281 posts
  •  
    Netherlands

Posted 08 May 2011 - 05:05 AM

I'm sorry if I didn't use the right words... iastor doesn't help, and we all agree it is not even required at all. It just happens to change timing, and probably by a matter of luck, avoids BSOD 7B.

On first use of iaStor driver then things are differently enumerated in registry than on reboot.
The timing for first use of iaStor can be quite different and severely have influence on the boot process.

I know that iaStor by itself is not needed for booting from USB,
but I think that properly installed iaStor driver helps to make booting easier and that helps to find USBSTOR entries.

I think we just need some extra wait time built-in before the messages of WaitBt appear.

:loleverybody:

#35 Sha0

Sha0

    WinVBlock Dev

  • Developer
  • 1682 posts
  • Location:reboot.pro Forums
  • Interests:Booting
  •  
    Canada

Posted 04 October 2012 - 09:53 AM

Before making a new WaitBt version, is anyone able to reproduce the scenario? What I'm looking for is:
  • Someone to keep a snap-shot of an image that BlueScreens ("problem" snap-shot; never modify!)
  • When a copy of the problem snap-shot can be "cured" by iaStor or USBoot or any other method
  • Then we can try with another copy of the original problem image, but with WaitBt, until we get WaitBt to "cure" the image
  • Extra emphasis: The original problem image should never be modified, otherwise the problem space cannot be properly bisected
Is anyone able to assist with these?

#36 wimb

wimb

    Gold Member

  • Developer
  • 2281 posts
  •  
    Netherlands

Posted 04 October 2012 - 10:32 AM

Yes I can do similar experiment as described here in post #816
http://reboot.pro/98...800#entry160064

and then use for other WaitBt experiments a copy of the same original XP VHD

:cheers:

#37 wimb

wimb

    Gold Member

  • Developer
  • 2281 posts
  •  
    Netherlands

Posted 05 October 2012 - 10:18 AM

Yes I can do similar experiment as described here in post #816
http://reboot.pro/98...800#entry160064

and then use for other WaitBt experiments a copy of the same original XP VHD

:cheers:


I repeated the described experiment and got the same result that DriveGuard LowerFilters driver prevents BSOD 7B
http://reboot.pro/98...800#entry160006

So I have a good XP-SH VHD available for testing if New WaitBt driver can prevent BSOD 7B in the given case.

- Installed XP in VHD on AMD machine (No DriverPacks added to WINDOWS so that iaStor is not available)
- Copy of VHD to USB followed by USB_XP_Fix.exe having iaStor fix Unchecked
- Boot with VHD on USB connected to Intel Dual core laptop - After Reboot got BSOD 7B

- Copy of Original VHD to USB followed by USB_XP_Fix.exe having iaStor fix Unchecked
- Boot with VHD on AMD machine and Install of DriveGuard - Reboot to see Driveguard message is present
- Boot with VHD on USB connected to Intel Dual core laptop - Boot and Reboot OK

Confirms that DriveGuard as Lower filter driver is working to prevent BSOD 7B
In all cases the laptop internal harddisk is invisible as expected since it requires iaStor which is not available.


The USB_XP_Fix Settings used for XP_SH.vhd

Attached File  USB_XP_FixSH.png   23.03KB   10 downloads

:cheers:

#38 Sha0

Sha0

    WinVBlock Dev

  • Developer
  • 1682 posts
  • Location:reboot.pro Forums
  • Interests:Booting
  •  
    Canada

Posted 05 October 2012 - 04:22 PM

So I have a good XP-SH VHD available for testing if New WaitBt driver can prevent BSOD 7B in the given case.

Before re-writing WaitBt as a full PnP driver, could you please test version 0.0.0.6?

Please make this one a LowerFilters driver for disk devices.

---EDIT---

With something like:

Windows Registry Editor Version 5.00



[HKEY_LOCAL_MACHINE\offline_system_hive\ControlSet001\Control\Class\{4D36E967-E325-11CE-BFC1-08002BE10318}]

"LowerFilters"=hex(7):77,00,61,00,69,00,74,00,62,00,74,00,00,00,00,00



[HKEY_LOCAL_MACHINE\offline_system_hive\ControlSet001\Services\waitbt]

"Start"=dword:00000000

"Group"="SCSI Miniport"

"Type"=dword:00000001







#39 wimb

wimb

    Gold Member

  • Developer
  • 2281 posts
  •  
    Netherlands

Posted 06 October 2012 - 07:00 AM

Adding waitbt.sys v6 + registry offline and booting with XP-SH VHD on USB resulted even on AMD machine in BSOD 7B

Then I decided first to boot with XP-SH VHD on USB connected to AMD and
then after booting to add waitbt.sys v6 + registry online as given below


Windows Registry Editor Version 5.00



[HKEY_LOCAL_MACHINESYSTEMControlSet001ControlClass{4D36E967-E325-11CE-BFC1-08002BE10318}]

"LowerFilters"=hex(7):77,00,61,00,69,00,74,00,62,00,74,00,00,00,00,00



[HKEY_LOCAL_MACHINESYSTEMControlSet001Serviceswaitbt]

"Type"=dword:00000001

"Start"=dword:00000000

"ImagePath"=hex(2):73,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,00,64,00,

72,00,69,00,76,00,65,00,72,00,73,00,5c,00,77,00,61,00,69,00,74,00,62,00,74,

00,2e,00,73,00,79,00,73,00,00,00

"Group"="SCSI Miniport"


Then Reboot is OK and waitbt is Installed as LowerFilters and Enumerates GenDisk hardware as shown below

Attached File  waitbt6.png   107.03KB   7 downloads

Then connected to Intel Dual Core laptop and booting but Reboot is giving BSOD 7B whereas DriveGuard driver was booting OK in that case.

Summarising:
waitbt.sys v6 can result easily in BSOD 7B and certainly does NOT prevent BSOD 7B

:cheers:

#40 Sha0

Sha0

    WinVBlock Dev

  • Developer
  • 1682 posts
  • Location:reboot.pro Forums
  • Interests:Booting
  •  
    Canada

Posted 06 October 2012 - 07:40 AM

Adding waitbt.sys v6 + registry offline and booting with XP-SH VHD on USB resulted even on AMD machine in BSOD 7B
...

Did you even see any WaitBt messages before the blue screen? (With the /SOS switch in BOOT.INI) If not, then something was missing... Either the file or Registry was not quite right. At the very least, it should still carry on the old behaviour. Please let me know, and thanks for testing! :)

#41 wimb

wimb

    Gold Member

  • Developer
  • 2281 posts
  •  
    Netherlands

Posted 06 October 2012 - 08:56 AM

Did you even see any WaitBt messages before the blue screen? (With the /SOS switch in BOOT.INI) If not, then something was missing... Either the file or Registry was not quite right. At the very least, it should still carry on the old behaviour. Please let me know, and thanks for testing! :)

Indeed something was missing (the waitbt.sys driver)
I made a mistake and forgot that the new v6 filename is waitbt.sys whereas USB_XP_Fix.exe wanted to copy waitbt32.sys
I repeated now on AMD machine and using /sos switch in boot.ini
Message waitbt: Alive occurs and booting is OK on AMD machine.

Then the Dual core laptop:
- first boot OK, but waitbt shows in Enum "INITSTARTFAILED"=dword:00000001 (may be for Internal HDD that requires iaStor which is not present)
- Other New Hardware found is Installed automatically in 3 minutes

Windows Registry Editor Version 5.00



[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\waitbt]

"Type"=dword:00000001

"Start"=dword:00000000

"ImagePath"=hex(2):73,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,00,64,00,\

72,00,69,00,76,00,65,00,72,00,73,00,5c,00,77,00,61,00,69,00,74,00,62,00,74,\

00,2e,00,73,00,79,00,73,00,00,00

"Group"="SCSI Miniport"



[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\waitbt\Enum]

"Count"=dword:00000003

"NextInstance"=dword:00000003

"0"="USBSTOR\\Disk&Ven_Samsung&Prod_S2_Portable&Rev_\\0000002CE09310500F4A&0"

"1"="WinVBlock\\FileHardDisk\\1&c0ac9c8&0&Hash_47344480"

"INITSTARTFAILED"=dword:00000001

"2"="USBSTOR\\Disk&Ven_Generic-&Prod_Multi-Card&Rev_1.00\\20071114173400000&0"




- Then on Reboot
waitbt: Alive > WinVBlock Arrived > some more msgs .... > disk signature not found (many msgs) > BSOD 7B

Normally on Reboot then DriveGuard driver would prevent BSOD 7B whereas waitbt v6 fails on that occasion.

:cheers:

Intel Dual Core laptop giving on Reboot BSOD 7B

Attached File  waitbt411.jpg   75.61KB   13 downloads = Attached File  waitbt414.jpg   68.84KB   16 downloads = Attached File  waitbt415.jpg   79.25KB   11 downloads

#42 wimb

wimb

    Gold Member

  • Developer
  • 2281 posts
  •  
    Netherlands

Posted 06 October 2012 - 09:27 AM

Some Screenshots of Intel Dual Core laptop are given above.

#43 wimb

wimb

    Gold Member

  • Developer
  • 2281 posts
  •  
    Netherlands

Posted 06 October 2012 - 10:33 AM

Attached File  waitbt431_Boot_OK.jpg   76.56KB   13 downloads = Attached File  waitbt434_Reboot_7B.jpg   68.77KB   14 downloads

1st Boot OK and = Reboot BSOD 7B

XP VHD (WinVBlock driver) located on Samsung Portable USB-harddisk
VHD signature = A74D A74D
USB signature = 0167 21AA

on Dual Core laptop
At first boot then disk arrived sequence Samsung USB > WinVBlock
At Reboot then disk arrived sequence WinVBlock > Samsung USB

In the last case the disk signature of the WinVBlock Boot disk is not provided and BSOD 7B occurs.

Could it be that the sequence of disk arrived is the origin of BSOD 7B ?

:cheers:

#44 Sha0

Sha0

    WinVBlock Dev

  • Developer
  • 1682 posts
  • Location:reboot.pro Forums
  • Interests:Booting
  •  
    Canada

Posted 06 October 2012 - 01:13 PM

...
Then the Dual core laptop:
- first boot OK,

Yay! Not so fast, we should celebrate! This tells us that the AddDevice pause is enough!

but waitbt shows in Enum "INITSTARTFAILED"=dword:00000001 (may be for Internal HDD that requires iaStor which is not present)

I'm not 100% sure what that's for.

- Other New Hardware found is Installed automatically in 3 minutes

When the other new hardware is installed, that includes the USB hardware. When that happens, the service order changes and the USB drivers go back to after WinVBlock. WaitBt isn't going to help with that, as WaitBt doesn't care about USB.

Keeping an eye on the service order is something that USBoot does, apparently. An alternative would be to adjust all copies of the .INF files for USB hardware so that the service order is as desired.


Windows Registry Editor Version 5.00



[HKEY_LOCAL_MACHINESYSTEMControlSet001Serviceswaitbt]

"Type"=dword:00000001

"Start"=dword:00000000

"ImagePath"=hex(2):73,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,00,64,00,

72,00,69,00,76,00,65,00,72,00,73,00,5c,00,77,00,61,00,69,00,74,00,62,00,74,

00,2e,00,73,00,79,00,73,00,00,00

"Group"="SCSI Miniport"



...

...

Thanks for sharing your Registry details.

A note about ImagePath: If it is not present, the NTLDR will look for SystemRootSystem32DriversServiceName.SYS So you can omit it, in this case.

...
Could it be that the sequence of disk arrived is the origin of BSOD 7B ?

Absolutely. As previously discussed, if the WinVBlock disk arrives before the USB disk, then WinVBlock can't find the backing disk. You really need the USB services to start before WinVBlock (sensible), or I need to add a work-around to WinVBlock (ugly).

Case closed! :thumbsup: (Right? :suda:)

#45 wimb

wimb

    Gold Member

  • Developer
  • 2281 posts
  •  
    Netherlands

Posted 06 October 2012 - 02:31 PM

When the other new hardware is installed, that includes the USB hardware. When that happens, the service order changes and the USB drivers go back to after WinVBlock. WaitBt isn't going to help with that, as WaitBt doesn't care about USB.
.....
Absolutely. As previously discussed, if the WinVBlock disk arrives before the USB disk, then WinVBlock can't find the backing disk. You really need the USB services to start before WinVBlock (sensible), or I need to add a work-around to WinVBlock (ugly).

How about changing the Load Order Group of WinVBlock ?
It is now SCSI Miniport
We might set it to a later group e.g. System Bus Extender
I will try that and report about it.

EDIT:
WinVBlock with Group=System Bus Extender still loaded before USBSTOR for the given case.
Well, in any case such rare troublesome cases can be solved by using DriveGuard ubdrvgd.sys driver

:cheers:

#46 Sha0

Sha0

    WinVBlock Dev

  • Developer
  • 1682 posts
  • Location:reboot.pro Forums
  • Interests:Booting
  •  
    Canada

Posted 06 October 2012 - 04:58 PM

How about changing the Load Order Group of WinVBlock ?
It is now SCSI Miniport
We might set it to a later group e.g. System Bus Extender

Nope. WinVBlock should start before the disk driver.

...
Well, in any case such rare troublesome cases can be solved by using DriveGuard ubdrvgd.sys driver

Or you could find and modify all the .INFs for USB hardware to prevent them from changing the service order. All the USB drivers that are required for USB storage should be started just before the SCSI Miniport group, for simplicity. You could consider usbstor to be appropriate for the SCSI Miniport group, but who cares. The Tag of the driver can be used for further granularity. Microsoft's SysInternals' LoadOrd can be handy to confirm.

Or you could have a shutdown script that sets the desired order.

Original post now has version 0.0.0.7. I mentioned you in the relevant git commit message, wimb! :clap:

#47 Doodoo

Doodoo

    Frequent Member

  • Advanced user
  • 344 posts

Posted 07 October 2012 - 08:35 PM

Keeping an eye on the service order is something that USBoot does, apparently.


Hard to confirm for sure... but it seems like a sensible hypothesis
http://reboot.pro/13...300#entry123520

Try reading USBoot ServiceGuard as "USBbootwatcher" :cheers:: http://www.911cd.net...topic=22473&hl=


Note however, that we're talking about another USBoot component (ServiceGuard), and that keeping an eye on the service order does not seem to be something that DriveGuard does on its own (to be comfirmed !)

#48 Sha0

Sha0

    WinVBlock Dev

  • Developer
  • 1682 posts
  • Location:reboot.pro Forums
  • Interests:Booting
  •  
    Canada

Posted 08 October 2012 - 04:30 AM

...
Note however, that we're talking about another USBoot component (ServiceGuard), and that keeping an eye on the service order does not seem to be something that DriveGuard does on its own (to be comfirmed !)

Right. In case you missed it, WaitBt now accomplishes the goal of avoiding the bug-check in wimb's problem scenario. That the service order gets changed later by hardware installation is really a problem that WaitBt shouldn't deal with, just as you suppose that DriveGuard doesn't deal with it.

#49 wimb

wimb

    Gold Member

  • Developer
  • 2281 posts
  •  
    Netherlands

Posted 08 October 2012 - 05:53 AM

Normally on Reboot then DriveGuard driver would prevent BSOD 7B whereas waitbt v6 fails on that occasion.

On Reboot then DriveGuard driver is preventing BSOD 7B where waitbt v6 and 7 fail for the given case.
However, it would be better if we have more testing for other BSOD 7B cases, but I have none available at home.
So I used the given troublesome case, where until now only DriveGuard is rebooting without BSOD 7B.

May be good to rephrase the tested troublesome case where only DriveGuard can prevent BSOD 7B:
For the Dual Core laptop without Install of iaStor driver and using UsbBootWatcher (USB Services as Group=Boot Bus Extender with Start=0)
then 1st Boot with XP VHD on USB is OK, but Reboot fails with BSOD 7B

It is worthwhile to mention that UsbBootWatcher always kept the USB Services as Group=Boot Bus Extender with Start=0
So I think that DriveGuard has some other secret ....to protect and prevent BSOD 7B
The new waitbt driver like DriveGuard driver is installed as LowerFilters driver
and I can see that waitbt v7 also Enumerates the GenDisk hardware, but apparently that is not enough to prevent BSOD 7B

May be Doodoo and Michele13 or others can do some additional testing.

:cheers:

#50 Sha0

Sha0

    WinVBlock Dev

  • Developer
  • 1682 posts
  • Location:reboot.pro Forums
  • Interests:Booting
  •  
    Canada

Posted 08 October 2012 - 06:38 AM

On Reboot then DriveGuard driver is preventing BSOD 7B where waitbt v6 and 7 fail for the given case.

Doodoo just suggested that USBoot ServiceGuard is responsible. Do you think Doodoo is mistaken? Are you installing multiple USBoot components?

...
It is worthwhile to mention that UsbBootWatcher always kept the USB Services as Group=Boot Bus Extender with Start=0
So I think that DriveGuard has some other secret ....to protect and prevent BSOD 7B

Are you sure this other secret is not the ServiceGuard?

We have already established from your pictures that the WinVBlock disk appears before the USB disk. This is the cause for the bug-check. That is not a guess. How can DriveGuard prevent this? It does not know about WinVBlock. Have you examined HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlServiceGroupOrder : List ? Have you used LoadOrd to examine the service order?

The new waitbt driver like DriveGuard driver is installed as LowerFilters driver

It will probably work as an upper filter, too. The point is: Since you showed that DriveGuard was not producing any FDOs, then that suggested to me that a simple pause caused by its AddDevice routine was enough to prevent the bug-check. So I wrote that into WaitBt and it works.

and I can see that waitbt v7 also Enumerates the GenDisk hardware, but apparently that is not enough to prevent BSOD 7B

Neither driver is "enumerating" anything. That list is simply the PnP Manager keeping track of what devices a driver's AddDevice function has succeeded.

Can you please share how you installed DriveGuard? Was it by .INF or installer program or manual copy of .SYS files and manual Registry entries? How many files are involved?




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users