196 replies to this topic

[Doodoo]

Thanks for your hard work and finding solution for Dell laptop.

Until now I added CriticalDeviceDatabase entries derived from iaAHCI.inf for Intel AHCI Controller (ending on cc_0106)
Your results mean that I have to add additionally the CDD entries derived from iaStor.inf for Intel RAID Controller (ending on cc_0104)

You're very welcome, Wimb !!
To be very honnest, I'm more than happy to have spent some time on this issue, and to have contributed to improving your tools ! I wouldn't bother if I wasn't a happy user of your tools, and if I didn't care about improving them....

In fact, I effectively noticed that the CDDB entries in your iastor.reg were entirely derived from iaAHCI.inf and none from iastor.inf.
Because I really don't know anything about INF files, I assumed there was a good reason for doing so. But it sounds like your iastor.reg has to be updated, as new versions of the driver are released.
Nevertheless, according to the discussions we've had with Shao, ideally iastor.sys (add associated CDDB entries) should not be required at all to boot from USB. This is the USBoot approach, which (as far as understand) seems to be very robust, because it doesn't need updating with -present or future- drivers.There is still something we need to understand so that XP and Win7 can boot on any machine without iastor.sys (granted that you might not be able to see the internal HDD, but that's another issue). Are you happy to go down this route ?

[Doodoo]

As I see it we cannot find a satisfying theory explaining the issue at hand by merely taking here and there bits and pieces (which are anyway welcome ) we need to do (unfortunately a lot of ) tests aimed to EXCLUDE the possible before excluding the impossible and (still unfortunately) due to past experience, we cannot tag as "impossible" even quite a lot of things that make no or very little sense (remember we are talking of doing non-standard things in a closed source, mostly UNdocumented proprietary OS, reknown for having the queerest possible issues) .

Message received. I know who amongst us is NOT the expert, and I'm happy to do as I'm told. Yes I have taken here and there bits and pieces (which are sometimes slighlty out of topic), but I believe many tricks which make the sucess of USBoot.org are discussed in the historical thread.... Hopefully a few selected quotes will get one of the experts here on the right tracks to make complete sense of it (it is highly unlikely I will).

[Doodoo]

Back to basics: do you use Dietmar's ntdetect.com?

Yes I have tried it but it doesn't help. You can find some background information here and in the next few dozens posts.

Current Dell BIOS and grub4dos: don't use map --mem

I'm not using map --mem but just map. This is effectively your own method, described here.

[Doodoo]

I hope this information helps!

So many thanks Shao, for all this useful information
Now I need some time to digest it ! It sounds like all the key ingredients taken care of by USBoot ArcPath and USBoot DriveGuard are here... Now there is just to figure out what they really do and how, to prevent these BSODs !!
By the way, my wife didn't bring her laptop home last night, and she's off work today.... So I won't be able to report how things go with your wait10.sys before a couple of days, but I can't wait.... I have a sneaking suspicion it will boot nicecely, and I have just realised that when I install DriveGuard (without proper activation), it might just spend some time making a few checks but at the end of the day doing nothing....

[MedEvil]

I may be getting old and forgetful , but really don't remember having seen an IDE drive with a "Stand-alone" jumper

Yes some manufacturers had master/slave/singledrive jumper, but more common was master-singledrive/slave.

[Doodoo]

Putting all of this together, a STOP 0x7B is thrown when the ARC name specified by BOOT.INI does not resolve to a volume that can be opened.

Dietmar is exactly on the same line :
http://www.911cd.net...ndpost&p=101631

Why this bluescreen appears is, because you have no arcpath.

By the way, could you shed more light on what the effect of the "the third and the fourth registry keys" in the above post is ?

Also, based on the known rules to determine the ARC name(s) for the disk(s), is it possible to make sure that the boot vokume is known as rdisk(0)partition(1) ??
This is something that USBoot seems to be able to do (although the link below is not related to boot isues):
http://www.911cd.net...&hl=&pid=124387

In fact, thinking about it, I suppose it doesn't really work like that, but the other way around... It looks like USBoot ArcGuard is in charge of resolving the ARC path of the system volume, in order to protect the right one with the EWF filter. This is what you can found in the registry of a USBoot enabled XP:

[HKEY_LOCAL_MACHINE\systemdst\ControlSet002\Services\ubarcgd\Parameters\Tasks\01]

"ArcName"="SystemVolume"

"Drive"="C:\\"

"File"="!SysVol!.3D866D1B"

"Id"="rootSysvol"



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

"ArcName"="SystemVolume"

Note that usually (such as in Wimb's tools), you'd get something like:

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

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

But how a storage adapter that is unrelated to the boot volume can have any impact on one's ability to get past a STOP 0x7B, I am sticking to my guesses for now.

I can't wait to solve the mystery too...

[Sha0]

Dietmar is exactly on the same line...

I learned something about someone at that post you shared, completely unrelated to any technical discussion. Thanks for sharing that link.

By the way, could you shed more light on what the effect of the "the third and the fourth registry keys" in the above post is ?

I saw 0 Registry keys at that link you shared. Which are you referring to?

Also, based on the known rules to determine the ARC name(s) for the disk(s), is it possible to make sure that the boot volume is known as rdisk(0)partition(1) ??

The boot volume ought to match whatever BOOT.INI ARC name choice was used. A boot driver can certainly create its own symbolic link to whatever, but I'd expect that when Windows attempts to create the same symbolic link (if it can match the disk signature), it would encounter an error. I have not tested whether or not this would result in a different STOP error.

In fact, it's possible to write a no7b_32.sys driver which will prevent STOP 0x7B from ever occurring... All it needs to do is to provide a fake disk with a partition with a usable filesystem and an SMSS.EXE in that filesystem, and spoof the MBR signature and boot partition offset to match what IoGetBootDiskInformation() tells us is expected. But that wouldn't be too useful.

This is something that USBoot seems to be able to do (although the link below is not related to boot isues):
http://www.911cd.net...&hl=&pid=124387

How is anyone using EWF without Windows XP Embedded? Do the licensing terms allow for that?

In fact, thinking about it, I suppose it doesn't really work like that, but the other way around... It looks like USBoot ArcGuard is in charge of resolving the ARC path of the system volume, in order to protect the right one with the EWF filter. This is what you can found in the registry of a USBoot enabled XP:

[HKEY_LOCAL_MACHINE\systemdst\ControlSet002\Services\ubarcgd\Parameters\Tasks\01]

"ArcName"="SystemVolume"

"Drive"="C:\\"

"File"="!SysVol!.3D866D1B"

"Id"="rootSysvol"



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

"ArcName"="SystemVolume"

Yup. 3D866D1B sure looks like it could be the four-byte signature for the MBR.

[cdob]

The boot volume ought to match whatever BOOT.INI ARC name choice was used.

Is PhysicaldriveN importand too?

Physicaldrive0 may change at USB boot.
With and without internal hard disk and different BIOS set Physicaldrive0 to USB drive or a internal hard disk.

[Sha0]

Is PhysicaldriveN importand too?

Physicaldrive0 may change at USB boot.
With and without internal hard disk and different BIOS set Physicaldrive0 to USB drive or a internal hard disk.

Important for what? It's not important for STOP 0x7B. You can use WinObj and see that the \\.\PhysicalDriveXX objects are symbolic links to the "whole device" "partition 0". I believe that it is the order of creation of the \Device\HarddiskXX directories which determines the order of the PhysicalDriveXX symlinks.

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

First come, first serve?

[MedEvil]

A related question.
Diskimages are loaded into ramdisks at pio mode. Any chance to get them loaded with UDMA by some driver tricks, at least theoretical?

[Doodoo]

I saw 0 Registry keys at that link you shared. Which are you referring to?

Ooops I mixed everything up. That's the link:
http://www.911cd.net...indpost&p=90809
Look for "third and fourth" keys you will understand what I'm referring to.

How is anyone using EWF without Windows XP Embedded? Do the licensing terms allow for that?

Yes, as far as I understand. You can download XP Embeded trial from Microsoft in order to get the driver. These files are obviously not redistributable, though.
Great info here: http://blog.granturi...earch/label/ewf
and these: http://www.saunalaht...ws_embedded.php

[Sha0]

A related question.
Diskimages are loaded into ramdisks at pio mode. Any chance to get them loaded with UDMA by some driver tricks, at least theoretical?

Dunno. Does this help?

[MedEvil]

Dunno. Does this help?

Nope, wrong topic.
This deals with transfer modes in a running XP, when atapi.sys is used.
In a PE atapi.sys get's not used before the XP Bootscreen with the blue bar runs. Which happens in a ramboot system not until after the image is already loaded, which is useless since a RAM-Disk does not care about PIO or UDMA mode.

No, what i'm talking about, is a way to enable setupldr to load the image at higher speeds. I think setupldr uses BIOS calls to load the image.

[Sha0]

Look for "third and fourth" keys you will understand what I'm referring to.

You meant "third and the fourth", I think.

By the way, could you shed more light on what the effect of the "the third and the fourth registry keys" in the above post is ?

Have you read this? 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!

Yes, as far as I understand. You can download XP Embeded trial from Microsoft in order to get the driver. These files are obviously not redistributable, though.

I've downloaded a Windows XP Emebbed trial several years ago and had fun evaluating it. I did not try EWF but am familiar with its purpose. 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.

- DESCRIPTION OF OTHER RIGHTS, CONDITIONS AND LIMITATIONS
- Evaluation Only/Time Sensitive Runtimes. The SOFTWARE is provided only for the internal testing and evaluation purposes described in this EULA. ...
- Limitations on Reverse Engineering, Decompilation, and Disassembly. ...
- No Distribution. ...
- Competing Product. ...
- Device Limitations. ...
You may not use or include the SOFTWARE, nor any components thereof, including without limitation the Runtimes, in the development of a general purpose computing device...
- Prerelease Code. ...
- Maintenance. ...
- No Rental/Transfer. ...
- Acceptance. ...

[Sha0]

Diskimages are loaded into ramdisks at pio mode.

No, what i'm talking about, is a way to enable setupldr to load the image at higher speeds. I think setupldr uses BIOS calls to load the image.

Ah. That makes sense. I can load a disk image from an iSCSI disk as an ImDisk RAM disk, so your first statement confused me. Thanks for clarifying.

Any chance to get them loaded with UDMA by some driver tricks, at least theoretical?

So if you are talking about SETUPLDR/NTLDR RAM disk loading, that's at pre-kernel time. There is only one usable driver at pre-kernel time, NTBOOTDD.SYS, right? In addition:

When SETUPLDR starts from an HDD partition, it only makes sense for it to use INTerrupt 0x13 (BIOS) access to the HDD. Why? Because it has not been pre-configured to use a particular driver for the HDD access; it must work on any computer and INT 0x13 access is obviously available on any computer which provides INT 0x13 for booting an HDD.

I think setupldr uses BIOS calls to load the image.

[MedEvil]

You see, i miss two important information about NTBOOTDD.SYS.
Would this driver already be used to load the ramdiskimage or will this driver only be used after the kernel takes over?
Your link sounds like prekernel, but not sure.

Would UDMA even be possible with a NTBOOTDD.SYS version of atapi.sys.
Or is there another reason, why UDMA is not supported by any NT Bootloader?

Hope you can clear this up for me.

[Sha0]

...information about NTBOOTDD.SYS.
Would this driver already be used to load the ramdiskimage or will this driver only be used after the kernel takes over?

NTBOOTDD.SYS is used when a scsi() ARC name is used. NTBOOTDD.SYS is almost always going to be a copy of some other FOO.SYS file which ought to be a boot-start SCSI miniport-group driver referenced in the SYSTEM hive.

NTLDR will load NTBOOTDD.SYS when a scsi() ARC name is chosen. It will load the other FOO.SYS copy again when it loads all boot-start drivers.

NTBOOTDD.SYS is used pre-kernel. Whatever driver it is a copy of (if any) will be used post-kernel.

The following does not invoke NTBOOTDD.SYS:

[boot loader]

timeout=30

default=ramdisk(0)\WINDOWS



[operating systems]

ramdisk(0)\WINDOWS="MS RAMDISK XP" /fastdetect /sos /rdpath=scsi(0)disk(0)rdisk(0)partition(1)\xp_img.fat /rdimageoffset=0

The error message is:

Windows could not start due to an error while booting from a RAMDISK.
Windows failed to open the RAMDISK image.

Your link sounds like prekernel, but not sure.

Yes it's pre-kernel but the BOOT.INI sample above doesn't seem to help.

Would UDMA even be possible with a NTBOOTDD.SYS version of atapi.sys.

I don't know for sure, but I don't know what would prevent it.

Or is there another reason, why UDMA is not supported by any NT Bootloader?

What makes you think it isn't? I'm sorry that I do not know.

[MedEvil]

What makes you think it isn't? I'm sorry that I do not know.

It did some work on this with cdob, last year or the year before.
We changed CD layouts for PE to improve bootspeed.

The further a file is positioned toward the rim of a CD, the higher the possible read speed.
From a certain point on, the CD drive is able to deliver data faster, than pio mode allows to.
Moving files further past this point did not improve bootspeed further. So no UDMA mode in default PE.

I checked then builds with a special driver, if and when UDMA works.
Timimgs with the special UDMA driver and the default atapi driver, showed that there was no difference pre kernel, only post kernel did things speed up.

For running a PE straight of a CD, this is still very useful, since the majority of files is loaded post kernel. But not for a ramboot, cause the loading of the image happens pre kernel.

[cdob]

XP SP3, VMware Player.
USB flash drive attache as a USB drive. Fixed bit set by firmware: hard disk
Booted by PloP.
XP does boot from USB drive.

IDE controller deleted at device manager. File mshdc.inf deleted.
No SCSI controller attached.
Reboot to BSOD 0x7B.

XP Embedded usbhub.sys and usbstor.sys copied to system32\drivers
XP does boot from USB drive.

XP SP3 usbstor.sys restored again: XP does boot from USB drive.
XP SP3 usbhub.sys restored again: BSOD 0x7B

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.


XP Embedded usbhub.sys copied to syste32\drivers
XP does boot from USB drive.

Did I messed wait10.sys usage?

"USBoot DriveGuard" is a disk PNP filter driver.

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

[Wonko the Sane]

OT , but not much , I seem to remember that Dietmar at the time reported "more compatibility" (or if you prefer better chances of success booting) with XP SP1 USB*.SYS drivers than with SP2 ones.
The USBHUB.SYS being a "critical" file may also explain or at least be connected with this other issue:
http://reboot.pro/5209/page__st__30
though it is often connected with "absolute" USB bootability (BIOS/real mode) I seem to remember also cases of 0x0000007b connected to the actual port.

Another small piece of information is that AFAICR, Windows XP embedded sported the "feature" of USB booting in 2007 BUT it uses a "standard" XP SP1 NTDETECT.COM.
So it is possible that the problem (and solution) is not "only" in NTDETECT.COM or "only" in any USB*.SYS but in a combination of the two.



Wonko

[Doodoo]

NTBOOTDD.SYS is used when a scsi() ARC name is used. NTBOOTDD.SYS is almost always going to be a copy of some other FOO.SYS file which ought to be a boot-start SCSI miniport-group driver referenced in the SYSTEM hive.

Details are quite a bit beyond my understanding... But I have seen reports saying the very same thing, (from trusted sources, ...Tim... (aka Usboot.org) and Dietmar):
http://www.911cd.net...&hl=&pid=138203
http://www.911cd.net...&hl=&pid=125684

[Doodoo]

Is PhysicaldriveN importand too?

Physicaldrive0 may change at USB boot.
With and without internal hard disk and different BIOS set Physicaldrive0 to USB drive or a internal hard disk.

Important for what? It's not important for STOP 0x7B. You can use WinObj and see that the \\.\PhysicalDriveXX objects are symbolic links to the "whole device" "partition 0". I believe that it is the order of creation of the \Device\HarddiskXX directories which determines the order of the PhysicalDriveXX symlinks.

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

First come, first serve?

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

[Wonko the Sane]

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 ?

Hmm that would give a sense to the "Arc Guard" service.
In BOOT.INI the disk/volume is identified by an arc path, compare with the Recovery Console Command map and map arc:
http://www.microsoft...p.mspx?mfr=true


Wonko

[Doodoo]

Please accept my apologies for lagging a bit behind you guys, but I would like to keep track of the conversation, before it really gets to a territory where I will NOT understand a single thing (it might have to get there though, for all problems to be solved )

XP SP3, VMware Player.
USB flash drive attache as a USB drive. Fixed bit set by firmware: hard disk
Booted by PloP.
XP does boot from USB drive.

IDE controller deleted at device manager. File mshdc.inf deleted.
No SCSI controller attached.
Reboot to BSOD 0x7B.

Sorry if I am a bit thick... But is this supposed to demonstrate that (at least under certain circumstances) XP doesn't like the absence of internal HDD ?

XP Embedded usbhub.sys and usbstor.sys copied to system32\drivers
XP does boot from USB drive.

XP SP3 usbstor.sys restored again: XP does boot from USB drive.
XP SP3 usbhub.sys restored again: BSOD 0x7B

Presumably this shows that usbhub.sys is critically important ?

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.

At this point I'm a bit lost. Shao suggested to use wait10.sys in lieu of a storage adapter driver, in order to "change the timing of events and give enough time for the volume on the USB storage to become available before the boot volume is looked-for".
But here you use wait10.sys in lieu of intelppm... Is it known if intelppm is loaded before the boot volume is looked-for ? Presumably it is garanteed for storage adapter drivers.

XP Embedded usbhub.sys copied to syste32\drivers
XP does boot from USB drive.

Ok, so usbhub.sys really is critical.

"USBoot DriveGuard" is a disk PNP filter driver.

Could you ellaborate a bit ? You seem to know more about DriveGuard than most people here !! Is it doing the same thing as dummydisk.sys or cfadisk.sys ? Anything different ? Anything more ?

[Doodoo]

OT , but not much , I seem to remember that Dietmar at the time reported "more compatibility" (or if you prefer better chances of success booting) with XP SP1 USB*.SYS drivers than with SP2 ones.
The USBHUB.SYS being a "critical" file may also explain or at least be connected with this other issue:
http://reboot.pro/5209/page__st__30

If I may, can I add something along the same line, by the very author of USBoot:

http://www.911cd.net...ndpost&p=122156

Though I haven't tried the tutorials myself as I'm using another approach, I guess that the problem is somehow connected to certain changes in the USB drivers that were made by Microsoft after SP1 because of some problems with USB power states.

So I would first advise you to use the XP SP1 drivers (if you not actually already do) and if this doesn't help you may replace usbhub.sys by a renamed copy of usbhubb.sys from XP embedded 2007.

Nevertheless, as we speak, USBoot.org does not require any modification to the system files whatsoever, neither usbhub.sys, nor ntdetect.com, and yet it seems to work 100% as far as I understand.