wait10.sys renamed to intelppm.sys and registry settings:
"Group"="System Bus Extender"
Did I messed wait10.sys usage?
Unfortunately, yes. wait10.sys
is coded to perform the 10-second wait when its AddDevice
routine is called, not when the driver is merely initialized. It must have a device physically present in the system with a CDDB association so that Windows will request wait10 to drive the device. In addition, I originally recommended replacing iaStor.sys with this because the test would closely mimic the stage
(time) when iaStor apparently "allows" the boot from USB to happen.
OK, so what you guys are saying is that even if after booting XP, inspection of boot.ini says Physicaldrive0, it is not garanteed that PhysicalDrive0 really is what it was thought to be at POST (sorry if I don't use the correct terminology, but you get the idea).
Right. INT 0x13 HDD order (0x80, 0x81, 0x82, etc.) is not inherently known to Windows because Windows doesn't use INT 0x13. So MBR signatures are the only way for Windows to know which Windows
disk corresponds to which INT 0x13
disk. As far as I know, the index for each Windows disk corresponds to first-come, first-served logic. If an iSCSI driver provides iSCSI disks before an iaStor driver provides Intel SATA disks, then I do believe the iSCSI disk would be PhysicalDrive0
. Similarly, often a WinVBlock disk winds up as PhysicalDrive1 if IDE disks are present, even though the WinVBlock disk has the boot volume and even though back when it was a MEMDISK or GRUB4DOS disk, it was INT 0x13 drive 0x80 and the IDE disk was 0x81.
But even if drives have been shuffled for some reason, this will never cause a BSOD 7B, as long as the ARC path resolves to a volume that can be mounted ?
OK here is my guess.
My understanding is that this bit asks "iaStor.sys" to drive the USB device with the specified Vendor and Product ID. I believe the ClassGUID only means "USB". Is that correct ?
Absolutely. But in addition, a CDDB entry is only used if the device has not already been properly installed with an .INF
My understanding is that this bit asks "disk.sys" to drive the disk with specified HardwareID. The ClassGUID is effectively that of a disk.
2 points scored!
Same note about CDDB entries being or not being used as previous.
Presumably, in the hierarchy of things, the "disk" is one (or a few) level down the "USB device" in the previous registry entry ?
I'm not sure I know what you mean by that. If you mean the timing of things, the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ServiceGroupOrder\List
Registry value shows the order in which drivers are initialized. So does Microsoft
What is not clear to me, is in what way is this different (if at all) from just plugging your USB device whilst XP is running, and automativally let it be recognised ?
The only difference that I am aware of is when
your USB storage device is installed; before or after Windows boots the boot volume.
Also, imagine a more complex scenario, where XP is not directly installed on my USB device, but in an IMG which resides on the USB device. Would that require yet another CDDB entry, of an even lower level ? Would that be with a ClassGUID of a disk, a volume, something else ? Which driver should be used ?
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.
What is legal and illegal is a very sensitive subject on this forum these days (no need to give any names). It is not an excuse, but it sounds like without knowing I've been doing something illegal for some time, so have pretty much everyone trying to boot XP from flash media....
Agreed. Using Windows XP Embedded components with non-Embedded Windows might yield more capabilities, but if MS license agreements are violated in the course of one's day-to-day business, that's no good. Also, an audit could identify such violations.
strings \windows\system32\drivers\disk.sys | findstr /i diskWhat is this "strings" command that you use ? I couldn't find anything like it....
great tool from Sysinternals.
By the way, in the MS article you shared a link for, there is a section
During the post-boot phase, the USB hub driver (USBHUB.SYS) was modified to require (wait for) the UFD boot storage device to be initialized.
This might be the big deal in our discussion. I'm definitely interested in the results of using wait10.sys on your wife's laptop (if that was the one with that iaStor CDDB entry).