Jump to content











Photo
- - - - -

Win7 USB boot- specific model motherboard won't boot w/ AHCI or RAID.. others work fine


  • Please log in to reply
32 replies to this topic

#26 Agent_Smith

Agent_Smith

    Member

  • Members
  • 37 posts
  •  
    United States

Posted 03 May 2011 - 03:38 PM

Fair enough, your different perspective is at least as valuable as mine ! There is so much I still need to learn myself, I wouldn't dare say I know the truth and anyone else is wrong.


I think your experience is incredibly valuable and useful. You mentioned you had BSOD 7B on 15-20 computers which is a whole lot more than most people on this forum ever use... I only have at hand 3 or 4 different machines, which are not even all really mine... However the fact that you haven't yet seen a machine that is "too fast" or one that is "slow enough" doesn't mean it will never happen in the future. And this leads to the next step:

Your pragmatic approach is perfectly fine. But caring about "universality" is in itself is a good enough reason to try to understand the root cause of the problem, in order to come up with a solution which is known to be future-proof, and not just a tweak which "happens to work today, but may not work tomorrow"

Till we have absolutely irrefutable evidence, all we can do is speculate that this or that is happening. Any hypothesis can (within limits of reason) be thought to be true, as long as a counter example is not found (i.e. a BSOD 7B is not seen).


You are right, it is very trial and error, and I have no idea if this will necessary continue this way. IMO, even 15 data points is not very many. I think its enough to spot a very strong link, but I'm guessing I'd need hundreds to escape the statistical uncertanties.

It is obviously very time consuming, but if you can check that all three solutions behave the same 100% on many machines (the more the better !), that will be very informative ! As long as we don't find a counter-example, we cannot rule out the fact that is purely down to timing...

In fact there might be a fourth option (at least for XP):


You can try to replace the standard usbhub.sys file with the version from XP Embedded SP3 (from http://iorboaz.blogs...ndows-2003.html) or from the Feature Pack 2.
This has also given me 100% success, but that was only on 4-5 different machines. If you have the time, it would be interesting to test on many more !
But anyway for Win7 I don't know if in there is also a variant of usbhub.sys to be taken from Win7 Embedded.


Well, I am using Windows 7, so I can't that embedded driver...

As far as the other solutions, I'm thinking that I can't see the harm in going with the kitchen sink approach. From a practical standpoint, I can't see the harm in including ubdrvgd.sys and cdob's changes. Based on the working theory, its probably not necessary, but I'm hesitant to flat out leave the ubdrvgd solution as I've had zero problems in the last few days - and as you might guess its sort of important for me that I have a working tool on hand since I'm using it on a daily basis.

Edited by Agent_Smith, 03 May 2011 - 03:40 PM.


#27 Doodoo

Doodoo

    Frequent Member

  • Advanced user
  • 344 posts

Posted 06 May 2011 - 11:15 AM

I also tested the waitbt.sys, and it also works without any storage controllers...
So, it looks like all three measures will buy enough time for whatever it is that is happening..


It is obviously very time consuming, but if you can check that all three solutions behave the same 100% on many machines (the more the better !), that will be very informative ! As long as we don't find a counter-example, we cannot rule out the fact that is purely down to timing...

Actually I have jut realised I have found myself a counter-example, where WaitBt and DriveGuard do not produce the same result (WaitBt gives a BSOD 7B, but DriveGuard allows to boot properly).
It is a slightly different scenario because I am trying to boot from an IMG, not from flat files, so WinVBlock also comes into the equation. Nevertheless, it looks like DriveGuard actually does more than just wait....

#28 Agent_Smith

Agent_Smith

    Member

  • Members
  • 37 posts
  •  
    United States

Posted 06 May 2011 - 11:09 PM

Thanks for the information. I guess I will stick with ubdrvgd then.

Its unexpected though. After this thread, I thought for sure it was inert.

If you have time, I'd love to hear how cdob's registry changes compare. I would assume that it would be the same as waitbt, but I guess we can't be sure...

#29 Sha0

Sha0

    WinVBlock Dev

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

Posted 07 May 2011 - 08:53 AM

...I have found...WaitBt and DriveGuard do not produce the same result (WaitBt gives a BSOD 7B, but DriveGuard allows to boot properly).
It is a slightly different scenario because I am trying to boot from an IMG, not from flat files, so WinVBlock also comes into the equation. Nevertheless, it looks like DriveGuard actually does more than just wait....

It is a way different scenario: WaitBt is designed to help for booting from USB. You are not booting from USB. :smiling9:

Thanks for the information. I guess I will stick with ubdrvgd then.

Its unexpected though. After this thread, I thought for sure it was inert.

GAH! The information is not relevant to booting from USB. Also, please do not take that as meaning "WaitBt causes a STOP 0x7B." WaitBt doesn't "give" any 0x7Bs to anyone, but it can fail to prevent one that would otherwise occur. Your "kitchen sink approach" is fine, in my opinion.

If you have time, I'd love to hear how cdob's registry changes compare. I would assume that it would be the same as waitbt, but I guess we can't be sure...

Not applicable!

#30 Doodoo

Doodoo

    Frequent Member

  • Advanced user
  • 344 posts

Posted 07 May 2011 - 12:36 PM

You are not booting from USB. :smiling9:

Shao, I think there is a misunderstanding....
In the counter-example I pointed to, I am booting from USB indeed ! The only catch is that I am booting from an IMG, not from flat files.

Also, please do not take that as meaning "WaitBt causes a STOP 0x7B." WaitBt doesn't "give" any 0x7Bs to anyone, but it can fail to prevent one that would otherwise occur.

That is crystal clear. All my example shows is that (on one particular machine) WaitBt fails to prevent the STOP 7B, whereas DriveGuard happens to succeed. But without WaitBt I would get a STOP 7B anyway...

I guess I will stick with ubdrvgd then (...) After this thread, I thought for sure it was inert.

My example seems to suggest that DriveGuard does more than just wait (which is what WaitBt does). But in fact it may just start waiting at a different time, or till a different event... It could well be inert after all.

Let's try to recap. There are four scenarios:
  • Boot Win7 from flat files on USB. PollBootPartitionTimeout is probably key here. So far I don't know of any reports where it didn't work. I don't think DriveGuard helps in any way in this scenario (but of course the "kitchen sink approach" is fine !)
  • Boot XP from flat files on USB. WaitBt works great (see first boot) and it seems to me that it has the same effect in XP as PollBootPartitionTimeout in Win7.
  • Boot Win7 from VHD on USB. Timing of boot events is a bit unexpected (example from VHD on HDD), but it is probably beneficial to try to understand why it works, and perhaps use similar ideas on XP
  • Boot XP from IMG on USB. WaitBt cannot help in this scenario, but DriveGuard happens to help sometimes (not always). Why it sometimes helps is not understood... Just lucky timing ? (starts waiting at a different time, or till a different event ?)


#31 Agent_Smith

Agent_Smith

    Member

  • Members
  • 37 posts
  •  
    United States

Posted 07 May 2011 - 02:56 PM

It is a way different scenario: WaitBt is designed to help for booting from USB. You are not booting from USB. :smiling9:


GAH! The information is not relevant to booting from USB. Also, please do not take that as meaning "WaitBt causes a STOP 0x7B." WaitBt doesn't "give" any 0x7Bs to anyone, but it can fail to prevent one that would otherwise occur. Your "kitchen sink approach" is fine, in my opinion.


Not applicable!


I thought this was all in the context of booting from USB?

I do understand that your driver can't cause a stop 7b, because all it does is wait for a few seconds. I've already added the kitchen sink approach to my build, but was starting to wonder if it was uselessly redundant...

Also, why would cdob's changes not be applicable? I thought it just had the usb drivers load early and then forced it to wait up to 30 seconds to detect the USB volume.. Did I misunderstand? Does it work differently?

#32 Sha0

Sha0

    WinVBlock Dev

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

Posted 07 May 2011 - 03:31 PM

Shao, I think there is a misunderstanding....
In the counter-example I pointed to, I am booting from USB indeed ! The only catch is that I am booting from an IMG, not from flat files.

"I am booting from an IMG" != "I am booting from USB". Just because USB is in the mix, doesn't mean that you are booting from USB. For example, you could do the "XP Kansas City Shuffle" and have a SAN be established post-kernel and have WinVBlock use the SAN as the backing disk, even if you originally booted pre-kernel from an image file on USB.

That is crystal clear. All my example shows is that (on one particular machine) WaitBt fails to prevent the STOP 7B, whereas DriveGuard happens to succeed. But without WaitBt I would get a STOP 7B anyway...

And it appeared to discourage Agent_Smith from using WaitBt. Thanks for clarifying.

I thought this was all in the context of booting from USB?

Please see above. In fact, this is all quite ironic... :whistling:

Remember when some people thought that a mass storage controller driver (other than USB's) might be required in order to boot from USB, even though we'd expect to only need USB drivers? To that, I say "no way!"

"IASTOR prevents a STOP 0x7B with USB boot" != "IASTOR is required in order to prevent a STOP 0x7B with USB boot"

Doodoo's scenario is eerily similar: That USB drivers might be required in order to boot from an image file, even though someone (outside of this thread) might expect that only the image file driver is needed. To that, I say "obviously!" The difference being, of course, that the image file is backed by USB mass storage.

"USB drivers prevent a STOP 0x7B with image-file-on-USB" && "USB drivers are required in order to prevent a STOP 0x7B with image-file-on-USB"
:loleverybody:

I do understand that your driver can't cause a stop 7b, because all it does is wait for a few seconds. I've already added the kitchen sink approach to my build, but was starting to wonder if it was uselessly redundant...

Since we do not understand the inner workings of some of the elements, it's not known for certain. Maybe it is. :smiling9:

Also, why would cdob's changes not be applicable? I thought it just had the usb drivers load early and then forced it to wait up to 30 seconds to detect the USB volume.. Did I misunderstand? Does it work differently?

Not applicable to Doodoo's Windows XP. Also not applicable because WinVBlock is reporting the disk right away, then not finding the backing disk. Whether or not we wait 0 seconds or 30 seconds after that for the arrival of more disks, it's already too late.

#33 Doodoo

Doodoo

    Frequent Member

  • Advanced user
  • 344 posts

Posted 07 May 2011 - 06:54 PM

"I am booting from an IMG" != "I am booting from USB". Just because USB is in the mix, doesn't mean that you are booting from USB.

Thanks for explaining this one more time. I suppose I am not the only one to make this confusion, and I was obviously a bit too quick when reducing "I am booting from an IMG on USB" in "I am booting from USB".

And it appeared to discourage Agent_Smith from using WaitBt. Thanks for clarifying.

I'm really sorry if that's how it came across.... Let's make it clear I am the biggest fan of your work, and I'm prepared to encourage anyone to use your drivers ! :loleverybody:
In fact Wimb's example could just as well discourage Agent_Smith from using DriveGuard...

"IASTOR prevents a STOP 0x7B with USB boot" != "IASTOR is required in order to prevent a STOP 0x7B with USB boot"

Absolutely.

"USB drivers prevent a STOP 0x7B with image-file-on-USB" && "USB drivers are required in order to prevent a STOP 0x7B with image-file-on-USB"

I read && as "==". In this case I can only say "absolutely" once again.

Whether or not we wait 0 seconds or 30 seconds after that for the arrival of more disks, it's already too late.

Which is why it is useful to wait before WinVBlock is loaded... And you have already provided a solution for that, Wait10.sys ! And I encourage everyone to use it !




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users