196 replies to this topic

[Doodoo]

Have you read this?

Yes I have, even before you asked this question !! Very very useful for guys like me who don't know much about the internal mechanics of windows but are trying to learn.

The Registry keys I think you're referring to are CDDB entries. What is your impression of what CDDB entries do, given post #24 and the "this" link I just gave? Try taking a guess at what they are for. If you make a mistake, your guess might reveal what piece is missing from your understanding, or else you will be correct!

OK here is my guess.

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\CriticalDeviceDatabase\USB#Vid_1058&Pid_0300]

"Service"="usbstor"

"ClassGUID"="{36FC9E60-C465-11CF-8056-444553540000}"

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 ?

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\CriticalDeviceDatabase\USBSTOR#DiskWDC_____WD1600BB-00FTA0_15.0]

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

"Service"="disk

My understanding is that this bit asks "disk.sys" to drive the disk with specified HardwareID. The ClassGUID is effectively that of a disk. Presumably, in the hierarchy of things, the "disk" is one (or a few) level down the "USB device" in the previous registry entry ?

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

However, I still have the LICENSE AGREEMENT.RTF file and it reads to me like one cannot simply keep using EWF forever nor use it with a Windows that is not Windows Embedded.

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

strings \windows\system32\drivers\disk.sys | findstr /i disk

What is this "strings" command that you use ? I couldn't find anything like it....

[MedEvil]

@MedEvil
Use a BIOS or firmware with UDMA enabled, e.g. a Promise Ultra TX.

How do i do that? Havn't seen any description like that on a manufacturers site.
Besides, wouldn't it be kinda pointless? It's not a solution that can be carryed around with the PE.

[Sha0]

wait10.sys renamed to intelppm.sys and registry settings:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\intelppm]
"Start"=dword:00000000
"Group"="System Bus Extender"

BSOD 0x7B.
...
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 ?

I agree.

OK here is my guess.

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\CriticalDeviceDatabase\USB#Vid_1058&Pid_0300]

"Service"="usbstor"

"ClassGUID"="{36FC9E60-C465-11CF-8056-444553540000}"

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

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\CriticalDeviceDatabase\USBSTOR#DiskWDC_____WD1600BB-00FTA0_15.0]

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

"Service"="disk

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 's Sysinternals' LoadOrd.exe.

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 disk

What is this "strings" command that you use ? I couldn't find anything like it....

Another great tool from Sysinternals.

By the way, in the MS article you shared a link for, there is a section that includes:

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

[Doodoo]

As far as I know, the index for each Windows disk corresponds to first-come, first-serve 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

Thinking again about it, I remember (and it struck me) that when I booted my IMG from USB on my dekstop PC, the boot volume (C:) was located on PhysicalDrive6 in disk management (PhysicalDrive0 was the internal HDD, PhysicalDrive1 the USB stick I was booting from, PhysicalDrive2 to 5 assigned to a multi-card-reader, and PhysicalDrive6 the actual WinVBlock disk...).

However, this http://www.911cd.net...&hl=&pid=124387
seems to go even further: rdisk(0)partition(1) may have a different meaning before boot (when boot.ini is processed), and after boot (when the EWF filter is enabled). Or is it the same issue but I didn't realise it ?

But in addition, a CDDB entry is only used if the device has not already been properly installed with an .INF file.

Can a USB stick or even a USB HDD ever be installed with an INF file ? When windows automatically recognises the device, does it create the very same CDDB entry we are talking about, or does it create some other entries ?

I'm not sure I know what you mean by that. If you mean the timing of things

Most likely the representation I have in my mind is over-simplified. But I think of hierarchy as one bigger object containing a smaller one, which contains an even smaller one... But you're right it is probably better (and yet still simple) to think about it in terms of timing, or in terms of providing a capability: first usbstor.sys drives the USB device, so that disk.sys can in turn drive the disk, so that eventually wvblk32.sys can drive the file-backed disk.

Now, in the context of booting from USB, presumably the device we are trying to boot from should have a CDDB entry, or I should say a number of entries (e.g. one for the device, one for the disk, possibly one for the file back disk, etc...), or it won't work ?

In fact, inspection of the CDDB list in a USBoot enabled XP is fairly interesting (see attached file): the USBoot scripts automatically create CDDB entries for ALL the USB devices and disks found in windows INF files (this is a time consuming exercise, but I think trying USBoot once for yourself would be very instructive indeed). This would also explain why USBoot doesn't seem to require that the target USB device ever be recognised by XP.

Nevertheless, I have checked that the very USB stick I am booting from doesn't have a CDDB entry created by USBoot, and yet it works.... But I understand that most devices have a list of compatibleIDs, which, presumably would (almost) always be found in windows INF files ? Am I making this up or is it sensible ?

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.

Using files not included in XP (such as ewf.sys) seems to be a violation of MS license agreements, but can it be argued that for some other files, you can start from the version existing in XP (e.g. ntdetect.com or usbhub.sys) and apply a patch of your own to obtain a different version, which happens to be similar (if not identical) to the version found in XP Embedded ?

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

Results tomorrow morning. In the meantime, anyone can make the same experiment, e.g. on any laptop or desktop computer requiring iastor.sys, but taking care to delete all the CDDB entries in wimb's iastor.reg. Everyone should still be able to boot, granted they won't be able to see the internal HDD.

Attached Files

•  xp-usboot-phase123-CDDB.7z   4.31KB   12 downloads

[Sha0]

However, this http://www.911cd.net...&hl=&pid=124387
seems to go even further: rdisk(0)partition(1) may have a different meaning before boot (when boot.ini is processed), and after boot (when the EWF filter is enabled). Or is it the same issue but I didn't realise it ?

Pre-kernel, the multi() ARC names should correpond to INT 0x13 drives. Post-kernel, there is no such thing as an INT 0x13 drive, so the ARC names have to be determined somehow else (as previously discussed). So it's easily possible (and even useful, sometimes) for an ARC name to resolve to a different drive pre- than post-.

Since I haven't tried EWF (except for once during XP Embedded testing which I can't remember very well), I don't know how it determines which disk(s)/volume(s) to protect.

If someone installs XP to an IDE HDD and then copies that HDD to a USB disk, if Windows happens to find the IDE disk before the USB disk, it makes sense that the "XP Kansas City Shuffle" would happen; the function responsible for assigning ARC names decides that the IDE disk contains the boot volume based on the MBR signature match. How often might this scenario complicate the testing that people are doing? As a matter of removing variables during testing, it can be handy to use the same computer. If the internal disk's MBR is not overwritten with zeroes, it could retain an MBR signature that actually complicates testing.

Can a USB stick or even a USB HDD ever be installed with an INF file ?

It is preferable (in general) to install all devices with their installers or at least with their supporting .INF files. Yes, USB sticks and disks can be installed with .INF files.

When windows automatically recognises the device, does it create the very same CDDB entry we are talking about, or does it create some other entries ?

What device? You might notice the [HardwareIdsDatabase] section in TXTSETUP.SIF. That looks convincingly like the out-of-the-box, initial population of the CDDB. Anyone can add CDDB entries; .INF files, installers, users, .reg imports...

If you are asking about the USB disk, I don't know for sure, but think the answer is no. Since it should be compatible with GenDisk, there's no need for a CDDB entry. If you are asking about a particular PCI USB controller, then yes, I'd suggest having CDDB entries for it.

Most likely the representation I have in my mind is over-simplified. But I think of hierarchy as one bigger object containing a smaller one, which contains an even smaller one... But you're right it is probably better (and yet still simple) to think about it in terms of timing, or in terms of providing a capability: first usbstor.sys drives the USB device, so that disk.sys can in turn drive the disk, so that eventually wvblk32.sys can drive the file-backed disk.

By the way, this post, this post and the "conversation" at the end of this post might be interesting to you.

Now, in the context of booting from USB, presumably the device we are trying to boot from should have a CDDB entry, or I should say a number of entries (e.g. one for the device, one for the disk, possibly one for the file back disk, etc...), or it won't work ?

You might want CDDB entries for the USB Mass Storage Device's IDs (or compatible IDs) -> USBSTOR, and for each parent device.

Nevertheless, I have checked that the very USB stick I am booting from doesn't have a CDDB entry created by USBoot, and yet it works.... But I understand that most devices have a list of compatibleIDs, which, presumably would (almost) always be found in windows INF files ? Am I making this up or is it sensible ?

Quite sensible. Device Manager, View -> Devices by connection. Find the USB disk. It'll have GenDisk as an ID of some sort. Look at the parent device. Check if it has CDDB entries. If not, they might not be needed because the device has already been properly installed with an .INF file... Probably long ago.

Using files not included in XP (such as ewf.sys) seems to be a violation of MS license agreements, but can it be argued that for some other files, you can start from the version existing in XP (e.g. ntdetect.com or usbhub.sys) and apply a patch of your own to obtain a different version, which happens to be similar (if not identical) to the version found in XP Embedded ?

I don't know what the universal legal ratio is. For example, someone could have a 1-byte file and "patch" it to become the latest movie.

Results tomorrow morning. In the meantime, anyone can make the same experiment, e.g. on any laptop or desktop computer requiring iastor.sys, but taking care to delete all the CDDB entries in wimb's iastor.reg. Everyone should still be able to boot, granted they won't be able to see the internal HDD.

Thanks a lot! If it turns out that "wait for USB storage device to be available" is a big key piece, perhaps an open source and trivial driver could help with that requirement; some future wait10.sys or something!

[Doodoo]

Thanks a lot! If it turns out that "wait for USB storage device to be available" is a big key piece, perhaps an open source and trivial driver could help with that requirement; some future wait10.sys or something!

Shao, you deserve a big round of applause, a la Dietmar :
ITWORKS ITWORKS ITWORKS ITWORKS

Screen capture on the Dell laptop:

Attached Files

•  desktop.PNG   253.9KB   24 downloads

[Doodoo]

Since I haven't tried EWF (except for once during XP Embedded testing which I can't remember very well), I don't know how it determines which disk(s)/volume(s) to protect.

The protected volumes are determined with their arc path:

[HKEY_LOCAL_MACHINE\systemdst\ControlSet002\Services\ewf\Parameters\Protected\Volume0]

"ArcName"="multi(0)disk(0)rdisk(0)partition(1)"

But for the reasons that we have just discussed, rdisk(0)partition(1) might not be the boot volume, even if boot.ini says so. Therefore if you want to protect the boot volume, you have to be a bit more clever than that, which is I think where USBoot ArcGuard comes into play.
Still, it must be more subtle than that, because on my XP tweaked with wimb's tools, the boot volumes is properly protected by the EWF filter, although the registry says protect "rdisk(0)partition(1)" but disk manager reports my boot volume on PhysicalDisk6....

If someone installs XP to an IDE HDD and then copies that HDD to a USB disk, if Windows happens to find the IDE disk before the USB disk, it makes sense that the "XP Kansas City Shuffle" would happen; the function responsible for assigning ARC names decides that the IDE disk contains the boot volume based on the MBR signature match.

This sounds like a very likely scenario if anyone "clone" their HDD.... As far as I am concerned I think I have not been affected, because I have always tried to boot from an IMG, which was created from scratch with its own signature (wimb's tools look after MountedDevices to make sure the boot volume is mounted as C:)

I don't know what the universal legal ratio is. For example, someone could have a 1-byte file and "patch" it to become the latest movie.

Yes that's a never ending debate....

[Sha0]

Shao, you deserve a big round of applause, a la Dietmar :
ITWORKS ITWORKS ITWORKS ITWORKS

Well I'm certainly glad to read that. Guess #2 has more evidence, then. I sincerely appreciate your willingness to test, Doodoo.

Here are the files for this extremely trivial driver:

wait10.c:

/**

 * Copyright (C) 2011, Shao Miller <shao.miller@yrdsb.edu.on.ca>.

 *

 * This program is free software: you can redistribute it and/or modify

 * it under the terms of the GNU General Public License as published by

 * the Free Software Foundation, either version 3 of the License, or

 * (at your option) any later version.

 *

 * This program is distributed in the hope that it will be useful,

 * but WITHOUT ANY WARRANTY; without even the implied warranty of

 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the

 * GNU General Public License for more details.

 *

 * You should have received a copy of the GNU General Public License

 * along with this program.  If not, see <http://www.gnu.org/licenses/>.

 */



/**

 * @file

 *

 * Wait 10 seconds driver specifics.

 */



#include <ntddk.h>



KEVENT dummy_event;



static NTSTATUS W10AddDevice(

    IN PDRIVER_OBJECT driver_obj,

    IN PDEVICE_OBJECT pdo

  ) {

    LARGE_INTEGER timeout;



    /* 10 seconds. */

    timeout.QuadPart = -100000000LL;

    DbgPrint("Wait10: Waiting...\n");

    KeWaitForSingleObject(

        &dummy_event,

        Executive,

        KernelMode,

        FALSE,

        &timeout

      );

    DbgPrint("Wait10: Done.\n");

    return STATUS_UNSUCCESSFUL;

  }



NTSTATUS DriverEntry(

    IN PDRIVER_OBJECT DriverObject,

    IN PUNICODE_STRING RegistryPath

  ) {

    KeInitializeEvent(&dummy_event, SynchronizationEvent, FALSE);

    DriverObject->DriverExtension->AddDevice = W10AddDevice;

    DbgPrint("Wait10: DriverEntry() done.\n");

    return STATUS_SUCCESS;

  }

wait10.rc:

1 VERSIONINFO

FILEVERSION 0,0,0,1

PRODUCTVERSION 0,0,0,1

FILEOS 0x40004

FILETYPE 0x3 {

    BLOCK "StringFileInfo" {

        BLOCK "000004B0" {

            VALUE "CompanyName", "Shao Miller"

            VALUE "FileDescription", "Wait 10 Seconds Driver"

            VALUE "FileVersion", "0.0.0.1 (March-22-2011)"

            VALUE "InternalName", "Wait 10 Seconds Driver"

            VALUE "LegalCopyright", "© 2011 Shao Miller, All rights reserved, Licensed under GPL."

            VALUE "OriginalFilename", "wait10.sys"

            VALUE "ProductName", "Wait 10 Seconds Driver"

            VALUE "ProductVersion", "0.0.0.1"

          }

      }



    BLOCK "VarFileInfo" {

        VALUE "Translation", 0x0000 0x04B0

      }

  }

wait10.def:

NAME WAIT10.SYS



EXPORTS

  DriverEntry

sources:

TARGETNAME=wait10

TARGETTYPE=DRIVER

TARGETPATH=obj

SOURCES=wait10.c wait10.rc

DLLDEF=wait10.def

To build:

build

[MedEvil]

Sorry, but 2 things still to do.
1. Find a fool proof way to load the driver at the right time without replacing iastore.
2. Change the driver from wait 10 to wait till device ready.

For 1), how about replacing usbhub.sys with your driver, which then in turn loads the real usbhub.sys once done waiting?

[Sha0]

...perhaps an open source and trivial driver could help with that requirement; some future wait10.sys or something!

Sorry, but 2 things still to do.
1. Find a fool proof way to load the driver at the right time without replacing iastore.
2. Change the driver from wait 10 to wait till device ready.

For 1), how about replacing usbhub.sys with your driver, which then in turn loads the real usbhub.sys once done waiting?

Agreed on #1.

For #2, please remember that NTLDR loads boot-start drivers. We cannot load the real usbhub.sys until the FS is available. The FS isn't available until after the boot volume is available. The boot volume isn't available until after the boot disk is available. The boot disk isn't available until after the USB mass storage device is available. The USB mass storage device isn't available until after the USB hub is available. The USB hub isn't available until after usbhub.sys has been loaded.

Don't worry, there's likely another way.

[MedEvil]

Don't worry, there's likely another way.

I think, you must have made a mistake or M$ has no clue, what they're talking about. Cause: "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."

If usbhub.sys is required to work before the device can be initialized, how then can it wait until after this has happened?

[Sha0]

If usbhub.sys is required to work before the device can be initialized, how then can it wait until after this has happened?

I'm pretty sure that the article means that usbhub.sys starts working right away, but ensures that the attached USB mass storage device is initialized before the driver says "I have no more work to do." Thus, when the hub is queried for its children, we are guaranteed that the USB mass storage device is available.

[MedEvil]

Sounds like we would need to increase the timeout in usbhub.sys.
But how your wait.sys should have managed to do this, is beyond me.
I can see one driver delaying another from loading. But one driver causing another to take a nap while running?

[wimb]

@Doodoo and @Sha0

Congratulations with wait10.sys results and better understanding of what is causing BSOD 7B

Hope to implement your results somehow in future versions of IMG_XP package .....

[Doodoo]

Congratulations with wait10.sys results and better understanding of what is causing BSOD 7B
Hope to implement your results somehow in future versions of IMG_XP package .....

Hi Wimb,
I'm really glad we all managed to get to the bottom of this problem (Shao should get all the credits... I've only been learning and experimenting !)
For now, may I make two suggestions ?

• For piece of mind, and have confidence that we're going in the right direction, I think it would be good if you suggested to anyone that still has BSODs 7B with your tools, to replace usbhub.sys with the XP Embedded version (I don't think it wouldn't be appropriate for me to make this suggestion). If all BSODs disappear it will be a significant step. Also, it means you don't need any more to include iastor.sys in your tools, nor to maintain the associated registry tweaks (that would only allow seeing the internal HDD, but wouldn't be help as such to boot)
• Another possible improvement would be (I think) to be inspired by the USBoot approach, and to process Windows native INF files, to add all known USB devices and disks in the CDDB (see this post).This way, it wouldn't be required any more to have the target USB device recognised, and you could copy your XP IMG from device to device without worrying (granted there might be a few exceptions, where e.g. compatibleIDs provide no match)

[Doodoo]

Completely unrelated, but another BSOD 7B challenge: can you explain that one ?

[wimb]

Also, it means you don't need any more to include iastor.sys in your tools, nor to maintain the associated registry tweaks (that would only allow seeing the internal HDD, but wouldn't be help as such to boot)

I prefer to keep option to add iaStor.sys and be Universal, since I would like to see in general the Internal Harddisk.
I agree with all other suggestions but hope that the effect of wait10.sys can be built-in somehow.

[maanu]

hmm i agreed to wimb above. wait10S is good add-on .

by the way , WHERE i can find this new wait10S?

@ shao

i think dear , you should make another topic for this driver and explain in short way the purpose/idea of it.

thanks so much Doodo0 for testing and shao for providing..

[MedEvil]

I realized this morning, that this topic comes a few years to late to be worth the trouble.

Simply take the whole XP and stick it into a ram loading .wim. Wim should be less than 300MB, which means it will work on any computer with at least 500MB RAM.
Any computer that has not at least 500MB RAM surely still has USB1.1 and running XP from a USB-Stick is anyway not an option.

Another nice side effect of this setup is, that no illegal use of drivers is needed.

[wimb]

For computer with BIOS having slow USB bootspeed support,
then booting from FILEDISK on USB is much faster than loading RAMDISK.

Loading RAMDISK for 1.6 GB on USB took me 54 min whereas booting from FILEDISK on USB occurred in only 1.8 min

http://reboot.pro/13...post__p__120249

[Doodoo]

I realized this morning, that this topic comes a few years to late to be worth the trouble.

Well yes and no.... XP is not dead yet, many companies are not rolling out Win7 yet, because of the costs it involves. Spending time on XP sounds like wasting time but I don't think it really is. I can already say that Win7 from USB gives me the same BSOD 7B on the Dell laptop, possibly for the very same reasons.

Simply take the whole XP and stick it into a ram loading .wim. Wim should be less than 300MB, which means it will work on any computer with at least 500MB RAM.

I am NOT AT ALL familiar with all the possibilities and tools which have been developed for Win7 but can however be used on XP. How do you generate this XP.wim and how do you boot it ?

By the way, if anyone cares to investigate why, I should stress again that because of the BSOD 7B I got on the Dell laptop when booting from USB, I tried to boot from RAM indeed, but even that, did not work properly. As said in my first post (there is a lot of stuff in there), it would boot fine (no BSOD), but would freeze completely when the desktop shows up. On the other hand, the same IMG with the extra CDDB registry entry for the ICH9 controller works well when booting from RAM.... But again I can't think of any reason why.

[Doodoo]

hmm i agreed to wimb above. wait10S is good add-on .
by the way , WHERE i can find this new wait10S?

You can download it from here.
But you should understand that for now, it is not entirely fit for purpose. It couldn't be added to wimb's tools and suddenly get everything to work. A good thing to do at the moment if you want to help, is (assuming you get a BSOD in the first place, obviously):

• to replace iastor.sys with wait10.sys, and report if that makes any difference. If your hardware requires another driver than iastor.sys, then replace that one with wait10.sys obviously.
• with the original iastor.sys (or other driver), to replace usbhub.sys with the XP Embedded version, and report if that makes any difference.

[maanu]

my img boots ok on every system in my office , as well any other systems i could boot it on .

i ll look around anyhow, thanks

[MedEvil]

Loading RAMDISK for 1.6 GB on USB took me 54 min whereas booting from FILEDISK on USB occurred in only 1.8 min

1.6GB / 54min = 518KB/s
1.8min = 108sec
518KB/s * 108sec = 54,63MB

So assuming, that loading individual files is just as fast as reading one big continuous file. (Which is never true in my experience.)
Your boot from filedisk can max. have loaded 54,63MB.
My graphics card driver is already bigger than that.

And just for the record, 518KB/s is less than what a 1x DVD drive can deliver (1350 KB/s) and still less, than what a 4x CD drive can deliver (600KB/s). Lately seen one of those?

[Sha0]

Sounds like we would need to increase the timeout in usbhub.sys.

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

But how your wait.sys should have managed to do this, is beyond me.
I can see one driver delaying another from loading. But one driver causing another to take a nap while running?

That's not what it does. The function (in the kernel) which causes STOP 0x7B will be delayed by wait10.sys. By the time it is called, another thread has made the boot volume on the USB mass storage device available.

Completely unrelated, but another BSOD 7B challenge: can you explain that one ?

Dunno Windows 7 very well. Sorry.

...you should make another topic for this driver and explain in short way the purpose/idea of it.

This driver was really just a trivial test which provided evidence for guess #2: Timing of events was changed by the presence of iaStor, thus alleviating the STOP 0x7B. Now that we have this evidence, a better driver is possible. This one has limited use.

thanks so much Doodo0 for testing and shao for providing..

You're welcome, I'm sure.

I realized this morning, that this topic comes a few years to late to be worth the trouble.

For you, perhaps. 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.

Simply take the whole XP and stick it into a ram loading .wim...
...
Another nice side effect of this setup is, that no illegal use of drivers is needed.

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?