Get DeviceObject pointer from name

Greetings all,

We have a PCIe device which exposes some useful information in config space in the event that the firmware bombs. The Management Requires that I provide a utility to read this information. This I am able to do - I get the pdo name from SetupDi, pass it to a newly-created non-pnp driver, which calls IoGetDeviceObjectPointer, and sends IRP_MJ_PNP/IRP_MN_READ_CONFIG to the device to read config space. Simples.

However there are states where the firmware is badly enough broken that the in-box function driver (stornvme) is not able to start. In that case, IoGetDeviceObjectPointer fails with STATUS_NO_SUCH_DEVICE. This leads to a few questions:-

  1. Can I get that pointer via other means? My best lead so far has been ObReferenceObjectByName - but I’d rather not use undocumented functions if there is a better way.

  2. I’ve tried ObReferenceObjectByName(), but it returns STATUS_OBJECT_TYPE_MISMATCH (I tried *IoFileObjectType and *IoDeviceObjectType without success) - any ideas what might work?

  3. It IS possible to read the device’s config space when in this state - DeviceManager shows enough to prove that it can. I guess I don’t know yet what will happen if I send IRP_MN_READ_CONFIG when the function driver isn’t started, I’m thinking it should be OK but does anyone have evidence to the contrary?

  4. Is there just a better way to do this?

xxxxx@thegreenho.me wrote:

  1. It IS possible to read the device’s config space when in this state - DeviceManager shows enough to prove that it can. I guess I don’t know yet what will happen if I send IRP_MN_READ_CONFIG when the function driver isn’t started, I’m thinking it should be OK but does anyone have evidence to the contrary?

IRP_MN_READ_CONFIG is handled by the PCI bus driver. If you can get
that request into a PCI-created PDO, it will work whether or not there
is any more drivers on top of it.

  1. Is there just a better way to do this?

If you can make that work, that’s the better solution. You CAN just
blast direct reads into the configuration space yourself, bypassing any
drivers. You go to hell for that, of course, because you don’t own that
resource, but in case of emergency it’s worth remembering.


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

Tim,

As I remind people you can not only go to hell, you can be dragged to
court. I know of a startup where they did this and lost not only the
company but also personal wealth because they pulled the shit of going
direct to the PCI space. Creating a filter for the PCI bus driver is not
that hard (I’ve done it for several firms), if this is a drop dead
requirement, then that is the way to go.

Don Burn
Windows Driver Consulting
Website: http://www.windrvr.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Wednesday, March 11, 2015 12:59 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Get DeviceObject pointer from name

xxxxx@thegreenho.me wrote:

  1. It IS possible to read the device’s config space when in this state -
    DeviceManager shows enough to prove that it can. I guess I don’t know yet
    what will happen if I send IRP_MN_READ_CONFIG when the function driver isn’t
    started, I’m thinking it should be OK but does anyone have evidence to the
    contrary?

IRP_MN_READ_CONFIG is handled by the PCI bus driver. If you can get that
request into a PCI-created PDO, it will work whether or not there is any
more drivers on top of it.

  1. Is there just a better way to do this?

If you can make that work, that’s the better solution. You CAN just blast
direct reads into the configuration space yourself, bypassing any drivers.
You go to hell for that, of course, because you don’t own that resource, but
in case of emergency it’s worth remembering.


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


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

> You CAN just blast direct reads into the configuration space yourself, bypassing any drivers.

You go to hell for that, of course, because you don’t own that resource, …

Thanks Tim, I am aware of that particular road to perdition, and am strenuously avoiding it :slight_smile:
Thanks more so for confirming my thoughts on (3).

Further news…
The following code works:-

RtlInitUnicodeString(&pciDriverNameString, L"\Driver\pci");
status = ObReferenceObjectByName(&pciDriverNameString,
OBJ_CASE_INSENSITIVE | OBJ_OPENIF,
NULL,
0,
*IoDriverObjectType,
KernelMode,
NULL,
(PVOID *)&extension->pciDriverObject);
[…]
if (extension->pciDriverObject)
{
#define MY_PROPBUF_SIZE 256
PDEVICE_OBJECT pdo = extension->pciDriverObject->DeviceObject;
WCHAR propBuf[MY_PROPBUF_SIZE];
ULONG dummy;
while (pdo)
{
MY_DPRINT((LOG_VERBOSE, “Found pci pdo %p\n”, pdo));
if (NT_SUCCESS(IoGetDeviceProperty(pdo,
DevicePropertyPhysicalDeviceObjectName, MY_PROPBUF_SIZE, propBuf, &dummy)))
{
MY_DPRINT((LOG_VERBOSE, " %ws\n", propBuf));
}
pdo = pdo->NextDevice;
}
}

  • and I can match the pdo name I’m looking for.
    This doesn’t feel safe though - I expect the device object list is protected by a lock to which I don’t have access. Any hints on how I could make this concept robust?

> Creating a filter for the PCI bus driver

I like this idea. One question before I delve in …
The requirements are (reasonably for once :wink: that any such debugging service is only installed and run where we need to diagnose a fault. We don’t want to have to install this for normal use (otherwise we’d just use my nvme driver, which starts successfully even if the firmware dies).
Would I be able to attach a PCI filter driver live, without a reboot?
And detach after downloading the data?
And delete the service without another reboot?

(OK, that turned into three questions…)

Unfortunately no, the PCI filter driver will be in the stack for everything.
This is the problem, I wish Microsoft would add an interface that allow
these queries, it seems like something that a large number of companies try,
and half of them head down the road to hell.

Don Burn
Windows Driver Consulting
Website: http://www.windrvr.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@thegreenho.me
Sent: Wednesday, March 11, 2015 1:25 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Get DeviceObject pointer from name

Creating a filter for the PCI bus driver

I like this idea. One question before I delve in …
The requirements are (reasonably for once :wink: that any such debugging
service is only installed and run where we need to diagnose a fault. We
don’t want to have to install this for normal use (otherwise we’d just use
my nvme driver, which starts successfully even if the firmware dies).
Would I be able to attach a PCI filter driver live, without a reboot?
And detach after downloading the data?
And delete the service without another reboot?

(OK, that turned into three questions…)


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