Validating WDF Object Handle? Retrieving Type?

I’ve been spending time looking at Custom WDF Object Types and Framework Class Extensions recently.

It’s all good, except for one striking omission: There does not seem to be any way to:

  • Validate that a given Handle is, in fact, a valid WDF Object Handle
  • Determine the type of a WDF Object given its handle… or alternatively, validate that a given handle is associated with a specific Object type

I will be the first to admit that it’s taken me 15 years to discover this “deficiency” – But we’ve only been able to write Class Extensions since Windows 8. And that’s what most particularly drives this need.

One would have thought that, when adding support for creating Custom WDF Object Types (which are basically just child objects of another WDF Object Type), the WDF devs would have taken inspiration from ObReferenceObjectByHandle. Which is basically exactly what I want.

What’s the established programming pattern here? Am I missing something really obvious?

Peter

Let me also note that the inability to universally retrieve the parent Object handle is also… very inconvenient.

I’ve got a WDFDMAENABLER, for example. How am I supposed to get the WDFDEVICE with which it’s associated? If we’re playing at the level of a Class Extension, we’re not really in a position to “stuff it in a Context” when the WDFDMAENABLER is created and then retrieve that Cotnext later.

Peter

There is some hackery possible. A WDF handle is the negative of the underlying framework object. So, if the value is negative in KMDF, then it can’t be a WDF handle. A human being could look at the negation of the handle and judge whether it is a kernel address, but it’s harder to have a computer do that.

The first two bytes of every WDF object happen to be an object type code, from fxtypes.h. That’s all internal, but it does mean KMDF has enough knowledge to tell you what the device is.