PAGED_CODE raise an Assert

Hello at all,
My name is Giando and is the first time that deal with to develop a KMDF; in practice i’m a newbe
and my knowledge in kernel systems is quite little.
I’m developing a WDF KMDF functional driver for a PCI board.
My develop platform is a Windows7 SP1 x64, and i work with VisualStudio 2015 and WDK10.
The target where test the board is a dual boot machine with win7 SP1 x86 and win10 x86.
I written the driver using like reference the Toaster, PCIDRV and AMCC5933 samples.
I used also kmdf_fx2 for to learn even if this driver how you know is not for PCI.
Now my problem is:
every time that the user test program execute a DeviceIocontrol, i have a BSOD on “EvtIoDeviceControl”.
The macro “PAGED_CODE();” raise with an ASSERT because the IOCTL LEVEL is in “DISPATCH_LEVEL”.
Unfortunatly even with Windbg i’m not confident, so at the moment i didn’t understand where the LEVEL
is elevated to “DISPATCH_LEVEL” when entry in “EvtIoDeviceControl”.
Can help me ?

TIA.

Giando V.

If you would read the documentation for EvtIoDeviceControl you could see
that it can be called at any IRQL up to and including DISPATCH_LEVEL. The
only case in which this would not be true is when your driver is on top of
the driver stack, which is not your case.

https://msdn.microsoft.com/en-us/library/windows/hardware/ff541758(v=vs.85).aspx

On 18 November 2015 at 12:57, wrote:

> Hello at all,
> My name is Giando and is the first time that deal with to develop a KMDF;
> in practice i’m a newbe
> and my knowledge in kernel systems is quite little.
> I’m developing a WDF KMDF functional driver for a PCI board.
> My develop platform is a Windows7 SP1 x64, and i work with VisualStudio
> 2015 and WDK10.
> The target where test the board is a dual boot machine with win7 SP1 x86
> and win10 x86.
> I written the driver using like reference the Toaster, PCIDRV and AMCC5933
> samples.
> I used also kmdf_fx2 for to learn even if this driver how you know is not
> for PCI.
> Now my problem is:
> every time that the user test program execute a DeviceIocontrol, i have a
> BSOD on “EvtIoDeviceControl”.
> The macro “PAGED_CODE();” raise with an ASSERT because the IOCTL LEVEL is
> in “DISPATCH_LEVEL”.
> Unfortunatly even with Windbg i’m not confident, so at the moment i didn’t
> understand where the LEVEL
> is elevated to “DISPATCH_LEVEL” when entry in “EvtIoDeviceControl”.
> Can help me ?
>
> TIA.
>
> Giando V.
>
> —
> 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
>

More so, KMDF queues all IRPs, and the queue consumer runs on DISPATCH, so EvtIoDeviceControl is always DISPATCH.

You need to use EvtIoInCallerContext to be at PASSIVE for IOCTLs.


Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com
“Gurzou Alexandru” wrote in message news:xxxxx@ntdev…
If you would read the documentation for EvtIoDeviceControl you could see that it can be called at any IRQL up to and including DISPATCH_LEVEL. The only case in which this would not be true is when your driver is on top of the driver stack, which is not your case.

https://msdn.microsoft.com/en-us/library/windows/hardware/ff541758(v=vs.85).aspx

On 18 November 2015 at 12:57, wrote:

Hello at all,
My name is Giando and is the first time that deal with to develop a KMDF; in practice i’m a newbe
and my knowledge in kernel systems is quite little.
I’m developing a WDF KMDF functional driver for a PCI board.
My develop platform is a Windows7 SP1 x64, and i work with VisualStudio 2015 and WDK10.
The target where test the board is a dual boot machine with win7 SP1 x86 and win10 x86.
I written the driver using like reference the Toaster, PCIDRV and AMCC5933 samples.
I used also kmdf_fx2 for to learn even if this driver how you know is not for PCI.
Now my problem is:
every time that the user test program execute a DeviceIocontrol, i have a BSOD on “EvtIoDeviceControl”.
The macro “PAGED_CODE();” raise with an ASSERT because the IOCTL LEVEL is in “DISPATCH_LEVEL”.
Unfortunatly even with Windbg i’m not confident, so at the moment i didn’t understand where the LEVEL
is elevated to “DISPATCH_LEVEL” when entry in “EvtIoDeviceControl”.
Can help me ?

TIA.

Giando V.


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

Thanks very much

Maxim & Alexandru for your helpful infos.

Best Regards.

Giando V.

Not correct on either count, I’m afraid.

KMDF is *allowed* to queue all I/O Requests. It does not necessarily do so. It may.

The KMDF contract is that EvtIoDeviceControl (and, in fact, any EvtIoXxxx callback) can execute at any IRQL <= DISPATCH_LEVEL. I just wrote about this in the last issue of The NT Insider.

If you want your EvtIoDeviceControl Event Processing Callback to be run at IRQL PASSIVE_LEVEL, all you need to do is establish a PASSIVE_LEVEL constraint (specified in the WDF_OBJECT_ATTRIBUTES) when you create your WDFDEVICE.

If this isn’t clear, or we can help further, don’t hesitate to post back.

Peter
OSR
@OSRDrivers

Hello Peter,

Thanks a lot for your puntualizations.

I just download the last issue of NT_Insider a couple days ago, but i still not read it ( Opss! ).
Please, can you tell me exactly which is the article?

Yes, sorry but is not very clear for me. Can you explain a little more in depth this item ?

Thank You for your help.

Best Regards.

Giando V.

Did you mean ‘when you create your WDFDEVICE’ or ‘when you call WdfIoQueueCreate’?

Well, I *meant* “when you create your WDFDEVICE” but you certainly can do it “after you’ve created your device when you create your WDF_QUEUE”

“The Three Most Common KMDF Errors in Shipping Drivers” talks about assuming you’ll be called at IRQL PASSIVE_LEVEL in your EvtIoXxxx Event Processing Callback. This is a *very* common, and very bad, architectural error.

Link to The NT Insider: http:



No problem.

Let’s assume you have a device that is serviced by a single WDF Queue… and let’s take Mr. Corbin’s implicit suggestion to establish the Execution Level constraint on the Queue.

Prior to calling WdfIoQueueCreate, you allocate and initialize a WDF_OBJECT_ATTRIBUTES structure:


WDF_OBJECT_ATTRIBUTES objAtts;
WDF_OBJECT_ATTRIBUTES_INIT(&objAtts);



You then set an execution-level constraint in those Object Attributes.


objAtts.ExecutionLevel = WdfExecutionLevelPassive;



Allocate and initialize your WDF_IO_QUEUE_CONFIG structure as you do now.

Then, when you create your Queue, specify the Object Attributes that you initialized with the ExecutionLevel constraint:



status = WdfIoQueueCreate(device, &queueConfig, &objAtts, &devContext->MyQueueHandle);

if(!NT_SUCCESS(status)) {


}



Result: Your EvtIoXxxx entry points (for that Queue) will always be called at IRQL PASSIVE_LEVEL.

Peter
OSR
@OSRDrivers</http:>