Post on 18-Jan-2016
transcript
How to Develop a KMDF Driver
OutlineOutline
WDF Object modelDDI OrganizationObject context memoryObject lifetime
WDF Request Flow Through the DriverRequest processing StagesWDFQUEUEsRequest forwarding and ServicingCancellationPower management and I/O
PNP and Power managementDirection we want to go inA brief design overview
WMIWDFIOTARGET
In stack Opened by nameUSB
Windows Driver Foundation- ExperienceWindows Driver Foundation- Experience
Windows Driver Foundation Object ModelWindows Driver Foundation Object Model
Expresses WDF concepts and DDIs within an object model
Defines a uniform set of behaviors for all objects
Scales from simple to complex abstractions
Isolates internal implementation details
Uses object concepts familiar to WDM driver developers
Windows Driver Foundation Object ModelWindows Driver Foundation Object Model
Objects are the basis of WDFRepresent drivers, devices, queues, etc.
Have properties, methods, and events
Provide a driver-configurable context memory
Are reference counted
Organized hierarchically (parent/child relationship)Hierarchy allows for automatic destruction of objects
Referenced by handles, not pointers
Interacting with WDF ObjectsInteracting with WDF Objects
The driver interacts with WDF objects through the DDIs
Driver actionsCreates objects it requires
Defines callback routines to handle events for each object
Defines type and allocation of any context memory
Invokes DDIs on an object in response to events
WDF actions:Manages reference counts for objects
Manages object parent/child relationships
Calls driver-defined callback routines when events occur
Takes default action when driver does not specify a callbackWDF does the right things by default without any work by the driver
Object DDIsObject DDIs
PropertiesReplace direct field access
Get and Set Values
“Can’t fail”, have no status return
MethodsPerform operations on the object
Have optional return status
EventsNotify the driver of state changes
C functions registered by the driver
Invoked by WDF when event occurs
DDI ConventionsDDI Conventions
All references to WDF objects are through handles
Handle is the first parameter to each WDF DDI
Property naming convention:Wdf<ObjectType>Get
Wdf<ObjectType>SetExample: WdfDeviceGetDriver(WDFDEVICE Device)
Method naming convention:Wdf<ObjectType><Operation>
Example: WdfObjectDelete(WDFOBJECT Object)
Event naming convention:Evt<ObjectType><Event>
Example: EvtObjectCleanup(WDFOBJECT)
Provides storage for a driver’s object-specific information
Similar to a device extension
Can be associated with any WDF object
Allocated from non-paged pool in driver-supplied size and type
Exists for the lifetime of the WDF object
WDF frees the memory when the object is destroyed
Macros assist in defining the type from a standard C structure
Accessed through pointer retrieved through the object handle
Object’s can have more than one context, if the types differ
Optional callbacks assigned per contextEach context can be hooked into the destruction of an object
EvtObjectCleanup and EvtObjectDestroy: described later
Object Context MemoryObject Context Memory
Object LifetimeObject Lifetime
WDF objects are reference counted
WDF maintains a reference on an object until it is deleted
Driver typically does not have to maintain references
BUT driver may extend an object’s lifetime by taking its own reference:
VOID WdfObjectReference(WDFOBJECT Object)
VOID WdfObjectDereference(WDFOBJECT Object)
Calls to WdfObjectReference and WdfObjectDereference must be balanced to prevent object leaks
Object Lifetime EventsObject Lifetime Events
EvtObjectCleanup event Invoked when an object is being deleted
Object may still have references
Similar to IRP_MJ_CLEANUP
Drivers should release any references added upon this notification
Used to resolve circular references
EvtObjectDestroy eventInvoked when object reference count goes to zero
Handle and any associated context memoryare destroyed
Similar to IRP_MJ_CLOSE
Object ParentingObject Parenting
Parent/child relationships established atobject creation
Parent holds reference count on each child
When the parent object is deleted, the child objects are deleted automatically
Child objects are deleted, then the parent
Some objects have pre-defined parents
AdvantagesHelps to automate object cleanup for the device driver
Failures in initialization paths, such as EvtDriverDeviceAdd, automatically release any objects associated with the WDFDEVICE
Core Windows Driver Foundation ObjectsCore Windows Driver Foundation Objects
Unique types are defined for each WDF object handle
Core objects common across most driversWDFDRIVER
WDFDEVICE
WDFQUEUE
WDFREQUEST
Some additional utility object examplesWDFDPC
WDFWORKITEM
WDFTIMER
WDFDMAENABLER
WDFIOTARGET
WDFWMIDATABLOCK
WDFMEMORY
WDF Request FlowWDF Request Flow
IRP Dispatcher Pnp/Power Package
I/O Package
Read/Write/Ioctls/
Create/Close/Cleanup
WMI Package
Hardware Resource
Management
(DMA, Interrupt, I/O)
Parallel Queue
Sequential Queue
Manual Queue
IoTarget
WDFREQUEST
Next Driver
Pnp/Power Events
Pnp/Power Events
IRP
Next Driver
Driver
Request ProcessingRequest Processing
When a request arrives from WDM, it is dispatched for action:
PnP/Power package Handles PnP and power requests
Notifies other packages of status changes
Windows Management Instrumentation (WMI) packageHandles WMI requests, including event tracing
I/O packageHandles most I/O requests
I/O targetIssues requests to another driver
Request Processing (con’t)Request Processing (con’t)
Each package operates on the request by one or more of the following:
Raising events to the driver
Forwarding the request to another package or I/O target for further processing
Completing the request based on its own action
Completing the request as a result of a driver API call
If the request has not been processed when it reaches the end of frameworks processing:
Filter drivers forward the request to the next lower driver automatically
Other drivers complete the request with STATUS_INVALID_DEVICE_REQUEST
IRP Dispatcher Pnp/Power Package
I/O Package
Read/Write/Ioctls/
Create/Close/Cleanup
WMI Package
Hardware Resource
Management
(DMA, Interrupt, I/O)
Parallel Queue
Sequential Queue
Manual Queue
IoTarget
WDFREQUEST
Next Driver
Pnp/Power Events
Pnp/Power Events
IRP
I/O ProcessingI/O Processing
Pnp/Power Events
Pnp/Power/WMI IRPs
I/O ProcessingI/O Processing
Arriving requests are sorted into WDFQUEUEs
WDFQUEUEs present requests to the driver
Processes two categories of I/O requestsOpen, cleanup and close
Read, write, and device I/O control
Interacts with the PnP/Power packageReceive notification of
Device removal
System and device power state
Surprise removal
Respond to queries based on current I/O operations outstanding
Interacts with operating system’s I/O cancellation model
Create, Cleanup, Close HandlingCreate, Cleanup, Close Handling
IRP_MJ_CREATE, IRP_MJ_CLOSE, and IRP_MJ_CLEANUP requests generate events
EvtDeviceFileCreate
EvtDeviceFileClose
EvtDeviceFileCleanup
If no callback is registeredAllows CREATE by default
Automatically handles CLEANUP and CLOSE
CREATE requests result in creation of a WDFFILEOBJECT object
Driver can configure an exclusive open policy and let the framework handle it
Request ObjectRequest Object
WDFREQUEST is the WDF representation of an IRP
Presented by WDF to the driver as the result of an I/O request
Can also be created by the driver and presented to WDF to send I/O to another driver
Object properties represent IRP fields
As with all WDF objectsHas a reference count
Allows driver context memory
Automatically frees child resources on completionSuch as associated memory buffers or MDLs
WDFQUEUE ObjectWDFQUEUE Object
Presents requests from WDF to the device driver
Operates as an I/O adapter Enqueues and dequeues requests
Controls the concurrency of requests presented to the driver
Allows processing to pause and resume
Supports request cancellation and cancel-safe queues
Synchronizes I/O operations with PnP/Power state transitions
Reports outstanding I/O operations to PnP/Power stage
Optionally serializes event callbacks
Defers event callbacks to comply with PASSIVE_LEVEL constraints
Tracks “in-flight” requests currently being serviced by the driver
More than just a list of pending requests!
WDFQUEUE EventsWDFQUEUE Events
WDFQUEUE objects use callbacks to notify driver of WDFREQUEST events
EvtIoRead – Called for IRP_MJ_READ requests
EvtIoWrite – Called for IRP_MJ_WRITE requests
EvtIoDeviceControl – Called for IRP_MJ_DEVICE_CONTROL requests
EvtIoDeviceControlInternal – Called for IRP_MJ_INTERNAL_DEVICE_CONTROL requests
EvtIoStop – Called when a power state change has been requested
EvtIoDefault – Called for any request that does not have a specific callback registered
EvtRequestCancel – Called when a specific WDFREQUEST is cancelled
Mapping of Requests to QueuesMapping of Requests to Queues
A driver typically creates multiple queues for different request characteristics
Power management options
Number of requests serviced at a given time
Hardware resource mapping
The driver controls which requests go to which queue
WDF can automatically forward specific requests to a WDFQUEUE with WdfDeviceConfigureRequestDispatching
Driver can receive requests on one WDFQUEUE and manually forward them to another with WdfRequestForwardToIoQueue
WDFQUEUE Concurrency ControlWDFQUEUE Concurrency Control
“In-flight” requestsRequests that a driver has received from a WDFQUEUE but has not yet completed
Driver can control the concurrency of “in-flight” requests
WDFQUEUE supports three request concurrency models:
Sequential - single request model Similar to current Start I/O model
New requests are not delivered until the previous request is completed
Parallel model - any number of requests may be active at once
Manual model - driver retrieves requests at its own pace
A driver can create multiple WDFQUEUES of different types to sort requests based on the device’s concurrency model
Request Cancellation And SuspensionRequest Cancellation And Suspension
The operating system may request that the driver stop processing an “in-flight” request
WDM I/O cancellation from thread/process exit, or cancel API
System PnP/Power events such as hibernation
Device removal
In some cases the system wants the request Cancelled, or completed with an error code
In other cases the system wants request processing to temporarily pause, or Suspend
Driver will be notified later to resume processing
Framework Handling of Request Framework Handling of Request Cancellation And SuspensionCancellation And Suspension
Requests that have not been delivered to the driver (still in queue) can be canceled or suspended automatically
Any request received by the framework and not yet delivered to the driver is automatically cancelable
Request will be completed by the framework on WDM I/O cancellation
Requests received by the framework and not yet delivered to the device driver can affect the power state of the device
Framework can automatically restore device power before delivering the request to the driver
Framework can automatically stop/start the queue in response to PnP/Power events
Configurable based on power policy
Driver’s Responsibility For Request Driver’s Responsibility For Request CancellationCancellation
To avoid race conditions, “in-flight” requests cannot be cancelled unless explicitly made cancelable by the driver
A request should be made cancelable by the driver if:
The request involves a long term operation
The request might never succeed (such as waiting for asynchronous input)
The driver makes a request cancelable by calling WdfRequestMarkCancelable
When a request is cancelled:The framework invokes EvtRequestCancel to notify the driver
The driver must eventually complete the request
WDFQUEUE Power ManagementWDFQUEUE Power Management
Power management of WDFQUEUEs Enabled by default
Configurable on a per WDFQUEUE basis
Advantages of power-managed queuesNotify PnP/Power package of arriving I/O requests so that device power can be automatically restored
Notify PnP/Power package of empty queue so that device can be powered down through its idle timer
Notify driver of power-state changes for “in-flight” requests through the EvtIoStop callback
A driver can use both power-managed and non-power managed queues
Sort requests based on requirements for its power model
Driver’s Responsibility For Request Driver’s Responsibility For Request SuspensionSuspension
Requests may be suspended due to:A system suspend power event
A system hibernation power event
In-flight requests are notified of power state transitions by the EvtIoStop event callback for their WDFQUEUE
Ignoring EvtIoStop events delays the power state transition until all in-flight I/O requests are complete
Drivers should handle EvtIoStop events forLong-running requests
Requests that might not complete, such as asynchronous input
Handling EvtIoStop provides a good user experience for laptops and other power-managed systems
System logs which devices delay power state transitions
Request Suspension (con’t)Request Suspension (con’t)
A driver can respond to an EvtIoStop event by:Completing the request
Re-queuing the request
Acknowledging the event but continuing to hold the request
Ignoring the stop event if the current request will complete in a timely manner
Some EvtIoStop events require the driver to complete the request immediately
Device removal or surprise removal request
Signaled by WDF_REQUEST_STOP_ACTION_FLAGS
Driver Control of WDFQUEUEsDriver Control of WDFQUEUEs
WDFQUEUEs may pause and resume the delivery of requests in response to
Power state changes, based on power policy
Driver API calls such as WdfIoQueueStop
Both the driver and power management must allow processing for requests to be delivered
Requests sent while a WDFQUEUE is paused will be delivered when the queue resumes
Synchronization of WDFQUEUE EventsSynchronization of WDFQUEUE Events
Outstanding I/O request synchronizationI/O requests received from a WDFQUEUE are asynchronous
Requests may be completed within an event callback or after return from it
Driver controls number of concurrent I/O operations through WDFQUEUE request concurrency type
Parallel
Sequential
Manual (driver control)
Constraints on concurrent execution of event callbacksSet in WDF_OBJECT_ATTRIBUTES
Control the number of simultaneously executing event callbacks, not actual I/O operations
Help manage access to shared data in the WDFQUEUE context memory
Callbacks can have PASSIVE_LEVEL constraintWDFQUEUE automatically invokes the callback from a system work item if required
So you don’t have to worry if an upper level driver calls you at DISPATCH_LEVEL
IRP Dispatcher
I/O Package
Read/Write/Ioctls/
Create/Close/Cleanup
WMI Package
Hardware Resource
Management
(DMA, Interrupt, I/O)
Parallel Queue
Sequential Queue
Manual Queue
IoTarget
WDFREQUEST
Next Driver
Pnp/Power Events
Pnp/Power Events
IRP
I/O ProcessingI/O Processing
Pnp/Power Events
Pnp/Power/WMI IRPs
Pnp/Power Package
Motivation for a Deeper Abstraction Motivation for a Deeper Abstraction Around PnP and Power ManagementAround PnP and Power Management
WDM drivers are too complicated
PnP and Power are separate and unsynchronized concepts
Learning all the rules in the DDK takes yearsThere are lots of rules that aren’t easy to find in the DDK
What are all the rules? I keep on finding them!
Complexity takes time to fully testBugs remain in even the most mature code
Most drivers go through many revisions
The fear of unknown side effects makes forward progress difficult
Rules + LOC + Test = a minimal implementation
Motivation for a Deeper Abstraction Motivation for a Deeper Abstraction Around PnP and Power ManagementAround PnP and Power Management
WDM drivers have thousands of lines of code for PnP/PM
Code is required for all IRPs, even if the device doesn’t implement them
A lot of boilerplate code must be added before you can get started
Few understand the boilerplate code
Modifying it is very difficult due to unknown side affects
The code distracts from what is really going on in the driver
Advanced functions and practices were left to drivers and not encapsulated in the OS layer
Partly because the burden on driver writers wasn’t well understood
Motivation For A Deeper Abstraction Motivation For A Deeper Abstraction Around PnP and Power ManagementAround PnP and Power Management
A minimal implementation is not a “good citizen” as defined by the OS
Everybody is sensitive to time-to-market“Good citizenship” involves too many things
Support PnPSupport “Removal” to enable upgrade without a reboot, hot-plugSupport “Surprise Removal” to allow a user to yank a plugSupport “Rebalance” to enable other devices to be hot-plugged
Support Power ManagementSupport S-state IRPs to allow the system to go to sleepConvert them to D-state IRPs to ensure that your device context is preservedSupport “Fast Resume” so that the system will be usable more quickly
Aggressive Power ManagementSupport Wait/WakeSupport idle-time power management to save power while the system is running
WDF Design Goals for PnP/PMWDF Design Goals for PnP/PM
Remove as much boilerplate as possible
Allow driver to provide callbacks only for events that are “interesting”
Automatically provide good default PnP behaviorRebalance
Removal
Surprise Removal
Automatically provide good default power behaviorSupport Sleep, Hibernate
Support “Fast Resume”
Support idle-time power management
Provide clear error-handling pathsSome software errors automatically handled
Some hardware errors handled by resetting the device
WDF Design Goals for PnP/PMWDF Design Goals for PnP/PM
Call all PnP/Power-related driver callbacks at PASSIVE_LEVEL, even for non power pageable stacks
Reduce the size of the code in a driverThe code that is there is the essence of your driver
Make all PnP and PM transitions consistentThis makes it possible to test all of the PnP/PM code in a driver
Remove the need for a driver to track stateNo need to keep a history of PnP/Power IRPs
No need to guess what action is necessary based on target system state
Manage device handle lifetime
Make ordering guarantees
Allow a driver to interact directly with WDM, if necessaryInteracting with WDM unnecessary in the common case
Integration of PnP and PowerIntegration of PnP and Power
WDF treats PnP and Power as a unified modelYou can’t turn a device on if you don’t know how to configure it
You can’t configure a device if you don’t know how to turn it on
Most PnP operations also involve turning the device on or off
WDM PnP operations modeled as a series of primitive operations
WDF callbacks are based around primitive operationsMost are neither wholly power or wholly PnP
Each primitive is a callback
Nearly all callbacks perform one particular operation
WDF is internally implemented as a set of interlocking state machines
PnP and Power IRPs cause state machines to start passing events back and forth
PnP and Power PrimitivesPnP and Power Primitives
Primitive software operations correspond to device hardware actionsPrimitives involve very few (or no) choices
Result in straight-line code They don’t require tracking of state history
Every primitive is optionalWhen implemented, they augment WDF behavior
They tend to be small and very focusedCauses callback proliferationResulting callbacks are simple and maintainable
They tend to have fairly simple rules associated with them
For every “Do” primitive, there is an “Undo” primitive
Order in which the primitives are called is guaranteedFrom bottom to top when powering upFrom top to bottom when powering down (exact reverse of power up)
Power Up CallbacksPower Up Callbacks
EvtDevicePrepareHardwareOne time initialization, first callback where device is in D0
Map in memory mapped I/O, inspect hw for revision, features, etc.
EvtDeviceD0EntryBring the device into D0, no interrupts connected
EvtInterruptEnable (at DIRQL)Enable interrupt generation in the hardware
EvtDeviceD0EntryPostInterruptsEnableFurther D0 initialization if it requires a connected interrupt
DMAEvtDmaEnablerFill
EvtDmaEnablerEnable
EvtDmaEnablerSelfManagedIoStart
Power managed queues are started
Self managed IO, EvtDeviceSelfManagedIoInit or Restart Miscellaneous catchall: start watch dog timers, async HW operations
WDM Actions Versus WDF ActionsWDM Actions Versus WDF Actions
IRP_MN_START_DEVICEProcess new hardware resources, except if you don’t use them
Map hardware, except if it’s already mapped
Put your device in D0, except if it’s already there
Connect interrupt, except if it’s already connected
Start asynchronous hardware operations, except if they were already started
etc.
EvtDevicePrepareHardwareProcess new hardware resources
Map your hardware
EvtDeviceD0EntryPut your device in D0
EvtInterruptEnableProgram your hardware toenable interrupts
EvtDeviceSelfManagedIoInitStart asynchronoushardware operations
Power Down CallbacksPower Down Callbacks
EvtDeviceSelfManagedIoSuspendMiscellaneous catch all: stop watch dog timers, async hw operations
Power managed queues are stopped
DMAEvtDmaEnablerSelfManagedIoStop
EvtDmaEnablerDisable
EvtDmaEnablerFlush
EvtDeviceD0ExitPreInterruptsDisableMove the device into Dx, if it requires a connected interrupt
EvtInterruptDisable (at DIRQL)Disable interrupt generation in the HW
EvtDeviceD0ExitMove the device into Dx, no interrupts connected
EvtDeviceReleaseHardwareOne time deinitialization, called when the device is in Dx!
Unmap in memory mapped I/O, etc.
Power Policy OwnershipPower Policy Ownership
Something has to decide what level of power (D-state) is appropriate for a device
That decision isn’t centralized in the kernel
It depends on the usage model for the device
It should be centralized somewhere
Probably in the driver that controls the hardware (FDO)
WDF provides a rich set of automatic behaviors
Device to low-power when the system goes to sleep/hibernate
Device to low-power when the device is idle
Device to high-power when there are requests to process
Automatic arming for wake while the system is running(device is idle)
Automatic arming for wake while the system is sleeping
Enabling UI in device manager to control wake behaviors
WDF implements correct parent/child power policy interaction
If a parent and child are powered down and the child needs to power up, WDF will automatically bring the parent into fully power
Bus Drivers Are Trivial To WriteBus Drivers Are Trivial To Write
WDF can handle most of the detailsReporting children to WDM
Coordinating scanning for children
Maintaining the list of children
WDF has two models for bus enumerationStatic: child device status rarely, if ever, changes
Dynamic: child device status is expected to change at any time
Drivers responsible forIdentifying children
Generating IDs
Generating resource requirementsWDF encapsulates reporting of resource requirements in a much easier to use interface
Identifying capabilities
Notification back to WDF that children have been removed
IRP Dispatcher
I/O Package
Read/Write/Ioctls/
Create/Close/Cleanup
WMI Package
Hardware Resource
Management
(DMA, Interrupt, I/O)
Parallel Queue
Sequential Queue
Manual Queue
IoTarget
WDFREQUEST
Next Driver
Pnp/Power Events
Pnp/Power Events
IRP
WMIWMI
Pnp/Power Events
Pnp/Power/WMI IRPs
Pnp/Power Package
Windows Management Interface (WMI)Windows Management Interface (WMI)
WDF fully handles IRP_MJ_SYSTEM_CONTROL
WMI usage patternRegister providers and instances upon device arrival
Fire events when necessary
Report statistics
Update state
Unregister upon device removal (graceful or surprise remove)
WDF takes care of most of this for youYou still have to fire events and implement instance callbacks
In WDM, using wmilib.sys allowed for a static registration easily, but made dynamic registration difficult
In WDF, both static and dynamic registration of providers and instances is very easy to do
Also support for kernel mode ETW / Tracing
WMI ObjectsWMI Objects
WDFWMIPROVIDERThis schema for the data being reported
GUID from the MOF
Properties of the data (expensive, event only, tracing)
Contains N number of WDFWMIINSTANCEs
Once created, cannot be manually deletedAutomatically deleted when the parent WDFDEVICE is
Has callbacks for enable and disable of event collection
WDFWMIINSTANCEInstance of a WDFWMIPROVIDER
Can be deleted after creation at any time
Can be added or deleted at IRQL <= DISPATCH_LEVEL
Can use its context as a source for read only dataThis allows for very easy data collection with minimal effort
Callbacks are not synchronized to PnP/PM state
IRP Dispatcher
I/O Package
Read/Write/Ioctls/
Create/Close/Cleanup
WMI Package
Hardware Resource
Management
(DMA, Interrupt, I/O)
Parallel Queue
Sequential Queue
Manual Queue
IoTarget
WDFREQUEST
Next Driver
Pnp/Power Events
Pnp/Power Events
IRP
I/O TargetsI/O Targets
Pnp/Power Events
Pnp/Power/WMI IRPs
Pnp/Power Package
WDFIOTARGETWDFIOTARGET
A WDFIOTARGET is a WDF object which encapsulates Opening a device object or stack by name
Formatting a request to send to the target
Calling IoCallDriver in coordination with PnP state of the target owner and the target state itself
Synchronization of sent I/O with target state changes
A WDFIOTARGET uses WDF object reference counting to guard against freeing of resources while a WDFREQUEST is pending
WDFREQUEST FormattingWDFREQUEST Formatting
It is a WDF design goal to allow the driver to send I/O without needing to know the underlying memory description
This also applies to incoming I/O
The WDFIOTARGET will format the WDFREQUEST based on the request type
Convert a provided PVOID to an PMDL
Retrieve a buffer from a provided PMDL
When using a WDFMEMORY, the target will reference the WDFMEMORY for the duration of the format, which is bound by either
A reformat before sending the WDFREQUEST
The WDFREQUEST completion
WDFREQUEST FormattingWDFREQUEST Formatting
A WDFMEMORY can be retrieved from a WDFREQUEST and then used in a subsequent format
The WDFMEMORY is based on the current stack location
It is a snapshot of the underlying IRP values before formatting the next stack location
The underlying IRP fields will be restored when the I/O has completed back to the driver
If the current buffer and the target’s desired buffer are PMDLs, WDF will create a partial PMDL to reduce PTE usage
Sending of I/OSending of I/O
A WDFREQUEST can be sent synchronously or asynchronously
Unlike WDM, you do not have to implement your own synchronous send
Synchronous I/O You can use any type of memory (PVOID, PMDL, WDFMEMORY)
Asynchronous I/O requires the use of WDFMEMORYYou can specify a timeout
WDF synchronizes request cancellation from the timer and the client driver via WdfRequestCancelSentRequest() with the request completion and cancellation of the timer itself upon completion
State Synchronization and Sending of I/OState Synchronization and Sending of I/O
A WDFREQUEST is sent only when the target is in the proper state
A request will be queued on a stopped target for sending at a later time
Optional timeout will be started when queued
State can be ignored and force a send
The state of the WDFIOTARGET is not affected by a PnP state change in the owning device
For an in stack target, WDF assumes that queues or self managed I/O will control the sending of I/OFor an opened (e.g. remote) target, the states are disjoint already
The target tracks queued and sent requests and can cancel them when the target state changes
The target object itself will not be freed until all sent I/O has completed!
Call to ActionCall to Action
Work together with us to make WDF successfulConsider WDF for any Windows driver development projectJoin WDF beta program
Use the guest account (Guest ID: Guest4WDF) on http://beta.microsoft.com to sign up for beta
Provide feedbackEmail
windf @ microsoft.com - Kernel Mode Driver Frameworkumdfdbk @ microsoft.com - User Mode Driver Frameworkdrvpft @ microsoft.com - PREfast for Driverssdvfdbk @ microsoft.com - Static Driver Verifier
Newsgroupsmicrosoft.beta.windows.driverfoundationmicrosoft.beta.windows.driverfoundation.announcements
Web Resources http://www.microsoft.com/whdc/driver/wdf/default.mspx http://www.microsoft.com/whdc/DevTools/ddk/default.mspx
© 2005 Microsoft Corporation. All rights reserved.This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.