196 replies to this topic

[MedEvil]

What USBHUB.SYS timeout? Is there one that you know of?

I understood your answer in that way, that i was wrong assuming that wait10.sys would delay the loading of usbhub.sys, so the 10 second timeout has to happen between usbhub loading and its timeout.

The organization that employs me has 30,000+ XP computers; it'd be handy to be able to boot any one of them to a licensed XP on a USB disk, during trouble-shooting processes.

Who said you can't still do that? It's just, that there exist easier ways these days. A few years back, your solution would have been the only one.

I don't know much about the .WIM-booting thing, but this post seems to suggest requirements beyond a Windows XP or Windows Server 2003 installation source. Could you possibly confirm or deny that, MedEvil? If I have an XP installation source, can I .WIM-boot XP without using any unlicensed software?

Keep forgeting that setupldr needs to be from Win2k3. So build from only XP source, not possible. But a build from a Win2k3 source is.
About the files required from WAIK. WAIK is no 'try before you buy' version, like Windows embedded. Once you have it, you can use it for as long as you like.

If you like to check it out. LiveXP comes with a Wim.script, though the WAIK files (and setupldr from Win2k3 if source is XP) still need to be supplied.

[Sha0]

I understood your answer in that way, that i was wrong assuming that wait10.sys would delay the loading of usbhub.sys, so the 10 second timeout has to happen between usbhub loading and its timeout.

My current understanding is that the driver initialization and device initialization goes something like this:
Kernel: Create root device.
Kernel: Create root-enumerated devices. Enqueue them for later activation with their associated drivers.
Kernel: Initialize first driver.
Kernel: Are there any "foo" devices queued for this driver? Yes: Ask the first driver to drive each "foo" device.
Kernel: Do any of these "foo" devices have any children? Yes: Enqueue the children for later activation with their associated drivers.
Kernel: Initialize second driver.
Kernel: Are there any "bar" devices queued for this driver? Yes: Ask the second driver to drive each "bar" device.
Kernel: Do any of these "bar" devices have any children? Yes: Enqueue the children for later activation with their associated drivers.
Kernel: Initialize the third driver.
...

Now suppose that a "disk" device BAZ comes along after disk.sys has already been passed. BAZ will not be initialized by the boot thread because it has already taken care of "disk" devices. BAZ will have to wait for some other thread to take care of it. If the boot thread has finished and it's time to create ARC names, those ARC names might be created before BAZ has been taken care of.

The point of wait10.sys was that it would delay the boot thread and create an opportunity for some other thread to take care of the USB mass storage device and its volumes. Then these would be ready by the time the boot thread creates ARC names.

If you like to check it out. LiveXP comes with a Wim.script, though the WAIK files (and setupldr from Win2k3 if source is XP) still need to be supplied.

Thanks for the info, MedEvil.

[MedEvil]

Thanks for the in depth explaination.

But we're now full circle at the beginning again.
Does wait10.sys delay the loading of usbhub.sys or not? The hacked Embedded version, has a build in 'wait till' process.

[Sha0]

Does wait10.sys delay the loading of usbhub.sys or not? The hacked Embedded version, has a build in 'wait till' process.

No, wait10.sys doesn't need to delay the initialization of USBHUB.SYS. It delays the creation of ARC names. In those 10 seconds, the USB mass storage device and any of its volumes get the opportunity to be started.

[MedEvil]

Ahhh! Thank you, thank you, thank you!

Now i understand. So wait10.sys uses actually a different approach, to create the same effect, the embedded version of usbhub.sys does.

So i assume, that wait10.sys will delay the loading of disk.sys. ?

[Wonko the Sane]

Very, very good work.
A maybe little step but in the right direction, and a living proof that notwithstanding Doodoo's IMHO too "low-profile", he contributed to solve or at least correctly "frame" what the problem is/was , even self-declared n00bs or less experienced members CAN provide helpful insights, ideas and reports.

@Sha0

But of course, before anyone asks for this, we need also :
wait9.sys
wait8.sys
wait7.sys
...

and tests to see if we can shave a few seconds off it .


Wonko

[Sha0]

So i assume, that wait10.sys will delay the loading initialization of disk.sys. ?

But of course, before anyone asks for this, we need also :
wait9.sys
wait8.sys
wait7.sys
...

and tests to see if we can shave a few seconds off it .

I agree that an arbitrary 10 seconds is pretty silly. The whole driver was just for the sake of testing. A real solution should probably work differently.

[MedEvil]

Hey, we're finaly on the same page. Who would have guessed!

[cdob]

I used wait10 as replacement for vmscsi.sys: booting from USB does work
I used wait10 as replacement for pccide.sys: BSOD 0x7b


A default XP contains

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PCI]

"Group"="Boot Bus Extender"



[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PCIIde]

"Group"="System Bus Extender"



[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\atapi]

"Group"="SCSI miniport"



[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Disk]

SCSI miniport

"DependOnGroup"=hex(7):53,43,53,49,20,6d,69,6e,69,70,6f,72,74,00,00

"Group"="SCSI Class"

Service disk is connected to group SCSI miniport.

Adapted to USB booting:

REGEDIT4



;http://support.microsoft.com/kb/103000/

;http://support.microsoft.com/kb/115486/



[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\usbohci]

"Group"="Boot Bus Extender"

"Start"=dword:00000000



[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\usbuhci]

"Start"=dword:00000000

"Group"="Boot Bus Extender"



[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\usbehci]

"Start"=dword:00000000

"Group"="Boot Bus Extender"





[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\usbhub]

"Start"=dword:00000000

"Group"="System Bus Extender"

;Boot Bus Extender

"DependOnGroup"=hex(7):42,6f,6f,74,20,42,75,73,20,45,78,74,65,\

 6e,64,65,72,00,00





[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\usbstor]

;System Bus Extender

"DependOnGroup"=hex(7):53,79,73,74,65,6d,20,42,75,73,20,45,78,\

  74,65,6e,64,65,72,00,00

"Group"="SCSI miniport"

"Start"=dword:00000000

Internal group loading is sorted alpabetically too:
Boot Bus Extender: pci.sys is loaded first, usb?hci loaded next
System Bus Extender: usbhub is loaded
SCSI miniport: usbstor.
Remember disk.sys is connected to SCSI miniport.

Plain XP SP3 files boot from USB.
No addional drivers are involved.
No internal disk connected.

[MedEvil]

Plain XP SP3 files boot from USB.
No addional drivers are involved.
No internal disk connected.

Wow, this sounds like something cool to test for Doodoo.

[Doodoo]

Plain XP SP3 files boot from USB.
No addional drivers are involved.
No internal disk connected.

Amazing solution, cdob !!

I think we are getting in the right direction to the ultimate solution.
I have tried it... and it almost works. Well I should say it doesn't work for me
By the way, I've been messing with regedit 4 / regedit 5 formats, and if anyone wants to check my settings, just in case:

[HKEY_LOCAL_MACHINE\systemdst\ControlSet001\Services\UsbBootWatcher] "ImagePath"="UsbBootWatcher.exe" "ObjectName"="LocalSystem" "DisplayName"="Usb Boot Watcher Service" "ErrorControl"=dword:00000000 "Start"=dword:00000002 "Type"=dword:00000010 [HKEY_LOCAL_MACHINE\systemdst\ControlSet001\Services\usbccgp] "Type"=dword:00000001 "Start"=dword:00000000 "ErrorControl"=dword:00000001 "DisplayName"="Microsoft USB Generic Parent Driver" "ImagePath"=hex(2):73,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,00,44,00,\   52,00,49,00,56,00,45,00,52,00,53,00,5c,00,75,00,73,00,62,00,63,00,63,00,67,\   00,70,00,2e,00,73,00,79,00,73,00,00,00 "Group"="Boot Bus Extender" "Tag"=dword:00000012 [HKEY_LOCAL_MACHINE\systemdst\ControlSet001\Services\usbehci] "Type"=dword:00000001 "Start"=dword:00000000 "ErrorControl"=dword:00000001 "DisplayName"="Microsoft USB 2.0 Enhanced Host Controller Miniport Driver" "ImagePath"=hex(2):73,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,00,44,00,\   52,00,49,00,56,00,45,00,52,00,53,00,5c,00,75,00,73,00,62,00,65,00,68,00,63,\   00,69,00,2e,00,73,00,79,00,73,00,00,00 "Group"="Boot Bus Extender" "Tag"=dword:0000000f [HKEY_LOCAL_MACHINE\systemdst\ControlSet001\Services\usbhub] "Type"=dword:00000001 "Start"=dword:00000000 "ErrorControl"=dword:00000001 "DisplayName"="USB2 Enabled Hub" "ImagePath"=hex(2):73,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,00,44,00,\   52,00,49,00,56,00,45,00,52,00,53,00,5c,00,75,00,73,00,62,00,68,00,75,00,62,\   00,2e,00,73,00,79,00,73,00,00,00 "Group"="System Bus Extender" "Tag"=dword:00000011 "DependOnGroup"=hex(7):42,00,6f,00,6f,00,74,00,20,00,42,00,75,00,73,00,20,00,\   45,00,78,00,74,00,65,00,6e,00,64,00,65,00,72,00,00,00,00,00 [HKEY_LOCAL_MACHINE\systemdst\ControlSet001\Services\usbohci] "Type"=dword:00000001 "Start"=dword:00000000 "ErrorControl"=dword:00000001 "Group"="Boot Bus Extender" [HKEY_LOCAL_MACHINE\systemdst\ControlSet001\Services\usbstor] "Type"=dword:00000001 "Start"=dword:00000000 "ErrorControl"=dword:00000001 "DisplayName"="USB Mass Storage Driver" "ImagePath"=hex(2):73,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,00,44,00,\   52,00,49,00,56,00,45,00,52,00,53,00,5c,00,55,00,53,00,42,00,53,00,54,00,4f,\   00,52,00,2e,00,53,00,59,00,53,00,00,00 "Group"="SCSI miniport" "DependOnGroup"=hex(7):53,00,79,00,73,00,74,00,65,00,6d,00,20,00,42,00,75,00,\   73,00,20,00,45,00,78,00,74,00,65,00,6e,00,64,00,65,00,72,00,00,00,00,00 [HKEY_LOCAL_MACHINE\systemdst\ControlSet001\Services\usbuhci] "Type"=dword:00000001 "Start"=dword:00000000 "ErrorControl"=dword:00000001 "DisplayName"="Microsoft USB Universal Host Controller Miniport Driver" "ImagePath"=hex(2):73,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,00,44,00,\   52,00,49,00,56,00,45,00,52,00,53,00,5c,00,75,00,73,00,62,00,75,00,68,00,63,\   00,69,00,2e,00,73,00,79,00,73,00,00,00 "Group"="Boot Bus Extender" "Tag"=dword:00000010

[Doodoo]

[Deleted] Just plain wrong comments...

[cdob]

Actually I'm booting flat files, no image.

Most likely a driver error: timing still.
Which image driver do you use?
How is this driver launched?
How does image driver find the file?

[Doodoo]

Most likely a driver error: timing still.
Which image driver do you use?
How is this driver launched?
How does image driver find the file?

I'm using WinVBlock 0.0.1.8-DEV (Jan-30-2011)
The file is passed to the driver as explained here. However, I seem to remember Shao saying that the file should be locked when it has been recognised by the driver... And it never happens for me. I can delete the actual IMG I have just booted from....

Back to our problem... Do we need to be more specific ? Use DependOnService instead of DependOnGroup ? Do we need one more dependency level like "SCSI miniport depends on WinVBlock" (well, you get the idea)

[Sha0]

I used wait10 as replacement for vmscsi.sys: booting from USB does work
I used wait10 as replacement for pccide.sys: BSOD 0x7b

wait10 has two functions: DriverEntry() and W10AddDevice(). DriverEntry() does not perform the 10-second wait. DriverEntry() is always invoked. W10AddDevice() performs the 10-second wait. W10AddDevice() is only invoked if a CDDB entry associates a device with the driver.

If you had no physical devices with CDDB entries to invoke pciide, then the 10-second wait would not be performed.

Service disk is connected to group SCSI miniport.
...
Remember disk.sys is connected to SCSI miniport.

What do you mean? Disk.sys is in the group "SCSI Class".

[Doodoo]

A maybe little step but in the right direction, and a living proof that notwithstanding Doodoo's IMHO too "low-profile", he contributed to solve or at least correctly "frame" what the problem is/was , even self-declared n00bs or less experienced members CAN provide helpful insights, ideas and reports.

Thanks Wonko, I'm glad if I have been of any help, but all I have done is to collect pieces of evidence really. I would have been incapable to interpret them, this is where Shao has been invaluable. I should thank him publicly again for his patience and all the time he spends giving "self-sufficient" explanations, where most people would just go for the quick and easy option, and only provide a short answer, which is pretty meanigless and useless for someone who is still learning.

I wouldn't describe myself as a n00b, but I am very wary of self-declared experts as they very rarely turn out to be experts.... I like to think I am a fast learner and I simply have some common sense. It's a matter of personality I suppose, but some people live very well with problems without really understanding their cause; I simply can't.Sometimes it's not possible to solve them, but at least you know why.

[Sha0]

Ok, here's a different driver, attached. Simply give it a Services entry at the end of the boot-start groups, something like:

Windows Registry Editor Version 5.00



[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\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,44,00,\

  52,00,49,00,56,00,45,00,52,00,53,00,5c,00,77,00,61,00,69,00,74,00,62,00,74,\

  00,33,00,32,00,2e,00,73,00,79,00,73,00,00,00

"Group"="Base"

Adjust the ImagePath value as appropriate for your 32- or 64-bit architecture.

--- Attachment removed due to newer version. ---

[Doodoo]

That gave me a BSOD... But maybe I did something wrong: just copied waitbt32.sys in system32/drivers, added the services entry in the registry, and no CDDB entry for my ICH9 controller (i.e. iastor not loaded, which results in BSOD until now). Anything else I should try ?

PS: in the registry, you probably want to slightly adjust ImagePath, which currently points to wait32.sys instead of waitbt32.sys

[Sha0]

That gave me a BSOD... But maybe I did something wrong: just copied waitbt32.sys in system32/drivers, added the services entry in the registry,

Ack! waitbt is not supposed to yield STOP 0x7B! It is supposed to loop until the boot disk is found, even if that means looping forever. Could you confirm your STOP error code? I guess I need to add a message so that you can tell if the driver is even invoked.

and no CDDB entry for my ICH9 controller (i.e. iastor not loaded, which results in BSOD until now). Anything else I should try ?

I'm pretty sure you did everything correctly, as long as there weren't any typos. Any chance you could add /SOS to the kernel options in BOOT.INI and observe whether or not waitbt32.sys is loaded by NTLDR? It should be close to the end of the loaded drivers.

PS: in the registry, you probably want to slightly adjust ImagePath, which currently points to wait32.sys instead of waitbt32.sys

Speaking of typos, thanks. I've corrected the previous post.

--- EDIT ---

I've added a message to the driver attached to the previous post. Now if you use the /SOS switch in BOOT.INI, you ought to see "WaitBt: Alive." on the screen which shows the kernel version and number of processors. Please give this a try, Doodoo, and kindly confirm whether the driver is being invoked at all.

[Doodoo]

I've added a message to the driver attached to the previous post. Now if you use the /SOS switch in BOOT.INI, you ought to see "WaitBt: Alive." on the screen which shows the kernel version and number of processors. Please give this a try, Doodoo, and kindly confirm whether the driver is being invoked at all.

Hi Shao, I can now confirm that I can see waitbt32.sys being loaded by NTLDR, and I can also see the message "WaitBt: Alive." on the screen which shows the kernel version and number of processors. But almost immediately after that I also get BSOD 7B, WinVBLock: Alive

[Doodoo]

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ServiceGroupOrder\List Registry value shows the order in which drivers are initialized. So does Microsoft 's Sysinternals' LoadOrd.exe.

Very useful little tool indeed ! I've just tried it, out of curiousity, and the results (on the NC10 notebook where I can boot obviously) are attached.
Here is the interesting bit (I believe)

Boot	System Bus Extender	17*	usbhub	USB2 Enabled Hub

Boot	SCSI miniport       	25  	iaStor Intel AHCI Controller

Boot	SCSI miniport          	n/a*	usbstor	USB Mass Storage Driver

Boot	SCSI miniport       	n/a*	wvblk32	

Boot	SCSI Class           	2   	Disk    Disk Driver

Boot	Base              	n/a*	waitbt	

WinVBlock should always be loaded near or in the SCSI miniport service group. It will thus provide a GenDisk device before 0x7B time. For a sector-mapped disk (your IMG), the backing disk must be available by the time WinVBlock goes looking for it. If the backing disk is USB storage, then the USB disk must be available before WinVBlock goes looking for the backing disk.

Looking at the above results, I was just wondering....usbstor and WinVBlock are in the same group, SCSI miniport. But if for some reason WinVBlock is loaded before usbstor, it's going to be looking for the IMG before the backing disk is availble. Maybe it would help to add tags, in order to make sure WinVBlock is always loaded last in the class SCSI miniport ?
Presumably, if the alphabetical order applies, WinVBlock should come towards the end anyway... But tags might be useful for FiraDisk

Attached Files

•  LoadOrder.txt   4.96KB   7 downloads

[cdob]

W10AddDevice() is only invoked if a CDDB entry associates a device with the driver.

Thanks for clarify. No, I didn't used CCDB, service start=0 only.

USB booting is a timing issue.
Is it possible to solve this at XP default drivers?
How to include winVBlock to default driver stack?

What do you mean? Disk.sys is in the group "SCSI Class".

Open registry, goto services disk:
there is a entry "DependOnGroup" value "SCSI miniport"

There is group and flag setting to set drive load order.
And "DependOnService" and "DependOnGroup" to set driver dependencies.
Can windows be made more USB friendly using this?

Idea, not tested:
USBstor: set "DependOnService" to "usbhub"
at USB boot, WinVBlock: set "DependOnService" to "usbstor"

Unfortunately my testing USB flash is broken in the meantime:
write errors at certain sectors

Curious: at a USB SSD Combo hard disk USB booting does work.
No mass storage controller driver loaded, no USB "DependOnGroup" settings.


@Doodoo
add /bootlog to boot.ini and read ntbtlog.txt.
http://support.micro....com/kb/833721/

[Doodoo]

Open registry, goto services disk:
there is a entry "DependOnGroup" value "SCSI miniport"

I wonder if that could be a partial explanation of the problem, see below:

http://support.micro....com/kb/103000/

DependOnGroup REG_MULTI_SZ Group name
Specifies zero or more group names. If one or more groups is listed, at least one service from the named group must be loaded before this service is loaded.

Therefore, it sounds to me as if the service "disk" could be started as soon as iastor.sys is loaded (in the group "SCSI miniport"), but before wvblk32.sys is loaded.
Maybe it would be beneficial to add to the disk services "DependOnService wvblk32"

Idea, not tested:
USBstor: set "DependOnService" to "usbhub"
at USB boot, WinVBlock: set "DependOnService" to "usbstor"

I tried the same just before you suggested but still gave me BSOD 7B. In fact I have just realised that "USBstor: set DependOnService to usbhub" is probably useless, because the load order is garanteed by ServiceGroupOrder, according to that:

http://support.micro....com/kb/115486/

the order of loading is not guaranteed, other than that all device drivers in a group load before the next group loads.

But now I'm getting really confused... If all device drivers in a group load before any in the next group loads, what's the point of having DependOnGroup, with the meaning defined above ?

add /bootlog to boot.ini and read ntbtlog.txt.

I have tried it, but had EWF enabled... It looks like it didn't produce any logfile.... I need to try again

On a different note, I tried to replace usbhub.sys with the XP Embedded version. And I didn't get a BSOD... So that really makes a difference.
My understanding is that replacing usbstor.sys is not critical, it just makes the boot volume fixed, and thus prevents the user from ejecting it....

Some useful information (although not fundamentally new) here: http://blogs.msdn.co...nformation.aspx
and here: http://iorboaz.blogs...ndows-2003.html
The former mentions "verify that your BIOS is enumerating your UFD by using the XPE instrumented NTDETECT". What is this ? Can it be of any help ?
The latter mentions: "only usbhub.sys was an absolute must for me to boot XP SP3 but both [i.e. usbstor.sys too] were necessary for me to boot Windows Server 2003 SP2"

[Doodoo]

The former mentions "verify that your BIOS is enumerating your UFD by using the XPE instrumented NTDETECT". What is this ? Can it be of any help ?

OK I've just found the answer:

Download http://www.microsoft...DF-AABBAA78914F

The BIOS may fail to properly enumerate USB bootable devices, which results in a blue screen and failure of USB boot. When troubleshooting USB boot failure, use the USBNTD.CHK tool and the following procedure to verify that the BIOS properly enumerates USB bootable devices. To verify USB bootable devices

• Copy USBNTD.CHK from the Value Add folder on the installation disk to the USB boot medium and rename it NTDETECT.COM.
• Boot the device.
• The tool displays the bootable devices identified by the BIOS.

If bootable devices are found, the following output appears:
Enumerating Interrupt 13 disks found on this system
DriveSelect-MaxCylinders-SectorsPerTrack-MaxHeads-NumberDrives <NNN>-<NN>-<N>-<NN>-<NNN> ... <NNN>-<NN>-<N>-<NN>-<NNN> Enumeration done. Press a key to continue...

[Sha0]

...I can now confirm that I can see waitbt32.sys being loaded by NTLDR, and I can also see the message "WaitBt: Alive." on the screen which shows the kernel version and number of processors. But almost immediately after that I also get BSOD 7B, WinVBLock: Alive

Ok, thanks again! Attached to this post is a version which should provide the error message. Would you please give it a try?

...I was just wondering....usbstor and WinVBlock are in the same group, SCSI miniport. But if for some reason WinVBlock is loaded before usbstor, it's going to be looking for the IMG before the backing disk is availble. Maybe it would help to add tags, in order to make sure WinVBlock is always loaded last in the class SCSI miniport ?
Presumably, if the alphabetical order applies, WinVBlock should come towards the end anyway... But tags might be useful for FiraDisk

Well actually, WinVBlock goes looking for the backing disk once Windows first tries to read the sector-mapped disk, so this is a little later than the stage you are considering. I think the ordering you have is fine.

USB booting is a timing issue.

Agreed.

Is it possible to solve this at XP default drivers?

I think a third-party helper is needed, such as the WaitBt driver attached to this post (once any bugs are ironed out).

How to include winVBlock to default driver stack?

I don't understand this question; sorry. I also notice that this thread of discussion sporadically goes from "USB booting -- STOP 0x7B prevention" to "Booting image file on USB -- STOP 0x7B prevention."

there is a entry "DependOnGroup" value "SCSI miniport"

Right. Thanks for clarifying what you meant by "connected."

Curious: at a USB SSD Combo hard disk USB booting does work.
No mass storage controller driver loaded, no USB "DependOnGroup" settings.

If it's all about timing, it will be very difficult to gain an understanding without kernel debugging. Why? Because experiments will yields "success" and "failure" based on something you are not measuring in your experimentation.

The latter mentions: "only usbhub.sys was an absolute must for me to boot XP SP3 but both [i.e. iastor.sys too] were necessary for me to boot Windows Server 2003 SP2"

I think it is possible to piece together from the current thread of discussion why NTDETECT.COM might have anything to with USB booting.

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