OS approach to finding the BOOT disk

Hi

When does OS gives up finding the BOOT disk i.e. throws inaccessible boot device BSOD 0x7B.
I am booting of a remote disk using my Virtual storage miniport whcih uses the NDIS miniport as transport. All these componenst are BOOT start. Below is what happens in working case

1. My NDIS miniport starts
2. My protocol driver starts
3. Protocol driver gets BIND
4. Protocol driver creates a Virtual Storage PDO
5. My storage driver discovers disks

Basically like iscsi initiator but instead of tcpip,sys it is my custom protocol driver

All above works as long as teh system has a my boot NIC and any other NIC (boot start) .

But once I remove the other NIC on system, I fail BSOD inaccessible boot device, 0x7B.

Looks like all the while I had a timing issue but just happened to work and now came across a setup where before I get a chance to create my storage PDO, OS gives up with 0x7B BSOD.

Is above approximation of OS finding a remote DISK to boot off correct?

How do I resolve above BSOD given that my protocol driver does’t have or know all the conveniences/actions that native iscsi initiator has?

Thx

What bug check parameters do you see?

Usually it contains the device name (or partition name) from which the boot
was attempted and failed. If you can see that, you might be able to find
the device stack and see which PDO is it leading to.

'Coz I do believe that your PDO should have been created when this bug
check came in. From what I know it implies that the file system could not
mount due to either a bad sector on the disk or improper partitioning or
some other early stage read/write failure.

But if the OS got loaded (i.e. it successfully went through the earlier
pre-boot stages of loading the MBR etc), the PDO should be there.

On Sat, Mar 31, 2012 at 9:50 AM, wrote:

> Hi
>
> When does OS gives up finding the BOOT disk i.e. throws inaccessible boot
> device BSOD 0x7B.
> I am booting of a remote disk using my Virtual storage miniport whcih uses
> the NDIS miniport as transport. All these componenst are BOOT start. Below
> is what happens in working case
>
> 1) My NDIS miniport starts
> 2) My protocol driver starts
> 3) Protocol driver gets BIND
> 4) Protocol driver creates a Virtual Storage PDO
> 5) My storage driver discovers disks
>
> Basically like iscsi initiator but instead of tcpip,sys it is my custom
> protocol driver
>
> All above works as long as teh system has a my boot NIC and any other NIC
> (boot start) .
>
> But once I remove the other NIC on system, I fail BSOD inaccessible boot
> device, 0x7B.
>
> Looks like all the while I had a timing issue but just happened to work
> and now came across a setup where before I get a chance to create my
> storage PDO, OS gives up with 0x7B BSOD.
>
> Is above approximation of OS finding a remote DISK to boot off correct?
>
> How do I resolve above BSOD given that my protocol driver does’t have or
> know all the conveniences/actions that native iscsi initiator has?
>
> Thx
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

Yes I see DriverEntry of my virtual storage miniport being called (Not sure if that is what you meant by PDO should be there). But DriverEntry just calls StorportInitialize() and does nothing, since it has no hardware and is virtual. So no HwFindAdapter/Initialize yet. Below is that state after BSOD

BugCheck 7B, {803a7bb0, c0000034, 0, 0}

Probably caused by : ntkrpamp.exe ( nt!PnpMarkBootPartition+10b )

Followup: MachineOwner

my PDO

DevNode 0x84dc64e0 for PDO 0x84dc6668
InstancePath is “Root\LEGACY_MY_VIRT_STORAGE_MINIPORT\0000”
ServiceName is “MY_V_S_P”
State = DeviceNodeStarted (0x308)
Previous State = DeviceNodeEnumerateCompletion (0x30d)

Only at the end protocol driver initialization, I call WdfChildListAddOrUpdateChildDescriptionAsPresent() which then results in calls to FindAdapater/Iniatiale/StartIO().

But in failure case I get the BSOD even before I get to call WdfChildListAddOrUpdateChildDescriptionAsPresent().

I will debug BSOD params again and update.

I am not sure how it was working all along, and below is my hypothesis
0) My NDIS miniport started, which kicked off my PRotocol driver as well

1. Sicne that extra NIC driver is BOOT start, during BOOT stages OS has to call its DriverEntry(), which adds extra time before OS has to make the decision.
2. By that time my protocol_driver raced to call WdfChildListAddOrUpdateChildDescriptionAsPresent() and merrily all appeared working ?

Constrained on time/release, I want to know If conatcting MS is the eventual road to resolve this (since I am doing something like iscsi initiator, but no one knows what all support OS has hooked in for its iscsi initiator), I want to know that and if that is the case, I want to let powers to be know that, and come back to what I care - debug/understand and re-architect for solution if one is plausible as well.

When your storage driver starts, the NIC PDOs MUST be up. You only get one chance to report LUNs. This can be controlled by start order.

Below are componenst in my stack for this.

I thought a long while back I was mucking with that and ended up with below (supposedly so far) working case

a) Virtual Bus Driver (BOOT start) ; LoadOrderGroup = PNP_TDI
b) NDis miniport (BOOT start) ; LoadOrderGroup = NDIS
c) Protocol driver ( shared same binary as [a] but has its own INF and is non-BOOT start)
d) Virtual Storage Miniport Driver (BOOTt start).

None (except [a,b])) has LoadOrderGroup group set. Please suggest what should the LoadOrderGroup, start order.
Atleast for [c] is taken care by [a,b] since it is ndis protocol driver and shares same binary as [a].

The load sequence I see is below

A) Birtual Bus loads –>DriverEntry/EvtDeviceAdd
B) NDIS miniport load –>Drivery, MiniportInitialize()
C) Protocl Driver loads –> Driver Entry already called in A), ProtocolBindAdapater() gets called
D) I am initializing my protocolBindAdapater… have not yet called WdfChildListAddOrUpdateChildDescriptionAsPresent(Storage_miniport_instance for taht particular BOOT PORT)
E) Storage Miniport laods –> DriverEntry() gets called, no FindAdapater/Initilaize() etc yet…

I failing case BSOD happens here…
(Maybe OS has no more BOOT start drivers. No Luns presented yet, BSOD…)

In passing case I get to do below
F) Finish protocolBindAdapater() by called WdfChildListAddOrUpdateChildDescriptionAsPresent(Storage_miniport_instance for taht particular BOOT PORT)
(There are still other BOOT start driver, so OS loading them,…)
G) Storage miniport is fully up, gets its clalbacks, provides Luns etc.
(MAybe OS finsihed laoding all BOOT start driver here, checks for luns, and they are present, so all GOOD)

Concerns)
i) I get to report Luns only if the initialziation of the transport stack of the that BOOT port is over (i.e prootocl_Bind_Adapater() is complete).
II) Untill then I cannot go out on to the wire to discover Luns

Thinking of creating some dummy or Global PDO duirn stage a) above?, but I could have multiple cards/ports (of the same type of which only one of it is the BOOT port). Please suggest what should the LoadOrderGroup, start order of above components.

Nodes when BSOD happened

DevNode 0x85058750 for PDO 0x8505cb70
InstancePath is “PCI\VEN_…4400”
ServiceName is “My_NDIS_miniport”
State = DeviceNodeStarted (0x308)
Previous State = DeviceNodeEnumerateCompletion (0x30d)

DevNode 0x84dc64e0 for PDO 0x84dc6668
InstancePath is “Root\LEGACY_MY_VIRT_STORAGE_MINIPORT\0000”
ServiceName is “MY_V_S_P”
State = DeviceNodeStarted (0x308)
Previous State = DeviceNodeEnumerateCompletion (0x30d)

DevNode 0x84dce698 for PDO 0x84dce820
InstancePath is “Root\SYSTEM\0001”
ServiceName is “My_Virtual_Bus_driver”
State = DeviceNodeStarted (0x308)
Previous State = DeviceNodeEnumerateCompletion (0x30d)

Note that NDIS miniport is a PnP creature. Even if you force it to load
using LoadOrderGroup, it will only cause it to load and call its
DriverEntry.
But the StartDevice (or MiniportAddDevice) will be called not before all the
PnP & power chores are done.
Does the second netcard (with which your driver seems to work) belong to the
same miniport?
– pa

I was mucking with LoadOrder and dependencies a while back in this, nothing seemed to have helped, except making them BOOT start (and put my ndis miniport in paging path etc).

netcard1 - a single port card
netcard2 - dual port card
The second netcard (netcard2) has a different device_id i.e a different, inf/service_name/binary. It is also set to BOOT start.

It seems

1. During netcard1 test cycle, Always we had that netcard2 or something, which never exposed the race condition and the hole we were in.
   (OR)
2. During netcard2 test cycles - we were (UN/)lucky, never were able to reproduce (maybe of teh extra port or just teh ndis miniport si totally different for this –> timing etc)

This is reproducable on different falavors of OS if the system has only netcard1, as soon as I put the netcard2 the issue goes away on all cases.

I will keep digging at the problem, but do please let me know if it requires MS case for clean resolution. Need to pipe that up the chain.

Also are there below mechanisms

1. Tell OS to pend for a while before it gives up looking fro BOOT disk
2. Any reg keys some where, on which OS depends for how long it waits before it gives up and says 0x7B BSOD.

1 you can’t
2 it doesn’t exist

d

debt from my phone

From: xxxxx@yahoo.com
Sent: 3/31/2012 9:07 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] OS approach to finding the BOOT disk

Also are there below mechanisms

1. Tell OS to pend for a while before it gives up looking fro BOOT disk
2. Any reg keys some where, on which OS depends for how long it waits before it gives up and says 0x7B BSOD.

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Are you sure you are not receiving any read/write CDBs in your virtual
miniport?

On Sun, Apr 1, 2012 at 10:02 AM, Doron Holan wrote:

> 1 you can’t
> 2 it doesn’t exist
>
> d
>
> debt from my phone
> ------------------------------
> From: xxxxx@yahoo.com
> Sent: 3/31/2012 9:07 PM
> To: Windows System Software Devs Interest List
> Subject: RE:[ntdev] OS approach to finding the BOOT disk
>
> Also are there below mechanisms
> 1) Tell OS to pend for a while before it gives up looking fro BOOT disk
> 2) Any reg keys some where, on which OS depends for how long it waits
> before it gives up and says 0x7B BSOD.
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

> When does OS gives up finding the BOOT disk i.e. throws inaccessible boot device BSOD 0x7B.

This can occur due to any errors on a boot disk, like a failed read.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

>>
Are you sure you are not receiving any read/write CDBs in your virtual
miniport?
<<

I do not see HwStorFindAdapter hence no HwStorInitialize and hence no HwStorStartIo being called at all.
All I get is DriverEntry() and then BSOD. I will double check on no HwStorStartIo being called.

How are you creating your virtual storage adapters? On the other end of
your NIC, I am assuming there would be a device server and you are probably
creating PDOs of the LUNs in that device server. How are your bringing them
in storage stack?

On Sun, Apr 1, 2012 at 2:44 PM, wrote:

> >>
> Are you sure you are not receiving any read/write CDBs in your virtual
> miniport?
> <<
>
> I do not see HwStorFindAdapter hence no HwStorInitialize and hence no
> HwStorStartIo being called at all.
> All I get is DriverEntry() and then BSOD. I will double check on no
> HwStorStartIo being called.
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

>c) Protocol driver ( shared same binary as [a] but has its own INF and is non-BOOT start)
Your Protocol driver must have BOOT start. It could be a potential problem because the driver may causes a fatal delay which could not bring up your stack of driver in time.

Igor Sharovar

O.k. will try Protocol Driver to be BOOT start as well.

Also noticed below.
When the system has hard drives removed (to ensure booting from the remote LUN), we get BSODs. When the hard drives are locally installed, but the BIOS is set to prioritize the Option ROM boot, we get consistant successful boots from the remote LUN

>How are you creating your virtual storage adapters?
Vistual storage driver is installed at BOOT start. So at boot timejust its DriverEntry() is called where in I assuem the PDO is hence already created by the system?).
The protocol driver through KMDF mechanisms will create a Virtual Storage FDO for every port, whenever ithe protocol driver gets bound to its underlying NDIS miniport. From then on everything is the same, we get Storport callbacks, discover disks, indicate to OS and they get shown in the DiskMgr etc.

>>Your Protocol driver must have BOOT start.
Protocol driver shares the binary with Virtal Bus driver which is already BOOT start.
-Virtual Bus Driver starts first - it does NDisRegisterProtocolDriver().
-NDIS Miniport driver is BOOT start. It starts next.
-Once NDIS miniport starts, NDIS will call ProtocolBindAdapater() since DriverEntrey has already been called.

Not sure if making Protocol Driver as well BOOT start will optimize anything else above? but will try.

>Protocol driver shares the binary with Virtal Bus driver which is already BOOT start.
It does not really matter. But it matter for you when NDIS will bind your Protocol driver to a NDIS miniport driver. If a Protocol driver is not a BOOT start driver the binding would happen when the BOOT stage completed which is too late for you. For example, tcpip.sys is a Protocol NDIS driver and it is a BOOT start driver since Vista SP1 and Win2008. And there are specific reasons why Microsoft change start type of tcpip.sys from 1 to 0 (boot start).

Igor Sharovar

I am getting ProtocolBindAdapater during BOOT stages (else I would never succeed in any of the cases)
After above I get DriverEntry of my storage Virtual miniport.
(But before my protocol driver can create the PDO (or FDO?) of the Storage Virtual miniport, I BSOD).

Yes tcpip.sys is BOOT start for a reason, not sure what all hooks ISCSI initiatior has got in the OS.
But I did changed my protocol to BOOT_start and it started BSODing. Now debugging that as well.

Background:
A while we did investigate why not make protocol driver also BOOT start and I remember by that it ended up starting twice or causing a failure in some way. I am figuring out now what were those exact reasons as well.

Do you have again 0X7b BSoD?

Igor Sharovar