Windows For Devices Articles

  • Home > Windows For Devices Articles

        Maximizing driver quality in Windows XP Embedded -- Part 2

        Staff | Date: Jul 2, 2007 | Comments: 1


        Foreword: This is part 2 of a two-part series about tools that help developers assess device driver code quality. In Part 1, the author described how to use the Verifier tool; here he explains what to do when Verifer reports a problem.




        Maximizing Driver Quality in Windows XP Embedded

        Part 2: Using PFD and SDV

        by Nick Nehrhood

        This is a continuation of the article I wrote here. This part focuses on the utilities that you can add to your toolbox, which will help you ensure quality for drivers for which you do have source code access. Both of these tools are used during compile time of your driver and are available from the Windows Driver Development Kit. Please see the first article to find out how to procure the kit.

        PREfast for Drivers (PFD)

        The first tool is PREfast for Drivers -- which I'll call PFD in this article. PFD is a compile-time static verification tool that analyzes your C or C++ code and looks for common basic coding errors that the compiler may have missed. This utility does not actually execute any code that it's validating but instead tries to detect come of the compile issues that the compiler itself may ignore and would probably be pretty difficult to debug. In addition -- PFD has an additional module which is designed to detect errors in the kernel-mode driver code.

        If you're interested in seeing one example of the tool's output then here's a MSDN sample for PFD called "Uninitialized Variables and NULL Pointers". If you want to read more about PFD, check out this link.

        PFD was designed to analyze 32-bit code written for either the x86 or the x86-64 architecture (commonly called 'x64' -- not to be confused with the IA64 architecture). I also recommend that you check out the PREfast Step-by-Step page, here. Finally, I found that Channel 9 has done a video about PREfast for Drivers. One of the developers, Donn Terry, is interviewed on the topic of PFD and even provides some insight as to what benefits and differences (at a high level) exist between PREfast for Drivers and PREfast.

        Static Driver Verifier (SDV)

        The second tool is Static Driver Verifier -- which I'll call SDV in this article. SDV takes a systematic approach to verifying the driver code, in order to ensure that your driver code, which is written in C, doesn't cause any interoperability issues with the Windows OS kernel. This utility will examine all code paths within the code and even has the ability to find errors in obscure code paths which may or may not be exercised even with through testing.

        SDV can validate File System Filter drivers as well as device drivers which are in compliance with the Windows Driver Model (WDM). It can validate function drivers, filter drivers, and bus drivers in the x86 as well as the x86-64 environment.

        If you're interested in seeing one example of the tool's usage and output then you can check out this article, titled "Verifying Fail_Driver1." If you want to read more about SDV, you can visit this link.

        What to do with these tools

        So, you may ask, "Nick, what would you do?" Well, I would run both utilities if my code was written in C, and if my code was written in C++ or managed code (.NET) then I would only use PFD.

        Yes -- that's right. You read that correctly. PFD can even verify drivers written in managed code! Also, if you're interested in the normal PREfast (the version used against your applications), then you can get it by purchasing Visual Studio 2005 Team Edition for Software Developers or Visual Studio 2005 Team Suite. For more information on either of those please see this link (search for the words "Static Code Analyzer" to find where PREfast applies).

        Ultimately it is up to you, the drivers' developers and testers, to ensure that the drivers that are shipping on/in your company's products are of the utmost quality. After all is said and done, you definitely don't want users to be greeted with a blue screen. *Grin*


        Copyright (c) 2007 Microsoft Corp. All rights reserved. Reproduced by WindowsForDevices.com with permission. This article was originally published on the Windows XP Embedded team blog, here.


        About the author: Nick Nehrhood's fascination with computers started at age 10 when his uncle showed him an Amiga. He is known as the "hardware guru" of the XP Embedded Team where he has been since 2001. Still a "child at heart," Nick's spare time interests include gaming, software development, and being a "Wikipedia addict."


        Related stories: