AddDevice Question

Prokash_Sinha-1 · November 30, 2011, 6:12pm

Hope someone can shed lights on this -

I’ve a class lower filter driver in the storage stack. So it sits right
below disk.sys.
The driver being a boot Volumn filter can not return anything but
STATUS_SUCCESS

Now if certain condition(s) occur(s), the filter should be a (1)transperant
filter at best or (2) better yet no dispatch entries ever gets executed.

As of now the implementation takes the option (2) above, when those
conditions are early enough that no FiDo is created and Attached to the
existing

stack.

So in case of those early enough conditions, it still does leave the
AddDevice pointer to the driver’s AddDevice routine. Setting this back to
NULL,

(BTW; that is what we get from the system when it invokes DriverEntry point)
seems to bugcheck ( need to verify couple more time ).

Now with the AddDevice being pointed to the driver’s AddDevice routine, it
never gets called ( actually that is what we want ). And the Driver shows

up in windbg lm. So the driver is loaded successfully, but has no FiDo, and
not attached to the stack.

DeviceTree confirms that it is not attached to the storage stack ( while in
case of normal scenario, it shows up in the stack, and it is fine)

So the questions are -

a) What is/are the percondition(s) for AddDevice tobe called? (RK: It
is good that it is not being called, but just to know …). Meaning does the
system checks to see if DO is created or not?

b) If the following BugCheck is relevant to this design (Rk: Under debugger,
only sometime I get this and trying to understand if there is deep

rooted latent bug that we have in the driver that is causing this )

0: kd> !analyze -v

****************************************************************************
***

*
*

* Bugcheck Analysis
*

*
*

****************************************************************************
***

INACCESSIBLE_BOOT_DEVICE (7b)

During the initialization of the I/O system, it is possible that the driver

for the boot device failed to initialize the device that the system is

attempting to boot from, or it is possible for the file system that is

supposed to read that device to either fail its initialization or to simply

not recognize the data on the boot device as a file system structure that

it recognizes. In the former case, the argument (#1) is the address of a

Unicode string data structure that is the ARC name of the device from which

the boot was being attempted. In the latter case, the argument (#1) is the

address of the device object that could not be mounted.

If this is the initial setup of the system, then this error can occur if

the system was installed on an unsupported disk or SCSI controller. Note

that some controllers are supported only by drivers which are in the Windows

Driver Library (WDL) which requires the user to do a custom install. See

the Windows Driver Library for more information.

This error can also be caused by the installation of a new SCSI adapter or

disk controller or repartitioning the disk with the system partition. If

this is the case, on x86 systems the boot.ini file must be edited or on ARC

systems setup must be run. See the "Advanced Server System Administrator’s

User Guide" for information on changing boot.ini.

If the argument is a pointer to an ARC name string, then the format of the

first two (and in this case only) longwords will be:

USHORT Length;

USHORT MaximumLength;

PWSTR Buffer;

That is, the first longword will contain something like 00800020 where 20

is the actual length of the Unicode string, and the next longword will

contain the address of buffer. This address will be in system space, so

the high order bit will be set.

If the argument is a pointer to a device object, then the format of the
first

word will be:

USHORT Type;

That is, the first word will contain a 0003, where the Type code will ALWAYS

be 0003.

Note that this makes it immediately obvious whether the argument is a
pointer

to an ARC name string or a device object, since a Unicode string can never

have an odd number of bytes, and a device object will always have a Type

code of 3.

Arguments:

Arg1: fffff880009a9928, Pointer to the device object or Unicode string of
ARC name <— It is the arc name

Arg2: ffffffffc0000034

Arg3: 0000000000000000

Arg4: 0000000000000000

Debugging Details:

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0x7B

PROCESS_NAME: System

CURRENT_IRQL: 2

LAST_CONTROL_TRANSFER: from fffff80002dc06d2 to fffff80002cc2f60

STACK_TEXT:

fffff880009a9178 fffff80002dc06d2 : fffff880009a9928 fffffa8003b83310
0000000000000065 fffff80002d09314 : nt!DbgBreakPointWithStatus

fffff880009a9180 fffff80002dc14be : 0000000000000003 0000000000000000
fffff80002d05ee0 000000000000007b : nt!KiBugCheckDebugBreak+0x12

fffff880009a91e0 fffff80002ccb004 : 0000000000000003 fffff80002cc66f0
0000000000000010 0000000000000086 : nt!KeBugCheck2+0x71e

fffff880009a98b0 fffff80002ddf0d6 : 000000000000007b fffff880009a9928
ffffffffc0000034 0000000000000000 : nt!KeBugCheckEx+0x104

fffff880009a98f0 fffff800031f8034 : 0000000000000001 ffffffff80000308
0000000000000047 fffff8a000379480 : nt!PnpBootDeviceWait+0x136

fffff880009a9970 fffff800031f8921 : fffff8a000091c00 fffff80000812d20
0000000000000003 ffffffff8000016c : nt!IopInitializeBootDrivers+0x624

fffff880009a9a40 fffff800031fbb20 : 0000000000000000 0000000000000010
ffffffff80000028 fffff80000812d20 : nt!IoInitSystem+0x801

fffff880009a9b40 fffff8000314c419 : 000409af00040768 fffffa8003b83310
0000000000000080 fffffa8003b83890 : nt!Phase1InitializationDiscard+0x1290

fffff880009a9d10 fffff80002f6e166 : 00040b1800040aa4 0000000000000080
000144a400040b40 fffff80002ca9479 : nt!Phase1Initialization+0x9

fffff880009a9d40 fffff80002ca9486 : fffff80002e43e80 fffffa8003b83310
fffff80002e51c40 000144bc0004109f : nt!PspSystemThreadStartup+0x5a

fffff880009a9d80 0000000000000000 : fffff880009aa000 fffff880009a4000
fffff880009a9260 0000000000000000 : nt!KxStartSystemThread+0x16

Don_Burn · November 30, 2011, 6:19pm

When I’ve disabled the AddDevice routine soon or later I’ve always
gotten a BSOD. The best approach is to determine you don’t want to be
in the stack and not create the device or attach it in AddDevice, just
return STATUS_SUCCESS.

Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

“Prokash Sinha” wrote in message news:xxxxx@ntdev:

> Hope someone can shed lights on this -
>
>
>
> 1) I’ve a class lower filter driver in the storage stack. So it sits right
> below disk.sys.
>
>
>
> 2) The driver being a boot Volumn filter can not return anything but
> STATUS_SUCCESS
>
>
>
>
>
> Now if certain condition(s) occur(s), the filter should be a (1)transperant
> filter at best or (2) better yet no dispatch entries ever gets executed.
>
>
>
> As of now the implementation takes the option (2) above, when those
> conditions are early enough that no FiDo is created and Attached to the
> existing
>
> stack.
>
>
>
>
>
> So in case of those early enough conditions, it still does leave the
> AddDevice pointer to the driver’s AddDevice routine. Setting this back to
> NULL,
>
> (BTW; that is what we get from the system when it invokes DriverEntry point)
> seems to bugcheck ( need to verify couple more time ).
>
>
>
>
>
> Now with the AddDevice being pointed to the driver’s AddDevice routine, it
> never gets called ( actually that is what we want ). And the Driver shows
>
> up in windbg lm. So the driver is loaded successfully, but has no FiDo, and
> not attached to the stack.
>
>
>
> DeviceTree confirms that it is not attached to the storage stack ( while in
> case of normal scenario, it shows up in the stack, and it is fine)
>
>
>
>
>
> So the questions are -
>
>
>
>
>
> a) What is/are the percondition(s) for AddDevice tobe called? (RK: It
> is good that it is not being called, but just to know …). Meaning does the
> system checks to see if DO is created or not?
>
>
>
>
>
> b) If the following BugCheck is relevant to this design (Rk: Under debugger,
> only sometime I get this and trying to understand if there is deep
>
> rooted latent bug that we have in the driver that is causing this )
>
>
>
> 0: kd> !analyze -v
>
> *************************************************************************
>
>
> *
> *
>
> * Bugcheck Analysis
> *
>
> *
> *
>
> *************************************************************************
>
>
>
>
> INACCESSIBLE_BOOT_DEVICE (7b)
>
> During the initialization of the I/O system, it is possible that the driver
>
> for the boot device failed to initialize the device that the system is
>
> attempting to boot from, or it is possible for the file system that is
>
> supposed to read that device to either fail its initialization or to simply
>
> not recognize the data on the boot device as a file system structure that
>
> it recognizes. In the former case, the argument (#1) is the address of a
>
> Unicode string data structure that is the ARC name of the device from which
>
> the boot was being attempted. In the latter case, the argument (#1) is the
>
> address of the device object that could not be mounted.
>
> If this is the initial setup of the system, then this error can occur if
>
> the system was installed on an unsupported disk or SCSI controller. Note
>
> that some controllers are supported only by drivers which are in the Windows
>
> Driver Library (WDL) which requires the user to do a custom install. See
>
> the Windows Driver Library for more information.
>
> This error can also be caused by the installation of a new SCSI adapter or
>
> disk controller or repartitioning the disk with the system partition. If
>
> this is the case, on x86 systems the boot.ini file must be edited or on ARC
>
> systems setup must be run. See the “Advanced Server System Administrator’s
>
> User Guide” for information on changing boot.ini.
>
> If the argument is a pointer to an ARC name string, then the format of the
>
> first two (and in this case only) longwords will be:
>
> USHORT Length;
>
> USHORT MaximumLength;
>
> PWSTR Buffer;
>
> That is, the first longword will contain something like 00800020 where 20
>
> is the actual length of the Unicode string, and the next longword will
>
> contain the address of buffer. This address will be in system space, so
>
> the high order bit will be set.
>
> If the argument is a pointer to a device object, then the format of the
> first
>
> word will be:
>
> USHORT Type;
>
> That is, the first word will contain a 0003, where the Type code will ALWAYS
>
> be 0003.
>
> Note that this makes it immediately obvious whether the argument is a
> pointer
>
> to an ARC name string or a device object, since a Unicode string can never
>
> have an odd number of bytes, and a device object will always have a Type
>
> code of 3.
>
> Arguments:
>
> Arg1: fffff880009a9928, Pointer to the device object or Unicode string of
> ARC name <— It is the arc name
>
> Arg2: ffffffffc0000034
>
> Arg3: 0000000000000000
>
> Arg4: 0000000000000000
>
>
>
> Debugging Details:
>
> ------------------
>
>
>
>
>
> DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
>
>
>
> BUGCHECK_STR: 0x7B
>
>
>
> PROCESS_NAME: System
>
>
>
> CURRENT_IRQL: 2
>
>
>
> LAST_CONTROL_TRANSFER: from fffff80002dc06d2 to fffff80002cc2f60
>
>
>
> STACK_TEXT:
>
> fffff880009a9178 fffff80002dc06d2 : fffff880009a9928 fffffa8003b83310
> 0000000000000065 fffff80002d09314 : nt!DbgBreakPointWithStatus
>
> fffff880009a9180 fffff80002dc14be : 0000000000000003 0000000000000000
> fffff80002d05ee0 000000000000007b : nt!KiBugCheckDebugBreak+0x12
>
> fffff880009a91e0 fffff80002ccb004 : 0000000000000003 fffff80002cc66f0
> 0000000000000010 0000000000000086 : nt!KeBugCheck2+0x71e
>
> fffff880009a98b0 fffff80002ddf0d6 : 000000000000007b fffff880009a9928
> ffffffffc0000034 0000000000000000 : nt!KeBugCheckEx+0x104
>
> fffff880009a98f0 fffff800031f8034 : 0000000000000001 ffffffff80000308
> 0000000000000047 fffff8a000379480 : nt!PnpBootDeviceWait+0x136
>
> fffff880009a9970 fffff800031f8921 : fffff8a000091c00 fffff80000812d20
> 0000000000000003 ffffffff8000016c : nt!IopInitializeBootDrivers+0x624
>
> fffff880009a9a40 fffff800031fbb20 : 0000000000000000 0000000000000010
> ffffffff80000028 fffff80000812d20 : nt!IoInitSystem+0x801
>
> fffff880009a9b40 fffff8000314c419 : 000409af00040768 fffffa8003b83310
> 0000000000000080 fffffa8003b83890 : nt!Phase1InitializationDiscard+0x1290
>
> fffff880009a9d10 fffff80002f6e166 : 00040b1800040aa4 0000000000000080
> 000144a400040b40 fffff80002ca9479 : nt!Phase1Initialization+0x9
>
> fffff880009a9d40 fffff80002ca9486 : fffff80002e43e80 fffffa8003b83310
> fffff80002e51c40 000144bc0004109f : nt!PspSystemThreadStartup+0x5a
>
> fffff880009a9d80 0000000000000000 : fffff880009aa000 fffff880009a4000
> fffff880009a9260 0000000000000000 : nt!KxStartSystemThread+0x16

Prokash_Sinha-1 · November 30, 2011, 6:48pm

Thanks Don!

That seems to matches with my observation(s) so far.

Mistake in My original note - there is no FiDO before AddDevice, so that can
not be a precondition

As of now, it is loaded. It does not have any CDO, no FiDO etc. None of the
dispatches ever gets called ( well hackers’ aside). I guess this sounds
about the way to go…

-pro

When I’ve disabled the AddDevice routine soon or later I’ve always gotten a
BSOD. The best approach is to determine you don’t want to be in the stack
and not create the device or attach it in AddDevice, just return
STATUS_SUCCESS.

Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

Prokash_Sinha-1 · November 30, 2011, 7:23pm

One more thing, what is nature of that Bug?? It brushes away with a long
discussion about what are the possible causes…

I’ve another fltr driver from the OEM, and I need to dig a bit deeper to
see, what is causing such a seemingly unnatural and sporadic BugCheck under
debugger? _If I run the same binary without debugger hooked up/stepped thru,
I don’t seem to see it. Also in free build with the same steps I don’t see
it.

only when I step thru the driver entry sometime I see it.

-pro

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Prokash Sinha
Sent: Wednesday, November 30, 2011 3:48 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] AddDevice Question

Thanks Don!

That seems to matches with my observation(s) so far.

Mistake in My original note - there is no FiDO before AddDevice, so that can
not be a precondition

As of now, it is loaded. It does not have any CDO, no FiDO etc. None of the
dispatches ever gets called ( well hackers’ aside). I guess this sounds
about the way to go…

-pro

When I’ve disabled the AddDevice routine soon or later I’ve always gotten a
BSOD. The best approach is to determine you don’t want to be in the stack
and not create the device or attach it in AddDevice, just return
STATUS_SUCCESS.

Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

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

Peter_Viscarola_OSR · November 30, 2011, 8:21pm

Personally, I’m a big fan of option A, above… that is, “go transparent.” It just always seems more flexible to me, I always *know* it’s going to work, and I rarely can *really* know by AddDevice time that I don’t want to instantiate.

Not creating the filter device object and returning STATUS_SUCCESS from AddDevice should be fine… but I really can’t remember ever doing it in a shipping product.

Peter
OSR

Alex_Grig · November 30, 2011, 10:49pm

I suppose the service for your filter has Boot Start type, and it’s registered as a lower filter for disk class. This should cause its AddDevice to be called when the disk stack is being built. If your AddDevice is null while the driver is a lower filter, I think the stack creation will fail and cause the dreaded 7B. When AddDevice is called, I think HKLM\SYSTEM is fully readable.

Prokash_Sinha-1 · November 30, 2011, 10:59pm

Once again, thanks Peter!

Yes, option A is more intuitive to me too, just trying to avoid having the presence in the stack while we know that at least this BootSession will not correct the situation and turn the filter into active mode from transparent mode. Ideally,
it should not even load ( no memory footprint), but as I understand - for a Boot Vol filter that may not be an option!

I think I will rearrange some Init code to make it fully transparent.

-pro

On Nov 30, 2011, at 5:20 PM, xxxxx@osr.com wrote:

Personally, I’m a big fan of option A, above… that is, “go transparent.” It just always seems more flexible to me, I always *know* it’s going to work, and I rarely can *really* know by AddDevice time that I don’t want to instantiate.

Not creating the filter device object and returning STATUS_SUCCESS from AddDevice should be fine… but I really can’t remember ever doing it in a shipping product.

Peter
OSR

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