Device Path Exerciser test in HCT 11.1 problem?

I have an user interface to my driver. The Device Path Exerciser test found
it, lucky me. Well the things BSOD. Here’s the stack.

f71eabe4 baf585d5 005c003f 81e587f8 81e594d8 sunbrdge!PnpLockDevice+0xd
[f:\src\penguin\sw\intel\win2k\wdm\wdmpnp.c @ 65]
f71eabfc 804eca36 005c003f 00000007 806c8214
sunbrdge!DriverPnPControlIO+0x29
[f:\src\penguin\sw\intel\win2k\bridge\brdrvobj.c @ 665]
f71eac0c 80647111 82de0ffc f71eaca0 82de0f68 nt!IopfCallDriver+0x31
f71eac30 8056b1ed f71eaca0 81813940 81e587f8 nt!IovCallDriver+0x9e
f71eac5c 8056bfb1 81e587f8 f71eac7c f71eaca8 nt!IopSynchronousCall+0xb8
f71eaca0 80552ad5 81813940 f71eacb0 00000000
nt!IopGetRelatedTargetDevice+0x4f
f71eacb4 806001e0 81813940 f71ead18 f71ead64
nt!IoGetRelatedTargetDevice+0x14
f71ead48 804da140 000000d8 0006e224 00314e10
nt!NtSetVolumeInformationFile+0xd0
f71ead48 7ffe0304 000000d8 0006e224 00314e10 nt!KiSystemService+0xc4
0006e1f0 77f765c3 0100cefd 000000d8 0006e224
SharedUserData!SystemCallStub+0x4
0006e1f4 0100cefd 000000d8 0006e224 00314e10
ntdll!ZwSetVolumeInformationFile+0xc

Now to my confusion. I thought the IO manager was suppose to gurantee a
valid DeviceObject address on input to my major I/O interface functions.
The stack above proves that that is not the case.

Now to my question. Do I have to save away a lookaside list of DeviceObject
pointers (i.e. the DriverObject) that have been created from my AddDevice
function? This lookaside list would be used in validating device objects
that have been sent to my major I/O interface functions.

Is this right? Or is there something else that is wrong?

Joe

Look and see if the DeviceExtension is 0. That is usually the problem the
exerciser interjects.

“Joe Moriarty” wrote in message
news:xxxxx@ntdev…
>
> I have an user interface to my driver. The Device Path Exerciser test
found
> it, lucky me. Well the things BSOD. Here’s the stack.
>

Doug wrote:

Look and see if the DeviceExtension is 0. That is usually the problem the
exerciser interjects.

My first reaction was, “say what?” Then I realized that a valid, if
slightly devious, test would be to null the DeviceExtension pointer when
the reference count on a DEVICE_OBJECT drops to zero. That would catch
people who keep stale DEVICE_OBJECT pointers somewhere, or who have
completion routines for IRPs that finish after IoDeleteDevice returns,
etc. Is that what you’re talking about?


Walter Oney, Consulting and Training
Basic and Advanced Driver Programming Seminars
Now teaming with John Hyde for USB Device Engineering Seminars
Check out our schedule at http://www.oneysoft.com

How can check to see if the DeviceExtension is 0 when the address for the
DeviceObject is invalid?

Joe

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Doug
Sent: Wednesday, February 19, 2003 8:44 AM
To: NT Developers Interest List
Subject: [ntdev] Re: Device Path Exerciser test in HCT 11.1 problem?

Look and see if the DeviceExtension is 0. That is usually the problem the
exerciser interjects.

“Joe Moriarty” wrote in message
> news:xxxxx@ntdev…
> >
> > I have an user interface to my driver. The Device Path Exerciser test
> found
> > it, lucky me. Well the things BSOD. Here’s the stack.
> >
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@east.sun.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com

How it gets to be NULL is not what I am talking about. I just know that I
have seen the exerciser pass me a valid DeviceObject with a NULL
DeviceExtension. I had code to always check to make sure the device
extension data was valid (i.e. signature check like devExt->Signature), but
if the device extension is NULL, it would cause a trap which is why they
probably include it.

Doug

“Walter Oney” wrote in message news:xxxxx@ntdev…
> My first reaction was, “say what?” Then I realized that a valid, if
> slightly devious, test would be to null the DeviceExtension pointer when
> the reference count on a DEVICE_OBJECT drops to zero. That would catch
> people who keep stale DEVICE_OBJECT pointers somewhere, or who have
> completion routines for IRPs that finish after IoDeleteDevice returns,
> etc. Is that what you’re talking about?

I have never seen the exerciser pass an invlaid Device Object.

“Joe Moriarty” wrote in message
news:xxxxx@ntdev…
>
> How can check to see if the DeviceExtension is 0 when the address for the
> DeviceObject is invalid?
>
> Joe

Device Path Excerciser CAN’T pass an invalid Device Object. And it
certainly doesn’t zero any internal pointers. It’s a 100% user-mode
application.

Now, it DOES send some rather devious functions off to drivers, and some
rather devious PATH names on the Create… but an “invalid” Device Object?
Nope.

P

“Doug” wrote in message news:xxxxx@ntdev…
>
> I have never seen the exerciser pass an invlaid Device Object.
>
> “Joe Moriarty” wrote in message
> news:xxxxx@ntdev…
> >
> > How can check to see if the DeviceExtension is 0 when the address for
the
> > DeviceObject is invalid?
> >
> > Joe
>
>
>
>

I just call them as I see them from the device driver point of view.
Previous beta versions of HCT 11 with the path exerciser had NULL device
extension fields which I had to account for to stop the traps in my driver.

“Peter Viscarola” wrote in message news:xxxxx@ntdev…
>
> Device Path Excerciser CAN’T pass an invalid Device Object. And it
> certainly doesn’t zero any internal pointers. It’s a 100% user-mode
> application.