WdfWorkItemCreate error STATUS_WDF_INCOMPATIBLE_EXECUTION_LEVEL

NTDEV
1

I am calling WdfWorkItemCreate from my EvtIoDeviceControl queue callback
routine and I am getting an STATUS_WDF_INCOMPATIBLE_EXECUTION_LEVEL. Any
ideas what is wrong? This is not supposed to happen according to the doc.

“The WdfWorkItemCreate method must be called at IRQL <= DISPATCH_LEVEL.”

“The EvtIoDeviceControl callback function can be called at IRQL <=
DISPATCH_LEVEL”

Below is the code I use the setup the queue and below that is the code I use
to try and setup the work item.

Thanks,
Greg

WDF_IO_QUEUE_CONFIG_INIT_DEFAULT_QUEUE(&ioCallbacks,
WdfIoQueueDispatchSequential);

ioCallbacks.EvtIoDeviceControl = DioEvtDeviceControl;

status = WdfIoQueueCreate(device,
&ioCallbacks,
WDF_NO_OBJECT_ATTRIBUTES,
NULL);

NTSTATUS status = STATUS_SUCCESS;
PWORKER_ITEM_CONTEXT context;
WDF_OBJECT_ATTRIBUTES attributes;
WDF_WORKITEM_CONFIG workitemConfig;
WDFWORKITEM hWorkItem;

WDF_OBJECT_ATTRIBUTES_INIT_CONTEXT_TYPE(&attributes,
WORKER_ITEM_CONTEXT);

attributes.ParentObject = devContext->WdfDevice;

WDF_WORKITEM_CONFIG_INIT(&workitemConfig, CallbackFunction);

status = WdfWorkItemCreate( &workitemConfig,
&attributes,
&hWorkItem);

if (!NT_SUCCESS(status)) {
return status;
}

2

It sounds like you’re EvtIoDeviceControl routine is being called at
DISPATCH_LEVEL.

What synchronization scope do you have for your device?
Is there a driver above you calling into your driver or an applciation?

Beverly

On 1/12/07, Greg Coleson wrote:
> I am calling WdfWorkItemCreate from my EvtIoDeviceControl queue callback
> routine and I am getting an STATUS_WDF_INCOMPATIBLE_EXECUTION_LEVEL. Any
> ideas what is wrong? This is not supposed to happen according to the doc.
>
> “The WdfWorkItemCreate method must be called at IRQL <= DISPATCH_LEVEL.”
>
> “The EvtIoDeviceControl callback function can be called at IRQL <=
> DISPATCH_LEVEL”
>
> Below is the code I use the setup the queue and below that is the code I use
> to try and setup the work item.
>
> Thanks,
> Greg
>
> WDF_IO_QUEUE_CONFIG_INIT_DEFAULT_QUEUE(&ioCallbacks,
> WdfIoQueueDispatchSequential);
>
> ioCallbacks.EvtIoDeviceControl = DioEvtDeviceControl;
>
> status = WdfIoQueueCreate(device,
> &ioCallbacks,
> WDF_NO_OBJECT_ATTRIBUTES,
> NULL);
>
>
> NTSTATUS status = STATUS_SUCCESS;
> PWORKER_ITEM_CONTEXT context;
> WDF_OBJECT_ATTRIBUTES attributes;
> WDF_WORKITEM_CONFIG workitemConfig;
> WDFWORKITEM hWorkItem;
>
> WDF_OBJECT_ATTRIBUTES_INIT_CONTEXT_TYPE(&attributes,
> WORKER_ITEM_CONTEXT);
>
> attributes.ParentObject = devContext->WdfDevice;
>
> WDF_WORKITEM_CONFIG_INIT(&workitemConfig, CallbackFunction);
>
> status = WdfWorkItemCreate( &workitemConfig,
> &attributes,
> &hWorkItem);
>
> if (!NT_SUCCESS(status)) {
> return status;
> }
>
>
>
> —
> 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
>

3

STATUS_WDF_INCOMPATIBLE_EXECUTION_LEVEL refers to the execution level in
the framework’s attributes, not the current IRQL. Did you setup your
WDFDEVICE with any execution or sync values other then the default?

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Greg Coleson
Sent: Friday, January 12, 2007 11:44 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] WdfWorkItemCreate error
STATUS_WDF_INCOMPATIBLE_EXECUTION_LEVEL

I am calling WdfWorkItemCreate from my EvtIoDeviceControl queue callback

routine and I am getting an STATUS_WDF_INCOMPATIBLE_EXECUTION_LEVEL.
Any
ideas what is wrong? This is not supposed to happen according to the
doc.

“The WdfWorkItemCreate method must be called at IRQL <= DISPATCH_LEVEL.”

“The EvtIoDeviceControl callback function can be called at IRQL <=
DISPATCH_LEVEL”

Below is the code I use the setup the queue and below that is the code I
use
to try and setup the work item.

Thanks,
Greg

WDF_IO_QUEUE_CONFIG_INIT_DEFAULT_QUEUE(&ioCallbacks,
WdfIoQueueDispatchSequential);

ioCallbacks.EvtIoDeviceControl = DioEvtDeviceControl;

status = WdfIoQueueCreate(device,
&ioCallbacks,
WDF_NO_OBJECT_ATTRIBUTES,
NULL);

NTSTATUS status = STATUS_SUCCESS;
PWORKER_ITEM_CONTEXT context;
WDF_OBJECT_ATTRIBUTES attributes;
WDF_WORKITEM_CONFIG workitemConfig;
WDFWORKITEM hWorkItem;

WDF_OBJECT_ATTRIBUTES_INIT_CONTEXT_TYPE(&attributes,
WORKER_ITEM_CONTEXT);

attributes.ParentObject = devContext->WdfDevice;

WDF_WORKITEM_CONFIG_INIT(&workitemConfig, CallbackFunction);

status = WdfWorkItemCreate( &workitemConfig,
&attributes,
&hWorkItem);

if (!NT_SUCCESS(status)) {
return status;
}

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

4

Here is the code. The only reason I am trying to create a work item here is
that I want to open and read a file here and the ZwOpenFile hangs in the
routine. My only thought as to why it was hanging is that tin IRQL level
was wrong which should not be the case here since I am the only driver
talking to this device (top level) so I should be called at PASSIVE level.

//
// Register the PnP and power callbacks. Power policy related callbacks
will
// be registered later in SotwareInit.
//
WdfDeviceInitSetPnpPowerEventCallbacks(DeviceInit, &pnpPowerCallbacks);

//
// Create our Device Object and its associated context
//
WDF_OBJECT_ATTRIBUTES_INIT(&objAttributes);

//
// Associate our device context structure type with our WDFDevice
//
WDF_OBJECT_ATTRIBUTES_SET_CONTEXT_TYPE(&objAttributes,
DIO_DEVICE_CONTEXT);

//
// Other attributes we might set are EvtCleanupCallback (called when
// the object is deleted) and EvtDestroyCallback (called when the
object’s
// references go to zero)…
//

//
// Set the synch scope to device so that child objects such as queue
// and DpcForIsr can inherit the device-level synchronization. By
// doing so, we make sure that queue dispatch callbacks for ioctl,
// cancel-routine, and DpcForIsr are all synchronized with the
// same device-level spinlock provided by the framework. This enables
// us to access global resources among these callbacks without
// worrying about synchronizing access to them with our own lock.
//
// Also by specifying passive execution level, framework ensures
// that our Io callbacks will never be called at DISPATCH_LEVEL.

objAttributes.SynchronizationScope = WdfSynchronizationScopeDevice;

//
// We want our device object NAMED, thank you very much
//
status = WdfDeviceInitAssignName(DeviceInit, &ntDeviceName);

if (!NT_SUCCESS(status))
{
#if DBG
DbgPrint(“WdfDeviceInitAssignName failed 0x%0x\n”, status);
#endif
return(status);
}

//set direct IO for speed
WdfDeviceInitSetIoType(DeviceInit, WdfDeviceIoDirect);

//
// Create the device now
//
// Device Init structure
status = WdfDeviceCreate(&DeviceInit,
&objAttributes, // Attributes for WDF Device
&device); // returns pointer to new WDF Device

“Doron Holan” wrote in message
news:xxxxx@ntdev…
STATUS_WDF_INCOMPATIBLE_EXECUTION_LEVEL refers to the execution level in
the framework’s attributes, not the current IRQL. Did you setup your
WDFDEVICE with any execution or sync values other then the default?

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Greg Coleson
Sent: Friday, January 12, 2007 11:44 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] WdfWorkItemCreate error
STATUS_WDF_INCOMPATIBLE_EXECUTION_LEVEL

I am calling WdfWorkItemCreate from my EvtIoDeviceControl queue callback

routine and I am getting an STATUS_WDF_INCOMPATIBLE_EXECUTION_LEVEL.
Any
ideas what is wrong? This is not supposed to happen according to the
doc.

“The WdfWorkItemCreate method must be called at IRQL <= DISPATCH_LEVEL.”

“The EvtIoDeviceControl callback function can be called at IRQL <=
DISPATCH_LEVEL”

Below is the code I use the setup the queue and below that is the code I
use
to try and setup the work item.

Thanks,
Greg

WDF_IO_QUEUE_CONFIG_INIT_DEFAULT_QUEUE(&ioCallbacks,
WdfIoQueueDispatchSequential);

ioCallbacks.EvtIoDeviceControl = DioEvtDeviceControl;

status = WdfIoQueueCreate(device,
&ioCallbacks,
WDF_NO_OBJECT_ATTRIBUTES,
NULL);

NTSTATUS status = STATUS_SUCCESS;
PWORKER_ITEM_CONTEXT context;
WDF_OBJECT_ATTRIBUTES attributes;
WDF_WORKITEM_CONFIG workitemConfig;
WDFWORKITEM hWorkItem;

WDF_OBJECT_ATTRIBUTES_INIT_CONTEXT_TYPE(&attributes,
WORKER_ITEM_CONTEXT);

attributes.ParentObject = devContext->WdfDevice;

WDF_WORKITEM_CONFIG_INIT(&workitemConfig, CallbackFunction);

status = WdfWorkItemCreate( &workitemConfig,
&attributes,
&hWorkItem);

if (!NT_SUCCESS(status)) {
return status;
}

—
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

5

Greg Coleson wrote:

I am calling WdfWorkItemCreate from my EvtIoDeviceControl queue callback
routine and I am getting an STATUS_WDF_INCOMPATIBLE_EXECUTION_LEVEL. Any
ideas what is wrong? This is not supposed to happen according to the doc.

“The WdfWorkItemCreate method must be called at IRQL <= DISPATCH_LEVEL.”

“The EvtIoDeviceControl callback function can be called at IRQL <=
DISPATCH_LEVEL”

Below is the code I use the setup the queue and below that is the code I use
to try and setup the work item.

The doc explains this. STATUS_WDF_INCOMPATIBLE_EXECUTION_LEVEL means
that AutomaticSerialization in your WDF_WORKITEM_CONFIG is set to TRUE
but the parent object’s execution level is not set to passive.
WDF_WORKITEM_CONFIG_INIT, by default, sets AutomaticSerialzation to TRUE.

Add
workitemConfig.AutomaticSerialization = FALSE;
and you should be good to go.

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

6

Greg, you should look at the output !wdfkd.wdflogdump and see what it says. I think i know what the problem is though. set workitemConfig.AutomaticSerialization to FALSE before creating the workitem so that the work item does not try to serialize itself against the WDFDEVICE.

d

7

setting workitemConfig.AutomaticSerialization = FALSE;

fixed the work item create issue.

Thanks,
Greg

“Greg Coleson” wrote in message news:xxxxx@ntdev…
> Here is the code. The only reason I am trying to create a work item here
> is that I want to open and read a file here and the ZwOpenFile hangs in
> the routine. My only thought as to why it was hanging is that tin IRQL
> level was wrong which should not be the case here since I am the only
> driver talking to this device (top level) so I should be called at PASSIVE
> level.
>
> //
> // Register the PnP and power callbacks. Power policy related callbacks
> will
> // be registered later in SotwareInit.
> //
> WdfDeviceInitSetPnpPowerEventCallbacks(DeviceInit, &pnpPowerCallbacks);
>
> //
> // Create our Device Object and its associated context
> //
> WDF_OBJECT_ATTRIBUTES_INIT(&objAttributes);
>
> //
> // Associate our device context structure type with our WDFDevice
> //
> WDF_OBJECT_ATTRIBUTES_SET_CONTEXT_TYPE(&objAttributes,
> DIO_DEVICE_CONTEXT);
>
> //
> // Other attributes we might set are EvtCleanupCallback (called when
> // the object is deleted) and EvtDestroyCallback (called when the
> object’s
> // references go to zero)…
> //
>
> //
> // Set the synch scope to device so that child objects such as queue
> // and DpcForIsr can inherit the device-level synchronization. By
> // doing so, we make sure that queue dispatch callbacks for ioctl,
> // cancel-routine, and DpcForIsr are all synchronized with the
> // same device-level spinlock provided by the framework. This enables
> // us to access global resources among these callbacks without
> // worrying about synchronizing access to them with our own lock.
> //
> // Also by specifying passive execution level, framework ensures
> // that our Io callbacks will never be called at DISPATCH_LEVEL.
>
> objAttributes.SynchronizationScope = WdfSynchronizationScopeDevice;
>
> //
> // We want our device object NAMED, thank you very much
> //
> status = WdfDeviceInitAssignName(DeviceInit, &ntDeviceName);
>
> if (!NT_SUCCESS(status))
> {
> #if DBG
> DbgPrint(“WdfDeviceInitAssignName failed 0x%0x\n”, status);
> #endif
> return(status);
> }
>
> //set direct IO for speed
> WdfDeviceInitSetIoType(DeviceInit, WdfDeviceIoDirect);
>
> //
> // Create the device now
> //
> // Device Init structure
> status = WdfDeviceCreate(&DeviceInit,
> &objAttributes, // Attributes for WDF Device
> &device); // returns pointer to new WDF Device
>
> “Doron Holan” wrote in message
> news:xxxxx@ntdev…
> STATUS_WDF_INCOMPATIBLE_EXECUTION_LEVEL refers to the execution level in
> the framework’s attributes, not the current IRQL. Did you setup your
> WDFDEVICE with any execution or sync values other then the default?
>
> d
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Greg Coleson
> Sent: Friday, January 12, 2007 11:44 AM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] WdfWorkItemCreate error
> STATUS_WDF_INCOMPATIBLE_EXECUTION_LEVEL
>
> I am calling WdfWorkItemCreate from my EvtIoDeviceControl queue callback
>
> routine and I am getting an STATUS_WDF_INCOMPATIBLE_EXECUTION_LEVEL.
> Any
> ideas what is wrong? This is not supposed to happen according to the
> doc.
>
> “The WdfWorkItemCreate method must be called at IRQL <= DISPATCH_LEVEL.”
>
> “The EvtIoDeviceControl callback function can be called at IRQL <=
> DISPATCH_LEVEL”
>
> Below is the code I use the setup the queue and below that is the code I
> use
> to try and setup the work item.
>
> Thanks,
> Greg
>
> WDF_IO_QUEUE_CONFIG_INIT_DEFAULT_QUEUE(&ioCallbacks,
> WdfIoQueueDispatchSequential);
>
> ioCallbacks.EvtIoDeviceControl = DioEvtDeviceControl;
>
> status = WdfIoQueueCreate(device,
> &ioCallbacks,
> WDF_NO_OBJECT_ATTRIBUTES,
> NULL);
>
>
> NTSTATUS status = STATUS_SUCCESS;
> PWORKER_ITEM_CONTEXT context;
> WDF_OBJECT_ATTRIBUTES attributes;
> WDF_WORKITEM_CONFIG workitemConfig;
> WDFWORKITEM hWorkItem;
>
> WDF_OBJECT_ATTRIBUTES_INIT_CONTEXT_TYPE(&attributes,
> WORKER_ITEM_CONTEXT);
>
> attributes.ParentObject = devContext->WdfDevice;
>
> WDF_WORKITEM_CONFIG_INIT(&workitemConfig, CallbackFunction);
>
> status = WdfWorkItemCreate( &workitemConfig,
> &attributes,
> &hWorkItem);
>
> if (!NT_SUCCESS(status)) {
> return status;
> }
>
>
>
> —
> 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
>
>
>

8

Any thoughts on this issue?

ZwOpenFile hangs in
the routine. My only thought as to why it was hanging is that tin IRQL
level was wrong which should not be the case here since I am the only
driver talking to this device (top level) so I should be called at PASSIVE
level.

“Greg Coleson” wrote in message news:xxxxx@ntdev…
> setting workitemConfig.AutomaticSerialization = FALSE;
>
> fixed the work item create issue.
>
> Thanks,
> Greg
>
> “Greg Coleson” wrote in message news:xxxxx@ntdev…
>> Here is the code. The only reason I am trying to create a work item here
>> is that I want to open and read a file here and the ZwOpenFile hangs in
>> the routine. My only thought as to why it was hanging is that tin IRQL
>> level was wrong which should not be the case here since I am the only
>> driver talking to this device (top level) so I should be called at
>> PASSIVE level.
>>
>> //
>> // Register the PnP and power callbacks. Power policy related callbacks
>> will
>> // be registered later in SotwareInit.
>> //
>> WdfDeviceInitSetPnpPowerEventCallbacks(DeviceInit, &pnpPowerCallbacks);
>>
>> //
>> // Create our Device Object and its associated context
>> //
>> WDF_OBJECT_ATTRIBUTES_INIT(&objAttributes);
>>
>> //
>> // Associate our device context structure type with our WDFDevice
>> //
>> WDF_OBJECT_ATTRIBUTES_SET_CONTEXT_TYPE(&objAttributes,
>> DIO_DEVICE_CONTEXT);
>>
>> //
>> // Other attributes we might set are EvtCleanupCallback (called when
>> // the object is deleted) and EvtDestroyCallback (called when the
>> object’s
>> // references go to zero)…
>> //
>>
>> //
>> // Set the synch scope to device so that child objects such as queue
>> // and DpcForIsr can inherit the device-level synchronization. By
>> // doing so, we make sure that queue dispatch callbacks for ioctl,
>> // cancel-routine, and DpcForIsr are all synchronized with the
>> // same device-level spinlock provided by the framework. This enables
>> // us to access global resources among these callbacks without
>> // worrying about synchronizing access to them with our own lock.
>> //
>> // Also by specifying passive execution level, framework ensures
>> // that our Io callbacks will never be called at DISPATCH_LEVEL.
>>
>> objAttributes.SynchronizationScope = WdfSynchronizationScopeDevice;
>>
>> //
>> // We want our device object NAMED, thank you very much
>> //
>> status = WdfDeviceInitAssignName(DeviceInit, &ntDeviceName);
>>
>> if (!NT_SUCCESS(status))
>> {
>> #if DBG
>> DbgPrint(“WdfDeviceInitAssignName failed 0x%0x\n”, status);
>> #endif
>> return(status);
>> }
>>
>> //set direct IO for speed
>> WdfDeviceInitSetIoType(DeviceInit, WdfDeviceIoDirect);
>>
>> //
>> // Create the device now
>> //
>> // Device Init structure
>> status = WdfDeviceCreate(&DeviceInit,
>> &objAttributes, // Attributes for WDF Device
>> &device); // returns pointer to new WDF Device
>>
>> “Doron Holan” wrote in message
>> news:xxxxx@ntdev…
>> STATUS_WDF_INCOMPATIBLE_EXECUTION_LEVEL refers to the execution level in
>> the framework’s attributes, not the current IRQL. Did you setup your
>> WDFDEVICE with any execution or sync values other then the default?
>>
>> d
>>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com
>> [mailto:xxxxx@lists.osr.com] On Behalf Of Greg Coleson
>> Sent: Friday, January 12, 2007 11:44 AM
>> To: Windows System Software Devs Interest List
>> Subject: [ntdev] WdfWorkItemCreate error
>> STATUS_WDF_INCOMPATIBLE_EXECUTION_LEVEL
>>
>> I am calling WdfWorkItemCreate from my EvtIoDeviceControl queue callback
>>
>> routine and I am getting an STATUS_WDF_INCOMPATIBLE_EXECUTION_LEVEL.
>> Any
>> ideas what is wrong? This is not supposed to happen according to the
>> doc.
>>
>> “The WdfWorkItemCreate method must be called at IRQL <= DISPATCH_LEVEL.”
>>
>> “The EvtIoDeviceControl callback function can be called at IRQL <=
>> DISPATCH_LEVEL”
>>
>> Below is the code I use the setup the queue and below that is the code I
>> use
>> to try and setup the work item.
>>
>> Thanks,
>> Greg
>>
>> WDF_IO_QUEUE_CONFIG_INIT_DEFAULT_QUEUE(&ioCallbacks,
>> WdfIoQueueDispatchSequential);
>>
>> ioCallbacks.EvtIoDeviceControl = DioEvtDeviceControl;
>>
>> status = WdfIoQueueCreate(device,
>> &ioCallbacks,
>> WDF_NO_OBJECT_ATTRIBUTES,
>> NULL);
>>
>>
>> NTSTATUS status = STATUS_SUCCESS;
>> PWORKER_ITEM_CONTEXT context;
>> WDF_OBJECT_ATTRIBUTES attributes;
>> WDF_WORKITEM_CONFIG workitemConfig;
>> WDFWORKITEM hWorkItem;
>>
>> WDF_OBJECT_ATTRIBUTES_INIT_CONTEXT_TYPE(&attributes,
>> WORKER_ITEM_CONTEXT);
>>
>> attributes.ParentObject = devContext->WdfDevice;
>>
>> WDF_WORKITEM_CONFIG_INIT(&workitemConfig, CallbackFunction);
>>
>> status = WdfWorkItemCreate( &workitemConfig,
>> &attributes,
>> &hWorkItem);
>>
>> if (!NT_SUCCESS(status)) {
>> return status;
>> }
>>
>>
>>
>> —
>> 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
>>
>>
>>
>
>
>

9

If you turn on the KMDF verifier, it will do the IRQL check when you
open the target. What file/driver are you opening with ZwOpenFile? Did
you debug the create routine of the target name??

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Greg Coleson
Sent: Friday, January 12, 2007 12:26 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] WdfWorkItemCreate error
STATUS_WDF_INCOMPATIBLE_EXECUTION_LEVEL

Any thoughts on this issue?

ZwOpenFile hangs in
the routine. My only thought as to why it was hanging is that tin IRQL
level was wrong which should not be the case here since I am the only
driver talking to this device (top level) so I should be called at
PASSIVE
level.

“Greg Coleson” wrote in message
news:xxxxx@ntdev…
> setting workitemConfig.AutomaticSerialization = FALSE;
>
> fixed the work item create issue.
>
> Thanks,
> Greg
>
> “Greg Coleson” wrote in message
news:xxxxx@ntdev…
>> Here is the code. The only reason I am trying to create a work item
here
>> is that I want to open and read a file here and the ZwOpenFile hangs
in
>> the routine. My only thought as to why it was hanging is that tin
IRQL
>> level was wrong which should not be the case here since I am the only

>> driver talking to this device (top level) so I should be called at
>> PASSIVE level.
>>
>> //
>> // Register the PnP and power callbacks. Power policy related
callbacks
>> will
>> // be registered later in SotwareInit.
>> //
>> WdfDeviceInitSetPnpPowerEventCallbacks(DeviceInit,
&pnpPowerCallbacks);
>>
>> //
>> // Create our Device Object and its associated context
>> //
>> WDF_OBJECT_ATTRIBUTES_INIT(&objAttributes);
>>
>> //
>> // Associate our device context structure type with our WDFDevice
>> //
>> WDF_OBJECT_ATTRIBUTES_SET_CONTEXT_TYPE(&objAttributes,
>> DIO_DEVICE_CONTEXT);
>>
>> //
>> // Other attributes we might set are EvtCleanupCallback (called
when
>> // the object is deleted) and EvtDestroyCallback (called when the
>> object’s
>> // references go to zero)…
>> //
>>
>> //
>> // Set the synch scope to device so that child objects such as
queue
>> // and DpcForIsr can inherit the device-level synchronization. By
>> // doing so, we make sure that queue dispatch callbacks for ioctl,
>> // cancel-routine, and DpcForIsr are all synchronized with the
>> // same device-level spinlock provided by the framework. This
enables
>> // us to access global resources among these callbacks without
>> // worrying about synchronizing access to them with our own lock.
>> //
>> // Also by specifying passive execution level, framework ensures
>> // that our Io callbacks will never be called at DISPATCH_LEVEL.
>>
>> objAttributes.SynchronizationScope = WdfSynchronizationScopeDevice;
>>
>> //
>> // We want our device object NAMED, thank you very much
>> //
>> status = WdfDeviceInitAssignName(DeviceInit, &ntDeviceName);
>>
>> if (!NT_SUCCESS(status))
>> {
>> #if DBG
>> DbgPrint(“WdfDeviceInitAssignName failed 0x%0x\n”, status);
>> #endif
>> return(status);
>> }
>>
>> //set direct IO for speed
>> WdfDeviceInitSetIoType(DeviceInit, WdfDeviceIoDirect);
>>
>> //
>> // Create the device now
>> //
>> // Device Init structure
>> status = WdfDeviceCreate(&DeviceInit,
>> &objAttributes, // Attributes for WDF Device
>> &device); // returns pointer to new WDF Device
>>
>> “Doron Holan” wrote in message
>> news:xxxxx@ntdev…
>> STATUS_WDF_INCOMPATIBLE_EXECUTION_LEVEL refers to the execution level
in
>> the framework’s attributes, not the current IRQL. Did you setup your
>> WDFDEVICE with any execution or sync values other then the default?
>>
>> d
>>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com
>> [mailto:xxxxx@lists.osr.com] On Behalf Of Greg Coleson
>> Sent: Friday, January 12, 2007 11:44 AM
>> To: Windows System Software Devs Interest List
>> Subject: [ntdev] WdfWorkItemCreate error
>> STATUS_WDF_INCOMPATIBLE_EXECUTION_LEVEL
>>
>> I am calling WdfWorkItemCreate from my EvtIoDeviceControl queue
callback
>>
>> routine and I am getting an STATUS_WDF_INCOMPATIBLE_EXECUTION_LEVEL.
>> Any
>> ideas what is wrong? This is not supposed to happen according to the
>> doc.
>>
>> “The WdfWorkItemCreate method must be called at IRQL <=
DISPATCH_LEVEL.”
>>
>> “The EvtIoDeviceControl callback function can be called at IRQL <=
>> DISPATCH_LEVEL”
>>
>> Below is the code I use the setup the queue and below that is the
code I
>> use
>> to try and setup the work item.
>>
>> Thanks,
>> Greg
>>
>> WDF_IO_QUEUE_CONFIG_INIT_DEFAULT_QUEUE(&ioCallbacks,
>> WdfIoQueueDispatchSequential);
>>
>> ioCallbacks.EvtIoDeviceControl = DioEvtDeviceControl;
>>
>> status = WdfIoQueueCreate(device,
>> &ioCallbacks,
>> WDF_NO_OBJECT_ATTRIBUTES,
>> NULL);
>>
>>
>> NTSTATUS status = STATUS_SUCCESS;
>> PWORKER_ITEM_CONTEXT context;
>> WDF_OBJECT_ATTRIBUTES attributes;
>> WDF_WORKITEM_CONFIG workitemConfig;
>> WDFWORKITEM hWorkItem;
>>
>> WDF_OBJECT_ATTRIBUTES_INIT_CONTEXT_TYPE(&attributes,
>> WORKER_ITEM_CONTEXT);
>>
>> attributes.ParentObject = devContext->WdfDevice;
>>
>> WDF_WORKITEM_CONFIG_INIT(&workitemConfig, CallbackFunction);
>>
>> status = WdfWorkItemCreate( &workitemConfig,
>> &attributes,
>> &hWorkItem);
>>
>> if (!NT_SUCCESS(status)) {
>> return status;
>> }
>>
>>
>>
>> —
>> 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

10

Your comments suggest that your execution level is passive but I don’t
see where you’re setting that in the code. (maybe I missed it or it
wasn’t copied/pasted into your message). Also, I see that your
synchronization scope is device. I admit I have been away from using
WDF for a few months so my info may be a bit stale, but I think that
will cause your dispatch routine to be called at DISPATCH_LEVEL since
it wil acquire a lock before calling your callback if your exectuion
level is not set to passive (Again, that part of the code may have
escaped your cut/paste or my eyesight is failing.).

Beverly

On 1/12/07, Doron Holan wrote:
> If you turn on the KMDF verifier, it will do the IRQL check when you
> open the target. What file/driver are you opening with ZwOpenFile? Did
> you debug the create routine of the target name??
>
> d
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Greg Coleson
> Sent: Friday, January 12, 2007 12:26 PM
> To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] WdfWorkItemCreate error
> STATUS_WDF_INCOMPATIBLE_EXECUTION_LEVEL
>
> Any thoughts on this issue?
>
> ZwOpenFile hangs in
> the routine. My only thought as to why it was hanging is that tin IRQL
> level was wrong which should not be the case here since I am the only
> driver talking to this device (top level) so I should be called at
> PASSIVE
> level.
>
> “Greg Coleson” wrote in message
> news:xxxxx@ntdev…
> > setting workitemConfig.AutomaticSerialization = FALSE;
> >
> > fixed the work item create issue.
> >
> > Thanks,
> > Greg
> >
> > “Greg Coleson” wrote in message
> news:xxxxx@ntdev…
> >> Here is the code. The only reason I am trying to create a work item
> here
> >> is that I want to open and read a file here and the ZwOpenFile hangs
> in
> >> the routine. My only thought as to why it was hanging is that tin
> IRQL
> >> level was wrong which should not be the case here since I am the only
>
> >> driver talking to this device (top level) so I should be called at
> >> PASSIVE level.
> >>
> >> //
> >> // Register the PnP and power callbacks. Power policy related
> callbacks
> >> will
> >> // be registered later in SotwareInit.
> >> //
> >> WdfDeviceInitSetPnpPowerEventCallbacks(DeviceInit,
> &pnpPowerCallbacks);
> >>
> >> //
> >> // Create our Device Object and its associated context
> >> //
> >> WDF_OBJECT_ATTRIBUTES_INIT(&objAttributes);
> >>
> >> //
> >> // Associate our device context structure type with our WDFDevice
> >> //
> >> WDF_OBJECT_ATTRIBUTES_SET_CONTEXT_TYPE(&objAttributes,
> >> DIO_DEVICE_CONTEXT);
> >>
> >> //
> >> // Other attributes we might set are EvtCleanupCallback (called
> when
> >> // the object is deleted) and EvtDestroyCallback (called when the
> >> object’s
> >> // references go to zero)…
> >> //
> >>
> >> //
> >> // Set the synch scope to device so that child objects such as
> queue
> >> // and DpcForIsr can inherit the device-level synchronization. By
> >> // doing so, we make sure that queue dispatch callbacks for ioctl,
> >> // cancel-routine, and DpcForIsr are all synchronized with the
> >> // same device-level spinlock provided by the framework. This
> enables
> >> // us to access global resources among these callbacks without
> >> // worrying about synchronizing access to them with our own lock.
> >> //
> >> // Also by specifying passive execution level, framework ensures
> >> // that our Io callbacks will never be called at DISPATCH_LEVEL.
> >>
> >> objAttributes.SynchronizationScope = WdfSynchronizationScopeDevice;
> >>
> >> //
> >> // We want our device object NAMED, thank you very much
> >> //
> >> status = WdfDeviceInitAssignName(DeviceInit, &ntDeviceName);
> >>
> >> if (!NT_SUCCESS(status))
> >> {
> >> #if DBG
> >> DbgPrint(“WdfDeviceInitAssignName failed 0x%0x\n”, status);
> >> #endif
> >> return(status);
> >> }
> >>
> >> //set direct IO for speed
> >> WdfDeviceInitSetIoType(DeviceInit, WdfDeviceIoDirect);
> >>
> >> //
> >> // Create the device now
> >> //
> >> // Device Init structure
> >> status = WdfDeviceCreate(&DeviceInit,
> >> &objAttributes, // Attributes for WDF Device
> >> &device); // returns pointer to new WDF Device
> >>
> >> “Doron Holan” wrote in message
> >> news:xxxxx@ntdev…
> >> STATUS_WDF_INCOMPATIBLE_EXECUTION_LEVEL refers to the execution level
> in
> >> the framework’s attributes, not the current IRQL. Did you setup your
> >> WDFDEVICE with any execution or sync values other then the default?
> >>
> >> d
> >>
> >> -----Original Message-----
> >> From: xxxxx@lists.osr.com
> >> [mailto:xxxxx@lists.osr.com] On Behalf Of Greg Coleson
> >> Sent: Friday, January 12, 2007 11:44 AM
> >> To: Windows System Software Devs Interest List
> >> Subject: [ntdev] WdfWorkItemCreate error
> >> STATUS_WDF_INCOMPATIBLE_EXECUTION_LEVEL
> >>
> >> I am calling WdfWorkItemCreate from my EvtIoDeviceControl queue
> callback
> >>
> >> routine and I am getting an STATUS_WDF_INCOMPATIBLE_EXECUTION_LEVEL.
> >> Any
> >> ideas what is wrong? This is not supposed to happen according to the
> >> doc.
> >>
> >> “The WdfWorkItemCreate method must be called at IRQL <=
> DISPATCH_LEVEL.”
> >>
> >> “The EvtIoDeviceControl callback function can be called at IRQL <=
> >> DISPATCH_LEVEL”
> >>
> >> Below is the code I use the setup the queue and below that is the
> code I
> >> use
> >> to try and setup the work item.
> >>
> >> Thanks,
> >> Greg
> >>
> >> WDF_IO_QUEUE_CONFIG_INIT_DEFAULT_QUEUE(&ioCallbacks,
> >> WdfIoQueueDispatchSequential);
> >>
> >> ioCallbacks.EvtIoDeviceControl = DioEvtDeviceControl;
> >>
> >> status = WdfIoQueueCreate(device,
> >> &ioCallbacks,
> >> WDF_NO_OBJECT_ATTRIBUTES,
> >> NULL);
> >>
> >>
> >> NTSTATUS status = STATUS_SUCCESS;
> >> PWORKER_ITEM_CONTEXT context;
> >> WDF_OBJECT_ATTRIBUTES attributes;
> >> WDF_WORKITEM_CONFIG workitemConfig;
> >> WDFWORKITEM hWorkItem;
> >>
> >> WDF_OBJECT_ATTRIBUTES_INIT_CONTEXT_TYPE(&attributes,
> >> WORKER_ITEM_CONTEXT);
> >>
> >> attributes.ParentObject = devContext->WdfDevice;
> >>
> >> WDF_WORKITEM_CONFIG_INIT(&workitemConfig, CallbackFunction);
> >>
> >> status = WdfWorkItemCreate( &workitemConfig,
> >> &attributes,
> >> &hWorkItem);
> >>
> >> if (!NT_SUCCESS(status)) {
> >> return status;
> >> }
> >>
> >>
> >>
> >> —
> >> 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
>

11

Greg Coleson wrote:

Any thoughts on this issue?

ZwOpenFile hangs in
the routine. My only thought as to why it was hanging is that tin IRQL
level was wrong which should not be the case here since I am the only
driver talking to this device (top level) so I should be called at PASSIVE
level.

Your IRQL will be passive only if you have limited the execution level
to passive. The fact that you got an error creating the work item says
that you have NOT set execution level to passive. In that case, ALL of
your device queue callbacks will be called at DISPATCH_LEVEL.

Are you now saying that ZwOpenFile hangs in the work item? Or are you
asking why it hung in your EvtIoDeviceControl handler before the
change? The reason it hung before is that your EvtIoDeviceControl runs
at DISPATCH_LEVEL.

This is an important point. In WDM, we’re used to top-level IRP
handlers being called at passive in the caller’s context. In KMDF,
that’s no longer true. At passive level, all the framework does is
queue the IRP and return STATUS_PENDING. At some later point, it will
pull your request out of the queue, fetch the spin lock (thereby raising
to DISPATCH_LEVEL), and call your callback. It’s consistent, but very
different from WDM.

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

12

I am trying to use the verifier and want to verify that it is on but the
symbols for this call don’t seem to be loaded. Do I need the checked
version of Windows to do this or how do I load the symbols for this module
or is there a programatic way to verify that it is on?

kd> !wdfkd.wdfdriverinfo

error: Could not retrieve driver name parameter.
hint: Did you give the driver name parameter?
kd> !wdfdriverinfo wdfrawbusenumtest fff

*** ERROR: Symbol file could not be found. Defaulted to export symbols for
WDFLDR.SYS -
hint: Are symbols available for this driver?
hint: Did you exclude the .sys extension in the drivername parameter?

Could not find wdfrawbusenumtest in wdfldr client list
Default driver image name: wdfrawbusenumtest
WDF library image name:
hint: Are symbols available for this driver?
hint: Did you exclude the .sys extension in the drivername parameter?

Could not find wdfrawbusenumtest in wdfldr client list

“Doron Holan” wrote in message
news:xxxxx@ntdev…
If you turn on the KMDF verifier, it will do the IRQL check when you
open the target. What file/driver are you opening with ZwOpenFile? Did
you debug the create routine of the target name??

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Greg Coleson
Sent: Friday, January 12, 2007 12:26 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] WdfWorkItemCreate error
STATUS_WDF_INCOMPATIBLE_EXECUTION_LEVEL

Any thoughts on this issue?

ZwOpenFile hangs in
the routine. My only thought as to why it was hanging is that tin IRQL
level was wrong which should not be the case here since I am the only
driver talking to this device (top level) so I should be called at
PASSIVE
level.

“Greg Coleson” wrote in message
news:xxxxx@ntdev…
> setting workitemConfig.AutomaticSerialization = FALSE;
>
> fixed the work item create issue.
>
> Thanks,
> Greg
>
> “Greg Coleson” wrote in message
news:xxxxx@ntdev…
>> Here is the code. The only reason I am trying to create a work item
here
>> is that I want to open and read a file here and the ZwOpenFile hangs
in
>> the routine. My only thought as to why it was hanging is that tin
IRQL
>> level was wrong which should not be the case here since I am the only

>> driver talking to this device (top level) so I should be called at
>> PASSIVE level.
>>
>> //
>> // Register the PnP and power callbacks. Power policy related
callbacks
>> will
>> // be registered later in SotwareInit.
>> //
>> WdfDeviceInitSetPnpPowerEventCallbacks(DeviceInit,
&pnpPowerCallbacks);
>>
>> //
>> // Create our Device Object and its associated context
>> //
>> WDF_OBJECT_ATTRIBUTES_INIT(&objAttributes);
>>
>> //
>> // Associate our device context structure type with our WDFDevice
>> //
>> WDF_OBJECT_ATTRIBUTES_SET_CONTEXT_TYPE(&objAttributes,
>> DIO_DEVICE_CONTEXT);
>>
>> //
>> // Other attributes we might set are EvtCleanupCallback (called
when
>> // the object is deleted) and EvtDestroyCallback (called when the
>> object’s
>> // references go to zero)…
>> //
>>
>> //
>> // Set the synch scope to device so that child objects such as
queue
>> // and DpcForIsr can inherit the device-level synchronization. By
>> // doing so, we make sure that queue dispatch callbacks for ioctl,
>> // cancel-routine, and DpcForIsr are all synchronized with the
>> // same device-level spinlock provided by the framework. This
enables
>> // us to access global resources among these callbacks without
>> // worrying about synchronizing access to them with our own lock.
>> //
>> // Also by specifying passive execution level, framework ensures
>> // that our Io callbacks will never be called at DISPATCH_LEVEL.
>>
>> objAttributes.SynchronizationScope = WdfSynchronizationScopeDevice;
>>
>> //
>> // We want our device object NAMED, thank you very much
>> //
>> status = WdfDeviceInitAssignName(DeviceInit, &ntDeviceName);
>>
>> if (!NT_SUCCESS(status))
>> {
>> #if DBG
>> DbgPrint(“WdfDeviceInitAssignName failed 0x%0x\n”, status);
>> #endif
>> return(status);
>> }
>>
>> //set direct IO for speed
>> WdfDeviceInitSetIoType(DeviceInit, WdfDeviceIoDirect);
>>
>> //
>> // Create the device now
>> //
>> // Device Init structure
>> status = WdfDeviceCreate(&DeviceInit,
>> &objAttributes, // Attributes for WDF Device
>> &device); // returns pointer to new WDF Device
>>
>> “Doron Holan” wrote in message
>> news:xxxxx@ntdev…
>> STATUS_WDF_INCOMPATIBLE_EXECUTION_LEVEL refers to the execution level
in
>> the framework’s attributes, not the current IRQL. Did you setup your
>> WDFDEVICE with any execution or sync values other then the default?
>>
>> d
>>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com
>> [mailto:xxxxx@lists.osr.com] On Behalf Of Greg Coleson
>> Sent: Friday, January 12, 2007 11:44 AM
>> To: Windows System Software Devs Interest List
>> Subject: [ntdev] WdfWorkItemCreate error
>> STATUS_WDF_INCOMPATIBLE_EXECUTION_LEVEL
>>
>> I am calling WdfWorkItemCreate from my EvtIoDeviceControl queue
callback
>>
>> routine and I am getting an STATUS_WDF_INCOMPATIBLE_EXECUTION_LEVEL.
>> Any
>> ideas what is wrong? This is not supposed to happen according to the
>> doc.
>>
>> “The WdfWorkItemCreate method must be called at IRQL <=
DISPATCH_LEVEL.”
>>
>> “The EvtIoDeviceControl callback function can be called at IRQL <=
>> DISPATCH_LEVEL”
>>
>> Below is the code I use the setup the queue and below that is the
code I
>> use
>> to try and setup the work item.
>>
>> Thanks,
>> Greg
>>
>> WDF_IO_QUEUE_CONFIG_INIT_DEFAULT_QUEUE(&ioCallbacks,
>> WdfIoQueueDispatchSequential);
>>
>> ioCallbacks.EvtIoDeviceControl = DioEvtDeviceControl;
>>
>> status = WdfIoQueueCreate(device,
>> &ioCallbacks,
>> WDF_NO_OBJECT_ATTRIBUTES,
>> NULL);
>>
>>
>> NTSTATUS status = STATUS_SUCCESS;
>> PWORKER_ITEM_CONTEXT context;
>> WDF_OBJECT_ATTRIBUTES attributes;
>> WDF_WORKITEM_CONFIG workitemConfig;
>> WDFWORKITEM hWorkItem;
>>
>> WDF_OBJECT_ATTRIBUTES_INIT_CONTEXT_TYPE(&attributes,
>> WORKER_ITEM_CONTEXT);
>>
>> attributes.ParentObject = devContext->WdfDevice;
>>
>> WDF_WORKITEM_CONFIG_INIT(&workitemConfig, CallbackFunction);
>>
>> status = WdfWorkItemCreate( &workitemConfig,
>> &attributes,
>> &hWorkItem);
>>
>> if (!NT_SUCCESS(status)) {
>> return status;
>> }
>>
>>
>>
>> —
>> 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

13

Is your driver’s name wdfrawbusenumtest? What is the output of
!wdfkd.wdfldr? You have to give *your* driver’s name as the parameter
to !wdfdriverinfo (and not my internal test driver which is named
wdfrawbusenumtest :wink: ). The debugger extension requires KMDF symbols
(v1.5 is on the public sym server, older versions are in the DDK overlay
you installed) and most likely your driver’s symbols.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Greg Coleson
Sent: Tuesday, January 16, 2007 1:04 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] WdfWorkItemCreate error
STATUS_WDF_INCOMPATIBLE_EXECUTION_LEVEL

I am trying to use the verifier and want to verify that it is on but the

symbols for this call don’t seem to be loaded. Do I need the checked
version of Windows to do this or how do I load the symbols for this
module
or is there a programatic way to verify that it is on?

kd> !wdfkd.wdfdriverinfo

error: Could not retrieve driver name parameter.
hint: Did you give the driver name parameter?
kd> !wdfdriverinfo wdfrawbusenumtest fff

*** ERROR: Symbol file could not be found. Defaulted to export symbols
for
WDFLDR.SYS -
hint: Are symbols available for this driver?
hint: Did you exclude the .sys extension in the drivername parameter?

Could not find wdfrawbusenumtest in wdfldr client list
Default driver image name: wdfrawbusenumtest
WDF library image name:
hint: Are symbols available for this driver?
hint: Did you exclude the .sys extension in the drivername parameter?

Could not find wdfrawbusenumtest in wdfldr client list

“Doron Holan” wrote in message
news:xxxxx@ntdev…
If you turn on the KMDF verifier, it will do the IRQL check when you
open the target. What file/driver are you opening with ZwOpenFile? Did
you debug the create routine of the target name??

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Greg Coleson
Sent: Friday, January 12, 2007 12:26 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] WdfWorkItemCreate error
STATUS_WDF_INCOMPATIBLE_EXECUTION_LEVEL

Any thoughts on this issue?

ZwOpenFile hangs in
the routine. My only thought as to why it was hanging is that tin IRQL
level was wrong which should not be the case here since I am the only
driver talking to this device (top level) so I should be called at
PASSIVE
level.

“Greg Coleson” wrote in message
news:xxxxx@ntdev…
> setting workitemConfig.AutomaticSerialization = FALSE;
>
> fixed the work item create issue.
>
> Thanks,
> Greg
>
> “Greg Coleson” wrote in message
news:xxxxx@ntdev…
>> Here is the code. The only reason I am trying to create a work item
here
>> is that I want to open and read a file here and the ZwOpenFile hangs
in
>> the routine. My only thought as to why it was hanging is that tin
IRQL
>> level was wrong which should not be the case here since I am the only

>> driver talking to this device (top level) so I should be called at
>> PASSIVE level.
>>
>> //
>> // Register the PnP and power callbacks. Power policy related
callbacks
>> will
>> // be registered later in SotwareInit.
>> //
>> WdfDeviceInitSetPnpPowerEventCallbacks(DeviceInit,
&pnpPowerCallbacks);
>>
>> //
>> // Create our Device Object and its associated context
>> //
>> WDF_OBJECT_ATTRIBUTES_INIT(&objAttributes);
>>
>> //
>> // Associate our device context structure type with our WDFDevice
>> //
>> WDF_OBJECT_ATTRIBUTES_SET_CONTEXT_TYPE(&objAttributes,
>> DIO_DEVICE_CONTEXT);
>>
>> //
>> // Other attributes we might set are EvtCleanupCallback (called
when
>> // the object is deleted) and EvtDestroyCallback (called when the
>> object’s
>> // references go to zero)…
>> //
>>
>> //
>> // Set the synch scope to device so that child objects such as
queue
>> // and DpcForIsr can inherit the device-level synchronization. By
>> // doing so, we make sure that queue dispatch callbacks for ioctl,
>> // cancel-routine, and DpcForIsr are all synchronized with the
>> // same device-level spinlock provided by the framework. This
enables
>> // us to access global resources among these callbacks without
>> // worrying about synchronizing access to them with our own lock.
>> //
>> // Also by specifying passive execution level, framework ensures
>> // that our Io callbacks will never be called at DISPATCH_LEVEL.
>>
>> objAttributes.SynchronizationScope = WdfSynchronizationScopeDevice;
>>
>> //
>> // We want our device object NAMED, thank you very much
>> //
>> status = WdfDeviceInitAssignName(DeviceInit, &ntDeviceName);
>>
>> if (!NT_SUCCESS(status))
>> {
>> #if DBG
>> DbgPrint(“WdfDeviceInitAssignName failed 0x%0x\n”, status);
>> #endif
>> return(status);
>> }
>>
>> //set direct IO for speed
>> WdfDeviceInitSetIoType(DeviceInit, WdfDeviceIoDirect);
>>
>> //
>> // Create the device now
>> //
>> // Device Init structure
>> status = WdfDeviceCreate(&DeviceInit,
>> &objAttributes, // Attributes for WDF Device
>> &device); // returns pointer to new WDF Device
>>
>> “Doron Holan” wrote in message
>> news:xxxxx@ntdev…
>> STATUS_WDF_INCOMPATIBLE_EXECUTION_LEVEL refers to the execution level
in
>> the framework’s attributes, not the current IRQL. Did you setup your
>> WDFDEVICE with any execution or sync values other then the default?
>>
>> d
>>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com
>> [mailto:xxxxx@lists.osr.com] On Behalf Of Greg Coleson
>> Sent: Friday, January 12, 2007 11:44 AM
>> To: Windows System Software Devs Interest List
>> Subject: [ntdev] WdfWorkItemCreate error
>> STATUS_WDF_INCOMPATIBLE_EXECUTION_LEVEL
>>
>> I am calling WdfWorkItemCreate from my EvtIoDeviceControl queue
callback
>>
>> routine and I am getting an STATUS_WDF_INCOMPATIBLE_EXECUTION_LEVEL.
>> Any
>> ideas what is wrong? This is not supposed to happen according to the
>> doc.
>>
>> “The WdfWorkItemCreate method must be called at IRQL <=
DISPATCH_LEVEL.”
>>
>> “The EvtIoDeviceControl callback function can be called at IRQL <=
>> DISPATCH_LEVEL”
>>
>> Below is the code I use the setup the queue and below that is the
code I
>> use
>> to try and setup the work item.
>>
>> Thanks,
>> Greg
>>
>> WDF_IO_QUEUE_CONFIG_INIT_DEFAULT_QUEUE(&ioCallbacks,
>> WdfIoQueueDispatchSequential);
>>
>> ioCallbacks.EvtIoDeviceControl = DioEvtDeviceControl;
>>
>> status = WdfIoQueueCreate(device,
>> &ioCallbacks,
>> WDF_NO_OBJECT_ATTRIBUTES,
>> NULL);
>>
>>
>> NTSTATUS status = STATUS_SUCCESS;
>> PWORKER_ITEM_CONTEXT context;
>> WDF_OBJECT_ATTRIBUTES attributes;
>> WDF_WORKITEM_CONFIG workitemConfig;
>> WDFWORKITEM hWorkItem;
>>
>> WDF_OBJECT_ATTRIBUTES_INIT_CONTEXT_TYPE(&attributes,
>> WORKER_ITEM_CONTEXT);
>>
>> attributes.ParentObject = devContext->WdfDevice;
>>
>> WDF_WORKITEM_CONFIG_INIT(&workitemConfig, CallbackFunction);
>>
>> status = WdfWorkItemCreate( &workitemConfig,
>> &attributes,
>> &hWorkItem);
>>
>> if (!NT_SUCCESS(status)) {
>> return status;
>> }
>>
>>
>>
>> —
>> 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

14

I have the registry setting set correctly I think:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WdfDio\Parameters\Wdf

the key is: VerifierOn REG_DWORD 0x00000001(1)

kd> !wdfdriverinfo wdfdio fff

Default driver image name: wdfdio
WDF library image name: Wdf01000
FxDriverGlobals 0x84e767b0
WdfBindInfo 0xf78822c0
Version v1.5 build(6000)

Driver Handles:
dt FxDriver 0x85163AF0 : WDFDRIVER 0x7ae9c508
dt FxDevice 0x84E442F0 : WDFDEVICE 0x7b1bbd08 Context
84e444b8
dt FxDefaultIrpHandler 0x84E41128 : WDF INTERNAL
dt FxPkgGeneral 0x84E622E8 : WDF INTERNAL
dt FxWmiIrpHandler 0x8504CEC0 : WDF INTERNAL
dt FxPkgIo 0x84E39548 : WDF INTERNAL
dt FxIoQueue 0x84E39348 : WDFQUEUE 0x7b1c6cb0
dt FxIoQueue 0x84E3C010 : WDFQUEUE 0x7b1c3fe8
dt FxIoQueue 0x84E3C2C8 : WDFQUEUE 0x7b1c3d30
dt FxIoQueue 0x84E29390 : WDFQUEUE 0x7b1d6c68
dt FxPkgFdo 0x84E2B010 : WDF INTERNAL
dt FxCmResList 0x84E652C0 : WDFCMRESLIST 0x7b19ad38
dt FxResourceCm 0x850589C0 : WDF INTERNAL
dt FxResourceCm 0x84E44268 : WDF INTERNAL
dt FxResourceCm 0x84E3C268 : WDF INTERNAL
dt FxResourceCm 0x84E39200 : WDF INTERNAL
dt FxResourceCm 0x84E391A0 : WDF INTERNAL
dt FxCmResList 0x8506A810 : WDFCMRESLIST 0x7af957e8
dt FxResourceCm 0x84E60300 : WDF INTERNAL
dt FxResourceCm 0x84E60238 : WDF INTERNAL
dt FxResourceCm 0x84E59438 : WDF INTERNAL
dt FxResourceCm 0x84E60360 : WDF INTERNAL
dt FxResourceCm 0x84FD8410 : WDF INTERNAL
dt FxChildList 0x84E4A0E0 : WDFCHILDLIST 0x7b1b5f18
dt FxIoTarget 0x850E34D0 : WDFIOTARGET 0x7af1cb28
dt FxInterrupt 0x84F7FA18 : WDFINTERRUPT 0x7b0805e0
Context 84f7fb00
dt FxDpc 0x84E69688 : WDFDPC 0x7b196970
dt FxDpc 0x850619B0 : WDFDPC 0x7af9e648
dt FxDpc 0x84E2FBC8 : WDFDPC 0x7b1d0430
dt FxWmiProvider 0x85058A20 : WDF INTERNAL
dt FxWmiInstanceExternal 0x850666C0 : WDF INTERNAL
dt FxRequest 0x84E3E668 : WDFREQUEST 0x7b1c1990
dt FxRequest 0x84E69968 : WDFREQUEST 0x7b196690
dt FxRequest 0x84E29190 : WDFREQUEST 0x7b1d6e68
dt FxRequest 0x84E51F48 : WDFREQUEST 0x7b1ae0b0
dt FxRequest 0x84E43C40 : WDFREQUEST 0x7b1bc3b8
dt FxWorkItem 0x84E60580 : WDFWORKITEM 0x7b19fa78
Context 84e60600

Dump leaked handles: the driver is not tracking handles

WDF Verifier settings for wdfdio.sys is OFF

“Doron Holan” wrote in message
news:xxxxx@ntdev…
Is your driver’s name wdfrawbusenumtest? What is the output of
!wdfkd.wdfldr? You have to give your driver’s name as the parameter
to !wdfdriverinfo (and not my internal test driver which is named
wdfrawbusenumtest :wink: ). The debugger extension requires KMDF symbols
(v1.5 is on the public sym server, older versions are in the DDK overlay
you installed) and most likely your driver’s symbols.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Greg Coleson
Sent: Tuesday, January 16, 2007 1:04 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] WdfWorkItemCreate error
STATUS_WDF_INCOMPATIBLE_EXECUTION_LEVEL

I am trying to use the verifier and want to verify that it is on but the

symbols for this call don’t seem to be loaded. Do I need the checked
version of Windows to do this or how do I load the symbols for this
module
or is there a programatic way to verify that it is on?

kd> !wdfkd.wdfdriverinfo
----------------------------------
error: Could not retrieve driver name parameter.
hint: Did you give the driver name parameter?
kd> !wdfdriverinfo wdfrawbusenumtest fff
----------------------------------
*** ERROR: Symbol file could not be found. Defaulted to export symbols
for
WDFLDR.SYS -
hint: Are symbols available for this driver?
hint: Did you exclude the .sys extension in the drivername parameter?

Could not find wdfrawbusenumtest in wdfldr client list
Default driver image name: wdfrawbusenumtest
WDF library image name:
hint: Are symbols available for this driver?
hint: Did you exclude the .sys extension in the drivername parameter?

Could not find wdfrawbusenumtest in wdfldr client list

“Doron Holan” wrote in message
news:xxxxx@ntdev…
If you turn on the KMDF verifier, it will do the IRQL check when you
open the target. What file/driver are you opening with ZwOpenFile? Did
you debug the create routine of the target name??

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Greg Coleson
Sent: Friday, January 12, 2007 12:26 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] WdfWorkItemCreate error
STATUS_WDF_INCOMPATIBLE_EXECUTION_LEVEL

Any thoughts on this issue?

ZwOpenFile hangs in
the routine. My only thought as to why it was hanging is that tin IRQL
level was wrong which should not be the case here since I am the only
driver talking to this device (top level) so I should be called at
PASSIVE
level.

“Greg Coleson” wrote in message
news:xxxxx@ntdev…
> setting workitemConfig.AutomaticSerialization = FALSE;
>
> fixed the work item create issue.
>
> Thanks,
> Greg
>
> “Greg Coleson” wrote in message
news:xxxxx@ntdev…
>> Here is the code. The only reason I am trying to create a work item
here
>> is that I want to open and read a file here and the ZwOpenFile hangs
in
>> the routine. My only thought as to why it was hanging is that tin
IRQL
>> level was wrong which should not be the case here since I am the only

>> driver talking to this device (top level) so I should be called at
>> PASSIVE level.
>>
>> //
>> // Register the PnP and power callbacks. Power policy related
callbacks
>> will
>> // be registered later in SotwareInit.
>> //
>> WdfDeviceInitSetPnpPowerEventCallbacks(DeviceInit,
&pnpPowerCallbacks);
>>
>> //
>> // Create our Device Object and its associated context
>> //
>> WDF_OBJECT_ATTRIBUTES_INIT(&objAttributes);
>>
>> //
>> // Associate our device context structure type with our WDFDevice
>> //
>> WDF_OBJECT_ATTRIBUTES_SET_CONTEXT_TYPE(&objAttributes,
>> DIO_DEVICE_CONTEXT);
>>
>> //
>> // Other attributes we might set are EvtCleanupCallback (called
when
>> // the object is deleted) and EvtDestroyCallback (called when the
>> object’s
>> // references go to zero)…
>> //
>>
>> //
>> // Set the synch scope to device so that child objects such as
queue
>> // and DpcForIsr can inherit the device-level synchronization. By
>> // doing so, we make sure that queue dispatch callbacks for ioctl,
>> // cancel-routine, and DpcForIsr are all synchronized with the
>> // same device-level spinlock provided by the framework. This
enables
>> // us to access global resources among these callbacks without
>> // worrying about synchronizing access to them with our own lock.
>> //
>> // Also by specifying passive execution level, framework ensures
>> // that our Io callbacks will never be called at DISPATCH_LEVEL.
>>
>> objAttributes.SynchronizationScope = WdfSynchronizationScopeDevice;
>>
>> //
>> // We want our device object NAMED, thank you very much
>> //
>> status = WdfDeviceInitAssignName(DeviceInit, &ntDeviceName);
>>
>> if (!NT_SUCCESS(status))
>> {
>> #if DBG
>> DbgPrint(“WdfDeviceInitAssignName failed 0x%0x\n”, status);
>> #endif
>> return(status);
>> }
>>
>> //set direct IO for speed
>> WdfDeviceInitSetIoType(DeviceInit, WdfDeviceIoDirect);
>>
>> //
>> // Create the device now
>> //
>> // Device Init structure
>> status = WdfDeviceCreate(&DeviceInit,
>> &objAttributes, // Attributes for WDF Device
>> &device); // returns pointer to new WDF Device
>>
>> “Doron Holan” wrote in message
>> news:xxxxx@ntdev…
>> STATUS_WDF_INCOMPATIBLE_EXECUTION_LEVEL refers to the execution level
in
>> the framework’s attributes, not the current IRQL. Did you setup your
>> WDFDEVICE with any execution or sync values other then the default?
>>
>> d
>>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com
>> [mailto:xxxxx@lists.osr.com] On Behalf Of Greg Coleson
>> Sent: Friday, January 12, 2007 11:44 AM
>> To: Windows System Software Devs Interest List
>> Subject: [ntdev] WdfWorkItemCreate error
>> STATUS_WDF_INCOMPATIBLE_EXECUTION_LEVEL
>>
>> I am calling WdfWorkItemCreate from my EvtIoDeviceControl queue
callback
>>
>> routine and I am getting an STATUS_WDF_INCOMPATIBLE_EXECUTION_LEVEL.
>> Any
>> ideas what is wrong? This is not supposed to happen according to the
>> doc.
>>
>> “The WdfWorkItemCreate method must be called at IRQL <=
DISPATCH_LEVEL.”
>>
>> “The EvtIoDeviceControl callback function can be called at IRQL <=
>> DISPATCH_LEVEL”
>>
>> Below is the code I use the setup the queue and below that is the
code I
>> use
>> to try and setup the work item.
>>
>> Thanks,
>> Greg
>>
>> WDF_IO_QUEUE_CONFIG_INIT_DEFAULT_QUEUE(&ioCallbacks,
>> WdfIoQueueDispatchSequential);
>>
>> ioCallbacks.EvtIoDeviceControl = DioEvtDeviceControl;
>>
>> status = WdfIoQueueCreate(device,
>> &ioCallbacks,
>> WDF_NO_OBJECT_ATTRIBUTES,
>> NULL);
>>
>>
>> NTSTATUS status = STATUS_SUCCESS;
>> PWORKER_ITEM_CONTEXT context;
>> WDF_OBJECT_ATTRIBUTES attributes;
>> WDF_WORKITEM_CONFIG workitemConfig;
>> WDFWORKITEM hWorkItem;
>>
>> WDF_OBJECT_ATTRIBUTES_INIT_CONTEXT_TYPE(&attributes,
>> WORKER_ITEM_CONTEXT);
>>
>> attributes.ParentObject = devContext->WdfDevice;
>>
>> WDF_WORKITEM_CONFIG_INIT(&workitemConfig, CallbackFunction);
>>
>> status = WdfWorkItemCreate( &workitemConfig,
>> &attributes,
>> &hWorkItem);
>>
>> if (!NT_SUCCESS(status)) {
>> return status;
>> }
>>
>>
>>
>> —
>> 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

15

Just in case you didn’t do so, was the driver loaded after the VerifierOn setting was changed? The settings are established at driver load time (WdfDriverCreate), so changing the key afterward won’t work.

16

Thanks for the suggetsion, but I rebooted the system also, just to be sure
and no luck.
Any other ideas?

“Bob Kjelgaard” wrote in message
news:xxxxx@ntdev…
Just in case you didn’t do so, was the driver loaded after the VerifierOn
setting was changed? The settings are established at driver load time
(WdfDriverCreate), so changing the key afterward won’t work.

17

Is the extension you are using the one from the 6000 WDK? Is the service you placed the key under the correct one? No typos?

My apologies if these seem to be condescending questions- it’s just I use this practically every day without having any problems of this sort, and I’m trying to run down the list of possibilities (and most of them seem pretty unlikely and unrealistic at this point).

I even entered the same command you posted against a driver I’m currently debugging [nasty bugchecking SOB it’s being, too], and it shows verifier on and a host of related settings- that part looks a bit different, but I believe they appear because the verifier is on. I can’t say for sure about that because I ignore anything not relevant to the task at hand, and flush out any detailed memory as well. Anyway, my output’s below (yes, this is a post-Vista x64 build of the OS, but I doubt that’s relevant).

If it’s not any of that, then perhaps Doron has something- he’s usually in by now (but our offices are in different wings of the building, so I can’t tell you that for certain, either).

Hope I’m not wasting too much of your time…

3: kd> !wdfdriverinfo virtualstorage fff

Default driver image name: virtualstorage
WDF library image name: Wdf01000
FxDriverGlobals 0xfffff9800229ee80
WdfBindInfo 0xfffffa60029c81b8
Version v1.5 build(6001)

Driver Handles:
dt FxDriver 0xFFFFF98002302E60 : WDFDRIVER 0x0000067ffdcfd198 Context fffff98002302ff0
dt FxDevice 0xFFFFF98002326C70 : WDFDEVICE 0x0000067ffdcd9388 Context fffff98002326fe0
dt FxDefaultIrpHandler 0xFFFFF9800232CF9 : WDF INTERNAL
dt FxPkgGeneral 0xFFFFF98002332EF0 : WDF INTERNAL
dt FxWmiIrpHandler 0xFFFFF980022A4F50 : WDF INTERNAL
dt FxPkgIo 0xFFFFF980022AEE50 : WDF INTERNAL
dt FxIoQueue 0xFFFFF98002376C60 : WDFQUEUE 0x0000067ffdc89398
dt FxIoQueue 0xFFFFF98002380C60 : WDFQUEUE 0x0000067ffdc7f398
dt FxPkgFdo 0xFFFFF98002222BA0 : WDF INTERNAL
dt FxCmResList 0xFFFFF9800234EF50 : WDFCMRESLIST 0x0000067ffdcb10a8
dt FxCmResList 0xFFFFF98002356F50 : WDFCMRESLIST 0x0000067ffdca90a8
dt FxChildList 0xFFFFF98002268E70 : WDFCHILDLIST 0x0000067ffdd97188
dt FxChildList 0xFFFFF98002274E40 : WDFCHILDLIST 0x0000067ffdd8b1b8 Context fffff98002274fd0
dt FxIoTarget 0xFFFFF98002372EA0 : WDFIOTARGET 0x0000067ffdc8d158
dt FxWmiProvider 0xFFFFF980023B2F10 : WDFWMIPROVIDER 0x0000067ffdc4d0e8
dt FxWmiInstanceExternal 0xFFFFF980023BE : WDFWMIINSTANCE 0x0000067ffdc410c8
dt FxWmiProvider 0xFFFFF9800239CF10 : WDFWMIPROVIDER 0x0000067ffdc630e8
dt FxWmiInstanceExternal 0xFFFFF980023C6 : WDFWMIINSTANCE 0x0000067ffdc390c8
dt FxWmiProvider 0xFFFFF980023D2F10 : WDFWMIPROVIDER 0x0000067ffdc2d0e8
dt FxWmiInstanceExternal 0xFFFFF9800238A : WDFWMIINSTANCE 0x0000067ffdc750c8

No handles.

WDF Verifier settings for virtualstorage.sys is ON
Pool tracking is ON
Handle verification is ON
IO verification is ON
Lock verification is ON
Handle reference tracking is OFF

3: kd> .chain
Extension DLL search Path:
C:\Debuggers\WINXP;C:\Debuggers\winext;C:\Debuggers\winext\arcade;C:\Debuggers\pri;C:\Debuggers;C:\Debuggers\winext\arcade;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\PROGRA~1\CA\SHARED~1\SCANEN~1;C:\Program Files\CA\eTrust Antivirus;C:\Program Files (x86)\Microsoft SQL Server\90\Tools\binn;C:\Program Files\Microsoft Driver Test Manager\Controller\
Extension DLL chain:
d:\winddk\6000\bin\amd64\wdfkd.dll: image 6.0.6000.16386, API 1.0.0, built Thu Nov 02 02:42:30 2006
[path: d:\winddk\6000\bin\amd64\wdfkd.dll]
dbghelp: image 6.7.0001.0, API 6.0.6, built Thu Sep 14 15:08:48 2006
[path: C:\Debuggers\dbghelp.dll]
ext: image 6.7.0001.0, API 1.0.0, built Thu Sep 14 15:08:19 2006
[path: C:\Debuggers\winext\ext.dll]
exts: image 6.7.0001.0, API 1.0.0, built Thu Sep 14 15:08:08 2006
[path: C:\Debuggers\WINXP\exts.dll]
kext: image 6.7.0001.0, API 1.0.0, built Thu Sep 14 15:08:13 2006
[path: C:\Debuggers\winext\kext.dll]
kdexts: image 6.0.5720.0, API 1.0.0, built Thu Sep 14 15:19:48 2006
[path: C:\Debuggers\WINXP\kdexts.dll]

18

Greg-

Doron PM’d me he’ll be in meetings all day. So it looks like me or nothing…

Could you please either email me directly or post the output of

dt FxDriverGlobals

dc ?

Should at least put the extension in or out of the suspect state...

Thanks,
Bob Kjelgaard
19

Bob,
I think I am doing something wrong, but I don’t know enough to tell what it
is. I have been doing embedded development for 17 years (that is scary),
but my NT debug skills are rusty. I believe that I have not enabled the
KMDF verifier properly, but not sure what I missed.

kd> dt _FX_DRIVER_GLOBALS 0x84e767b0
+0x000 Linkage : _LIST_ENTRY [0xf366ee10 - 0xf366ee10]
+0x008 WdfHandleMask : 0xfffffff8
+0x00c WdfVerifierAllocateFailCount : -1
+0x010 Tag : 0x6f6944
+0x014 Driver : 0x85163af0 FxDriver
+0x018 DebugExtension : (null)
+0x01c LibraryGlobals : 0xf366ecb8 FxLibraryGlobalsType
+0x020 WdfTraceDelayTime : 0
+0x024 WdfLogHeader : 0x84e12000
+0x028 FxPoolFrameworks : FX_POOL
+0x07c FxPoolTrackingOn : 0 ‘’
+0x080 ThreadTableLock : 0
+0x084 ThreadTable : (null)
+0x088 WdfBindInfo : 0xf78822c0 _WDF_BIND_INFO
+0x08c ImageAddress : 0xf787f000
+0x090 ImageSize : 0x5000
+0x094 FxVerifierOn : 0 ‘’
+0x095 FxVerifierDbgBreakOnError : 0 ‘’
+0x096 FxVerifierHandle : 0 ‘’
+0x097 FxVerifierIO : 0 ‘’
+0x098 FxVerifierLock : 0 ‘’
+0x099 FxVerifyOn : 0 ‘’
+0x09a FxVerboseOn : 0 ‘’
+0x09b FxForceLogsInMiniDump : 0 ‘’
+0x09c BugCheckCallbackRecord : _KBUGCHECK_REASON_CALLBACK_RECORD
+0x0b8 Public : _WDF_DRIVER_GLOBALS

kd> dc 0x84e767b0
84e767b0 f366ee10 f366ee10 fffffff8 ffffffff …f…f…
84e767c0 006f6944 85163af0 00000000 f366ecb8 Dio…:…f.
84e767d0 00000000 84e12000 00000000 84e767dc … …g…
84e767e0 84e767dc 00000001 00000000 00000000 .g…
84e767f0 00040001 00000000 84e767f8 84e767f8 …g…g…
84e76800 00000000 84e76804 84e76804 00000000 …h…h…
84e76810 00000000 00000000 00000000 00000000 …
84e76820 00000000 00000000 00000000 00000000 …

“Bob Kjelgaard” wrote in message
news:xxxxx@ntdev…
Greg-

Doron PM’d me he’ll be in meetings all day. So it looks like me or
nothing…

Could you please either email me directly or post the output of

dt FxDriverGlobals output, as well as
dc ?

Should at least put the extension in or out of the suspect state…

Thanks,
Bob Kjelgaard

20

No need to worry about flames for doing something wrong here [unless I get the idea you’re doing something totally unsafe, and won’t listen to advice]. Stuff happens, even with the best devs [even if it didn’t, I’ve plenty of bonehead moves of my own to recall].

For instance, I should have asked for the next 128 bytes of the dc dump (forgot to check the structure size), but I don’t think that’s necessary. I’m sure it’s not the extension nor a build issue from what’s already here.

The path is pretty short from here (these commands will work assuming you have symbols for your driver), so I’ll add more detail than you may need:

kd> sxeld wdfdio.sys
_kd> g

Then disable/enable the device from device manager (or reboot if your driver can’t be unloaded). The debugger will break when your driver is loaded, but before it calls any code in it.

kd> bp wdfdio!DriverEntry
kd> g < this should then break at your DriverEntry>
kd> dv

The second parameter is a Unicode string the debugger should resolve for you- the name of the service key for the driver. Just keep it handy.

kd> sxdld wdfdio.sys (unless you really want a break every time you load it with the debugger attached).
kd> g

Then open up regedit, look for that key name- it should have a Parameters/Wdf subkey (it should be the one you already edited). That subkey should have a keyword named VerifierOn [spelling matters, but not case], which is a DWORD, and has a non-zero value.

If that’s there, then something heretofore unseen has failed in WdfDriverCreate- you DID pass the Registry path you received in DriverEntry on to that, correct?

Let’s see where that all leads for now- there aren’t [as far as I can recall] that many more places [if any] something can both let your driver load, but simultaneously miss that setting. So presumably we then switch to the bottom edge of the framework and start looking at the Registry calls.

PS if you don’t have symbols for your driver, that’s OK by me, too. I can give you a separate set of instructions for that situation.

To allude to the hot debate of the day, I lived in SoftIce most of the time I was an independent- I just never used symbols. Didn’t have them when I began debugging at the machine level (I think Jobs and Wozniak were still working out of the garage bout that time), and never really used them until recently [must admit they usually do save time]. But I do have what was once a new monitor it destroyed when its display driver made an apparently invalid mode switch on a Sony Vaio 9x box still acting as a paper weight somewhere in my apartment…_