Why must the parent of a WDFWORKITEM be a device?

NTDEV
1

The documentation for WdfCreateWorkItem includes the following

When the driver creates a work-item object, it must specify a parent object for the work-item object in the ParentObject member of the WDF_OBJECT_ATTRIBUTES structure. The parent object must be a framework device object or any object whose chain of parents leads to a framework device object. The framework will delete the work-item object when it deletes the device object.

I can see why having no parent at all would be bad for memory leakage, but why insist on a device object? What would be the problem with allowing a driver object?

I did try “attributes.ParentObject = WdfGetDriver();” just in case it would work but got STATUS_INVALID_DEVICE_REQUEST ftrom WdfCreateWorkItem.

To forstall the inevitable “Why do you want to do this?” question. I would like to log errors at the place they occur, which is sometimes in code running at Dispatch level. Some of the event logging routines use routines like RtlAnsiStringToUnicodeString, which must be called at passive level. The idea is to detect the IRQL and, if it is above passive, hand off the event log request to a worker thread. Unfortunately, at that point I don’t have a convenient device to give as a parent.

Any suggestions?

Thanks
Don

2

This is a restriction that WDM creates, not KMDF. See the docs for IoAllocateWorkItem, http://msdn2.microsoft.com/en-us/library/aa490569.aspx.

This begs the question on why you have a DPC running around with it being tied to a WDFDEVICE somewhere up the chain. This might be a feasible design (although I still have doubts as to why you can’t definitively know the WDFDEVICE that the DPC belongs to) if this is an NT4 legacy style driver which creates control devices. If so, just create a global unnamed control device that sits in a global somewhere and queue work items against it.

d

3

>

This is a restriction that WDM creates, not KMDF. See the
docs for IoAllocateWorkItem, http://msdn2.microsoft.com/en-us/library/aa490569.aspx.

I’ll look at that. … Ah, I see.

This begs the question on why you have a DPC running around
with it being tied to a WDFDEVICE somewhere up the chain.
This might be a feasible design (although I still have doubts
as to why you can’t definitively know the WDFDEVICE that the
DPC belongs to)

I just want to post an event log message and, because some of the
routines used to format the message have to run at passive, I need to hand
the request off if running at too high an IRQL. The messages aren’t
device specific so I use the driver object, rather than the device object
in IoAllocateErrorLogEntry.

It isn’t really a matter of not definitively knowing, more a matter of
not needing the device and thus, not passing it down to the error logging
routines.

if this is an NT4 legacy style driver which
creates control devices. If so, just create a global
unnamed control device that sits in a global somewhere and
queue work items against it.

It’s not a legacy driver. It’s several KMDF filters plus KMDF function drivers
all of which use the same event logging interface.

In the end, I’ve decided to partition the calls into two. Those that might
be above passive - when I always have a device around to hang the DPC on -
and those with no device (which must be running at passive). As an example of
the latter, consider how to log a device create failure. But since the code
creating new devices must be running at passive, I can use my (deviceless)
interface to report the error because it will never need to defer the request.

Thanks for your advice.

Don

4

> I can see why having no parent at all would be bad for memory leakage, but
why

insist on a device object?

I think this is because IoAllocateWorkItem is used to implement the WDF work
items.

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