Developing Drivers with WDF: ErrataUpdated: July 03, 2008 Note:
Chapter 1, Introduction to WDF
The last entry on this page is confusing. The text in the second bullet ends with "and" to indicate that it creates a complete sentence when combined with the preceding and following bullets. For clarity, however, this entry should instead read:
Chapter 7, Plug and Play and Power Management
In "State Changes and the Callback Sequence," the third sentence is ambiguous. It should read: More typically, the system transitions to an Sx state when the user closes the lid of a laptop or the driver for a network card powers down its device transitions its device to a Dx state when the cable is unplugged.
At the bottom right of the diagram, the last two callbacks should read:
At the bottom right of the diagram, the last two callbacks should read:
At the bottom right of the diagram, the last two callbacks should read:
The first paragraph at the top of the page refers to IWDFInitialize::SetPowerPolicyOwnership. The correct name of the method is IWDFDeviceInitialize::SetPowerPolicyOwnership. Chapter 9, I/O Targets
In "Device and Configuration Descriptors," the text under the second bullet is missing a word. The correct information is as follows:
In the middle of the page, the first bullet under the table capitalizes the name of the IPnpCallbackHardware interface incorrectly. Only the first "p" should be capitalized. Chapter 16, Hardware Resources and Interrupts
The text labeled Important near the top of the page incorrectly describes the sharing of MSIs. The text should read as follows: IMPORTANT If your device generates line-based interrupts, your driver’s interrupt service callback must be written so that it can share interrupt vectors or MSIs with another device. The function must not assume that it is called only for interrupts that its device generated. It should return TRUE only if its device actually did generate the interrupt. Returning TRUE under any other conditions can crash the system. If your device generates MSIs, your driver can safely assume that its interrupt service callback runs only if your device generated the interrupt. MSIs are rarely shared, so in most cases, the interrupt service callback is not required to verify that the MSI belongs to it. Instead, it can simply queue a DPC and return TRUE. The in-memory data that is the result of the DMA operation is guaranteed to be coherent by the time the interrupt service callback is invoked. However, in the rare stack in which your driver shares an MSI—typically because another driver in the stack has also registered for one of the device’s MSIs—the interrupt service callback must ensure that the MSI belongs to it before it queues the DPC and returns. Chapter 17, Direct Memory Access
In the last paragraph on the page, the third sentence is confusing. It should instead read: The allocated common-buffer area is not necessarily physically contiguous contiguous in the device-bus logical address space, although not necessarily contiguous in the physical address space. Chapter 23, PREfast for Drivers
Following the statement, "You can use the __drv_strictTypeMatch(mode) and __drv_strictType(typename, mode) annotations to ensure that PREfast checks whether a function is called with exactly the right type." The first bullet point should read:
KeEnterCriticalRegion has no parameters and no result value--it simply blocks until it succeeds.
In the second paragraph, the second sentence should read: This annotation specifies that the Target parameter must always be accessed by using an interlocked operation.
In Listing 23-24, "Example of annotation test cases for a function," the third line of code should read: … __drv_when(mode < 0 || mode > 2) … This example shows that when mode==0, neither parameter should be null. |
