Windows Driver Consulting http://www. If your path leads to a Windows Device Driver, we can help... Sat, 13 Aug 2016 15:01:54 +0000 en-US hourly 1 https://wordpress.org/?v=4.6.17 90933572 Another Step to Kernel String Safety http://www./2016/01/21/another-step-to-kernel-string-safety/ Thu, 21 Jan 2016 19:14:13 +0000 http://www./?p=643 Over roughly the last decade Microsoft has made a lot of effort on providing Safe String functions and requiring their use.  Unfortunately, there is at least one hole in this effort that some of us pointed out years ago, that is still there, namely the functions RtlInitAnsiString, RtlInitString and RtlInitUnicodeString.  The functions take a NULL […]

The post Another Step to Kernel String Safety appeared first on Windows Driver Consulting.

]]>
Over roughly the last decade Microsoft has made a lot of effort on providing Safe String functions and requiring their use.  Unfortunately, there is at least one hole in this effort that some of us pointed out years ago, that is still there, namely the functions , and RtlInitUnicodeString.  The functions take a NULL terminated string, and setup the appropriate counted string structure.  These three functions are all unsafe, but still remain widely in use.  For example, the Windows 8.1 WDK has 342 calls to these functions.
The problem with these calls is that they essentially use strlen and its derivatives to get the length of the string.  Now has no check for the end of the input string’s buffer, which is why calling the function is an error that recommends that you call RtlStringCbLength  instead, but RtlInitAnsiString doesn’t have the extra parameter the new call requires.
So how did this slip by?  The simple answer is the common use of these functions is:

RtlInitUnicodeString( &UniString, L”This is the string” );

Such a usage is perfectly safe, since the compiler guarantees the string constant as the second argument has a NULL terminator.  But what happens if the second argument is a variable?  If there is no NULL termination the function will keep going until it page faults.  Even for the case of a constant string, why are you doing this?  The compiler knows the length of the string, so why are you using time in your driver to calculate a constant?
Fortunately, there are a number of simple ways to replace the function.  The simplest for UNICODE_STRINGS is to use:

DECLARE_CONST_UNICODE_STRING( UniString, L”This is the string” );

This is almost identical to RtlInitUnicodeString but it declares the variable.  So if your original code used UniString multiple times in a function as the first argument to RtlInitUnicodeString you will have to make them unique.  While DECLARE_CONST_UNICODE_STRING does not have a documentation page, it was well covered in Doron Holon’s excellent.
The second approach is to:

UNICODE_STRING UniString = RTL_CONSTANT_STRING(L”This is the string”);

This version works with all the string types.  See the MSDN documentation for .

Finally, what are you doing with the string you just initialized?  Many old drivers use one of the RtlInitXXXString functions, then immediately copied the string to another string and appended some value.  With the safe string functions the better approach is to use .  In most cases a number of functions can be collapsed into a single call with this approach.

Once you have done the work of getting rid of these unsafe functions consider adding the following three lines to a common include file for your driver project so the functions are flagged in the future.

#pragma deprecated(RtlInitAnsiString)
#pragma deprecated(RtlInitString)
#pragma deprecated(RtlInitUnicodeString)

Hopefully, someday soon Microsoft will put these three lines into their include files where they really belong.

The post Another Step to Kernel String Safety appeared first on Windows Driver Consulting.

]]>
643
Build Drivers from the Command Line http://www./2016/01/06/build-drivers-from-the-command-line/ Wed, 06 Jan 2016 18:39:03 +0000 http://www./?p=635 There are a lot of reasons to be able to build drivers from the command line.  Many release engineering teams want to have automated nightly builds, and there are plenty of other uses for the capability. Recently I encountered more than one experienced Windows driver developer who complained that what they dislike about the Visual […]

The post Build Drivers from the Command Line appeared first on Windows Driver Consulting.

]]>
There are a lot of reasons to be able to build drivers from the command line.  Many release engineering teams want to have automated nightly builds, and there are plenty of other uses for the capability. Recently I encountered more than one experienced Windows driver developer who complained that what they dislike about the Visual Studio integration of the Windows Driver Kit (WDK) was the loss of the ability to build from the command line.  Actually, it is still available; in fact Microsoft recently released a .
This is another of those cases where in the transition to a new technology, it was assumed people were familiar with the details of Visual Studio.  The good news is that for the Windows 10 WDK, building from the command line is .  Below is my advice for those who wish to build from the command line for older WDK’s or if you are looking for a quick reference.
When the WDK was integrated into the recent Visual Studio’s, it also was migrated from the old NMAKE to the MsBuild tool.
Project versus Solution
When you create a driver in the WDK, you start with a project. In a logical sense, a project contains all the files that will be compiled into the driver or other specific product, along with all the compiler settings and other configuration data needed.  A solution is a container of one or more projects allowing them to be grouped together and built with a single command.
Command line building
To use Msbuild you need to set up the environment.  The easiest way to do this is to go to the Start menu folder for the version of the Visual Studio you are using and then choose Developer Command Prompt for VS201X where X is 2,3 or 5.   If you want to make this part of a script, invoke VsDevCmd.bat, which is located off the install directory for the appropriate Visual Studio in Common7\Tools.
If you go to the directory with the solution or project file and run MsBuild, it will build the item with the default configuration.  Most of us want to do this from a script.  To make this solid, you want a few arguments.  The most likely argument is a path to a solution or project file for the driver, so the script can be run from anywhere.  Note: if you install the Windows 8 WDK and Windows 8.1 WDK on the same system, the two versions of Visual Studio have a conflict.  Because of this you cannot use a project file from the Windows 8 WDK, but the solution file will still work.  Start by using a simple command line like:

Msbuild <path to solution or project>

Beyond this most of us want to build both 32 and 64 bit versions of the driver.  For that we need to add the switch /p:Platform=<arch> where arch is Win32, or x64.  For example:

Msbuild /p:Platform=Win32 <path to solution or project>

builds the 32-bit version of the driver.  Finally, a well designed script will need to specify the target version of Windows and whether to build the debug or release version of the driver.  The available options have changed depending on the version of the WDK. See the table below:

TargetWindows 8 WDKWindows 8.1 WDKWindows 10 WDK
Vista Debug/p:Configuration="Vista Debug"
Vista Release/p:Configuration="Vista Release"
Win7 Debug/p:Configuration="Win7 Debug"/p:Configuration="Win7 Debug"/p:TargetVersion=”Windows7”
/p:Configuration="Debug"
Win7 Release/p:Configuration="Win7 Release"/p:Configuration="Win7 Release"/p:TargetVersion=”Windows7”
/p:Configuration="Release"
Win8 Debug/p:Configuration="Win8 Debug"/p:Configuration="Win8 Debug"
Win8 Release/p:Configuration="Win8 Release"/p:Configuration="Win8 Release"
Win8.1 Debug/p:Configuration="Win8.1 Debug"/p:TargetVersion=”Windows8.1”
/p:Configuration="Debug"
Win8.1 Release/p:Configuration="Win8.1 Release"/p:TargetVersion=”Windows8.1”
/p:Configuration="Release"
Win10 Debug/p:TargetVersion=”Windows10”
/p:Configuration="Debug"
Win10 Release/p:TargetVersion=”Windows10”
/p:Configuration="Release"

For many script situations, you may want to rebuild the whole project; to do this add the switches /t:clean /t:rebuild to specify the targets of deleting all the files, then rebuilding.  The final result is:

Msbuild /p:platform=Win32 /p:Configuration=”Win7 Debug” /t:clean /t:rebuild <path>

Or

Msbuild /p:platform=Win32 /p:TargetVersion=”Windows7” /p:Configuration=”Debug” /t:clean /t:rebuild <path>

The first line works for the Window 8 or Windows 8.1 WDK and the other works for the Windows 10 WDK.  Finally, you may want to control the level of output.  In that case use the /v:<level> switch where level is: q[uiet], m[inimal], n[ormal], d[etailed], and diag[nostic].
There are a lot more capabilities in ; you can explore to go beyond this simple overview to get you started.

The post Build Drivers from the Command Line appeared first on Windows Driver Consulting.

]]>
635
An Update for Using PC-Lint with the Windows Driver Kit http://www./2015/07/06/an-update-for-using-pc-lint-with-the-windows-driver-kit/ Mon, 06 Jul 2015 17:32:30 +0000 http://www./?p=630 A couple of years ago I released a tool for using Lint with the Windows Driver Kit (WDK) that was described in my NT Insider article, Another Look at Lint.   For those unfamiliar with Lint, it is the checking program for the C language that came out of Bell Labs in 1978.  My tool supports […]

The post An Update for Using PC-Lint with the Windows Driver Kit appeared first on Windows Driver Consulting.

]]>
A couple of years ago I released a tool for using Lint with the Windows Driver Kit (WDK) that was described in my NT Insider article, .   For those unfamiliar with Lint, it is the checking program for the C language that came out of Bell Labs in 1978.  My tool supports , a modern variant capable of many advanced checks for both C and C++.
I have a new version of my tool that supports all WDK’s up to the release candidate for Windows 10.   The new version is an intermediate code drop; it supports all the new compilers and WDK’s but the lint definitions have not yet been tuned for the newer WDK’s.  There will be another release once the Windows 10 WDK is final.  You will be able to get the new version from the OSR site where the original article is located.
A lot of people think “I use /W4 and Code Analysis, so why do I need more”.  If you knew three good developers and asked them to review the code if your driver, would you only pick two of them to do the review?    Each of the tools uses a different approach to looking at the code, and while many of the bug reports are common to the tools, each has more than enough unique checks to make running all three tools worthwhile.
For example, the Windows 8 WDK samples are well checked by Microsoft, but Lint flags another 64K lines of warnings.  Some people will say the warnings are false positives, or are things “we don’t need to worry about”, but there are a number of items we should care about.  For instance:

Over 3000 variables declared but not referenced.  Sure they don’t break the code, but do they represent an omission error?  I.E. was there code supposed to be written, and somehow was not incorporated into the product?  The over 3000 doesn’t include another roughly 7000 structure fields or object members that are not referenced, while a lot of these are.
Assignment of a variable or field around 4000 times, where the value assigned is not referenced.  Again this doesn’t break anything, but it could be an omission error, or at least the programmer could get rid of the assignment.

Around 3000 functions that could be made static, improving modularization.  A lot of developers don’t like static, but this does signal to both the coders and the compiler that the function is only used in this module.

Over 2200 Boolean expressions that are always constant.  Yes, a number of these are intentional, but certainly not all.  In previous versions of the WDK, I have encountered large code blocks that could never be executed.  The compiler will remove them as dead code, but do you really want that when you are working on or reviewing the code?

The above is far from a complete list of items flagged. None of these are real errors, but do you really want these in code you are going to take for one of your drivers?  One of the good things about static checking tools is the more a developer uses them and actually changes the code to fix the warnings (versus just suppressing the warnings with a #pragma), the more one evolves their coding style to eliminate the warnings in the first place.
The issue about static checking tools is that so many developers view fixing the warnings or adding the annotations as just another chore that has to be done.  I view it as an opportunity to review the code from a different perspective.   When I am fixing a warning from one of the tools, I am looking at the code around the problem to see both why the problem occurred, and what other improvements can be done to the driver in that area.   The approach of using the various language checking tools and reviewing code is in itself a large topic that will be covered in a future blog post.

The post An Update for Using PC-Lint with the Windows Driver Kit appeared first on Windows Driver Consulting.

]]>
630
WDK Installation Tips http://www./2015/05/11/wdk-installation-tips/ Mon, 11 May 2015 13:55:51 +0000 http://www./?p=608 Updated for the Windows 10 Enterprise WDK. I was recently loading up a test machine with the various Window Driver Kits (WDKs) so I could test some tools I have been working on.  Even for someone who has been developing Windows drivers for a long time, the idiosyncrasies of the various kits and installing them […]

The post WDK Installation Tips appeared first on Windows Driver Consulting.

]]>
Updated for the Windows 10 Enterprise WDK.

I was recently loading up a test machine with the various Window Driver Kits (WDKs) so I could test some tools I have been working on.  Even for someone who has been developing Windows drivers for a long time, the idiosyncrasies of the various kits and installing them can drive you nuts.  To make things worse, I prefer to install the WDK’s in their own tree under a single WDK directory, rather than in the default location Microsoft chooses.  I figured people might want a primer.
WDKVisual StudioDesktop(1)Server(1)DownloadSample
Download
Windows 7None compiler
in kit
XP to 72003 to 2008 R2In kit
Windows 8(2)VS2012 (pro or higher)Vista to 82008 to 2012
Windows 8.1VS20137 to 8.12008 R2 to 2012 R2
Windows 10VS20157 to 102016
Windows 10
Enterprise
None compiler
in kit
7 to 102016

Notes:
1. While the listed versions are supported as targets, remember that in most cases a driver written for older OS works fine on future systems.  The rule is build for the earliest OS you wish to support.
2. The Windows 8 WDK is officially unsupported, but there are a lot of people still using it.
Windows 7 WDK
The install is pretty simple:
1. Download the ISO image
2. Burn the ISO to a DVD or mount it with a 3rd party ISO mounting tool
3. Run setup
4. Choose the components (typically build tools and debugger)
5. Specify the directory for the install
If you have already worked with a later WDK but not the older kits, then this kit has a number of surprises.  This kit is standalone, you do not need an additional compiler, and if you want to install the Software Development Kit (SDK) you should do it in its own directory.  This is the last kit that was not integrated with Visual Studio, instead it uses the BUILD command and SOURCES file to control and build drivers.  If you haven’t used BUILD before take a look at my paper on the environment http://www.microsoft.com/whdc/driver/foundation/DrvDev_Intro.mspx
If you want to integrate the WDK with a copy of Visual Studio, take a look at DDKBuild available from http://www.hollistech.com/. DDKBuild allows you to invoke the build process inside the Visual Studio Integrated Development Environment.  While there are other tools that integrate BUILD with Visual Studio out there, I prefer this one for the best documentation and since Mark Roddy was the original creator of the tool.
Windows 8 WDK
The install is as follows:

Standard Installation
Install in a non-standard directory
1. Install Visual Studio 2012
2. Install Windows 8 WDK
3. Install Windows 8 SDK (optional)
4. Open VS2012 if there is a menu named DRIVER install worked
1. Install Windows 8 WDK specifying the desired directory
2. Install Visual Studio 2012
3. From the control panel uninstall the WDK
4. Install Windows 8 WDK it will go where the first install put it
5. Install Windows 8 SDK (optional) this will go in the WDK directory
6. Open VS2012 if there is a menu named DRIVER install worked

One other caveat on Windows 8 WDK, if you plan to install the Windows 8.1 WDK on the same system then the Static Driver Verifier will not work in either environment!  This is a pain for those of us who have different clients using different environments, and prefer not to use virtual machines.
Windows 8.1 WDK
The install is as follows:

Standard InstallationInstall in a non-standard directory
1. Install Visual Studio 2013
2. Install Windows 8.1 WDK
3. Install Windows 8.1 SDK
4. Open VS2013 if there is a menu named DRIVER install worked
1. Install Windows 8.1 WDK specifying the desired directory
2. Install Visual Studio 2013
3. From the control panel repair the WDK
4. Install Windows 8.1 SDK this will go in the WDK directory
5. Open VS2013 if there is a menu named DRIVER install worked

As stated in the Windows 8 WDK, if you have VS2012 installed on the same system then the Static Driver Verifier will not work in either environment.
Windows 10 WDK
The Windows 10 WDK is the latest version of the kit.  Installation is different than the previous kits:

Standard InstallationInstall in a non-standard directory
1. Start the install of VS2015
1.1. Select Custom install
1.2. Expand Universal Windows app development tools
1.3. Select Tools and Windows SDK 10.0.10069
1.4. Click Next to continue and follow the prompts to complete the installation
2. Install Windows SDK for Windows 10
3. Install Windows Driver Kit (WDK) 10
1. Install Windows SDK for Windows 10 choosing the install directory
2. Install Windows Driver Kit (WDK) 10 goes into the directory for the SDK
3. Start the install of VS2015
3.1. Select Custom install
3.2. Expand Universal Windows app development tools
3.3. Select Tools and Windows SDK 10.0.10069
3.4. Click Next to continue and follow the prompts to complete the installation
4. From the control panel repair the SDK
5. From the control panel repair the WDK

To check if the WDK is correctly installed, try building a sample driver.  An error (a common problem is complaining about not finding warning.h) indicates the install was not correct. Note: if you did not perform custom install steps correctly, from the control panel change the VS2015 to reflect the above requirements, and then repair the SDK and WDK.

Windows 10 Enterprise WDK

The Windows 10 WDK is a stripped down version of the kit.  This kit has no GUI, you must use MsBuild command line actions to build drivers. Installation is quite different from the previous kits:
1.Open the downloaded ZIP file and extract the contents to the directory where you want the kit.
2.Run LaunchBuildEnv from an Administer CMD Window

The post WDK Installation Tips appeared first on Windows Driver Consulting.

]]>
608
Blogging Again http://www./2015/04/06/blogging-again/ Mon, 06 Apr 2015 20:52:49 +0000 http://www./?p=596 A little over 7 years ago, I stopped blogging as my consulting practice took off.   With a re-launch of my website I decided to return to blogging, but this time with a different focus.  One thing I consistently do is answer questions on the newsgroups and forums covering Windows driver development.  This blog will concentrate […]

The post Blogging Again appeared first on Windows Driver Consulting.

]]>
Tacoma-narrows-bridge-collapse

A little over 7 years ago, I stopped blogging as my consulting practice took off.   With a re-launch of my website I decided to return to blogging, but this time with a different focus.  One thing I consistently do is answer questions on the newsgroups and forums covering Windows driver development.  This blog will concentrate on common questions in developing device drivers, and in particular thoughts on creating high quality drivers.
Quality is a very important part of windows driver development, so I figured I should check the latest materials.  I was surprised to find that a web search placed high on the list my presentation and other papers from ten years ago!  In fact there was almost nothing since the 2005 WinHEC conference on the subject.
I started thinking about why we don’t talk about driver quality anymore, and I realized that there were a lot of reasons both good and bad that we don’t use the term quality.  The good is that the quality of Windows drivers has improved, a lot of this is because of Microsoft’s efforts in things like Code Analysis (aka Prefast), Static Driver Verifier, the Windows Driver Framework, and better samples.  The bad reasons, are in many way’s also related to the above tools, many developers think the tools take care of the problems.
Even though drivers have significantly improved, there is still a lot further for them to go.  Engineering bridges is an old and well established science yet we still have bridge collapses, computers are a little younger than the bridge collapse shown at the start of this post, and we still have a long ways to go.
So, I decided to focus much of this blog about developing high quality Windows device drivers.  A lot of this will still be about simple things for developing device drivers, because in actuality a lot of efforts related to quality are pretty simple, developers just get busy and don’t do them.  I hope there will be a few new items, but much of this will just going over best practices.
When I delivered the presentation above I got three kinds of responses:
1. People liked it and it got them thinking about what they did or did not do.
2. People complained “it was a repeat of Code Complete by Steve McConnell”, well yes you will find a lot of what I talk about in any good software development book.  Of course it is still important to apply it, a few years later I reviewed a driver written by one of the complainers, who seemed to have forgotten everything from the book and the talk.
3. People complained “I was expecting a new technique that solves all the driver quality issues”.  Yes, I really heard this a few times, of course I suspect these people have made their millions through one of the many offers for money we get in the email ;-).
If you are an experienced driver I hope you will ask yourself after reading one of these posts, Am I doing everything I can in the area the post was about to create quality drivers?  If you are new to windows driver development, or a manager trying to understand what is going on, please look at these as guidance for your efforts.

The post Blogging Again appeared first on Windows Driver Consulting.

]]>
596