IRQL changes to 2 upon IOCTL request from user level driver

NTDEV
1

Dear Members,

I wrote a Device driver for PCI card.

The device driver is fully based on the src\general\PLX9x5x sample except:

In “PLxEvtDevicePrepareHardware ” I did not call to “PLxPrepareHardware”.

In “PLxInitializeDeviceExtension” I did not call to “PLxInterruptCreate” and to “PLxInitializeDMA”

So there is no access to hardware.

There are no memory allocations in the driver.

In “PLxInitializeDeviceExtension” I added initialization for DeviceIoControl queue based on the src\general\ioctl sample:

// Configure a default queue so that requests that are not
// configure-fowarded using WdfDeviceConfigureRequestDispatching to goto
// other queues get dispatched here.
//
WDF_IO_QUEUE_CONFIG_INIT_DEFAULT_QUEUE(&ioQueueConfig,
WdfIoQueueDispatchSequential);

ioQueueConfig.EvtIoDeviceControl = FileEvtIoDeviceControl;

WDF_OBJECT_ATTRIBUTES_INIT(&attributes);
//
// Since we are using Zw function set execution level to passive so that
// framework ensures that our Io callbacks called at only passive-level
// even if the request came in at DISPATCH_LEVEL from another driver.
//
//attributes.ExecutionLevel = WdfExecutionLevelPassive;

status = WdfIoQueueCreate(controlDevice,
&ioQueueConfig,
&attributes,
&queue // pointer to default queue
);

But upon IOCTL request from the user level driver the IRQL is 2.
I checked it with KeGetCurrentIrql()

Should I enable the line:
“attributes.ExecutionLevel = WdfExecutionLevelPassive;” ?

I compiled the driver with “build -cefgz /wAll”. There are no warnings.

I configured the verifier to monitor IRQL changes. But the counter stays 0 upon IOCTL requests.

Upon start+end of every routine in the driver I printed IRQL. It is always 0.

What is the reason IRQL changes to 0 upon IOCTL request ?

Thanks,
Zvika

2

Zvi Vered wrote:

I wrote a Device driver for PCI card.

The device driver is fully based on the src\general\PLX9x5x sample
except:

In “PLxEvtDevicePrepareHardware ” I did not call to “PLxPrepareHardware”.

In “PLxInitializeDeviceExtension” I did not call to
“PLxInterruptCreate” and to “PLxInitializeDMA”

So there is no access to hardware.

Will there be, eventually?

But upon IOCTL request from the user level driver the IRQL is 2.
I checked it with KeGetCurrentIrql()

Should I enable the line:
“attributes.ExecutionLevel = WdfExecutionLevelPassive;” ?

If you need your ioctl handler to run at passive, then yes, you would
enable that line. Before you do so, however, you need to understand
whether you need to do that. Are you planning to do things in your
ioctl handler that do not work at a raised IRQL?

What is the reason IRQL changes to 0 upon IOCTL request ?

http://msdn.microsoft.com/en-us/library/windows/hardware/ff544763.aspx

Are you setting SynchronizationScope when you create your device?
That’s the most common reason. That requires KMDF to grab a spinlock
before calling your callback, and calling a spinlock raises your IRQL.

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

3

Ah. So you use KMDF. Then you need EvtIoInCallerContext.
From the docum: "The EvtIoInCallerContext callback function is called
at the IRQL of the calling thread. If the calling thread is from a
user-mode application, the callback function is called at IRQL =
PASSIVE_LEVEL. "

– pa

On 27-Aug-2012 22:01, Zvi Vered wrote:

Dear Members,
I wrote a Device driver for PCI card.
The device driver is fully based on the src\general\PLX9x5x sample except:
In “PLxEvtDevicePrepareHardware ” I did not call to “PLxPrepareHardware”.
In “PLxInitializeDeviceExtension” I did not call to “PLxInterruptCreate”
and to “PLxInitializeDMA”
So there is no access to hardware.
There are no memory allocations in the driver.
In “PLxInitializeDeviceExtension” I added initialization for
DeviceIoControl queue based on the src\general\ioctl sample:
// Configure a default queue so that requests that are not
// configure-fowarded using WdfDeviceConfigureRequestDispatching to
goto
// other queues get dispatched here.
//
WDF_IO_QUEUE_CONFIG_INIT_DEFAULT_QUEUE(&ioQueueConfig,
WdfIoQueueDispatchSequential);
ioQueueConfig.EvtIoDeviceControl = FileEvtIoDeviceControl;
WDF_OBJECT_ATTRIBUTES_INIT(&attributes);
//
// Since we are using Zw function set execution level to passive so
that
// framework ensures that our Io callbacks called at only passive-level
// even if the request came in at DISPATCH_LEVEL from another driver.
//
//attributes.ExecutionLevel = WdfExecutionLevelPassive;
status = WdfIoQueueCreate(controlDevice,
&ioQueueConfig,
&attributes,
&queue // pointer to default queue
);
But upon IOCTL request from the user level driver the IRQL is 2.
I checked it with KeGetCurrentIrql()
Should I enable the line:
“attributes.ExecutionLevel = WdfExecutionLevelPassive;” ?
I compiled the driver with “build -cefgz /wAll”. There are no warnings.
I configured the verifier to monitor IRQL changes. But the counter stays
0 upon IOCTL requests.
Upon start+end of every routine in the driver I printed IRQL. It is
always 0.

What is the reason IRQL changes to 0 upon IOCTL request ?
Thanks,
Zvika

4

That is the wrong answer. If irql is being changed to dispatch, it is probably because of the sequential queue. If you process io in incallercontext, you lose all sequential behavior and might as well use a parallel queue and then the irql change goes away

d

debt from my phone

From: Pavel A
Sent: 8/27/2012 12:44 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] IRQL changes to 2 upon IOCTL request from user level driver

Ah. So you use KMDF. Then you need EvtIoInCallerContext.
From the docum: "The EvtIoInCallerContext callback function is called
at the IRQL of the calling thread. If the calling thread is from a
user-mode application, the callback function is called at IRQL =
PASSIVE_LEVEL. "

– pa

On 27-Aug-2012 22:01, Zvi Vered wrote:

Dear Members,
I wrote a Device driver for PCI card.
The device driver is fully based on the src\general\PLX9x5x sample except:
In ?PLxEvtDevicePrepareHardware ? I did not call to ?PLxPrepareHardware?.
In ?PLxInitializeDeviceExtension? I did not call to ?PLxInterruptCreate?
and to ?PLxInitializeDMA?
So there is no access to hardware.
There are no memory allocations in the driver.
In ?PLxInitializeDeviceExtension? I added initialization for
DeviceIoControl queue based on the src\general\ioctl sample:
// Configure a default queue so that requests that are not
// configure-fowarded using WdfDeviceConfigureRequestDispatching to
goto
// other queues get dispatched here.
//
WDF_IO_QUEUE_CONFIG_INIT_DEFAULT_QUEUE(&ioQueueConfig,
WdfIoQueueDispatchSequential);
ioQueueConfig.EvtIoDeviceControl = FileEvtIoDeviceControl;
WDF_OBJECT_ATTRIBUTES_INIT(&attributes);
//
// Since we are using Zw function set execution level to passive so
that
// framework ensures that our Io callbacks called at only passive-level
// even if the request came in at DISPATCH_LEVEL from another driver.
//
//attributes.ExecutionLevel = WdfExecutionLevelPassive;
status = WdfIoQueueCreate(controlDevice,
&ioQueueConfig,
&attributes,
&queue // pointer to default queue
);
But upon IOCTL request from the user level driver the IRQL is 2.
I checked it with KeGetCurrentIrql()
Should I enable the line:
?attributes.ExecutionLevel = WdfExecutionLevelPassive;? ?
I compiled the driver with ?build -cefgz /wAll?. There are no warnings.
I configured the verifier to monitor IRQL changes. But the counter stays
0 upon IOCTL requests.
Upon start+end of every routine in the driver I printed IRQL. It is
always 0.

What is the reason IRQL changes to 0 upon IOCTL request ?
Thanks,
Zvika

NTDEV is sponsored by OSR

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

5

He must be in user context because he wants to map memory
into the caller process. This has priority over serialization.
Must be at passive and in user context.
– pa

On 27-Aug-2012 22:57, Doron Holan wrote:

That is the wrong answer. If irql is being changed to dispatch, it is
probably because of the sequential queue. If you process io in
incallercontext, you lose all sequential behavior and might as well use
a parallel queue and then the irql change goes away

d

debt from my phone

From: Pavel A
Sent: 8/27/2012 12:44 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] IRQL changes to 2 upon IOCTL request from user level
driver

Ah. So you use KMDF. Then you need EvtIoInCallerContext.
From the docum: "The EvtIoInCallerContext callback function is called
at the IRQL of the calling thread. If the calling thread is from a
user-mode application, the callback function is called at IRQL =
PASSIVE_LEVEL. "

– pa

On 27-Aug-2012 22:01, Zvi Vered wrote:
> Dear Members,
> I wrote a Device driver for PCI card.
> The device driver is fully based on the src\general\PLX9x5x sample except:
> In “PLxEvtDevicePrepareHardware ” I did not call to “PLxPrepareHardware”.
> In “PLxInitializeDeviceExtension” I did not call to “PLxInterruptCreate”
> and to “PLxInitializeDMA”
> So there is no access to hardware.
> There are no memory allocations in the driver.
> In “PLxInitializeDeviceExtension” I added initialization for
> DeviceIoControl queue based on the src\general\ioctl sample:
> // Configure a default queue so that requests that are not
> // configure-fowarded using WdfDeviceConfigureRequestDispatching to
> goto
> // other queues get dispatched here.
> //
> WDF_IO_QUEUE_CONFIG_INIT_DEFAULT_QUEUE(&ioQueueConfig,
> WdfIoQueueDispatchSequential);
> ioQueueConfig.EvtIoDeviceControl = FileEvtIoDeviceControl;
> WDF_OBJECT_ATTRIBUTES_INIT(&attributes);
> //
> // Since we are using Zw function set execution level to passive so
> that
> // framework ensures that our Io callbacks called at only passive-level
> // even if the request came in at DISPATCH_LEVEL from another driver.
> //
> //attributes.ExecutionLevel = WdfExecutionLevelPassive;
> status = WdfIoQueueCreate(controlDevice,
> &ioQueueConfig,
> &attributes,
> &queue // pointer to default queue
> );
> But upon IOCTL request from the user level driver the IRQL is 2.
> I checked it with KeGetCurrentIrql()
> Should I enable the line:
> “attributes.ExecutionLevel = WdfExecutionLevelPassive;” ?
> I compiled the driver with “build -cefgz /wAll”. There are no warnings.
> I configured the verifier to monitor IRQL changes. But the counter stays
> 0 upon IOCTL requests.
> Upon start+end of every routine in the driver I printed IRQL. It is
> always 0.
>
> What is the reason IRQL changes to 0 upon IOCTL request ?
> Thanks,
> Zvika

NTDEV is sponsored by OSR

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

6

Dear Mr. Roberts,

The driver will access hardware.
I disabled all hardware access to be sure that id does not cause the IRQL
change.

I’m calling to: attributes.SynchronizationScope =
WdfSynchronizationScopeDevice;
before WdfDeviceCreate.

This line is taken from the original sample.

Upon specific IOCTL I have to call to MmMapLockedPagesSpecifyCache.
This can work only at IRQL<=APC_LEVEL.

Thanks,
Zvika.

-----Original Message-----
From: Tim Roberts
Sent: Monday, August 27, 2012 10:26 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] IRQL changes to 2 upon IOCTL request from user level
driver

Zvi Vered wrote:

I wrote a Device driver for PCI card.

The device driver is fully based on the src\general\PLX9x5x sample
except:

In “PLxEvtDevicePrepareHardware ” I did not call to “PLxPrepareHardware”.

In “PLxInitializeDeviceExtension” I did not call to
“PLxInterruptCreate” and to “PLxInitializeDMA”

So there is no access to hardware.

Will there be, eventually?

But upon IOCTL request from the user level driver the IRQL is 2.
I checked it with KeGetCurrentIrql()

Should I enable the line:
“attributes.ExecutionLevel = WdfExecutionLevelPassive;” ?

If you need your ioctl handler to run at passive, then yes, you would
enable that line. Before you do so, however, you need to understand
whether you need to do that. Are you planning to do things in your
ioctl handler that do not work at a raised IRQL?

What is the reason IRQL changes to 0 upon IOCTL request ?

http://msdn.microsoft.com/en-us/library/windows/hardware/ff544763.aspx

Are you setting SynchronizationScope when you create your device?
That’s the most common reason. That requires KMDF to grab a spinlock
before calling your callback, and calling a spinlock raises your IRQL.

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

NTDEV is sponsored by OSR

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

7

Zvi Vered wrote:

The driver will access hardware.
I disabled all hardware access to be sure that id does not cause the IRQL
change.

I’m calling to: attributes.SynchronizationScope =
WdfSynchronizationScopeDevice;
before WdfDeviceCreate.

And that’s why your IRQL is raised. With this setting, all event
callbacks for queues and file objects grab a spinlock before they run.
That ensures that only one callback can run at a time. That allows for
lazy coding, because you can ignore most synchronization issues, but
grabbing a spinlock raises you to DISPATCH_LEVEL.

KMDF makes it very easy to oversynchronize your driver. One of the
issues in a PCI driver is that ISRs and DPCs do not grab that same
spinlock (unless you use AutomaticSerialization), so you still have to
worry about synchronizing access to shared data. Partly because of
that, and partly because of the IRQL issue, I always use
WdfSynchronizationScopeNone, and then protect access to shared data with
my own locks.

This line is taken from the original sample.

Upon specific IOCTL I have to call to MmMapLockedPagesSpecifyCache.
This can work only at IRQL<=APC_LEVEL.

You have two choices. You can change the sync scope to “None”, or you
can set ExecutionLevel to “passive”.

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

8

My suspicion is that lowering the IRQL is a seriously dangerous thing to
do. It means you have potential concurrency in a dispatch-level routine,
and since it is now schedulable, you can blow the DPC timing requirements.
No DPC will be dispatched until the current one returns, and you’ve
essentially guaranteed that this is unbounded. As far as I know, the only
correct way to get to PASSIVE_LEVEL is to use a driver thread, either one
from the general driver thread queue or a dedicated thread in your own
driver. The number of disaster scenarios that follow lowering IRQL to
PASSIVE_LEVEL from DISPATCH_LEVEL is huge, and includes arbitrary delays
of response to other devices (with potential malfunctions caused by the
induced latency) to bluescreens, disk corruption, and other fun things.
joe

Dear Members,

I wrote a Device driver for PCI card.

The device driver is fully based on the src\general\PLX9x5x sample except:

In “PLxEvtDevicePrepareHardware ” I did not call to
“PLxPrepareHardware”.

In “PLxInitializeDeviceExtension” I did not call to
“PLxInterruptCreate” and to “PLxInitializeDMA”

So there is no access to hardware.

There are no memory allocations in the driver.

In “PLxInitializeDeviceExtension” I added initialization for
DeviceIoControl queue based on the src\general\ioctl sample:

// Configure a default queue so that requests that are not
// configure-fowarded using WdfDeviceConfigureRequestDispatching to
goto
// other queues get dispatched here.
//
WDF_IO_QUEUE_CONFIG_INIT_DEFAULT_QUEUE(&ioQueueConfig,
WdfIoQueueDispatchSequential);

ioQueueConfig.EvtIoDeviceControl = FileEvtIoDeviceControl;

WDF_OBJECT_ATTRIBUTES_INIT(&attributes);
//
// Since we are using Zw function set execution level to passive so
that
// framework ensures that our Io callbacks called at only
passive-level
// even if the request came in at DISPATCH_LEVEL from another driver.
//
//attributes.ExecutionLevel = WdfExecutionLevelPassive;

status = WdfIoQueueCreate(controlDevice,
&ioQueueConfig,
&attributes,
&queue // pointer to default queue
);

But upon IOCTL request from the user level driver the IRQL is 2.
I checked it with KeGetCurrentIrql()

Should I enable the line:
“attributes.ExecutionLevel = WdfExecutionLevelPassive;” ?

I compiled the driver with “build -cefgz /wAll”. There are no
warnings.

I configured the verifier to monitor IRQL changes. But the counter stays 0
upon IOCTL requests.

Upon start+end of every routine in the driver I printed IRQL. It is always
0.

What is the reason IRQL changes to 0 upon IOCTL request ?

Thanks,
Zvika

NTDEV is sponsored by OSR

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

9

But this doesn’t guarantee anything about the context if the driver is
called from DPC level by another driver; it says that it has the IRQL of
the calling thread. The OP wants to LOWER the IRQL if it is called from
DISPATCH_LEVEL, but not in the expected way by using a driver thread. I
think disaster will soon follow.
joe

Ah. So you use KMDF. Then you need EvtIoInCallerContext.
From the docum: "The EvtIoInCallerContext callback function is called
at the IRQL of the calling thread. If the calling thread is from a
user-mode application, the callback function is called at IRQL =
PASSIVE_LEVEL. "

– pa

On 27-Aug-2012 22:01, Zvi Vered wrote:
> Dear Members,
> I wrote a Device driver for PCI card.
> The device driver is fully based on the src\general\PLX9x5x sample
> except:
> In “PLxEvtDevicePrepareHardware ” I did not call to
> “PLxPrepareHardware”.
> In “PLxInitializeDeviceExtension” I did not call to
> “PLxInterruptCreate”
> and to “PLxInitializeDMA”
> So there is no access to hardware.
> There are no memory allocations in the driver.
> In “PLxInitializeDeviceExtension” I added initialization for
> DeviceIoControl queue based on the src\general\ioctl sample:
> // Configure a default queue so that requests that are not
> // configure-fowarded using WdfDeviceConfigureRequestDispatching to
> goto
> // other queues get dispatched here.
> //
> WDF_IO_QUEUE_CONFIG_INIT_DEFAULT_QUEUE(&ioQueueConfig,
> WdfIoQueueDispatchSequential);
> ioQueueConfig.EvtIoDeviceControl = FileEvtIoDeviceControl;
> WDF_OBJECT_ATTRIBUTES_INIT(&attributes);
> //
> // Since we are using Zw function set execution level to passive so
> that
> // framework ensures that our Io callbacks called at only
> passive-level
> // even if the request came in at DISPATCH_LEVEL from another
> driver.
> //
> //attributes.ExecutionLevel = WdfExecutionLevelPassive;
> status = WdfIoQueueCreate(controlDevice,
> &ioQueueConfig,
> &attributes,
> &queue // pointer to default queue
> );
> But upon IOCTL request from the user level driver the IRQL is 2.
> I checked it with KeGetCurrentIrql()
> Should I enable the line:
> “attributes.ExecutionLevel = WdfExecutionLevelPassive;” ?
> I compiled the driver with “build -cefgz /wAll”. There are no
> warnings.
> I configured the verifier to monitor IRQL changes. But the counter stays
> 0 upon IOCTL requests.
> Upon start+end of every routine in the driver I printed IRQL. It is
> always 0.
>
> What is the reason IRQL changes to 0 upon IOCTL request ?
> Thanks,
> Zvika

NTDEV is sponsored by OSR

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

10

xxxxx@flounder.com wrote:

But this doesn’t guarantee anything about the context if the driver is
called from DPC level by another driver; it says that it has the IRQL of
the calling thread.

That’s very true, but that’s not what’s happening here. He’s not being
called from a driver. He’s being called from an application. It is his
KMDF SynchronizationScope setting that is causing the IRQL to be raised.

This is just one of those situations that is right on the border between
KMDF and WDM, where it is not possible to ignore the “man behind the
curtain”. Folks today who did not know what the world was like before
KMDF are trying to create KMDF drivers without an understanding of how
it interacts with WDM. There are just too many cases where the very
helpful KMDF abstraction has strong implications in the WDM world that
are not entirely obvious to newbies.

The OP wants to LOWER the IRQL if it is called from
DISPATCH_LEVEL, but not in the expected way by using a driver thread.

Sort of. The issue is that he didn’t understand WHY he was in dispatch
to begin with. It is a simple configuration problem.

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

11

Actually, the OP says explicitly that there is an expectation that this
will be called from another driver. From the originally posted code:

//
// Since we are using Zw function set execution level to passive so that
// framework ensures that our Io callbacks called at only passive-level
// even if the request came in at DISPATCH_LEVEL from another driver.
//
Note the last line of that comment.
joe

xxxxx@flounder.com wrote:
> But this doesn’t guarantee anything about the context if the driver is
> called from DPC level by another driver; it says that it has the IRQL of
> the calling thread.

That’s very true, but that’s not what’s happening here. He’s not being
called from a driver. He’s being called from an application. It is his
KMDF SynchronizationScope setting that is causing the IRQL to be raised.

This is just one of those situations that is right on the border between
KMDF and WDM, where it is not possible to ignore the “man behind the
curtain”. Folks today who did not know what the world was like before
KMDF are trying to create KMDF drivers without an understanding of how
it interacts with WDM. There are just too many cases where the very
helpful KMDF abstraction has strong implications in the WDM world that
are not entirely obvious to newbies.

> The OP wants to LOWER the IRQL if it is called from
> DISPATCH_LEVEL, but not in the expected way by using a driver thread.

Sort of. The issue is that he didn’t understand WHY he was in dispatch
to begin with. It is a simple configuration problem.

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

NTDEV is sponsored by OSR

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

12

xxxxx@flounder.com wrote:

Actually, the OP says explicitly that there is an expectation that this
will be called from another driver. From the originally posted code:

//
// Since we are using Zw function set execution level to passive so that
// framework ensures that our Io callbacks called at only passive-level
// even if the request came in at DISPATCH_LEVEL from another driver.
//
Note the last line of that comment.

That comment was copied word-for-word from the sample that he started
from. It doesn’t apply in his case.

This whole exercise is a great case study in why it is dangerous to
start copying code from a sample without understanding the decisions
made by the author of the sample.

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

13

This is what I refer to as the “bridge-color problem”

See http://www.flounder.com/bridge.htm
joe

xxxxx@flounder.com wrote:
> Actually, the OP says explicitly that there is an expectation that this
> will be called from another driver. From the originally posted code:
>
> //
> // Since we are using Zw function set execution level to passive so
> that
> // framework ensures that our Io callbacks called at only
> passive-level
> // even if the request came in at DISPATCH_LEVEL from another
> driver.
> //
> Note the last line of that comment.

That comment was copied word-for-word from the sample that he started
from. It doesn’t apply in his case.

This whole exercise is a great case study in why it is dangerous to
start copying code from a sample without understanding the decisions
made by the author of the sample.

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

NTDEV is sponsored by OSR

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

14

Dear Members,

I tried to call:
attributes.ExecutionLevel = WdfExecutionLevelPasive;

And then to:
status = WdfIoQueueCreate (…)

But WdfIoQueueCreate fails and returns: 0xC000000D (STATUS_INVALID_PARAMETER)

I also tried running the general\ioctl sample.

Upon IOCTL request IRQL=0.

I failed to understand why in the ioctl sample IRQL=0 and in PLx9x5x sample IRQL=2

Can you help ?

Thanks,
Zvika

15

don’t specify an ExecutionLevel or scope and you will get the irql you want. If you break in right after 0xC000000D is returned, you can run

!wdfkd.wdflogdump

And it will tell you why the error s being returned

d

debt from my phone
________________________________
From: xxxxx@gmail.com
Sent: 8/27/2012 9:44 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] IRQL changes to 2 upon IOCTL request from user level driver

Dear Members,

I tried to call:
attributes.ExecutionLevel = WdfExecutionLevelPasive;

And then to:
status = WdfIoQueueCreate (…)

But WdfIoQueueCreate fails and returns: 0xC000000D (STATUS_INVALID_PARAMETER)

I also tried running the general\ioctl sample.

Upon IOCTL request IRQL=0.

I failed to understand why in the ioctl sample IRQL=0 and in PLx9x5x sample IRQL=2

Can you help ?

Thanks,
Zvika

—
NTDEV is sponsored by OSR

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

16

> Dear Members,

I tried to call:
attributes.ExecutionLevel = WdfExecutionLevelPasive;

And then to:
status = WdfIoQueueCreate (…)

But WdfIoQueueCreate fails and returns: 0xC000000D
(STATUS_INVALID_PARAMETER)

That’s almost certainly because “…” is not a valid parameter list.
Seriously, how do you expect us to respond when you don’t even show us the
parameters of the call, the declarations of all variables, their scope and
extent, when they are initialized, and a few other irrelevant details such
as the context in which this is executed.

Note that assignment is not a call, so you can’t “call”
attributes.ExecutionLevel = WdfExecutionLevelPassive;
although you can certainly execute that assignment statement.
joe

I also tried running the general\ioctl sample.

Upon IOCTL request IRQL=0.

I failed to understand why in the ioctl sample IRQL=0 and in PLx9x5x
sample IRQL=2

Can you help ?

Thanks,
Zvika

NTDEV is sponsored by OSR

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

17

Not to be a pedantic asshole, but I disagree. This isn’t a KMDF vs WDM issue at all. It’s a lack of fundamental understanding of Windows I/O Subsystem architecture. Contenxt, DPCs, IRQLs, and one driver calling another aren’t WDM concepts. They’re Windows I/O Subsystem concepts.

I’m not saying there aren’t some rough edges of WDM that leak into KMDF… there are. But there are few.

This.

To me, this is just ONE MORE EXAMPLE of why you can’t learn to write drivers the way you learn to write C# applications: By figuring it out as you go along and cutting and pasting random shit from samples. I realize that’s how a whole generation of software developers have learned how to code. But that fundamentally DOES NOT WORK for driver development. There are overall, basic, system-wide, architectural concepts that you need to understand before you can “hack and whack” a driver into existence. Without knowledge of these concepts, you have no hope of writing a driver correctly.

OP: Do some reading about basic I/O Subsystem architecture and what the KMDF constructs that you’re using (such as synch scope and execution level) actually DO before you go off and try to write a driver. Did you try to drive a car without first learning the rules of the road (which side to drive on which side to pass on, the speed limit, etc)?? Because that’s the equivalent of what you’re doing here in driver land.

Peter
OSR

18

I will take it even further that Peter. Seriously, consider taking a
class on Windows driver writing. Even reading a book on a subject like
this can be hard, since you don’t know what “you don’t know”. A good
week long class can direct people through concepts and give them a firm
basis to better understand books and examples. Trying to learn things
yourself it is easy to miss something that is major but hard to grasp
(IRQL as this thread shows is a great example). I’ve taken classes when
the environment has a radical shift, for instance even though I had been
writing Windows drivers for six years when WDM came out I invested in
the OSR course. I pushed experienced colleagues to take KMDF classes
because again the world had radically changed. Much of what a good
class teaches is the new mindset (for example in KMDF the rich power of
context’s).

There are some excellent classes out there from OSR and others, if you
really want to do it right consider a class.

Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

“xxxxx@osr.com” wrote in message news:xxxxx@ntdev:

>
>
>


>
>
> Not to be a pedantic asshole, but I disagree. This isn’t a KMDF vs WDM issue at all. It’s a lack of fundamental understanding of Windows I/O Subsystem architecture. Contenxt, DPCs, IRQLs, and one driver calling another aren’t WDM concepts. They’re Windows I/O Subsystem concepts.
>
> I’m not saying there aren’t some rough edges of WDM that leak into KMDF… there are. But there are few.
>
>


>
> This.
>
> To me, this is just ONE MORE EXAMPLE of why you can’t learn to write drivers the way you learn to write C# applications: By figuring it out as you go along and cutting and pasting random shit from samples. I realize that’s how a whole generation of software developers have learned how to code. But that fundamentally DOES NOT WORK for driver development. There are overall, basic, system-wide, architectural concepts that you need to understand before you can “hack and whack” a driver into existence. Without knowledge of these concepts, you have no hope of writing a driver correctly.
>
>
>
> OP: Do some reading about basic I/O Subsystem architecture and what the KMDF constructs that you’re using (such as synch scope and execution level) actually DO before you go off and try to write a driver. Did you try to drive a car without first learning the rules of the road (which side to drive on which side to pass on, the speed limit, etc)?? Because that’s the equivalent of what you’re doing here in driver land.
>
> Peter
> OSR

19

rant:auxiliary
I have often had to tell my students: “You can’t debug a concurrent system
into correctness. You can only design it correctly. Then, when it fails,
you know you made an error in the implementation of your design.”

The number of times I’ve seen concurrent code in application space
sprinkled with Sleep(1) calls is frighteningly high. If I say “Why is
this Sleep() call here” the answer is “It won’t work without it” at which
point I say “No, it won’t work. The appearance of working is an
accident, but the fundamental design is wrong.” Often, I can find the
error within an hour; sometimes in under five minutes.

Or the “Why do you have a timeout on this WaitFor() call on the Mutex?”
and the answer is “Our program hangs if we don’t have a timeout”. Of
course, what they have written is

WaitForSingleObject(mutex, 5000);
// do things to the shared resource here…

which would be ROTFLMFAO if it weren’t so heartbreakingly sad that someone
would actually write code like this and think it made perfect sense.

One of my classic exercises is a producer/consumer model with a shared
queue between processes, using a mutex and semaphore on the free pool and
the queue. I tell them to write

switch(WaitForSingleObject(Semaphore, SEM_TIMEOUT))
{ /* WFSO sem /
case WAIT_TIMEOUT:
return NULL; // This is the spec I give them: return NULL on
timeout
case WAIT_OBJECT_0:
break;
default:
// report error via a specified interface here
return NULL;
} / WFSO sem /

switch(WaitForSingleObject(Mutex, INFINITE))
{ / WFSO mutex /
case WAIT_OBJECT_0:
break;
default:
// report error via a specified interface here
// Do appropriate recovery
return NULL;
} / WFSO mutex */

It is sad and amusing to watch them take the second one and replace the
switch with an if, because they only see two options at the moment, so
those must be the only two options. And for whom “do appropriate
recovery” means “do nothing”. When they get the project done, I create a
case in which the mutex gets abandoned, and ask what they plan to do about
it, and then I say “Now add a timeout to the mutex” and ask what they plan
to do about it. In 15 years, nobody has EVER reset the semaphore! And
this is after two days of lectures on concurrency, maintaining invariants,
and graceful error recovery! And deadlock, and deadlock detection
(heuristic) and deadlock recovery.

It is really, really important to understand the basic mechanisms involved
before haring off and throwing code at the problem in the hope that you
will stumble over the correct code sequence. This is most obvious in the
number of newbies who want to allocate kernel memory and map it into the
process, without even understanding how kernel memory works.
</rant:auxiliary>

Not to be a pedantic asshole, but I disagree. This isn’t a KMDF vs WDM
issue at all. It’s a lack of fundamental understanding of Windows I/O
Subsystem architecture. Contenxt, DPCs, IRQLs, and one driver calling
another aren’t WDM concepts. They’re Windows I/O Subsystem concepts.

I’m not saying there aren’t some rough edges of WDM that leak into KMDF…
there are. But there are few.

This.

To me, this is just ONE MORE EXAMPLE of why you can’t learn to write
drivers the way you learn to write C# applications: By figuring it out as
you go along and cutting and pasting random shit from samples. I realize
that’s how a whole generation of software developers have learned how to
code. But that fundamentally DOES NOT WORK for driver development. There
are overall, basic, system-wide, architectural concepts that you need to
understand before you can “hack and whack” a driver into existence.
Without knowledge of these concepts, you have no hope of writing a driver
correctly.

OP: Do some reading about basic I/O Subsystem architecture and what the
KMDF constructs that you’re using (such as synch scope and execution
level) actually DO before you go off and try to write a driver. Did you
try to drive a car without first learning the rules of the road (which
side to drive on which side to pass on, the speed limit, etc)?? Because
that’s the equivalent of what you’re doing here in driver land.

Peter
OSR

NTDEV is sponsored by OSR

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

20

Dear Members,

When I tried to set SynchronizationScope = WdfSynchronizationScopeNone the IRQL was 0 upon IOCTL code.

According to the documentation:
The framework does not synchronize the object’s event callback functions, so the callback functions might run concurrently on a multiprocessor system

My queue has only one callback function: MyQueue.EvtIoDeviceControl = MyIoctlHandler
All other callbacks are null.

In this case, shoud I have a problem using WdfSynchronizationScopeNone ?

Thanks,
Zvika