Windows Driver Foundation Facts

"The whole PnP/Power Management interface is so convoluted, it is hard even to teach it."

"Two words: Power Management. ...could you have made that any more painful? PnP is at least fathomable..."

"Power management is overly complicated, with too many sub states."

"I ultimately got IRP cancellation right, after starting with a buggy DDK/Knowledge Base sample."

"Too much boilerplate code that should be carried from one driver to another."

"Lacking information for synchronization issues between PnP and Power Management events."

"I thought that the IRP cancellation was the only area that was tough. But with WDM, power management and PnP got 'glued' onto the side of the interface."

"If something doesn't work, it's very difficult to diagnose what's wrong."

"New developers face a very steep learning curve."

"Time is of the essence - but reliability is a major plus."

PnP (22%) - Needs 3000+ lines of boilerplate code.
There is no synchronization support available with I/O.

Power (20%) - Handling all the power states is complicated.
Very difficult to get wait wake / selective suspend right.

IRP cancellation (17%) - I/O cancellation logic involves several race conditions and is very difficult to get right.

Concurrency and race conditions (especially for PnP / Cancellation / I/O).

50% of driver developers claim that existing WDM driver models are complicated.

70% percent say they want a newer model.

70% want a user-mode driver framework.

Kernel-mode framework and user-mode framework to support most device needs.

Static tools such as SDV and PFD for automatic discovery of bugs.

Built-in diagnostics and verification.

Debugger extensions.

Versioning allows multiple versions of frameworks to exist side by side.

Complicated boilerplate code is no longer required for handling PnP and Power IRPs.

Framework provides default processing and correct behavior for PnP and Power IRPs.

Framework provides state-of-the-art power management, with built-in support for run-time idle and waking the machine.

Synchronization model to address concurrency issues for asynchronous events - work items, DPC, timers, cancellation of I/O requests.

Driver-to-driver communication is simplified using I/O targets.

No worries about synchronizing PnP IRPs with I/O IRPs or synchronizing with your DPC for ISRs.

Queues are synchronized with PnP and power implementation.

Three different models to control concurrency of requests delivered to the driver: sequential, parallel, and manual.

Cancellation of requests is built into the framework. In most cases, developers will not have to worry about providing cancellation support in their drivers.

Allows optional serialization of I/O event callbacks invoked during I/O processing.