OSRLogo
OSRLogoOSRLogoOSRLogo x Subscribe to The NT Insider
OSRLogo
x

Everything Windows Driver Development

x
x
x
GoToHomePage xLoginx
 
 

    Fri, 20 Oct 2017     115100 members

   Login
   Join


 
 
Contents
  Online Dump Analyzer
OSR Dev Blog
The NT Insider
Downloads
ListServer / Forum
Driver Jobs
  Express Links
  · The NT Insider Digital Edition - May-June 2016 Now Available!
  · Windows 8.1 Update: VS Express Now Supported
  · HCK Client install on Windows N versions
  · There's a WDFSTRING?
  · When CAN You Call WdfIoQueueP...ously

The DDK Is Dead -- Long Live the LDK!

 

The DDK is scheduled for retirement.

 

Yup, that’s what I said.  Looking forward to Longhorn, the DDK will be discontinued.

 

In its place will rise an entirely new, and much more powerful, entity.  This new kit is currently referred to as the Longhorn Development Kit (LDK).  Before we go any further, it’s important to realize that everything in this article is entirely speculative. While we’ve been diligent at ensuring what appears in this article is correct as of press time, work on the LDK is presently ongoing.  As a result, things can, and probably will, change drastically between now and any product release.  Now that the lawyers are happy, we can continue.

 

The LDK will be different from the DDK in the same way that a Porsche is different from a Volkswagen.  Sure, they’re similar beasts and their each capable of getting you to the market, but there’s no way that they’re even in the same class.

 

Key to the LDK vision is an integrated platform that combines what today are the DDK and the Hardware Compatibility Tests (HCT).  This integrated platform will make it easier to build drivers and test them for correctness in one step.  It will also seek to integrate feedback from real user crash scenarios via OCA.

 

In addition, the LDK is scheduled to include a host of tools aimed at helping developers identify code and design errors as early as possible in the development cycle.  The goal of these tools is to create a series of overlapping “zones of coverage.”  Because each type of tool is most efficient at catching (and diagnosing) a particular type of error, the way to get the most comprehensive test coverage (with the easiest to decipher error diagnosis) is to utilize a set of tools that combine to form a complete test spectrum.

 

You can see the “overlapping zones of coverage” concept starting to emerge in the tools provided with the Windows Server 2003 DDK.  For example:

 

  • Errors such as potentially bad code paths or invalid conditional statements are most easily caught at compile time.  Prefast, a code scanning tool developed by Microsoft Research, can be used to catch these errors.  Prefast is publicly available for the first time in the Windows Server 2003 DDK.

 

  • Errors such as doing both interlocked and non-interlocked insertions on the same list head, or acquiring the same spin lock with KeAcquireSpinLock and KeAcquireInStackQueuedSpinLock, are most easily caught by including special diagnostic code in the driver executable during testing.  Call Usage Verifier (CUV) is provided to catch and warn the developer about precisely these errors.

 

  • Properly interpreting and validating user data buffer descriptions, especially on IOCTLs, is a common driver problem.  Errors in user data buffer interpretation are best found by a tool that can synthesize and send a broad spectrum of valid and invalid requests to a driver.  This helps exercise the driver’s logic.  A tool that does this is Device Path Exerciser (DC2).

 

  • Accidental pool corruption, by writing past the end of an allocation or by writing to a pool block that has already been freed, is best detected by the operating system itself.  Driver Verifier’s “special pool” mode finds and diagnoses such errors.

 

I’m sure you could cite other examples. In addition, I’m sure you could imagine how additional tools might fit into this equation.

 

While the most recent versions of the DDK have all the tools described above, they are all separate.  They require a developer to discover each tool and make a conscious effort to use that tool to test their driver.  Part of the goal of the LDK is to make this a more integrated processes, so that utilizing driver test tools is no more difficult than the build process is today.

 

There’s a lot more exciting stuff scheduled for the LDK.  We can only hope to talk about part of it here.  As time goes by, even more information about features and capabilities will emerge.  As these details are released, The NT Insider will keep you updated.

 

 

Related Articles
WINVER Incorrectly Defined in XP/.NET Beta DDK's Win2K Build Environment
Advantage: Driver Writer -- New Functions in the Windows XP DDK
XP DDK Resets PATH Environment Variable
New DDK Package -- The DDK Suite (Update)
Need the XP DDK FAST?
Must Use New DDK Compiler
Windows XP® DDK
Interview: All About the DDK
Guest Article: Simplifying Development with DDK Macros
WHICH DDK Do I Use??

User Comments
Rate this article and give us feedback. Do you find anything missing? Share your opinion with the community!
Post Your Comment

Post Your Comments.
Print this article.
Email this article.

Writing WDF Drivers I: Core Concepts
LAB

Nashua (Amherst), NH
15-19 May 2017

Writing WDF Drivers II: Advanced Implementation Techniques
LAB

Nashua (Amherst), NH
23-26 May 2017

Kernel Debugging and Crash Analysis
LAB

Dulles (Sterling), VA
26-30 Jun 2017

Windows Internals and Software Driver Development
LAB

Nashua (Amherst), NH
24-28 Jul 2017

 
 
 
 
x
LetUsHelp
 

Need to develop a Windows file system solution?

We've got a kit for that.

Need Windows internals or kernel driver expertise?

Bring us your most challenging project - we can help!

System hangs/crashes?

We've got a special diagnostic team that's standing by.

Visit the OSR Corporate Web site for more information about how OSR can help!

 
bottom nav links