NDIS Driver and IRP_MJ_SYSTEM_CONTROL handling

NTDEV
1

Hi all.

We’ve been meaning to test our NDIS Intermediate driver through driver verifier, but immediately encountered a BSOD: IO SYSTEM VERIFICATION ERROR in <our-driver.sys> (WDM DRIVER ERROR 220).

So I’ve been reading a little, and figured this error is caused by improper handling of IRP_MJ_SYSTEM_CONTROL, which is quite understandable as in our driver, we simply returned STATUS_UNSUCCESSFUL whenever this IRP was received.

The first thing I tried in order to deal with the situation, is changing STATUS_UNSUCCESSFUL to STATUS_NOT_SUPPORTED, which didn’t have any impact - the BSOD remained.

Now, I understand that we should either implement WMI support by handling this IRP correctly, or pass it down to the next-lower device in the stack.

I don’t think we’re interested in implementing WMI support, so our preferred choice would be the latter - pass the IRP to the next-lower device in the stack. However, what should we do if there is no next-lower device in the stack? We’re not a filter driver, but an NDIS driver - as I said, and we’re not actually ‘IN’ the devices stack (we never do IoAttachDeviceToDeviceStack). So what should we do?

This whole topic is brand new to me, so I hope I’ve made myself reasonably clear, and haven’t got the idea entirely wrong.

Anxiously awaiting your advice…

Thanks,
S.

---------------------------------
Cheap Talk? Check out Yahoo! Messenger’s low PC-to-Phone call rates.</our-driver.sys>

2

I’m a novice too but generally, if you are the lowest level driver you should complete the IRP. You are not doing WMI stuff so I would just call IoCompleteRequest.

/Daniel

“Steven Gerrard” wrote in message news:xxxxx@ntdev…
Hi all.

We’ve been meaning to test our NDIS Intermediate driver through driver verifier, but immediately encountered a BSOD: IO SYSTEM VERIFICATION ERROR in <our-driver.sys> (WDM DRIVER ERROR 220).

So I’ve been reading a little, and figured this error is caused by improper handling of IRP_MJ_SYSTEM_CONTROL, which is quite understandable as in our driver, we simply returned STATUS_UNSUCCESSFUL whenever this IRP was received.

The first thing I tried in order to deal with the situation, is changing STATUS_UNSUCCESSFUL to STATUS_NOT_SUPPORTED, which didn’t have any impact - the BSOD remained.

Now, I understand that we should either implement WMI support by handling this IRP correctly, or pass it down to the next-lower device in the stack.

I don’t think we’re interested in implementing WMI support, so our preferred choice would be the latter - pass the IRP to the next-lower device in the stack. However, what should we do if there is no next-lower device in the stack? We’re not a filter driver, but an NDIS driver - as I said, and we’re not actually ‘IN’ the devices stack (we never do IoAttachDeviceToDeviceStack). So what should we do?

This whole topic is brand new to me, so I hope I’ve made myself reasonably clear, and haven’t got the idea entirely wrong.

Anxiously awaiting your advice…

Thanks,
S.

------------------------------------------------------------------------------
Cheap Talk? Check out Yahoo! Messenger’s low PC-to-Phone call rates.</our-driver.sys>

3

----- Original Message -----
From: Steven Gerrard
To: Windows System Software Devs Interest List
Sent: Thursday, November 30, 2006 8:08 AM
Subject: [ntdev] NDIS Driver and IRP_MJ_SYSTEM_CONTROL handling

Hi all.

We’ve been meaning to test our NDIS Intermediate driver through driver verifier, but immediately encountered a BSOD: IO SYSTEM VERIFICATION ERROR in <our-driver.sys> (WDM DRIVER ERROR 220).

So I’ve been reading a little, and figured this error is caused by improper handling of IRP_MJ_SYSTEM_CONTROL, which is quite understandable as in our driver, we simply returned STATUS_UNSUCCESSFUL whenever this IRP was received.

Probably it’s a stupid question. Are you completing the IRP correctly with IoCompleteRequest?

Can you provide the output of !analyze -v of the crash dump?

Have a nice day
GV

The first thing I tried in order to deal with the situation, is changing STATUS_UNSUCCESSFUL to STATUS_NOT_SUPPORTED, which didn’t have any impact - the BSOD remained.

Now, I understand that we should either implement WMI support by handling this IRP correctly, or pass it down to the next-lower device in the stack.

I don’t think we’re interested in implementing WMI support, so our preferred choice would be the latter - pass the IRP to the next-lower device in the stack. However, what should we do if there is no next-lower device in the stack? We’re not a filter driver, but an NDIS driver - as I said, and we’re not actually ‘IN’ the devices stack (we never do IoAttachDeviceToDeviceStack). So what should we do?

This whole topic is brand new to me, so I hope I’ve made myself reasonably clear, and haven’t got the idea entirely wrong.

Anxiously awaiting your advice…

Thanks,
S.

------------------------------------------------------------------------------
Cheap Talk? Check out Yahoo! Messenger’s low PC-to-Phone call rates. — Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer</our-driver.sys>

4

On Nov 30, 2006, at 11:23 AM, Gianluca Varenni wrote:

----- Original Message -----
From: Steven Gerrard
To: Windows System Software Devs Interest List
Sent: Thursday, November 30, 2006 8:08 AM
Subject: [ntdev] NDIS Driver and IRP_MJ_SYSTEM_CONTROL handling

Hi all.

We’ve been meaning to test our NDIS Intermediate driver through
driver verifier, but immediately encountered a BSOD: IO SYSTEM
VERIFICATION ERROR in <our-driver.sys> (WDM DRIVER ERROR 220).
>
> So I’ve been reading a little, and figured this error is caused by
> improper handling of IRP_MJ_SYSTEM_CONTROL, which is quite
> understandable as in our driver, we simply returned
> STATUS_UNSUCCESSFUL whenever this IRP was received.
>
> Probably it’s a stupid question. Are you completing the IRP
> correctly with IoCompleteRequest?
>
> Can you provide the output of !analyze -v of the crash dump?
>

More questions: why are you getting these IRPs in your IM driver? Are
you registering a control device and setting an entry point for
SYSTEM_CONTROL? If you’re always simply failing it, don’t register
for it. And if you’re doing something sneaky with intercepting NDIS’s
entry point for your driver object, well, don’t; that causes problems
in various ways.

But fundamentally, if you don’t have any need for SYSTEM_CONTROL, you
shouldn’t register for it or handle it.

-sd</our-driver.sys>

5

IRP_MJ_SYSTEM_CONTROL must be supported by all devices. If a device doesn’t use WMI, it must forward the IRP. Also, he said he is not a filter. How can you make up from his message that his driver is an intermediate driver ?

Thanks,

/Daniel

“Steve Dispensa” wrote in message news:xxxxx@ntdev…

But fundamentally, if you don’t have any need for SYSTEM_CONTROL, you shouldn’t register for it or handle it.

-sd

6

The OP said he was testing an NDIS IM driver, right?

We’ve been meaning to test our NDIS Intermediate driver through
driver verifier, but immediately
> encountered a BSOD: IO SYSTEM VERIFICATION ERROR in driver.sys> (WDM DRIVER ERROR
> 220).

Maybe I’m missing something… I was tired when I read it the first
time…

-sd

On Dec 1, 2006, at 8:00 AM, Daniel Terhell wrote:

> IRP_MJ_SYSTEM_CONTROL must be supported by all devices. If a device
> doesn’t use WMI, it must forward the IRP. Also, he said he is not a
> filter. How can you make up from his message that his driver is an
> intermediate driver ?
>
> Thanks,
>
> /Daniel
>
> “Steve Dispensa” wrote in message
> news:xxxxx@ntdev…
>
> But fundamentally, if you don’t have any need for SYSTEM_CONTROL,
> you shouldn’t register for it or handle it.
>
> -sd
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at http://
> www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer

7

I think I’m missing something too, then.

A minimal NDIS IM driver does *not* directly expose a control device. Everything is managed under the hood by NDIS. If you take the passthru sample, it exposes a control device (registering it with NdisMRegisterDevice) and it doesn’t seem to have a dispatch routine for IRP_MJ_SYSTEM_CONTROL (which means that the OS will do it for you, probably completing those IRPs with a failure). What is the exact dispatcher code that you are using for that IRP?

You should have something like this

NTSTATUS
DispatchSystemControl(
IN PDEVICE_OBJECT DeviceObject,
IN PIRP Irp
)
{
PIO_STACK_LOCATION irpStack;
POPEN_INSTANCE pOpen;

Irp->IoStatus.Status = STATUS_UNSUCCESSFUL;
Irp->IoStatus.Information = 0;
IoCompleteRequest(Irp, IO_NO_INCREMENT);

return STATUS_UNSUCCESSFUL;
}

I’m not sure if STATUS_UNSUCCESSFUL is the correct error code, in any case there’s a page on that in the MSDN/DDK documentation regarding those IRPs

http://msdn2.microsoft.com/en-us/library/aa490413.aspx

I think that unless you do want to support WMI, you do not need to register a dispatcher for IRP_MJ_SYSTEM_CONTROL.

Have a nice day
GV

----- Original Message -----
From: Steve Dispensa
To: Windows System Software Devs Interest List
Sent: Friday, December 01, 2006 8:06 AM
Subject: Re: [ntdev] NDIS Driver and IRP_MJ_SYSTEM_CONTROL handling

The OP said he was testing an NDIS IM driver, right?

We’ve been meaning to test our NDIS Intermediate driver through driver verifier, but immediately
> encountered a BSOD: IO SYSTEM VERIFICATION ERROR in <our-driver.sys> (WDM DRIVER ERROR
> 220).

Maybe I’m missing something… I was tired when I read it the first time…

-sd

On Dec 1, 2006, at 8:00 AM, Daniel Terhell wrote:

IRP_MJ_SYSTEM_CONTROL must be supported by all devices. If a device doesn’t use WMI, it must forward the IRP. Also, he said he is not a filter. How can you make up from his message that his driver is an intermediate driver ?

Thanks,

/Daniel

“Steve Dispensa” wrote in message news:xxxxx@ntdev…

But fundamentally, if you don’t have any need for SYSTEM_CONTROL, you shouldn’t register for it or handle it.

-sd

—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer</our-driver.sys>

8

For NDIS drivers IRP_MJ_SYSTEM_CONTROL IS supported by all devices. It is
supported by the NDIS.sys driver, not within the individual “NDIS drivers”
themselves.

The “NDIS wrapper” creates and manipulates the DEVICE_OBJECT for NDIS
drivers. For example, in the case of PnP system PnP events are translated to
the NDIS equivalent.

A NDIS driver doesn’t actually have to handle any I/O paths in the
traditional sense.

Thomas F. Divine

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gianluca Varenni
Sent: Friday, December 01, 2006 11:54 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] NDIS Driver and IRP_MJ_SYSTEM_CONTROL handling

I think I’m missing something too, then.

A minimal NDIS IM driver does *not* directly expose a control device.
Everything is managed under the hood by NDIS. If you take the passthru
sample, it exposes a control device (registering it with
NdisMRegisterDevice) and it doesn’t seem to have a dispatch routine for
IRP_MJ_SYSTEM_CONTROL (which means that the OS will do it for you, probably
completing those IRPs with a failure). What is the exact dispatcher code
that you are using for that IRP?

You should have something like this

NTSTATUS
DispatchSystemControl(
IN PDEVICE_OBJECT DeviceObject,
IN PIRP Irp
)
{
PIO_STACK_LOCATION irpStack;
POPEN_INSTANCE pOpen;

Irp->IoStatus.Status = STATUS_UNSUCCESSFUL;
Irp->IoStatus.Information = 0;
IoCompleteRequest(Irp, IO_NO_INCREMENT);

return STATUS_UNSUCCESSFUL;
}

I’m not sure if STATUS_UNSUCCESSFUL is the correct error code, in any case
there’s a page on that in the MSDN/DDK documentation regarding those IRPs

http://msdn2.microsoft.com/en-us/library/aa490413.aspx

I think that unless you do want to support WMI, you do not need to register
a dispatcher for IRP_MJ_SYSTEM_CONTROL.

Have a nice day

GV

----- Original Message -----

From: Steve Dispensa mailto:xxxxx

To: Windows System mailto:xxxxx Software Devs Interest List

Sent: Friday, December 01, 2006 8:06 AM

Subject: Re: [ntdev] NDIS Driver and IRP_MJ_SYSTEM_CONTROL handling

The OP said he was testing an NDIS IM driver, right?

> We’ve been meaning to test our NDIS Intermediate driver through driver
verifier, but immediately

> encountered a BSOD: IO SYSTEM VERIFICATION ERROR in <our-driver.sys> (WDM
DRIVER ERROR

> 220).

Maybe I’m missing something… I was tired when I read it the first time…

-sd

On Dec 1, 2006, at 8:00 AM, Daniel Terhell wrote:

IRP_MJ_SYSTEM_CONTROL must be supported by all devices. If a device doesn’t
use WMI, it must forward the IRP. Also, he said he is not a filter. How can
you make up from his message that his driver is an intermediate driver ?

Thanks,

/Daniel

“Steve Dispensa” < mailto:xxxxx
xxxxx@positivenetworks.net> wrote in message news:xxxxx
news:xxxxx@ntdev…

But fundamentally, if you don’t have any need for SYSTEM_CONTROL, you
shouldn’t register for it or handle it.

-sd

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer</news:xxxxx></mailto:xxxxx></our-driver.sys></mailto:xxxxx></mailto:xxxxx>

9

On Dec 1, 2006, at 10:54 AM, Gianluca Varenni wrote:

http://msdn2.microsoft.com/en-us/library/aa490413.aspx

I think that unless you do want to support WMI, you do not need to
register a dispatcher for IRP_MJ_SYSTEM_CONTROL.

You know, that’s the impression I was under too until I read the
docs. In non-filter devices that don’t call down the stack (e.g. the
control device object that I have a hunch the OP was referring to), I
don’t think you have to register for WMI unless you want to. At
least, I never have, and lots of samples don’t, so I don’t think I’m
alone here.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/
Kernel_r/hh/Kernel_r/k113_05e7e62a-b1ed-46d8-a357-cb275e1499b6.xml.asp

“All drivers must support IRP_MJ_SYSTEM_CONTROL requests by supplying
a DispatchSystemControl routine.”

Am I wrong or is the documentation misleading? (Thinking in
particular of something like a control device object created by
NdisMRegisterDevice()).

-sd

10

By chance are you using WPP to do tracing in your driver? It will make WMI calls to set things up for you.

d

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Thomas F. Divine
Sent: Friday, December 01, 2006 9:15 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] NDIS Driver and IRP_MJ_SYSTEM_CONTROL handling

For NDIS drivers IRP_MJ_SYSTEM_CONTROL IS supported by all devices. It is supported by the NDIS.sys driver, not within the individual “NDIS drivers” themselves.

The “NDIS wrapper” creates and manipulates the DEVICE_OBJECT for NDIS drivers. For example, in the case of PnP system PnP events are translated to the NDIS equivalent.

A NDIS driver doesn’t actually have to handle any I/O paths in the traditional sense.

Thomas F. Divine

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Gianluca Varenni
Sent: Friday, December 01, 2006 11:54 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] NDIS Driver and IRP_MJ_SYSTEM_CONTROL handling

I think I’m missing something too, then.
?
A minimal NDIS IM driver does *not* directly expose a control device. Everything is managed under the hood by NDIS. If you take the passthru sample, it exposes a control device (registering it with NdisMRegisterDevice) and it doesn’t seem to have a dispatch routine for IRP_MJ_SYSTEM_CONTROL (which means that the OS will do it for you, probably completing those IRPs with a failure). What is the exact dispatcher code that you are using for that IRP?
?
You should have something like this
?
NTSTATUS
DispatchSystemControl(
??? IN PDEVICE_OBJECT??? DeviceObject,
??? IN PIRP??? Irp
??? )
{
??? PIO_STACK_LOCATION? irpStack;
?POPEN_INSTANCE??pOpen;
?
?Irp->IoStatus.Status = STATUS_UNSUCCESSFUL;
?Irp->IoStatus.Information = 0;
?IoCompleteRequest(Irp, IO_NO_INCREMENT);
?
?return STATUS_UNSUCCESSFUL;
}
I’m not sure if STATUS_UNSUCCESSFUL is the correct error code, in any case there’s a page on that in the MSDN/DDK documentation regarding those IRPs?
?
http://msdn2.microsoft.com/en-us/library/aa490413.aspx
?
I think that unless you do want to support WMI, you do not need to register a dispatcher for IRP_MJ_SYSTEM_CONTROL.
?
Have a nice day
GV
?
?
----- Original Message -----
From: Steve Dispensa
To: Windows System Software Devs Interest List
Sent: Friday, December 01, 2006 8:06 AM
Subject: Re: [ntdev] NDIS Driver and IRP_MJ_SYSTEM_CONTROL handling

The OP said he was testing an NDIS IM driver, right?

We’ve been?meaning to test our NDIS Intermediate driver through driver verifier, but immediately
?encountered a BSOD: IO SYSTEM VERIFICATION ERROR in?<our-driver.sys> (WDM DRIVER ERROR
>?220).
?

Maybe I’m missing something… I was tired when I read it the first time…

?-sd

On Dec 1, 2006, at 8:00 AM, Daniel Terhell wrote:

IRP_MJ_SYSTEM_CONTROL must be supported by all devices. If a device doesn’t use WMI, it must forward the IRP. Also, he said he is not a filter. How can you make up from his message that his driver is an intermediate driver ?
?
Thanks,
?
/Daniel
?
“Steve Dispensa” wrote in message?news:xxxxx@ntdev…

But fundamentally, if you don’t have any need for SYSTEM_CONTROL, you shouldn’t register for it or handle it.

?-sd

?

—?
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256?

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer</our-driver.sys>

11

I agree, the documentation is definitely misleading. In the “Required
Dispatch Routines” section, it says “Most drivers must handle the following
Dispatch routines:”.

Who are the “most drivers”?

Definitely not a device created with NdisMRegisterDevice, that doesn’t need
to manage PnP, power, WMI. Actually the passthru sample just deals with
open/close/ioctl, not even read/write.

GV

----- Original Message -----
From: Steve Dispensa
To: Windows System Software Devs Interest List
Sent: Friday, December 01, 2006 9:28 AM
Subject: Re: [ntdev] NDIS Driver and IRP_MJ_SYSTEM_CONTROL handling

On Dec 1, 2006, at 10:54 AM, Gianluca Varenni wrote:

http://msdn2.microsoft.com/en-us/library/aa490413.aspx

I think that unless you do want to support WMI, you do not need to register
a dispatcher for IRP_MJ_SYSTEM_CONTROL.

You know, that’s the impression I was under too until I read the docs. In
non-filter devices that don’t call down the stack (e.g. the control device
object that I have a hunch the OP was referring to), I don’t think you have
to register for WMI unless you want to. At least, I never have, and lots of
samples don’t, so I don’t think I’m alone here.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/Kernel_r/hh/Kernel_r/k113_05e7e62a-b1ed-46d8-a357-cb275e1499b6.xml.asp

“All drivers must support IRP_MJ_SYSTEM_CONTROL requests by supplying a
DispatchSystemControl routine.”

Am I wrong or is the documentation misleading? (Thinking in particular of
something like a control device object created by NdisMRegisterDevice()).

-sd

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

12

Read the DDK topic “NDIS Support for WMI”.

Thomas F. Divine

http://www.pcausa.com http:</http:>

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Steve Dispensa
Sent: Friday, December 01, 2006 12:29 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] NDIS Driver and IRP_MJ_SYSTEM_CONTROL handling

On Dec 1, 2006, at 10:54 AM, Gianluca Varenni wrote:

http:
http://msdn2.microsoft.com/en-us/library/aa490413.aspx

I think that unless you do want to support WMI, you do not need to register
a dispatcher for IRP_MJ_SYSTEM_CONTROL.

You know, that’s the impression I was under too until I read the docs. In
non-filter devices that don’t call down the stack (e.g. the control device
object that I have a hunch the OP was referring to), I don’t think you have
to register for WMI unless you want to. At least, I never have, and lots of
samples don’t, so I don’t think I’m alone here.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/Kernel_r/hh
/Kernel_r/k113_05e7e62a-b1ed-46d8-a357-cb275e1499b6.xml.asp

“All drivers must support IRP_MJ_SYSTEM_CONTROL requests by supplying a
http:c0c-b3c9-4d5e-aa51-4392f9c4283b.xml.asp> DispatchSystemControl routine.”

Am I wrong or is the documentation misleading? (Thinking in particular of
something like a control device object created by NdisMRegisterDevice()).

-sd

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer</http:></http:>

13

>IRP_MJ_SYSTEM_CONTROL must be supported by all devices.

By all PnP devices, including all PnP filters.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

14

“Maxim S. Shatskih” wrote in message
news:xxxxx@ntdev…
> >IRP_MJ_SYSTEM_CONTROL must be supported by all devices.
>
> By all PnP devices, including all PnP filters.
>

Thanks for pointing out. I took this line from the WMI guidelines which
don’t make this distinction.

/Daniel

15

> > >IRP_MJ_SYSTEM_CONTROL must be supported by all devices.

>
> By all PnP devices, including all PnP filters.
>

Thanks for pointing out. I took this line from the WMI guidelines which
don’t make this distinction.

For instance, control device objects of some kernel module (have nothing to do
with PnP) live fine without supporting IRP_MJ_SYSTEM_CONTROL.

But, for PnP stacks, IRP_MJ_SYSTEM_CONTROL is a must. You never know whether
some other participants of the devnode stack have registered with WMI, and so
all except the PDO must at least pass this IRP down, and the PDO must at least
complete it in some way.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com