Trouble with IoGetDeviceObjectPointer

I’m working on a lower level filter driver for test purposes which requires communication with a test app. So I create a device object that is named/indexed. All good so far.

One of the functionality that the lower level filter driver provides is to issue a request to the parent port to reset it. Now this causes an issue as I load the the lower level filter driver on the hub driver and the children (this is a compound device). The application resets the hub which causes the downstream devices to be removed/added.

So the application has handles to these “side” device objects, and when the hardware is re-enumerated, the filter driver needs to restore a connection the corresponding side device object via an index and using IoGetDeviceObjectPointer, which returns STATUS_INVALID_DEVICE_STATE.

I’m baffled by this. This is the first time I’ve used IoGetDeviceObjectPointer. I request FILE_READ_ATTRIBUTES as all I want is the device object pointer, from which I can get the WDFDEVICE for the side device object and then the context.

status = IoGetDeviceObjectPointer(&deviceName, FILE_READ_ATTRIBUTES, &controlFileObject, &controlDeviceObject);

The side device object is created as below(this might look familiar to some of you).

If I can’t use this, I’ll just use PnP notification, but I figured this would be a simple way to manage hardware coming and going when a handle is open to the side device objects. Any hints/tips/suggestions would be greatly appreciated.

deviceInit = WdfControlDeviceInitAllocate(
Driver,
&SDDL_DEVOBJ_SYS_ALL_ADM_RWX_WORLD_RWX_RES_RWX);

if (!deviceInit) {

}

WdfDeviceInitSetExclusive(deviceInit, FALSE);

status = WdfDeviceInitAssignName(deviceInit, &deviceName);

if (!NT_SUCCESS(status))
{

}

WDF_FILEOBJECT_CONFIG_INIT(&fileObjectConfig,
WdfFltrControlCreate,
WdfFltrControlClose,
WDF_NO_EVENT_CALLBACK);

WdfDeviceInitSetFileObjectConfig(deviceInit,
&fileObjectConfig,
NULL);

status = WdfDeviceCreate(&deviceInit,
&wdfObjectAttr,
&DeviceContext->WdfFltrControlDevice);
if (!NT_SUCCESS(status))
{

}

status = WdfDeviceCreateSymbolicLink(DeviceContext->WdfFltrControlDevice,
&linkName);

if (!NT_SUCCESS(status)) {

}

controlDeviceContext = GetControlDeviceContext(DeviceContext->WdfFltrControlDevice);
controlDeviceContext->DeviceContext = DeviceContext;
controlDeviceContext->Index = i;

WDF_IO_QUEUE_CONFIG_INIT_DEFAULT_QUEUE(&ioQueueConfig,
WdfIoQueueDispatchSequential);

ioQueueConfig.EvtIoDeviceControl = WdfFltrAppIntDeviceControl;

status = WdfIoQueueCreate(DeviceContext->WdfFltrControlDevice,
&ioQueueConfig,
WDF_NO_OBJECT_ATTRIBUTES,
NULL);
if (!NT_SUCCESS(status))
{

}
WdfControlFinishInitializing(DeviceContext->WdfFltrControlDevice);

Are you getting a PDEVICE_OBJECT created outside of your driver and getting a WDFDEVICE for it? The WDFDEVICE for it doesn’t exist in the context of your driver.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Wednesday, July 1, 2015 3:08 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Trouble with IoGetDeviceObjectPointer

I’m working on a lower level filter driver for test purposes which requires communication with a test app. So I create a device object that is named/indexed. All good so far.

One of the functionality that the lower level filter driver provides is to issue a request to the parent port to reset it. Now this causes an issue as I load the the lower level filter driver on the hub driver and the children (this is a compound device). The application resets the hub which causes the downstream devices to be removed/added.

So the application has handles to these “side” device objects, and when the hardware is re-enumerated, the filter driver needs to restore a connection the corresponding side device object via an index and using IoGetDeviceObjectPointer, which returns STATUS_INVALID_DEVICE_STATE.

I’m baffled by this. This is the first time I’ve used IoGetDeviceObjectPointer. I request FILE_READ_ATTRIBUTES as all I want is the device object pointer, from which I can get the WDFDEVICE for the side device object and then the context.

status = IoGetDeviceObjectPointer(&deviceName, FILE_READ_ATTRIBUTES, &controlFileObject, &controlDeviceObject);

The side device object is created as below(this might look familiar to some of you).

If I can’t use this, I’ll just use PnP notification, but I figured this would be a simple way to manage hardware coming and going when a handle is open to the side device objects. Any hints/tips/suggestions would be greatly appreciated.

deviceInit = WdfControlDeviceInitAllocate(
Driver,
&SDDL_DEVOBJ_SYS_ALL_ADM_RWX_WORLD_RWX_RES_RWX);

if (!deviceInit) {

}

WdfDeviceInitSetExclusive(deviceInit, FALSE);

status = WdfDeviceInitAssignName(deviceInit, &deviceName);

if (!NT_SUCCESS(status))
{

}

WDF_FILEOBJECT_CONFIG_INIT(&fileObjectConfig,
WdfFltrControlCreate,
WdfFltrControlClose,
WDF_NO_EVENT_CALLBACK);

WdfDeviceInitSetFileObjectConfig(deviceInit,
&fileObjectConfig,
NULL);

status = WdfDeviceCreate(&deviceInit,
&wdfObjectAttr,
&DeviceContext->WdfFltrControlDevice);
if (!NT_SUCCESS(status))
{

}

status = WdfDeviceCreateSymbolicLink(DeviceContext->WdfFltrControlDevice,
&linkName);

if (!NT_SUCCESS(status)) {

}

controlDeviceContext = GetControlDeviceContext(DeviceContext->WdfFltrControlDevice);
controlDeviceContext->DeviceContext = DeviceContext;
controlDeviceContext->Index = i;

WDF_IO_QUEUE_CONFIG_INIT_DEFAULT_QUEUE(&ioQueueConfig,
WdfIoQueueDispatchSequential);

ioQueueConfig.EvtIoDeviceControl = WdfFltrAppIntDeviceControl;

status = WdfIoQueueCreate(DeviceContext->WdfFltrControlDevice,
&ioQueueConfig,
WDF_NO_OBJECT_ATTRIBUTES,
NULL);
if (!NT_SUCCESS(status))
{

}
WdfControlFinishInitializing(DeviceContext->WdfFltrControlDevice);


NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

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

Doron,

No, I’m creating a WDFDEVICE

status = WdfDeviceCreate(&deviceInit,
&wdfObjectAttr,
&DeviceContext->WdfFltrControlDevice);

My hopes was that by using IoGetDeviceObjectPointer, I’d get the
PDEVICE_OBJECT address that corresponds to the WDFDEVICE that I created
previously. If I was a betting man, my bet now would be that it won’t work.

On Wed, Jul 1, 2015 at 5:01 PM, Doron Holan
wrote:

> Are you getting a PDEVICE_OBJECT created outside of your driver and
> getting a WDFDEVICE for it? The WDFDEVICE for it doesn’t exist in the
> context of your driver.
>
> d
>
> -----Original Message-----
> From: xxxxx@lists.osr.com [mailto:
> xxxxx@lists.osr.com] On Behalf Of
> xxxxx@gmail.com
> Sent: Wednesday, July 1, 2015 3:08 PM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] Trouble with IoGetDeviceObjectPointer
>
> I’m working on a lower level filter driver for test purposes which
> requires communication with a test app. So I create a device object that
> is named/indexed. All good so far.
>
> One of the functionality that the lower level filter driver provides is to
> issue a request to the parent port to reset it. Now this causes an issue
> as I load the the lower level filter driver on the hub driver and the
> children (this is a compound device). The application resets the hub which
> causes the downstream devices to be removed/added.
>
> So the application has handles to these “side” device objects, and when
> the hardware is re-enumerated, the filter driver needs to restore a
> connection the corresponding side device object via an index and using
> IoGetDeviceObjectPointer, which returns STATUS_INVALID_DEVICE_STATE.
>
> I’m baffled by this. This is the first time I’ve used
> IoGetDeviceObjectPointer. I request FILE_READ_ATTRIBUTES as all I want is
> the device object pointer, from which I can get the WDFDEVICE for the side
> device object and then the context.
>
> status = IoGetDeviceObjectPointer(&deviceName, FILE_READ_ATTRIBUTES,
> &controlFileObject, &controlDeviceObject);
>
> The side device object is created as below(this might look familiar to
> some of you).
>
> If I can’t use this, I’ll just use PnP notification, but I figured this
> would be a simple way to manage hardware coming and going when a handle is
> open to the side device objects. Any hints/tips/suggestions would be
> greatly appreciated.
>
> deviceInit = WdfControlDeviceInitAllocate(
> Driver,
>
> &SDDL_DEVOBJ_SYS_ALL_ADM_RWX_WORLD_RWX_RES_RWX);
>
> if (!deviceInit) {
>
> }
>
> WdfDeviceInitSetExclusive(deviceInit, FALSE);
>
> status = WdfDeviceInitAssignName(deviceInit, &deviceName);
>
> if (!NT_SUCCESS(status))
> {
>
> }
>
> WDF_FILEOBJECT_CONFIG_INIT(&fileObjectConfig,
> WdfFltrControlCreate,
> WdfFltrControlClose,
> WDF_NO_EVENT_CALLBACK);
>
> WdfDeviceInitSetFileObjectConfig(deviceInit,
> &fileObjectConfig,
> NULL);
>
> status = WdfDeviceCreate(&deviceInit,
> &wdfObjectAttr,
> &DeviceContext->WdfFltrControlDevice);
> if (!NT_SUCCESS(status))
> {
>
> }
>
> status =
> WdfDeviceCreateSymbolicLink(DeviceContext->WdfFltrControlDevice,
> &linkName);
>
> if (!NT_SUCCESS(status)) {
>
> }
>
> controlDeviceContext =
> GetControlDeviceContext(DeviceContext->WdfFltrControlDevice);
> controlDeviceContext->DeviceContext = DeviceContext;
> controlDeviceContext->Index = i;
>
> WDF_IO_QUEUE_CONFIG_INIT_DEFAULT_QUEUE(&ioQueueConfig,
>
> WdfIoQueueDispatchSequential);
>
> ioQueueConfig.EvtIoDeviceControl = WdfFltrAppIntDeviceControl;
>
> status = WdfIoQueueCreate(DeviceContext->WdfFltrControlDevice,
> &ioQueueConfig,
> WDF_NO_OBJECT_ATTRIBUTES,
> NULL);
> if (!NT_SUCCESS(status))
> {
>
> }
> WdfControlFinishInitializing(DeviceContext->WdfFltrControlDevice);
>
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> 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
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> 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
>

> If I can’t use this, I’ll just use PnP notification

Yes, this is the correct way.

Indexing is evil. After some devices went away in the middle of the sequence, you have holes in it, and so cannot enumerate the whole sequence (you don’t know when you’r done).


Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com

I think you only can create an IO Target for the device you’ve opening, not WDFDEVICE.

Remember that KMDF objects are belonging to a driver and NO references to them can cross driver boundary.
“CK Software Consulting” wrote in message news:xxxxx@ntdev…
Doron,

No, I’m creating a WDFDEVICE

status = WdfDeviceCreate(&deviceInit,
&wdfObjectAttr,
&DeviceContext->WdfFltrControlDevice);

My hopes was that by using IoGetDeviceObjectPointer, I’d get the PDEVICE_OBJECT address that corresponds to the WDFDEVICE that I created previously. If I was a betting man, my bet now would be that it won’t work.

On Wed, Jul 1, 2015 at 5:01 PM, Doron Holan wrote:

Are you getting a PDEVICE_OBJECT created outside of your driver and getting a WDFDEVICE for it? The WDFDEVICE for it doesn’t exist in the context of your driver.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Wednesday, July 1, 2015 3:08 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Trouble with IoGetDeviceObjectPointer

I’m working on a lower level filter driver for test purposes which requires communication with a test app. So I create a device object that is named/indexed. All good so far.

One of the functionality that the lower level filter driver provides is to issue a request to the parent port to reset it. Now this causes an issue as I load the the lower level filter driver on the hub driver and the children (this is a compound device). The application resets the hub which causes the downstream devices to be removed/added.

So the application has handles to these “side” device objects, and when the hardware is re-enumerated, the filter driver needs to restore a connection the corresponding side device object via an index and using IoGetDeviceObjectPointer, which returns STATUS_INVALID_DEVICE_STATE.

I’m baffled by this. This is the first time I’ve used IoGetDeviceObjectPointer. I request FILE_READ_ATTRIBUTES as all I want is the device object pointer, from which I can get the WDFDEVICE for the side device object and then the context.

status = IoGetDeviceObjectPointer(&deviceName, FILE_READ_ATTRIBUTES, &controlFileObject, &controlDeviceObject);

The side device object is created as below(this might look familiar to some of you).

If I can’t use this, I’ll just use PnP notification, but I figured this would be a simple way to manage hardware coming and going when a handle is open to the side device objects. Any hints/tips/suggestions would be greatly appreciated.

deviceInit = WdfControlDeviceInitAllocate(
Driver,
&SDDL_DEVOBJ_SYS_ALL_ADM_RWX_WORLD_RWX_RES_RWX);

if (!deviceInit) {

}

WdfDeviceInitSetExclusive(deviceInit, FALSE);

status = WdfDeviceInitAssignName(deviceInit, &deviceName);

if (!NT_SUCCESS(status))
{

}

WDF_FILEOBJECT_CONFIG_INIT(&fileObjectConfig,
WdfFltrControlCreate,
WdfFltrControlClose,
WDF_NO_EVENT_CALLBACK);

WdfDeviceInitSetFileObjectConfig(deviceInit,
&fileObjectConfig,
NULL);

status = WdfDeviceCreate(&deviceInit,
&wdfObjectAttr,
&DeviceContext->WdfFltrControlDevice);
if (!NT_SUCCESS(status))
{

}

status = WdfDeviceCreateSymbolicLink(DeviceContext->WdfFltrControlDevice,
&linkName);

if (!NT_SUCCESS(status)) {

}

controlDeviceContext = GetControlDeviceContext(DeviceContext->WdfFltrControlDevice);
controlDeviceContext->DeviceContext = DeviceContext;
controlDeviceContext->Index = i;

WDF_IO_QUEUE_CONFIG_INIT_DEFAULT_QUEUE(&ioQueueConfig,
WdfIoQueueDispatchSequential);

ioQueueConfig.EvtIoDeviceControl = WdfFltrAppIntDeviceControl;

status = WdfIoQueueCreate(DeviceContext->WdfFltrControlDevice,
&ioQueueConfig,
WDF_NO_OBJECT_ATTRIBUTES,
NULL);
if (!NT_SUCCESS(status))
{

}
WdfControlFinishInitializing(DeviceContext->WdfFltrControlDevice);


NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

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

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

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

Wait: You have a WDFDEVICE and you want the PDEVICE_OBJECT to which that corresponds?

In that case, all you need to do is call WdfDeviceWdmGetDeviceObject…

Peter
OSR
@OSRDrivers

Peter,

The problem is that IoGetDeviceObjectPointer fails, so I am not able to
call WdfDeviceWdmGetDeviceObject.

On Thu, Jul 2, 2015 at 5:11 AM, wrote:

>


>
> Wait: You have a WDFDEVICE and you want the PDEVICE_OBJECT to which that
> corresponds?
>
> In that case, all you need to do is call WdfDeviceWdmGetDeviceObject…
>
> Peter
> OSR
> @OSRDrivers
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> 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
>

xxxxx@gmail.com wrote:

I’m working on a lower level filter driver for test purposes which requires communication with a test app. So I create a device object that is named/indexed. All good so far.

One of the functionality that the lower level filter driver provides is to issue a request to the parent port to reset it. Now this causes an issue as I load the the lower level filter driver on the hub driver and the children (this is a compound device). The application resets the hub which causes the downstream devices to be removed/added.

So the application has handles to these “side” device objects, and when the hardware is re-enumerated, the filter driver needs to restore a connection the corresponding side device object via an index and using IoGetDeviceObjectPointer, which returns STATUS_INVALID_DEVICE_STATE.

I’m baffled by this.

Me, too. If you have a composite device, then the hub driver loads the
generic composite driver usbccgp, which loads the individual
interfaces. When you said “I load the lower level filter driver on the
hub driver”, do you actually mean the usbccgp driver that handles
composite devices? Or do you literally mean the hub driver that is
below that?

Are you attempting to “detach” the control device objects from the old,
dead child devices, and “attach” them to the new ones, so the
application connection lives across device generations? Is that your
goal? How had you planned to line up the old and new devices, to know
which control device was which? You could, for example, have a
collection in your driver context (which is global to all instances)
that maps a hardware ID to a WDFDEVICE. Then, in your initialization,
when you get the hardware ID, you can look it up in the collection. If
found, then you have your association. If not, then you need to create
a new one.

The framework internally has a way to map a PDEVICE_OBJECT to a
WDFDEVICE, but it’s not exposed to the outside.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.