Jump to content











Photo
- - - - -

BSOD 7B - Finally fixed for me! (maybe for you too...)


  • Please log in to reply
196 replies to this topic

#126 Sha0

Sha0

    WinVBlock Dev

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

Posted 30 March 2011 - 05:23 PM

Perhaps you're not responsible for this....

The "authoritative" post is here. It's possible that it's a common error, as people might be thinking "comment" rather than "she-bang".

#127 Doodoo

Doodoo

    Frequent Member

  • Advanced user
  • 344 posts

Posted 30 March 2011 - 05:33 PM

not only does FiRaDisk require the disk to be ready, it requires the volume with the image file to be ready, too.

I am not sure sure if this is right on topic, or completely out of topic, but when I install USBoot DriveGuard in a fresh, clean XP, I can see the following changes (amongst others) in the registry:


[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Class\{71A27CDD-812A-11D0-BEC7-08002BE2092F}\0008]

"InfPath"="volume.inf"

"InfSection"="volume_install"

"ProviderName"="Microsoft"

"DriverDateData"=hex:00,80,62,c5,c0,01,c1,01

"DriverDate"="7-1-2001"

"DriverVersion"="5.1.2600.0"

"MatchingDeviceId"="storage\\volume"

"DriverDesc"="Generic volume"



[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\DeviceClasses\{53f5630d-b6bf-11d0-94f2-00a0c91efb8b}\##?#STORAGE#Volume#1&30a96598&0&Signature75A6F3A3Offset7E00Length28B0A800#{53f5630d-b6bf-11d0-94f2-00a0c91efb8b}]

"DeviceInstance"="STORAGE\\Volume\\1&30a96598&0&Signature75A6F3A3Offset7E00Length28B0A800"



[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\DeviceClasses\{53f5630d-b6bf-11d0-94f2-00a0c91efb8b}\##?#STORAGE#Volume#1&30a96598&0&Signature75A6F3A3Offset7E00Length28B0A800#{53f5630d-b6bf-11d0-94f2-00a0c91efb8b}\#]

"SymbolicLink"="\\\\?\\STORAGE#Volume#1&30a96598&0&Signature75A6F3A3Offset7E00Length28B0A800#{53f5630d-b6bf-11d0-94f2-00a0c91efb8b}"



[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Enum\STORAGE\Volume\1&30a96598&0&Signature75A6F3A3Offset7E00Length28B0A800]

"Capabilities"=dword:000000e0

"ConfigFlags"=dword:00000000

"HardwareID"=hex(7):53,00,54,00,4f,00,52,00,41,00,47,00,45,00,5c,00,56,00,6f,\

  00,6c,00,75,00,6d,00,65,00,00,00,00,00

"ClassGUID"="{71A27CDD-812A-11D0-BEC7-08002BE2092F}"

"Class"="Volume"

"Driver"="{71A27CDD-812A-11D0-BEC7-08002BE2092F}\\0008"

"Mfg"="Microsoft"

"DeviceDesc"="Generic volume"



[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Enum\STORAGE\Volume\1&30a96598&0&Signature75A6F3A3Offset7E00Length28B0A800\LogConf]


Signature = 75A6F3A3 is indeed the signature of the raw disk image (IMG)
Offset = 7E00 + Length 28B0A800 = 682698240 (decimal) is indeed the size in bytes of the same

Could you shed some light on what these registry entry do ? Can it help at all to avoid BSOD 7B ?

#128 Sha0

Sha0

    WinVBlock Dev

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

Posted 30 March 2011 - 05:57 PM

Could you shed some light on what these registry entry do ? Can it help at all to avoid BSOD 7B ?

I'm not convinced that USBoot DriveGuard has anything to do with those Registry keys and values. Any volume on a USB disk will receive similar treatment once the volume has been installed (which happens automatically as long as you have \Windows\Inf\volume.inf).

The first key is referenced by the Driver value of the corresponding Enum\STORAGE\Volume\ key. It exists for devices which have been properly installed with an .INF file.

The second and third keys correspond to the information you can find using WinObj, but also categorize devices by their interface type. The GUID in the second and third key was mentioned earlier in this thread.

The fourth key represents a storage volume device which Windows has observed to be present at some point in its history.

Yes, volumes are required in order to open files on volumes. If an image file is your boot disk, then yes, those volumes need to be available before the image file is opened... But that is why WinVBlock has the sector-mapped disk feature, which doesn't care about volumes. Only if you tell WinVBlock to hot-swap to a file will a volume be needed, but that happens at a post-STOP-0x7B time, so it won't prevent you from booting the sector-mapped disk.

[volume_install]
;
; Nothing to do (these devices are raw). We just needed an INF
; match so these don't show up as "unknown" devices.



#129 Doodoo

Doodoo

    Frequent Member

  • Advanced user
  • 344 posts

Posted 30 March 2011 - 09:17 PM

And here it is, attached. This one will show the disk signatures and the name of each disk checked.

That works well on my regular comp where it always works.... Attached File  P1010121.png   65.6KB   14 downloads
But now BSOD 7B again on the Dell laptop :-(

#130 wimb

wimb

    Platinum Member

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

Posted 31 March 2011 - 05:05 AM

That works well on my regular comp where it always works.... But now BSOD 7B again on the Dell laptop :-(

Did you try the latest version 2.8 of IMG_XP package, which to prevent BSOD 7B will add extra
CriticalDeviceDatabase entries derived from iaStor.inf for Intel RAID Controller (ending on cc_0104) ?

#131 Doodoo

Doodoo

    Frequent Member

  • Advanced user
  • 344 posts

Posted 31 March 2011 - 08:10 AM

Did you try the latest version 2.8 of IMG_XP package, which to prevent BSOD 7B will add extra
CriticalDeviceDatabase entries ?

No, I didn't try it, but I know it will work. Why ? Because it just adds (amongst others) the registry entry mentioned in this post, which merely changes the timing of things, and (miraculously) gets everything to work.
On the other hand, the exercise we're going through with Shao, consists in deliberately not adding the aforementioned CDDB entry, so as to find the root cause of the problem and the ultimate solution as well (which should work with any SATA/RAID controller, for which XP drivers don't even exist, so you couldn't add the relevant CDDB entry anyway)

#132 Doodoo

Doodoo

    Frequent Member

  • Advanced user
  • 344 posts

Posted 31 March 2011 - 11:11 AM

I'm not convinced that USBoot DriveGuard has anything to do with those Registry keys and values. Any volume on a USB disk will receive similar treatment once the volume has been installed (which happens automatically as long as you have \Windows\Inf\volume.inf).

On closer inspection I think you're right, DriveGuard has nothing to do with that. It's just that my clean XP IMG has EWF filter enabled, so changes are not persistent, and volumes are not installed in there... But as soon as I commit changes (and I have to, in order to install DriveGuard !), these entries appear in the registry.

Yes, volumes are required in order to open files on volumes.

OK I think it all makes sense. It is consistent with your initial distinction between disks and volumes.

But that is why WinVBlock has the sector-mapped disk feature, which doesn't care about volumes. Only if you tell WinVBlock to hot-swap to a file will a volume be needed

Could you try to explain in a few simple words why the sector-mapped disk feature removes the need for a volume driver ? Because sectors are contiguous ? Maybe I'm still a bit confused between disks and volumes afer all.... :smiling9:
Also, what is hot-swap feature ? In which scenario is it useful ?

You are missing the exclamation mark between "#" and "GRUB4DOS"

Thanks, and well spotted :pulpfiction:
It makes all the difference !

#133 Sha0

Sha0

    WinVBlock Dev

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

Posted 01 April 2011 - 02:12 AM

But now BSOD 7B again on the Dell laptop :-(

Well it just occurred to me that WaitBt won't help here because it's not its fault that the boot disk is not available, it's WinVBlock's. If the USB disk wasn't available when WinVBlock went looking for it, then the disk becomes a "dud". This logic could be changed so that WinVBlock will wait for the backing disk to become available, but there might be a catch... If WinVBlock being in a waiting state hangs driver and device initialization, then if the backing disk is not already available, it might never get the chance to be. This will require some testing.

Could you try to explain in a few simple words why the sector-mapped disk feature removes the need for a volume driver ? Because sectors are contiguous ?

Yes. GRUB4DOS passes the contiguous sector range along with the original BIOS drive number of the backing disk (the latter is pretty useless). Thus WinVBlock takes a read request for sector XXX and redirects it as a read request for sector YYY on the backing disk. There are no files and no filesystems involved.

Also, what is hot-swap feature ? In which scenario is it useful ?

Since most often folks are booting an image file (which G4D currently demands to be a contiguous sector range), it is safer to work with an image file; the sectors that make it up are "in use" and so will not be re-purposed by FS defragmentation or other optimization.

#134 Doodoo

Doodoo

    Frequent Member

  • Advanced user
  • 344 posts

Posted 01 April 2011 - 09:42 AM

If the USB disk wasn't available when WinVBlock went looking for it, then the disk becomes a "dud".

Wow, your link couldn't have been more accurate ! :dubbio: Impressive stuff !

This logic could be changed so that WinVBlock will wait for the backing disk to become available,
If WinVBlock being in a waiting state hangs driver and device initialization, then if the backing disk is not already available, it might never get the chance to be.

There is still a (major) detail that I don't get. My understanding is that because of the "groups" assigned to critical drivers, they will always be loaded in the following order:
1. usbehci (Boot Bus Extender) - It could be usbohci or usbuhci depending on the particular machine. Drives the USB controller
2. usbhub (System Bus Extender) - Drives the USB device
3. usbstor (SCSI miniport) - Drives the storage adapter
4. wblk32.sys (SCSI miniport) - Drives the file-backed disk
5. disk.sys (SCSI Class) - Drives the disk

With this scenario (well depicted on Microsoft page for USB booting), I don't understand how a (higher level) device cannot be ready when a (lower level) device needs it...
E.g. how is it possible WinVBlock needs a device that's not available, although it's guaranteed (by groups load order) that all drivers along the path have already been loaded ?

Or perhaps "the driver has been loaded" and "the device is available" are two different things ? (the latter happening some unknown time after the former ? But then if that's the case, the problem we are facing must be happening ALL the time, i mean not only when booting from USB... So how is "the availability" of a device usually detected, as opposed to merely ensuring the driver has already been loaded ?)

As suggested by cdob, maybe this is the kind of problems that can be solved with the registry keys "DependOnGroup" and "DependOnService" ? See this example, where they define the following ServiceGroupOrder:


   	SCSI miniport

   	port

   	Primary disk

   	Load Me First

   	SCSI class

Next they define a new service, sampldrv, configured as follows:

   		\registry\machine\system\currentcontrolset\services\sampldrv

   		Group = Load Me First

   		DependOnGroup = REG_MULTI_SZ "SCSI miniport"

What's the point of having DependOnGroup = "SCSI miniport" (which means, at least one service in group in group "SCSI miniport" must be started before service sampldrv can be loaded), when it is garanteed anyway by ServiceGroupOrder that all drivers in group SCSI miniport will be loaded before any in the group Load Me First (which sampldrv belongs to) ?

I can only make sense of that, if "DependOnGroup" or "DependOnService" actually allow to delay loading a driver, till after some device is available (as opposed to till after some driver has been loaded). Does it make any sense ?

#135 Sha0

Sha0

    WinVBlock Dev

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

Posted 01 April 2011 - 04:06 PM

Wow, your link couldn't have been more accurate ! :dubbio: Impressive stuff !

Well, I do remember writing the code...

There is still a (major) detail that I don't get. My understanding is that because of the "groups" assigned to critical drivers, they will always be loaded in the following order:
1. usbehci (Boot Bus Extender) - It could be usbohci or usbuhci depending on the particular machine. Drives the USB controller
2. usbhub (System Bus Extender) - Drives the USB device
3. usbstor (SCSI miniport) - Drives the storage adapter
4. wblk32.sys (SCSI miniport) - Drives the file-backed disk
5. disk.sys (SCSI Class) - Drives the disk

That's not the issue. The issue is all at #5 and later, above. When the disks are probed for their MBRs, that is when WinVBlock goes looking for the backing disk. If the backing disk is not yet available, that's too bad.

...how is it possible WinVBlock needs a device that's not available, although it's guaranteed (by groups load order) that all drivers along the path have already been loaded ?

Or perhaps "the driver has been loaded" and "the device is available" are two different things ?

Right.

What's the point of having DependOnGroup = "SCSI miniport" (which means, at least one service in group in group "SCSI miniport" must be started before service sampldrv can be loaded), when it is garanteed anyway by ServiceGroupOrder that all drivers in group SCSI miniport will be loaded before any in the group Load Me First (which sampldrv belongs to) ?

I can only make sense of that, if "DependOnGroup" or "DependOnService" actually allow to delay loading a driver, till after some device is available (as opposed to till after some driver has been loaded). Does it make any sense ?

How about: "This driver B cannot start unless there is at least one driver A in the group FOO." That is: "If group FOO is empty, our driver cannot be started."

#136 cdob

cdob

    Gold Member

  • Expert
  • 1437 posts

Posted 02 April 2011 - 08:18 AM

There is still a (major) detail that I don't get. My understanding is that because of the "groups" assigned to critical drivers, they will always be loaded in the following order:

Driver load order is one point.

Contrary there is device detection by driver.
Windows initialize drivers at boot.
When is a device available actually?

Imagine:
BIOS uses legacy USB keyboard emulation.
And a BIOS intialize USB at boot.
USB hub driver is loaded, but no USB hub available currently.
Hence a USB storage driver can't find a USB drive.

Or a USB flash disk require long time to initialize, longer than a hard disk.
USB storage driver is loaded, but dosn't report a working USB drive.
Hence disk.sys can't access a disk, no disk available: BSOD 0x7b.

Back to 2005 http://www.911cd.net...indpost&p=97519
Group "System Reserved" for all USB drivers.
That's a strange driver load order: a USB driver is loaded first, pci.sys is loaded next.
At load time USB driver can't detect a USB device conected to PCI bus.
Seems to be a broken approach. Contrary "System Reserved" works in real life fine.
This approach seems to enable USB devices as early as possible.
This avoids timing BSOD 0x7b at some machines.

#137 Doodoo

Doodoo

    Frequent Member

  • Advanced user
  • 344 posts

Posted 02 April 2011 - 10:42 AM

Shao, Cdob,
I think it I understand everything a bit better thanks to you guys ! Many thanks for your explanations.

I am just wondering though: I guess many drivers in windows more or less face the same problem, i.e. not only need that some higher driver has already been loaded, but they also require that the device they drive is available.
How do they solve the problem "wait till device is available" without hanging the whole boot process ?

Shao, can you think of a solution in the short term ? Would that need to be integrated in WinVBlock itself ? Can I do anything more to support you ? Can you think of any more useful experiment ?

I can't help feeling there must be a relatively simple solution.... USBoot is the living proof ;)

#138 Sha0

Sha0

    WinVBlock Dev

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

Posted 04 April 2011 - 03:17 AM

When is a device available actually?

A PnP device ought to be considered available after it (the device's stack) has finished processing IRP_MJ_PNP + IRP_MN_START_DEVICE without error, if I recall correctly. The timing of this depends on the drivers in the device's stack; they can delay or complete the IRP whenever they like, but obviously not before the IRP is sent by the PnP Manager.

How do they solve the problem "wait till device is available" without hanging the whole boot process ?

I still believe what's critical is:

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.

Let's just pretend that the way in which the "normal" USBHUB.SYS reports its child devices is unlike the way in which storage adapter drivers report their child devices... Maybe USBHUB.SYS polls for devices. Maybe the fact that the USB disk is already connected doesn't trigger a "device arrived" event. Maybe something else. Whatever it is, it's not an issue for storage adapter drivers to report their child devices (disks) right away.

...can you think of a solution in the short term ?

WinVBlock could keep looking for the backing disk until it arrives, even if that might be forever... A problem with that is manageability: If there is a problem preventing the backing disk from becoming available, one might want the computer to report the failure and reboot, rather than wait forever. Consider remote management, for example.

Would that need to be integrated in WinVBlock itself ? Can I do anything more to support you ? Can you think of any more useful experiment ?

I think so. Not at the moment, thanks. Not at the moment.

I can't help feeling there must be a relatively simple solution.... USBoot is the living proof :dubbio:

Are you suggesting that USBoot is a simple driver? The 10-second-delay WaitBt seemed pretty simple. :whistling:

#139 Doodoo

Doodoo

    Frequent Member

  • Advanced user
  • 344 posts

Posted 04 April 2011 - 02:38 PM

WinVBlock could keep looking for the backing disk until it arrives, even if that might be forever...

Feel free to let me know if you implement this bit some time in the future, and you need a guinea-pig :dubbio:

Are you suggesting that USBoot is a simple driver? The 10-second-delay WaitBt seemed pretty simple. :whistling:

Maybe I didn't choose my words carefully enough... I think the idea is actually bloody clever, even if the implementation is relatively straightforward (for someone who knows what they are doing, hehe....)

#140 cdob

cdob

    Gold Member

  • Expert
  • 1437 posts

Posted 04 April 2011 - 06:31 PM

The 10-second-delay WaitBt seemed pretty simple.

How to use this driver?

Imagine there is a broken mass storage controller.
And mass storage controller is disabled in BIOS. No addional controller added.
There is USB controller and one USB stick connected only.

WaitBt and registry from post #92 result a BSOD 0x7b.
(usb?hci: Boot Bus Extender, usbhub and usbstor: System Bus Extender)

As far as I understand wait10 requires a CDDB entry.

VMware machine does boot at different timings:
usb?hci: System Reserved, usbhub and usbstor: System Bus Extender


Another hint to enhance confusion: USB bus is a polled.

http://www.softpedia...-switcher.shtml

USB Mouserate Switcher will allow you to enforce a mouse polling rate of 250 Hz (4 ms), 500 Hz (2 ms) or 1000 Hz (1 ms) and let you restore Windows' original "usbport.sys" (8 ms) if needed.

usbport.sys is patched, this should match USB storage too.

#141 Doodoo

Doodoo

    Frequent Member

  • Advanced user
  • 344 posts

Posted 05 April 2011 - 08:37 AM

As far as I understand wait10 requires a CDDB entry.

Absolutely... Shao may provide more details, but my understanding is that wait10.sys as it stands does not pretend to be the "ultimate solution". It was only an exercise to "show that timing really is critical", and that (at least in some circumstances) all it takes to avoid a BOSD 7B is some time !!!

As a matter of fact, you don't need any internal HDD, nor any mass storage drivers to boot. It just happens that when you have them, timing is a bit more favorable and you don't get a BSOD 7B.

Imagine there is a broken mass storage controller.
And mass storage controller is disabled in BIOS. No addional controller added.
There is USB controller and one USB stick connected only.

In this case of course it might not be possible to use wait10.sys since there is no driver which will be loaded (e.g. iastor.sys or pciide.sys) that can be replaced with it. Or is there ?

Again, wait10.sys as it stands may not be the "ultimate solution", in the sense that there is not necessarily a driver which is guaranteed to be loaded, but which is however not critical and can be replaced with wait10.sys. But at least it is a proof of concept and we know in which direction to look !

#142 Doodoo

Doodoo

    Frequent Member

  • Advanced user
  • 344 posts

Posted 05 April 2011 - 08:54 AM

As a temporary conclusion (as I hope there will be future developments to the whole story !), does anyone have an answer that question:

By the way, the usbhub.sys and usbstor.sys from XP Embedded FP2 look very much like regular XP files ("properties" say product version 5.1.2600.2996), so it might be OK to use them and avoid licensing problems ?

If we can use these files, then we may not have to find any other clever solution... :smart:

On a different note, some info about this:

Yay! I'm simply curious as to what your USBNTD.CHK file reports when you have FDD emulation configured in the BIOS

I have tried various formats (FDD and ZIP) and various computers, but USBNTD.CHK never reports the USB stick I have booted from as an HDD.
By the way at least on one computer it looks like GRUB4DOS doesn't like to boot from a ZIP formatted USB stick, as it can't find menu.lst (although the boot drive is mounted as (fd0) as if it had booted in FDD mode). Everything works fine when I boot from a FDD formated USB stick though.


#143 Sha0

Sha0

    WinVBlock Dev

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

Posted 05 April 2011 - 03:24 PM

Feel free to let me know if you...need a guinea-pig :smart:

Absolutely and with thanks.

How to use this driver?
...
WaitBt and registry from post #92 result a BSOD 0x7b.
(usb?hci: Boot Bus Extender, usbhub and usbstor: System Bus Extender)

As far as I understand wait10 requires a CDDB entry.

Absolutely... ...my understanding is that wait10.sys as it stands does not pretend to be the "ultimate solution". It was only an exercise to "show that timing really is critical", and that (at least in some circumstances) all it takes to avoid a BOSD 7B is some time !!!

As a matter of fact, you don't need any internal HDD, nor any mass storage drivers to boot. It just happens that when you have them, timing is a bit more favorable and you don't get a BSOD 7B.

Correct. It would be trivial to change the original WaitBt (whose source code is in this thread) to move the wait logic out of the AddDevice routine and into the DriverEntry routine. No CDDB entry would be required, in that case, and a simple Services entry with the driver marked as boot-start would be sufficient. The original experiment was simply to ensure that the waiting logic occurred at precisely the same time that iaStor appeared to "prevent" a STOP 0x7B on the particular laptop.

I have tried various formats (FDD and ZIP) and various computers...

Very handy info; thanks!

#144 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 14757 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 05 April 2011 - 10:46 PM

@Doodoo
There are TWO "ZIP-like" types, the first "HD-like" and the second "Floppy-like".
If you have first type, grub4dos should map it as (hdn), if using the second it should map it as (fdn)

How a given BIOS will behave with the one or the other varies much in my experience (or in other words there is rarely - please read as "never" - valid documentation from the motherboard manufacturer about the type of "ZIP" it's BIOS "expects").
Some info JFYI:
http://reboot.pro/?showtopic=4863
http://reboot.pro/5133/
http://reboot.pro/6546/
http://reboot.pro/7507/
http://reboot.pro/12436/

:)
Wonko

#145 Doodoo

Doodoo

    Frequent Member

  • Advanced user
  • 344 posts

Posted 06 April 2011 - 08:02 AM

@Doodoo
There are TWO "ZIP-like" types, the first "HD-like" and the second "Floppy-like".
If you have first type, grub4dos should map it as (hdn), if using the second it should map it as (fdn)

Thanks a lot Wonko for the useful precisions. I didn't know there were 2 kinds of ZIP formats... at least from the BIOS perspective.
As far as I am concerned, it looks like I have the FDD-like type, and this is what makes everything even more confusing:

  • if I boot from a FDD-formatted USB stick, it is indeed recognised as (fd0) in GRUB4DOS, and it finds my menu.lst
  • if I boot from a ZIP-formatted USB stick, it is also recognised as (fd0) in GRUB4DOS, but it doesn't find my menu.lst (which it should, from what I read here). I have to manually issue the following command:
    configfile (fd0)/menu.lst
Any explanation for that ?
At last, may I ask what it is your valuable opinion on that question ?

#146 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 14757 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 06 April 2011 - 03:06 PM

As far as I am concerned, it looks like I have the FDD-like type, and this is what makes everything even more confusing:

  • if I boot from a FDD-formatted USB stick, it is indeed recognised as (fd0) in GRUB4DOS, and it finds my menu.lst
  • if I boot from a ZIP-formatted USB stick, it is also recognised as (fd0) in GRUB4DOS, but it doesn't find my menu.lst (which it should, from what I read here). I have to manually issue the following command:
    configfile (fd0)/menu.lst
Any explanation for that ?

A queer BIOS ? (that would not be categorized as "news")
Are you sure the embedded menu.lst in the grldr version that you have is the same as the referenced ones.

At last, may I ask what it is your valuable opinion on that question ?

What is the question?
Do you have a licence for Windows XP Embedded, if yes you can legally use the files, if no, you cannot (past the trial or whatever).
Can you use it (no matter if from a legal standpoint you are breaching the EULA)?
Yes, of course.

:)
Wonko

#147 Doodoo

Doodoo

    Frequent Member

  • Advanced user
  • 344 posts

Posted 06 April 2011 - 03:30 PM

Are you sure the embedded menu.lst in the grldr version that you have is the same as the referenced ones.

No I am not, but it just occurred to me (before you asked :cheers:) that I should check.....

What is the question?
Do you have a licence for Windows XP Embedded, if yes you can legally use the files, if no, you cannot (past the trial or whatever).

Maybe I should rephrase the question.... Although these FP2 files can be obtained via a download which says "XP Embedded", there is nothing (as far as I can tell) which makes them recognisable as "XP Embedded" files, and they look like regular XP files.
Not only is the "Product Version" characteristic of XP, but also the "Product Name": Microsoft® Windows® Operating System. On the other hand for the SP3 files, you would get: "Product Name = Microsoft ® Windows ® XP Embedded"

If you want the question is: is there any means to detect that you have (possibly) breached the EULA by obtaining the files via "XP Embedded", since nothing distinguishes them from regular XP files ?
Whether or not it is acceptable to breach the EULA even if there is no means to detect that you have done so, is another debate.... :)

#148 Doodoo

Doodoo

    Frequent Member

  • Advanced user
  • 344 posts

Posted 06 April 2011 - 03:54 PM

Back to the thread's core topic: unsurprisingly, some useful research and experiments have already been carried out... This post and pretty much all the rest of the thread are worth reading, as far as the load order of the drivers is concerned.... That is for Win7 but presumably most of it applies to Win XP.

More useful info here: http://www.osronline...te-inf_7ap3.htm

It looks like the usual symptoms have been identified....
http://reboot.pro/90...dpost__p__79722

It seems Windows 7 needs at least 1 IDE/SATA/SCSI/RAID controller during boot even if it is booting from USB!

But Shao has really been the only one to understand that it's just a matter of time :)

#149 Sha0

Sha0

    WinVBlock Dev

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

Posted 06 April 2011 - 05:44 PM

...understand that it's just a matter of time :)

Well actually, further investigation has revealed that Microsoft Windows XP's IoGetBootDiskInformation() appears to closely resemble the logic found in ReactOS' implementation (gee, I wonder why)... Meaning that at least one disk is required to be available in order for that function to report the boot/system disks' MBR disk signatures. That might or might not have something to do with the karyonix quote you've given. It is also contrary to an assertion I made previously that this function could report the MBR disk signatures before any disks are available. The signature info is available, but it is essentially opaque to a driver developer; this function is the only interface that I'm aware of.

But anyway, a wild guess (untested) is that:
  • USB hub FDO is started
  • USB hub FDO is queried for bus relations
  • USB hub reports no children
  • ...
  • WinVBlock looks for the backing disk and doesn't find it. Boot disk is thus a dud.
  • A worker thread for the USB hub FDO does an initial poll for its own children and notes an attached storage device. It informs PnP Manager of the arrival
  • Too late for the WinVBlock disk, of course. STOP 0x7B
So introducing a delay looks like:
  • USB hub FDO is started
  • USB hub FDO is queried for bus relations
  • USB hub reports no children
  • WaitBt delays 10 seconds
  • During that 10 seconds in that thread, a worker thread for the USB hub FDO does an initial poll for its own children and notes an attached storage device. It informs PnP Manager of the arrival
  • WinVBlock looks for the backing disk and finds it. Boot disk is thus available.


#150 Doodoo

Doodoo

    Frequent Member

  • Advanced user
  • 344 posts

Posted 07 April 2011 - 12:08 PM

Meaning that at least one disk is required to be available in order for that function to report the boot/system disks' MBR disk signatures.

But then you mentioned it is possible to boot without any disk whatsoever :

You could potentially have a volume without any fixed disks. Consider BartPE booted via SMB. There aren't any disks, fixed, removable, none! BartPE from a CD can be the same! The volume on the CD is found.

So how can it work at all, without any fixed disk ?

That might or might not have something to do with the karyonix quote you've given.

Karyonix's observation was made further to this experiment (I wonder what the duplicate CDDB entries are for ?) and that one.

It would be trivial to change the original WaitBt (whose source code is in this thread) to move the wait logic out of the AddDevice routine and into the DriverEntry routine. No CDDB entry would be required, in that case, and a simple Services entry with the driver marked as boot-start would be sufficient.

I hope it's not asking too much, on top of what you've already done... But could you post a compiled version of this modified driver, together with the required registry entries ?
That might be very useful to investigate on all kinds of hardware, without worrying about CDDB entries ;) Many thanks in advance !




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users