IRP_MJ_PNP function doesnt call

Hi

I am trying to write simple WDM driver to catching device object that associated with plugged device. Basically i wrote DriverEntry such as following;

NTSTATUS DriverEntry(PDRIVER_OBJECT DriverObject, PUNICODE_STRING RegistryPath)
{
UNREFERENCED_PARAMETER(RegistryPath);

NTSTATUS status = STATUS_SUCCESS;
int i;
DriverObject->DriverUnload = DriverUnload;

for (i = 0; i <= IRP_MJ_MAXIMUM_FUNCTION; i++)
{
	DriverObject->MajorFunction[i] = DispatchPass;
}

// Biz sadece read request ile ilgileneceğiz.
DriverObject->MajorFunction[IRP_MJ_READ] = DispatchRead;
DriverObject->MajorFunction[IRP_MJ_PNP] = DispatchPnP;

DbgPrintEx(DPFLTR_IHVDRIVER_ID, DPFLTR_ERROR_LEVEL, "DriverEntry called\r\n");

return status;

}

But somehow, when i plugged flash memory or any device that connected with usb this function was not called. I tried KMDF driver with this function;
status = WdfDeviceInitAssignWdmIrpPreprocessCallback(
DeviceInit,
DispatchPnP,
IRP_MJ_PNP,
NULL,
0);

but it doesnt worked. I dont understand why. How can i catch device object which is associated plugged device?

btw, i wrote filter driver for ps2 keyboard and mouse, i want to write filter driver with same method by using pnp callback events. I’ll be happy if you can help me.

Regards.

How are you installing yourself into the stacks you want to filter? Adding a pnp handler doesn’t mean you will be included in every pnp stack. Being in a pnp stack requires an explicit install step to either be added a a device or class filter. Your filter driver for a ps2 keyboard and mouse, if based on the WDK samples, are installed as device upper filters.

1 Like

@Doron_Holan said:
How are you installing yourself into the stacks you want to filter? Adding a pnp handler doesn’t mean you will be included in every pnp stack. Being in a pnp stack requires an explicit install step to either be added a a device or class filter. Your filter driver for a ps2 keyboard and mouse, if based on the WDK samples, are installed as device upper filters.

Hi Doron,

Thank you for answer, Is it necessary to call the “DispatchPnP” function in my example? I want to have a common function for all usb devices without discrimination. Can you explain a little more about what I have to do? is it about .inf file? any documentation?

You need to do a lot more reading about Windows drivers and devices, because you don’t yet understand the fundamental concepts. One of OSR’s classes would be a good start.

Each device has its own independent set of drivers, and each driver instance handles one device. There is no single spot where all I/O requests funnel through. It is possible to load a filter driver as part of a single device’s stack, and it is possible to have a “class filter” where a new instance will be inserted into the stack for every device of a certain install class. If there were 8 devices in the class, you’d have 8 separate device objects.

For each device, your filter instance would get all of the I/O requests passing through.

What is it, exactly, that you are hoping to accomplish? What’s the overall goal? Given your misunderstandings of the fundamentals, it’s quite possible that your task is not achievable, or can be better achieved in another way.

But somehow, when i plugged flash memory or any device that connected with usb this function was not called

The most obvious question is “Why do you want to write a WDM driver in the year 2020,in the first place???”

Notwithstanding this part, lets proceed to your actual question.

First of all, if you want your DrvEntry() to get invoked by the system when your target device gets plugged in, you have to write an INF file that specifies your driver’s PnP role in the target PnP stack(s), and take an extra step of actually installing this file. Second, when your DrvEntry() gets actually invoked, it has to register AddDevice() function (i.e the one that actually creates a new device and attaches it to the stack), as well as IRP_MJ_PNP handler. This is the very,very,very minimum that any PnP- compliant driver has to do.

Once nothing, apart from the IRP_MJ_PNP handler registration part, has been done in so far, you are completely out of luck for the time being…

I want to have a common function for all usb devices without discrimination

Just like that? A generic function for all keychains, mice, cameras, and, in general, for all USB devices of all USB classes in existence?

Anton Bassov

Hi Tim,

Each device has its own independent set of drivers, and each driver instance handles one device.

An enlightenment came after this sentence :). I realized a driver called name “usbhub3”. Before and after mounting the disk with usb. It is attached.


And then i wrote this code;

`NTSTATUS status;
UNICODE_STRING DriverName = RTL_CONSTANT_STRING(L"\Driver\USBHUB3");

if (NULL != OrgDispatchPnPFunc)
{
	DbgPrintEx(DPFLTR_IHVDRIVER_ID, DPFLTR_ERROR_LEVEL, "Driver already attached\r\n");
	return STATUS_SUCCESS;
}

PDRIVER_OBJECT targetDriverObject = NULL;

status = ObReferenceObjectByName(&DriverName, OBJ_CASE_INSENSITIVE, NULL, 0, *IoDriverObjectType, KernelMode,
	NULL, (PVOID*)&targetDriverObject);

if (!NT_SUCCESS(status))
{
	DbgPrintEx(DPFLTR_IHVDRIVER_ID, DPFLTR_ERROR_LEVEL, "ObjectReferenceObjectByName failed: %ld\r\n", status);
	return status;
}

ObDereferenceObject(targetDriverObject);

//targetDriverObject.
OrgDispatchPnPFunc = targetDriverObject->MajorFunction[IRP_MJ_PNP];
targetDriverObject->MajorFunction[IRP_MJ_PNP] = DispatchPnP;`     

As you can see I keep the original function address specified for IRP_MJ_PNP. Then i set the my function address. My DispatchPnP function is empty. When i run this driver nothing happened when I plugged in the usb device. So i managed to block it. In DriverUnload function i set original function pointer with same method. The question is; is it a good way to hook another driver’s IRP message this way?

What is it, exactly, that you are hoping to accomplish? What’s the overall goal? Given your misunderstandings of the fundamentals, it’s quite possible that your task is not achievable, or can be better achieved in another way.

My goal is prevent usb devices for data loss. I read that this can be done with the usb bus filter driver, but I could not find an example.

Hi Anton,

The most obvious question is “Why do you want to write a WDM driver in the year 2020,in the first place???”
:))))))

I found a tutorial and I’m trying to learn. I don’t have a special request to write wdm. The subject is really complicated and I’m very confused. I also tried windows driver examples but I am more confused. What I am doing now is trying to learn. I prefer to write kmdf. I found a tutorial about wdm and thanks to this tutorial, I thought I could learn.

Maybe what serves my purpose is to write a filter driver. But I could not find the right example for such a wide-ranging request.

Just like that? A generic function for all keychains, mice, cameras, and, in general, for all USB devices of all USB classes in existence?

In the first place, I thought it might be good to have a common capture function for all usb devices. I may be thinking wrong. I’m learning. If I’m moving right, I can filter them in the next step. I would be very glad if you check my reply to Tim and write your valuable comments.

Regards

@anton_bassov said:

But somehow, when i plugged flash memory or any device that connected with usb this function was not called

The most obvious question is “Why do you want to write a WDM driver in the year 2020,in the first place???”

Notwithstanding this part, lets proceed to your actual question.

First of all, if you want your DrvEntry() to get invoked by the system when your target device gets plugged in, you have to write an INF file that specifies your driver’s PnP role in the target PnP stack(s), and take an extra step of actually installing this file. Second, when your DrvEntry() gets actually invoked, it has to register AddDevice() function (i.e the one that actually creates a new device and attaches it to the stack), as well as IRP_MJ_PNP handler. This is the very,very,very minimum that any PnP- compliant driver has to do.

Once nothing, apart from the IRP_MJ_PNP handler registration part, has been done in so far, you are completely out of luck for the time being…

I want to have a common function for all usb devices without discrimination

Just like that? A generic function for all keychains, mice, cameras, and, in general, for all USB devices of all USB classes in existence?

Anton Bassov

The question is; is it a good way to hook another driver’s IRP message this way?

Of course it’s not a good way. It’s slimy. You’re not part of their device stack, so you won’t get notified when something happens. If their driver should get reloaded, maybe because the last hub got replugged, the new driver will come up at a different address, and your remembered address will be wrong.

There is a well-defined and supported mechanism for filtering IRPs in a device stack: a filter driver. That way, you become part of the device stack, so you get notified any time something happens, and things all come up and shut down in an orderly way.

Windows already has group policies to block classes of USB devices from operating.

This is not a good learning exercise. It is a waste of time. Sort of like learning how to write with a goose quill instead of a pen or pencil. You can do it if you want to learn about how they did things back in the “days of old” … but it has very little practical use today.

Find a different tutorial. Stop wasting your time.

Peter

Hi Tim,

There is a well-defined and supported mechanism for filtering IRPs in a device stack: a filter driver. That way, you become part of the device stack, so you get notified any time something happens, and things all come up and shut down in an orderly way.

You mean IoAttachDeviceToDeviceStackSafe(…) function? I can attach with this function to all device objects in another driver. But this function needs device object which is part of target driver. But in my case the device object has not been created yet. My goal is to capture the moment when the device object was created. Is there a better way to do what I want? If yes, can you direct me on where to look?

Regards.

Did I mention that you’re wasting your time? I can’t remember if I said that yet…

Peter

Hi Peter,

First of all, thank you for your comment. It does not mean that I do not follow your advice. I’m doing this because I’m looking for a way out. I noticed that WDM is lower level than other driver models and KMDF covers WDM. Am I wrong? Like MFC with Win32. I think the best way to learn the basics is to try to understand with WDM.
After understanding how things happen in the background, I prefer to write KMDF. If I find a ready solution for my current problem, I would delay my learning process and prefer KMDF again. I dont insist on WDM.

Regards.

You are actually going about it backwards. Learn KMDF first, it is the
standard for kernel and user mode driver development. After you have
acquired a basic working knowledge of how to write a WDF driver, exploring
WDM apis is fine.

Mark Roddy

OP, You don’t have an AddDevice function in your DriverEntry().
As other said, don’t spend time on WDM unless you want to brain tease yourself. If you do, consider starting with a working example like toaster. Not sure if they still have it in DDK.

Regards,
Calvin

Hi Returning to the problem itself, as I mentioned before, I tried to understand windows driver examples and KMDF projects and did research. But I couldn’t find a solution. (This does not mean that there is no solution.) Since I could find a more understandable source about wdm, I proceeded through wdm. There is no other reason. I want to summarize what I want to do again. When any device is plugged into the USB, I want to capture and attach device object of this device as soon as it is created. I don’t want to make a distinction about these devices right now. I would be very pleased if you say that this can be done in acceptable ways in kmdf. Regards.

My goal is to capture the moment when the device object was created. Is there a better way to do what I want?

I TOLD you. Write a PnP filter driver. When you do that, the kernel will load your driver automatically for every new device that is created. Doing a filter driver is not just about which APIs you call. It’s about marking yourself in the registry so the operating system handles the details for you. KMDF makes filter drivers almost trivially easy.

I noticed that WDM is lower level than other driver models and KMDF covers WDM. Am I wrong?

Only partially. It is true that KMDF is built on top of WDM, but that’s almost entirely irrelevant. KMDF fixed things that are nearly impossible in WDM. KMDF manages the annoying details that everyone got wrong. It has been said that there has NEVER been a WDM driver that handles power management correctly until KMDF came along. Their state machine for handing PnP and Power events has hundreds of states.

No GUI programmer would think of doing a C++ Windows app direct to the API any more. Everyone uses MFC or WTL or Windows Forms, because those are provably better ways of doing things. The KMDF situation is very similar.

When any device is plugged into the USB, I want to capture and attach device object of this device as soon as it is created.

There is essentially nothing you can do that applies generically to all USB devices. You will only cause yourself pain. However, making yourself an upper filter to your USB hub devices would allow you to do this.

Hi Tim,

Thank you for your explanations. I am reviewing this code.

https://github.com/microsoft/Windows-driver-samples/blob/master/general/toaster/toastDrv/kmdf/filter/generic/filter.c

I think i am going on the right way. Are there any sources other than msdn that you can recommend to me? (e-books, class, article etc.)

Regards.

It has been said that there has NEVER been a WDM driver that handles power management correctly until KMDF came along.

Well, many things “have been said” on this planet. The trick here is to filter the very obvious hype and nonsense, and to allow only those statements that may have at least some theoretical chance of being plausible, “down the stack”. If this filtering criteria was applied here,
the above “assertion” (which was, indeed, made quite a few times in this NG) would have never stood a slightest chance, and would have been immediately discarded simply as “yet another ridiculous claim that one may hear from our usual suspects” by the topmost filter
in the stack right on the spot. However, as one can see, it gets repeated again and and again and again, for some reason.

Let’s imagine for a moment that this assertion is, indeed, true. It automatically implies that ABSOLUTELY all system-provided stacks, class drivers, bus drivers including ACPI.sys, and all other in-box drivers in existence that had been released before the advent of KMDF,
were “getting it wrong all the way”.

This, in turn, makes one wonder how Win2K and Windows XP managed to run not only without causing widespread fires and explosions, but even without damaging the hardware on more or less regular basis (please note that we are speaking about the PM stuff here)…

Anton Bassov

Anton,

Your ability to troll a thread astounds me, even after all these years, you know that?

I don’t know who authored the phrase about which you object, but it could have been me. And regardless, I stand by it as being a useful, if perhaps ever so slightly exaggerated, rubric.

Having BEEN there when KMDF’s PnP and Power State machine was being developed (and don’t forget our own Mr. Holan is one of the primary designers and developers of this work), I can tell you that nobody… NOBODY… had EVER taken the considerable time and effort required to figure out how the complete PnP and Power state machine should work before KMDF. I remember one specific occasion standing in the hallway with Mr. Oshins and (I think) Mr. Holan, looking at a diagram of the huge, evolving, PnP/Power state machine on the wall, discussing one particular state (I don’t remember what it was). None of us knew what should be done at that point. I remember one of the devs going down the hall to ask the guy who owned Power (I think) at the time exactly what he expected to happen, while we waited. He came back with the answer. And so it progressed through many, many, states.

It is a fact that I have never seen (prior to KMDF) a WDM driver (in-box or 3rd party) that handles PnP and Power via a State Machine. OSR is the only author that I am aware of that has always written PnP/Power code this way. This failing, by itself, almost guarantees getting the implementation wrong.

An even casually competent engineer will understand that there is a world of difference between an implementation being “correct” and an implementation working well enough “most of the time.” Clearly, the in-box WDM drivers handled PnP and Power right “most of the time.” That does not make them correct.

Continue to troll, as you do. But at least try a little harder to make arguments that aren’t so obviously ignorant.

Peter

While I don’t have the insider knowledge that Peter had, I was at the Driver Developer Conference where they showed the state machines. They were huge. One of the comments in the presentation was that a number of drivers were getting some of their more major holes fixed now that there was a model for “doing it right”.

So, Anton, Microsoft acknowledged years ago that there were significant holes in their implementation, why do you think you can get it right by yourself?