Jump to content











Photo
- - - - -

WaitBt for USB Booting


  • Please log in to reply
133 replies to this topic

#76 Sha0

Sha0

    WinVBlock Dev

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

Posted 11 October 2012 - 07:53 PM

...
At home I had prepared on my AMD machine three equal XP VHD files which have full DriverPacks Chipset + MassStorage + LAN integrated
On booting from ASUS P4P800-E with Intel Pentium 4 processor I get in case of
- no extra driver gives BSOD 7B
- with DriveGuard driver - Booting OK and new hardware found is properly installed
- with waitbt v8 driver - Booting OK but on auto Install of new hardware I get BSOD 7E - On Reboot stable but IDE Controller has exclamation mark
which I tried to solve, but then again BSOD 7E

So It remains rather tricky.

Blast! I'll have to figure out why this is, then. If all we need is the DriverEntry pause, then we can forget about setting it as a lower filter; that might be worth a try.

I will also test old wait10 driver (is that waitbt32.sys version 0.0.0.4 that is used in IMG_XP_64 package ?)

No, but I think it's attached to one of Doodoo's posts in this thread. I think it was wait10.sys.

#77 Doodoo

Doodoo

    Frequent Member

  • Advanced user
  • 344 posts

Posted 11 October 2012 - 08:26 PM

- no extra driver gives BSOD 7B
- with DriveGuard driver - Booting OK and new hardware found is properly installed
- with waitbt v8 driver - Booting OK but on auto Install of new hardware I get BSOD 7E - On Reboot stable but IDE Controller has exclamation mark

I haven't tried DriveGuard on my fussy machine, but will do.
However I did try something else... which might give more insight (more ideas ?) or add to the confusion:

- no extra driver gives BSOD 7B
- with waitbt v8 driver - Booting OK but on auto Install of new hardware I get BSOD 7E
- with XP Embedded SP2 Feature Pack usbhub.sys - Booting OK and new hardware found is properly installed

#78 Sha0

Sha0

    WinVBlock Dev

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

Posted 11 October 2012 - 09:56 PM

...
- with XP Embedded SP2 Feature Pack usbhub.sys - Booting OK and new hardware found is properly installed

That's rather the point of that special usbhub.sys, isn't it? The non-embedded version doesn't include a delay to allow for USB devices (such as the boot disk) to be enumerated and driven in time for the STOP 0x7B, which is what WaitBt is trying to help with.

I guess you are suggesting that WaitBt might be the cause of the system thread exception? That's possible. I'd still be interested in if you get this problem when removing WaitBt as a lower filter driver, but still having everything else about it the same.

#79 wimb

wimb

    Platinum Member

  • Developer
  • 2629 posts
  • Interests:Boot and Install from USB
  •  
    Netherlands

Posted 12 October 2012 - 05:10 AM

I have used wait10.sys driver and for the given case of Reboot on Dual Core laptop I get BSOD 7B

:cheers:


#80 Sha0

Sha0

    WinVBlock Dev

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

Posted 12 October 2012 - 06:51 AM

I have used wait10.sys driver and for the given case of Reboot on Dual Core laptop I get BSOD 7B

So it allows for an initally successful boot? And then after all hardware is installed and you reboot, it fails? Or can you not boot with it on the Dual Core laptop at all?

#81 wimb

wimb

    Platinum Member

  • Developer
  • 2629 posts
  • Interests:Boot and Install from USB
  •  
    Netherlands

Posted 12 October 2012 - 07:00 AM

So it allows for an initally successful boot? And then after all hardware is installed and you reboot, it fails? Or can you not boot with it on the Dual Core laptop at all?

Sorry but I have made a mistake and did not use wait10.sys in the right way - see post # 83 http://reboot.pro/14427/#entry161606

First boot on Intel Dual Core laptop is OK, but that is normal (always occur) for that case.
After auto install of new hardware found (but without install of iaStor needed to see internal harddisk) then Reboot gives BSOD 7B
It is exactly the same procedure as used before to study BSOD 7B on Intel dual Core laptop.

Only DriveGuard or waitbt v8 or Install of iaStor can prevent BSOD 7B for Reboot on Intel Dual Core laptop.

This is the only BSOD 7B testcase that I have at home.
The other case of BSOD 7B on ASUS P4P800-E with Intel Pentium 4 is a more realistic test,
since in that case all Chipset + MassStorage drivers are ready for Install from full DriverPacks
but cannot prevent the BSOD 7B occurring. Only DriveGuard prevents BSOD 7B for that case.
However, that computer is not available for me at home for testing
and only occassionally I have access to that system.

:cheers:

#82 Doodoo

Doodoo

    Frequent Member

  • Advanced user
  • 344 posts

Posted 12 October 2012 - 09:45 AM

- no extra driver gives BSOD 7B
- with waitbt v8 driver - Booting OK but on auto Install of new hardware I get BSOD 7E
- with XP Embedded SP2 Feature Pack usbhub.sys - Booting OK and new hardware found is properly installed

What I can add now:
- with DriveGuard - Booting OK and new hardware found is properly installed
- with waitbt v8 driver but only biosinfo.inf left in Windows/INF and other INF files removed - Booting OK and new hardware found is properly installed - Not terribly useful though, as I have no keyboard and no mouse support... But Windows is alive, and it shuts down properly when I press the power button...

I guess you are suggesting that WaitBt might be the cause of the system thread exception?

I wouldn't say the the cause... But it looks like DriveGuard and even the modified usbhub.sys manage things in a slightly different way, which avoids problems. Could something be happening to the WinVBlock disk driver when drivers for disks are being installed for the new hardware ?

That's rather the point of that special usbhub.sys, isn't it?

Yes but perhaps we could be inspired by this example ? Could we imagine to rename the vanilla XP usbhub.sys, write a fake usbhub.sys which would do some stuff for WinVBlock (perhaps just wait), then load the renamed usbhub.sys ? It would be some kind of wrapper basically, adding specific functionalities (or modifying functionalities although that might be diffcult/impossible)

#83 wimb

wimb

    Platinum Member

  • Developer
  • 2629 posts
  • Interests:Boot and Install from USB
  •  
    Netherlands

Posted 12 October 2012 - 11:13 AM

I have used wait10.sys driver and for the given case of Reboot on Dual Core laptop I get BSOD 7B

:cheers:

I have to make a correction for the wait10.sys experiment.
I thought that wait10.sys was to be used similar as waitbt.sys but now I know that was a mistake.

Sorry for the misunderstanding.

After reading http://reboot.pro/14130/#entry125347 on how to use wait10.sys
I saw that I have to add IaStor + registry (i used USB_XP_Fix.exe) and use wait10.sys renamed as IaStor.sys

When doing so then Boot and Reboot of Intel Dual Core is going fine
In device manager I see IDE Controller with exclamation mark due to IaStor driver being the renamed wait10.sys
and of course the internal harddisk is invisible since it needs the real IaStor driver.

Then instead of wait10.sys I renamed irenum.sys (InfraRed Bus Enumerator) as IaStor.sys
Surprisingly booting is OK and the IDE Controller has no exclamation mark.
So the 10 sec waiting of wait10.sys does not seem to be important.
The IaStor CriticalDeviceDatabase entries are probably all that matters to prevent BSOD 7B in this case.
Of course it is nonsence to have an Infrared Enumerator installed as IDE Controller, but the system does not notice this as strange.
It seems you must have something as IaStor.sys but it does not matter what it is.

:cheers:

#84 Sha0

Sha0

    WinVBlock Dev

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

Posted 12 October 2012 - 04:50 PM

Sorry but I have made a mistake and did not use wait10.sys in the right way - see post # 83 http://reboot.pro/14427/#entry161606

First boot on Intel Dual Core laptop is OK, but that is normal (always occur) for that case.

Now I'm confused. I thought you were never able to boot the Intel Dual Core laptop the first time without something. Am I mistaken? I thought your original test image would not boot on that computer without some kind of help.

After auto install of new hardware found (but without install of iaStor needed to see internal harddisk) then Reboot gives BSOD 7B
It is exactly the same procedure as used before to study BSOD 7B on Intel dual Core laptop.

It sure seems like after the new hardware is installed, the timing is changed such that the USB hub does not enumerate the USB disk in time for WinVBlock to find it. This actually makes sense: If the timing is so close that the attempt to install any device via a CriticalDeviceDatabase entry is enough time to allow the UBS hub to provide the USB disk, then when all of the devices are installed, that extra time is cut out, because there are no unknown devices.

Only DriveGuard or waitbt v8 or Install of iaStor can prevent BSOD 7B for Reboot on Intel Dual Core laptop.

Again, if the timing is that close, then all of these things could slow it down.

For the iaStor case, reading from a disk is relatively slow, plus there are multiple reads of the disk: Reading the MBR, reading the partitions' first sectors, reading FAT and NTFS information from the partitions... Slow! (Relatively.)

WaitBt obviously wants to slow things down. DriveGuard seems to slow things down.

This is the only BSOD 7B testcase that I have at home.
The other case of BSOD 7B on ASUS P4P800-E with Intel Pentium 4 is a more realistic test,
since in that case all Chipset + MassStorage drivers are ready for Install from full DriverPacks
but cannot prevent the BSOD 7B occurring. Only DriveGuard prevents BSOD 7B for that case.
However, that computer is not available for me at home for testing
and only occassionally I have access to that system.

Please try WaitBt on that when you get a chance, but without making it a lower filter. (Still a boot driver.) The lower filter entry could be causing a problem.

What I can add now:
- with DriveGuard - Booting OK and new hardware found is properly installed
- with waitbt v8 driver but only biosinfo.inf left in Windows/INF and other INF files removed - Booting OK and new hardware found is properly installed - Not terribly useful though, as I have no keyboard and no mouse support... But Windows is alive, and it shuts down properly when I press the power button...

Ok, great. So it's definitely hardware installation that triggers the system thread exception. In that case, please try WaitBt without making it a lower filter. Then let's see if the hardware installs fine.

I wouldn't say the the cause...

But it seems like it is, actually.

But it looks like DriveGuard and even the modified usbhub.sys manage things in a slightly different way, which avoids problems.

I think it's not fair to group DriveGuard and the XP Embedded USBHub.Sys together. Is DriveGuard a filter driver for USB devices? If not, then it's not likely going to help the USB hub directly, but it could still help by introducing a delay.

Could something be happening to the WinVBlock disk driver when drivers for disks are being installed for the new hardware ?

Actually, I just recently ran into a problem with WinVBlock 0.0.1.8 when updating its bus device in Device Manager. Try tracking down the WinVBlock .INF file and removing that as a test. Then we can find out if it's WinVBlock or WaitBt that's causing the problem. However! If you are saying that DriveGuard lets everything go smoothly, then it it has to be WaitBt.

Yes but perhaps we could be inspired by this example ? Could we imagine to rename the vanilla XP usbhub.sys, write a fake usbhub.sys which would do some stuff for WinVBlock (perhaps just wait), then load the renamed usbhub.sys ? It would be some kind of wrapper basically, adding specific functionalities (or modifying functionalities although that might be diffcult/impossible)

This is a very nice idea. I've thought about that same approach for a few different scenarios. There is a problem, however: USBHub.Sys doesn't have any function exports. Normally when NTLdr loads a driver, it examines that driver for dependencies and then loads those files, too. So we need our "wrapper" to depend on the real (but renamed) USBHub.Sys. But in order to get a dependency, the wrapper needs to call an exported function in USBHub.Sys. But there aren't any exported functions.

Along the same lines, however, would be if some future version of WaitBt was a filter for USB hubs! Then it could filter the "bus relations" query and introduce an intentional delay. However, that requires rewriting WaitBt as a full PnP driver, which is a fair bit of work. Right now, it's a "fake" PnP driver just because of its AddDevice routine.

I have to make a correction for the wait10.sys experiment.
I thought that wait10.sys was to be used similar as waitbt.sys but now I know that was a mistake.

Sorry for the misunderstanding.

No problem. It's been so long, I didn't even remember how Wait10 was supposed to be used.

After reading http://reboot.pro/14130/#entry125347 on how to use wait10.sys
I saw that I have to add IaStor + registry (i used USB_XP_Fix.exe) and use wait10.sys renamed as IaStor.sys

When doing so then Boot and Reboot of Intel Dual Core is going fine
In device manager I see IDE Controller with exclamation mark due to IaStor driver being the renamed wait10.sys
and of course the internal harddisk is invisible since it needs the real IaStor driver.

So Wait10 works for the initial boot and subsequent reboots! A major problem Wait10 has in contrast to modern WaitBt is that it doesn't even pretend to be a PnP driver, so using it for a CDDB entry results in the exclamation mark. There is no way it can drive a device that you see in Device Manager, since it is not PnP.

Then instead of wait10.sys I renamed irenum.sys (InfraRed Bus Enumerator) as IaStor.sys
Surprisingly booting is OK and the IDE Controller has no exclamation mark.

This is what makes me think that the time it takes to install any unknown device via a CDDB association is enough to allow the USB hub to enumerate the USB disk. Since IREnum.Sys is a PnP driver, there is no exclamation mark in Device Manager.

So the 10 sec waiting of wait10.sys does not seem to be important.

If the theory that the timing is so close is correct, then your statement above is likely correct. However, other systems might not be so close. :)

The IaStor CriticalDeviceDatabase entries are probably all that matters to prevent BSOD 7B in this case.
Of course it is nonsence to have an Infrared Enumerator installed as IDE Controller, but the system does not notice this as strange.
It seems you must have something as IaStor.sys but it does not matter what it is.

There is a simple experiment we can try: Remove the CDDB association for the PCI IDs for your Intel Dual Core laptop's disk controller from the image file's Registry. Remove the iaStor service Registry entry, too. Now figure out any other unknown device on that laptop's IDs. Make a CDDB entry for those IDs, with an association with IREnum.

For example:
  • Windows: "Hey, I'm booting on the Intel Dual Core laptop for the first time"
  • USB hub begins operation, but hasn't polled its devices, yet
  • PnP Manager: "Hey USB hub, what children do you have?"
  • USB hub: "I don't have any right now"
  • PnP Manager: "Ok"
  • PnP Manager: "Hey, here's an unknown device PCI\something_you_found_and_made_a_CDDB_entry_for"
  • PnP Manager: "Do we have a CDDB entry for this ID?"
  • PnP Manager: "Ah yes, I see that there is one. It associates with the IREnum driver (for example)"
  • Meanwhile, the USB hub polls its devices and find the USB disk: "Hey PnP Manager, I have had a child!"
  • PnP Manager: "Just a moment USB hub, I'm in the middle of something"
  • PnP Manager: "Where was I? Oh yes, install that unkown device. Ok... Done"
  • PnP Manager: "Now what did you want, USB hub? Oh yes, you have had a child. It looks like a GenDisk. Do we have a CDDB entry for this ID?"
  • PnP Manager: "Ah yes, I see that there is one. It associates with the Disk driver. Ok... Done"
  • PnP Manager then installs the volume and so on...
  • Windows: "Ok, PnP Manager is all finished doing what it could do"
  • Windows: "Do we have the boot volume, yet?"
  • Windows: "Ah yes, there it is. Whee!"
Instead of:
  • Windows: "Hey, I'm booting on the Intel Dual Core laptop for the first time"
  • USB hub begins operation, but hasn't polled its devices, yet
  • PnP Manager: "Hey USB hub, what children do you have?"
  • USB hub: "I don't have any right now"
  • PnP Manager: "Ok"
  • PnP Manager goes through looking for unknown devices and doesn't find any that have CDDB entries
  • Windows: "Ok, PnP Manager is all finished doing what it could do"
  • Windows: "Do we have the boot volume, yet?"
  • Windows: "Oh no, there isn't one. I'm feeling Blue!"
  • Meanwhile, the USB hub polls its devices and find the USB disk: "Hey PnP Manager, I have had a child!" But its lonely voice is lost in someone's scream of "STOP 0x0000007B!"


#85 Doodoo

Doodoo

    Frequent Member

  • Advanced user
  • 344 posts

Posted 12 October 2012 - 05:08 PM

In that case, please try WaitBt without making it a lower filter


How do you do that ? Do you only leave the services entry ?

[HKEY_LOCAL_MACHINEoffline_system_hiveControlSet001Serviceswaitbt]

"Start"=dword:00000000

"Group"="SCSI Miniport"

"Type"=dword:00000001





#86 Doodoo

Doodoo

    Frequent Member

  • Advanced user
  • 344 posts

Posted 12 October 2012 - 05:44 PM

So it's definitely hardware installation that triggers the system thread exception. In that case, please try WaitBt without making it a lower filter. Then let's see if the hardware installs fine.

Yep, with all INF files present in Windows/INF, and without making WaitBt a lower filter, no BSOD 7E, it just works fine.
Is there a specific reason for wanting to keep WaitBt as a lower filter though ?

#87 Doodoo

Doodoo

    Frequent Member

  • Advanced user
  • 344 posts

Posted 12 October 2012 - 08:55 PM

However, that requires rewriting WaitBt as a full PnP driver, which is a fair bit of work. Right now, it's a "fake" PnP driver just because of its AddDevice routine

Not sure if that is terribly important, but out of curiosity, is it possible to tell if DriveGuard is a full PnP driver or a fake one ?

#88 Sha0

Sha0

    WinVBlock Dev

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

Posted 12 October 2012 - 10:22 PM

How do you do that ? Do you only leave the services entry ?


[HKEY_LOCAL_MACHINEoffline_system_hiveControlSet001Serviceswaitbt]

"Start"=dword:00000000

"Group"="SCSI Miniport"

"Type"=dword:00000001

Agreed.

Yep, with all INF files present in Windows/INF, and without making WaitBt a lower filter, no BSOD 7E, it just works fine.
Is there a specific reason for wanting to keep WaitBt as a lower filter though ?

None that I know of.


Not sure if that is terribly important, but out of curiosity, is it possible to tell if DriveGuard is a full PnP driver or a fake one ?

It's probably real, because when it's activated with a code, I'm sure it does things like report removable storage as non-removable. That requires intercepting the queries.

#89 wimb

wimb

    Platinum Member

  • Developer
  • 2629 posts
  • Interests:Boot and Install from USB
  •  
    Netherlands

Posted 21 October 2012 - 07:25 AM

At home I had prepared on my AMD machine three equal XP VHD files which have full DriverPacks Chipset + MassStorage + LAN integrated (KTD)
On booting from ASUS P4P800-E with Intel Pentium 4 processor I get in case of
- no extra driver gives BSOD 7B
- with DriveGuard driver - Booting OK and new hardware found is properly installed
- with waitbt v8 driver - Booting OK but on auto Install of new hardware I get BSOD 7E - On Reboot stable but IDE Controller has exclamation mark
which I tried to solve, but then again BSOD 7E


All BSOD 7B problems are solved and waitbt v8 delay driver can be used, but is not needed in this case. :)

On booting from USB with ASUS P4P800-E with Intel Pentium 4 processor I get in case of
- no extra driver - Booting OK and new hardware found is properly installed - bootime = 35 sec
- with waitbt v8 - Booting OK and new hardware found is properly installed - boottime = 50 sec

I can confirm that BSOD 7E for waitbt v8 does not occur anymore when the LowerFilters registry for waitbt is omitted,
just as proposed by Sha0 and observed by Doodoo http://reboot.pro/14..._75#entry161631

Omitting the LowerFilters registry for waitbt also improves the boottime.
On booting from USB with my AMD machine that has BIOS with slow USB boot support then
- no extra driver - bootime = 85 sec
- with waitbt v8 - boottime = 100 sec (it was 180 sec previously by using Lowerfilters registry)
So waitbt v8 delay driver is using 15 sec extra boottime, which is acceptable.

It is also possible to prevent BSOD 7B without using any delay driver.
USB_XP_Fix.exe was improved such that the CriticalDeviceDatabase registry has all entries for IDE Controller and USB Controller Services
and that all IDE and USB Controller drivers if missing are extracted previously from the XP driver.cab file.

The CriticalDeviceDatabase registry of Windows 7 has much more entries as compared to XP.
IDE ATAATAPI Controller has ClassGuid={4D36E96A-E325-11CE-BFC1-08002BE10318} with entries in mshdc.inf
USB Controller has ClassGUID={36FC9E60-C465-11CF-8056-444553540000} with entries in usbport.inf and usbstor.inf and usb.inf

CriticalDeviceDatabase registry of XP is now improved and is comparable with Windows 7 by adding
all entries for Control Class {4D36E96A-E325-11CE-BFC1-08002BE10318} and {36FC9E60-C465-11CF-8056-444553540000}
http://reboot.pro/98...850#entry162027

:cheers:

#90 MedEvil

MedEvil

    Platinum Member

  • .script developer
  • 7771 posts

Posted 21 October 2012 - 10:14 AM

Brilliant solution, Wimb! :cheerleader: :cheerleader: :cheerleader:

I just wished all our genius project authors would maintain a post or a website, where they list all the little tricks, they employ in their projects.

So much knowledge was already been lost. :(

:cheers:

#91 Doodoo

Doodoo

    Frequent Member

  • Advanced user
  • 344 posts

Posted 24 October 2012 - 09:30 PM

It is also possible to prevent BSOD 7B without using any delay driver. USB_XP_Fix.exe was improved such that the CriticalDeviceDatabase registry has all entries for IDE Controller and USB Controller Services and that all IDE and USB Controller drivers if missing are extracted previously from the XP driver.cab file.


Excellent stuff really !! :clap:
Now I can't help asking a couple of cheeky questions:
  • Is this procedure garanteed to avoid the case where WinVBlock goes looking for its backing disk before it's available ? Or does it just happen to be working (out of luck) because timing is changed ?
  • Has this been inspired by USBoot perhaps ? I did report many months ago that part of the USBoot phase I and II is to populate the CriticalDeviceDatabase, with all known USB devices. Presumably this also avoids the need to "recognise" the USB stick you're trying to boot from, i.e. windows does not need to have seen it before it can boot off it. Below is just an excerpt of USBoot procedure:
Processing step VII: Installation of all available drivers of classes "USB" and "1394"

Processing step VIII: Installation of all available drivers of critical classes (excluding class "SCSIAdapter") but only generic ones for classes "System", "Keyboard" and "Mouse"

Processing step IX: Removal of information concerning non present devices

Processing step X: Reinstallation of present devices of class USB

Processing step XI: Reinstallation of present devices of class SYSTEM preferring generic device IDs


but the entire log file, attached in the post indicated above will give more details. So is this actually the key we've been looking for, and not so much DriveGuard ?

Oh and by they way, it appears that the USBoot author, ...Tim..., is a reboot member , albeit not very active ;)

#92 wimb

wimb

    Platinum Member

  • Developer
  • 2629 posts
  • Interests:Boot and Install from USB
  •  
    Netherlands

Posted 25 October 2012 - 07:04 AM

I got inspired by the fact that Windows 7 is performing so much better than XP for booting from USB on unknown hardware.
I also got inspired by your observation that simply adding CriticalDeviceDatabase entries for IDE Controller are needed to prevent BSOD 7B
http://reboot.pro/14130/
In fact the internal harddisk may remain invisible by using a fake driver like wait10.sys or another fake PNP driver instead of iaStor.sys
but it is essential that the System immediately knows what to do with the found Controller Hwids (IDE and USB and SCSI / RAID)
The CriticalDeviceDatabase entry indicates what Service to use and the Service describes where to find the driver and how to use it.
For each Controller Hwid found, the system needs a quick answer and if no answer is provided then BSOD 7B is the result.

Then I compared CriticalDeviceDatabase in Win7 with XP and concluded that many (really most) Controller entries are missing in XP.
My experience is that adding all IDE and USB Controller entries to the CriticalDeviceDatabase of XP
and unpacking the missing Controller drivers from driver.cab helps to prevent BSOD 7B and has solved for me all BSOD 7B problems.
The SCSI- and RAID-controller drivers other then the already supplied Intel iaStor.sys and AMD ahcix86.sys
are supported via integrated MassStorage DriverPack serving as a kind of Win7 DriverStore.

http://reboot.pro/98...850#entry162030

In this way the timing and logic in booting is improved, but it is advised to also add waitbt driver for some cases
e.g. SCSI- and RAID-controller drivers that are installed not fast enough via inf files
from the many subfolders of the WINDOWSDriverPacksM folder with MassStorage drivers.

:cheers:

#93 Doodoo

Doodoo

    Frequent Member

  • Advanced user
  • 344 posts

Posted 25 October 2012 - 07:56 AM

adding CriticalDeviceDatabase entries for IDE Controller are needed to prevent BSOD 7B http://reboot.pro/14130/

The irony in this example, is that the CriticalDeviceDatabase entry that made everything work, is NOT for the boot device (the USB stick), but for a device completely irrelevant in the boot process (the internal hard drive). To me this is just luck, not really a rock-solid procedure.

it is advised to also add waitbt driver for some cases e.g. SCSI- and RAID-controller drivers that are installed not fast enough via inf files from the many subfolders of the WINDOWS\DriverPacks\M folder with MassStorage drivers.

I'm not sure I understand the details here, but why not implement something similar to USBoot in this case ? I.e. parse all available INF files, retain all devices for specific classes of hardware, and install CDDB entries for all of them, without exception ?

#94 wimb

wimb

    Platinum Member

  • Developer
  • 2629 posts
  • Interests:Boot and Install from USB
  •  
    Netherlands

Posted 25 October 2012 - 08:07 AM

The irony in this example, is that the CriticalDeviceDatabase entry that made everything work, is NOT for the boot device (the USB stick), but for a device completely irrelevant in the boot process (the internal hard drive). To me this is just luck, not really a rock-solid procedure.

For each Controller Hwid found, the system needs a quick answer and if no answer is provided then BSOD 7B is the result.
It does not seem important that the internal harddisk is seen, e.g. you can replace iaStor.sys by a fake driver.

I'm not sure I understand the details here, but why not implement something similar to USBoot in this case ? I.e. parse all available INF files, retain all devices for specific classes of hardware, and install CDDB entries for all of them, without exception ?

All CDDB entries for IDE and USB Controller related to mshdc.inf and usbport.inf and usbstor.inf and usb.inf are added already completely.
USBoot excludes the SCSI and RAID Controllers, where I support those via integrated MassStorage DriverPack and the supplied iaStor.sys and ahcix86.sys

:cheers:

#95 Sha0

Sha0

    WinVBlock Dev

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

Posted 25 October 2012 - 08:15 AM

I got inspired by the fact that Windows 7 is performing so much better than XP for booting from USB on unknown hardware.
I also got inspired by your observation that simply adding CriticalDeviceDatabase entries for IDE Controller are needed to prevent BSOD 7B
http://reboot.pro/14130/
In fact the internal harddisk may remain invisible by using a fake driver like wait10.sys or another fake PNP driver instead of iaStor.sys
but it is essential that the System immediately knows what to do with the found Controller Hwids
...

I disagree. As far as I know, there is nothing that makes the IDs for a storage controller special, relative to other device IDs. All device IDs are treated equally and none can be known to be storage-related ahead of time. If timing is key, which it seems to be, then:
  • you can use any IDs that will be present and not already installed on the target device
  • you can use the CDDB to associate any class and service to those IDs, if:
  • the service is invoked at the right point in the boot sequence
  • the service costs the right amount of time
Does this make sense? I'd really like to see the idea vanish that things that are unrelated to booting from USB are related to booting from USB other than because of their semi- to un-predictable influence on timing; allowing for the USB hub to poll for its children.

#96 wimb

wimb

    Platinum Member

  • Developer
  • 2629 posts
  • Interests:Boot and Install from USB
  •  
    Netherlands

Posted 25 October 2012 - 08:31 AM

I disagree. As far as I know, there is nothing that makes the IDs for a storage controller special, relative to other device IDs. All device IDs are treated equally and none can be known to be storage-related ahead of time.

The Controllers are ahead in the Device tree and need to be found first and quickly.
The CriticalDeviceDatabase entries relates the found Hwids as being Controller (IDE or USB or SCSI/RAID)

Also devcon.exe can identify Hwids to be Controller :)

DEVCON find pci*

DEVCON hwids *CC_01* *Raid*


:cheers:

#97 Sha0

Sha0

    WinVBlock Dev

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

Posted 25 October 2012 - 08:45 AM

The Controllers are ahead in the Device tree

Ahead of what? The enumeration sequence during booting seems pretty consistent in Windows XP. For each installed device, its children are enumerated. For each non-installed device, the CDDB is checked in order to determine if the device can be installed. Once installed, its children are enumerated, and so on. This can be witnessed with WinDbg.

and need to be found first and quickly.

I disagree. Saying "needs" here suggests that the STOP 0x7B is somehow caused if storage controllers are not installed via CDDB "first and quickly." But this bug-check is actually a result of the boot volume not being found. For example, you should be able to boot from USB on a system without any storage controllers whatsoever and without any CDDB associations for any storage controller drivers other than USBStor. I think it'd be great to test such a system. Does anyone have one?

The CriticalDeviceDatabase entries relates the found Hwids

Agreed.

#98 wimb

wimb

    Platinum Member

  • Developer
  • 2629 posts
  • Interests:Boot and Install from USB
  •  
    Netherlands

Posted 25 October 2012 - 09:24 AM

Ahead of what?

Ahead of its children

I disagree. Saying "needs" here suggests that the STOP 0x7B is somehow caused if storage controllers are not installed via CDDB "first and quickly." But this bug-check is actually a result of the boot volume not being found. For example, you should be able to boot from USB on a system without any storage controllers whatsoever and without any CDDB associations for any storage controller drivers other than USBStor. I think it'd be great to test such a system. Does anyone have one?

Well that is in fact my Dual core laptop that requires iaStor.sys to see internal harddisk.
- without adding iaStor.sys + CDDB entries then 1st boot is OK, but Reboot is giving BSOD 7B
- adding iaStor.sys + CDDB entries then 1st boot + Reboot is OK

:cheers:

#99 Doodoo

Doodoo

    Frequent Member

  • Advanced user
  • 344 posts

Posted 25 October 2012 - 09:25 AM

All CDDB entries for IDE and USB Controller related to mshdc.inf and usbport.inf and usbstor.inf and usb.inf are added already completely.
USBoot excludes the SCSI and RAID Controllers, where I support those via integrated MassStorage DriverPack and the supplied iaStor.sys and ahcix86.sys


I'm not too sure how you create the missing CDDB entries, but from what I've witnessed, it seems to be pretty quick (a few seconds perhaps).
The equivalent process in USBoot is pretty lengthy, and takes several minutes (as much as 10 minutes from the log file in this post)
Are you doing any magic ?

#100 Doodoo

Doodoo

    Frequent Member

  • Advanced user
  • 344 posts

Posted 25 October 2012 - 09:33 AM

adding iaStor.sys + CDDB entries then 1st boot + Reboot is OK

Wimb, I think what we're trying to say here, is that "it works" unfortunately does not mean "this is the solution". The reverse is true though: "it does not work" un-ambiguously means "this is not the solution".

Your scenario happens to be working with CDDB entries.... it does not mean "CDDB entries are required", nor does it mean "CDDB entries guarantee you won't be getting a BSOD 7B". Does it make sense ?




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users