DDKBUILD -- Visual Studio .CMD Procedure For Building Drivers
Let's say you actually like using Visual Studio, and you want to use it to write drivers. You could configure all the VS options to match what's in the DDK... but you'll still be using the version of the compiler and linker that Visual Studio provides (which is, by the way, not the same as that used in any official DDK). What do you do?
OSR's DDKBUILD.BAT file to the rescue!? Just use this as an external build procedure, and you'll be able to build and browse drivers from within Visual Studio, but still use the DDK to ensure that the drivers you build will load and run flawlessly.
Associated article published in The NT Insider, May-June 2002 issue.
V7.4? R43 DDKBUILD.CMD (Updated?Nov 2009)
It adds support for the Windows 7 WDK(s) and introduces the option -CUV to invoke the Call Usage Verifier from PREfast. It implies -PREFAST, so that only -CUV needs to be given in such a case.
The Windows 7 WDK location is declared by using the variable W7BASE or WIN7BASE.
V6.12 DDKBUILD.BAT (Updated April 2008)
Add support for long file names.?? This updated was provided to us by Oliver Schneider.
V7.3? R27 DDKBUILD.CMD (Updated?Nov 2008)
Fixes problems outlined in NTDEV. This updated was provided to us by Oliver Schneider
||XP DDK to VISTA DDK|
||XP DDK to?WIN7 WDK|
||OSR, Oliver Schneider|
DDKBUILD V6.12, ZIP Archive, 5KB
DDKBUILD V7.4 R43?Final, ZIP Archive, 11.6KB
Number Of Downloads
This utility has been downloaded 26731 times.
Rate this utility and tell the community how well you like it. Is it a worthwhile download? Does it work as described?? Does it help you in your job as a driver writer or tester?
Click Here To Post Your Comment
thank you for sharing
28-Mar-12, wang junjie
Ouch, correction. The previous comment relates to rev31, not rev28 as mistakenly written. Sorry for the confusion.
02-Jun-09, Oliver S.
"Changes in rev28"
Eugene: thanks for pointing it out, I had almost forgotten about it as the age of the previous commit shows ;)
Steve: the information in the first chapter of the DDKWizard manual is meant to be useful to any user of the DDKBUILD scripts, indeed. I have been working a little on a separate manual and will perhaps release something along these lines as well in the future.
PS: Please note, I will integrate some more features concerning the various WDK versions, so rev28 can not be considered an actual release. But feel free to use it if it fixes something for you.
02-Jun-09, Oliver S.
"Regexp strings in v7.3 R27 need to be updated"
Regexp string findstr "warning[^.][DRCLU][0-9][0-9]* error[^.][DRCLU][0-9][0-9]*" "build%OSR_EXT%.log" is really not enough. Please look into https://svn.assarbad.net/ddkbuild/trunk/ for testing different codes.
findstr "warning[^.][CDMRU][0-9][0-9]* warning[^.][BRP][KCWG][0-9][0-9]* warning[^.][ACLPS][DNRTVX][JKLTX][0-9][0-9]* error[^.][CDMRU][0-9][0-9]* error[^.][BRP][KCWG][0-9][0-9]* error[^.][ACLPS][DNRTVX][JKLTX][0-9][0-9]*" "build%OSR_EXT%.log" works well.
10-Apr-09, Eugene Lomovsky
"Link to documentation"
It would be useful to have a link to documentation is. I've found something useful, at http://ddkwizard.assarbad.net/, even if not using ddkwizard itself. And some of the questions asked here are answered there.
11-Mar-09, Steve Kovner
"Reply to the previous three posts"
Thiago: should be fixed in 7.3 now.
Bogdan: you don't need to do this with DDKBUILD.CMD anymore. It has a relatively smart auto-detection built-in (for the *BASE directory).
"Let's say I'm building my project for win2k3, and I have DDK for win2k8 installed. So, in batch file for build I have to do two things - set WLHBASE to DDK path and set "WLHNet" type for building project." Well, you don't have to set the base directory anymore, at least.
"My point is, isn't it a bit redundant? I mean, if WLHBASE and only it is set, ddkbuild.cmd has all the information necessary to understand that if I'm using "ddkbuild.cmd WNET" I actually mean "ddkbuild.cmd WLHNet", doesn't it?" This would in fact be overly complicated and let us consider the case where you have three or more DDKs/WDKs installed that are able to build for a particular target platform, how would you determine which DDK/WDK to use then? That's why you have to tell which DDK to use and the target platform. With DDKBUILD.CMD it is no more necessary to give the BASE path, unless you want something that can not be detected (e.g. DDK in a path that is checked out from a VCS).
Alvin: you didn't follow the instructions to register DDKBUILD. Either add the path to DDKBUILD into the (system or user) PATH variable, or add it into the VS settings as pointed out in the DDKWizard manual.
28-Oct-08, Oliver Schneider
"ddkbuild.cmd' is not recognized"
dev environment:visual studio 2008 + Vista WDK 6000 + ddkbuild.cmd It's the first time for me to use it. what's problem ? thanks in advance. output:
1>------ Build started: Project: Driver1.WNET, Configuration: WNET checked (PREfast) Win32 ------ 1>Performing Makefile project actions 1>'ddkbuild.cmd' is not recognized as an internal or external command, 1>operable program or batch file. 1>Project : error PRJ0019: A tool returned an error code from "Performing Makefile project actions"
14-Oct-08, Alvin Hu
"DDK version autodetection"
Let's say I'm building my project for win2k3, and I have DDK for win2k8 installed. So, in batch file for build I have to do two things - set WLHBASE to DDK path and set "WLHNet" type for building project.
My point is, isn't it a bit redundant? I mean, if WLHBASE and only it is set, ddkbuild.cmd has all the information necessary to understand that if I'm using "ddkbuild.cmd WNET" I actually mean "ddkbuild.cmd WLHNet", doesn't it?
It's not a big deal really, but I wonder - am I doing something wrong?
29-Sep-08, Bogdan Opanchuk
"Possible bug with -jpath flag"
This is a great utility, I've been using it for months and it saved me a lot of time and trouble! :) But now I've faced a situation that might be a bug when using the -jpath flag.
DDKBuild doesn't work as it should with the -jpath flag of the build utility. The ddkbuild.cmd appears to consider that each flag is grouped with others (such as in "-cefZ") or separated by " " ("-c -e -f -Z"), but doesn't address flags that has parameters, such as the -jpath flag (-jpath ).
I fixed it by removing the "-e" appended to the bflags var (line 597) as it is already part of the bflags (the bflags is initialized as "-Ze", line 587).
Here in my project I didn't have any problem with this approach, but I wonder if there is a specific situation where the "-e" flag must be appended to every flag passed to the build utility.
PS: I'm using ddkbuild v7.2 (April 2008)
12-Aug-08, Thiago Figueredo Cardoso
"Sorry, I do not get notifications for this topic ..."
... hence no timely answer.
Vladimir: if you are using the WDK 6001, you should use the WLH* configurations, not the WNET ones. WNET is used for Windows 2003 Server DDKs (only!). I agree that WLH* is a bit outdated, but if MS continues to introduce new switches or change existing ones, it will be quite hard to maintain a single version that can (automatically) distinguish between these.
20-Jan-08, Oliver S.
"WDK 6001 problem"
It's very convenient utility. Thanks. There is a small problem when using it for build WNETAMD64 by using WDK 6001. Setenv.bat (which is called internally by ddkbuild) does not recognize "AMD64" parameter. It must be replaced by "x64". For ddkbuild.cmd it's solved by fixing the following line: set OSR_CMDLINE="%%BASEDIR%%\bin\setenv.bat" %%BASEDIR%% %%BuildMode%% AMD64 WNET
19-Oct-07, Vladimir Zinin
"The browse files ..."
To be honest I deactivate browse files in all my driver projects. Instead I use Visual AssistX, which will - after pointing it to the DDK/WDK headers - parse the actual header files and provide a much enhanced version of IntelliSense allong with a lot more improvements in the IDE. I'd not want to work without it anymore, although it is kind of expensive for "just" a plugin. And yes, they are known to be incompatible. Until I found VAX, I had even problems between some "older" IDE version (2003, if I recall correctly) and the "newer" tools in the Windows 2003 SP1 DDK.
06-Sep-07, Oliver Schneider
"VC6.0 bscmake incompatible with WDK 6000?"
My VC6.0 bscmake complains the *.sbr files generated by WDK 6000 are corrupted. Anyone would like to share?
02-Apr-07, Eng Ban Ong
"Support for UMDF"
How about the support for UMDF builds?
05-Dec-06, Amloorp Anand
"A fix is in the works along with some other updates"
Hi, A fix is in the works for this. Thanks for pointing this out.
03-May-06, Mark Cariddi
"Build flags problem"
Great utility, but I found one problem. The batch file assumes that the flags passed to "build" are all in one parameter. My directory tree has several directories that are not built for each project, and I use the ~ operator to exclude them. For example:
build ~dir1 ~dir2
Since bflags is reset for each flag, my build only gets executed as
build ~dir2 -e
It's easy enough to fix -- Essentially bflags should have each flag appended instead of replacing the whole thing. (This is at line 304 in ddkbuild.cmd, and line 522 in ddkbuild.bat v6.5.)
03-May-06, Jeff Claar
"Could you please correct my name :-)"
Hi Mark, just found back to the OSR downloads today. My surname actually spells "Schneider" ;)
I included the bugfix from Cornelis and just replaced the old 6.5 header with the one from the 7.0 beta. You can download it together with a perl script from: http://assarbad.info/stuff/!export/create_proj.zip
The perl script is used to create a skeleton VC2003.NET project (without solution) that is pre-configured for the WNET DDK and has configurations for W2K, WXP and WNET. Furthermore the skeleton makes use of the new feature introduced after the beta script was published by Mark - pre and post build steps. Just put files named ddkprebld.cmd and ddkpostbld.cmd in the same folder in which DDKBUILD is being executed (so the directory with the dirs or sources file in it) and make full use of all the environment variables available after DDKs setenv.bat has been executed. I've introduced this on the NTDEV list already without any feedback. So maybe here's the better place then?!
Hope the guys at OSR will update the script to this latest corrected version - thanks to Cornelis for pointing out that typo.
15-Mar-06, Oliver S.
"Another way to build"
Place this in the build cmd line of VS: cmd /c "C:\WINDDK\3790~1.183\bin\setenv.bat C:\WINDDK\3790~1.183 chk WXP && cd $(InputDir) && C:\WINDDK\3790~1.183\bin\x86\build -eMI". The arguments for setenv.bat come from the shortcuts placed in the start menu. This allows you to build from VS as if you just clicked the shortcuts changed to the directory and ran the build command, the recommended way to do it.
21-Jan-06, Kwadwo Mireku
"DDKBUILD V7.0 Beta"
Thanks for the comments on this, I'll look into it.
17-Jan-06, Mark Cariddi
"DDKBUILD V7.0 Beta"
Great script, but with one small typeo - %%BASEDIR% below is missing a %.
:: WNET build for 64bit (AMD) using WNET DDK :WNETAMD64Build set OSR_BUILDNAME=WNET 64 BIT BUILD using WNET DDK set BASEDIR=%WNETBASE% set OSR_CMDLINE=%%BASEDIR%%\bin\setenv.bat %%BASEDIR% %%mode%% AMD64 WNET goto :EOF
12-Jan-06, Cornelis van Rikxoort
"Building for Win 2k with WNET3790.1830 DDK"
Looks like a tiny inconsquential bug for those of us still writing for windows 2000
I was getting an error on the line: call %BASEDIR%\bin\w2k\set2k.bat %BASEDIR% %mode%
changed to: call %BASEDIR%\bin\setenv.bat %BASEDIR% %mode%
and was troubled no more.
20-Dec-05, Eric Zweighaft
"Thanks for the comments"
Thanks for the comments, I'll look into correcting this.
07-Dec-05, Mark Cariddi
"Cool tool ;)"
Did you review the fixes (of typos and code) I sent in to Mark, recently?
28-Nov-05, Oliver S.
Of course this is just brilliant stuff!
One tiny niggle on the browse:
Currently you get the headers from the last build you made and not those for the currently active configuration. Not a big deal, except when your half asleep after a long shift, but it doesn't look too hard to fix either?
Just add plaform and buildtype options into the sbrList name, and we can use /o to identify configuration specific .bsc files. I see you already do this for %CPU% so your nearly there!
Two other VC 6 'features' can trip up the casual browser (I think its the same on .NET too)
1. VC uses include paths from the devstudio settings to locate header files (if you right click on the #include and select open include file) its 'pot-luck' where you end up.
2. Anything that writes "error" or "warning" to the output stream will result in VC counting up the number of errors/warnings. Gee that's smart programming by the VC team (not!)
'anything' in this context, happens to include old versions of resource compilers (they emit "compiling error log file" or something similar). So if you include resources like you should, and still use (say) the W2K DDK, like you should NOT, then you'll see this.
And really that is absolutely ALL I've found wrong with this approach, over many years trying things this way, and various other alternatives for best productivity.
And lets face it that isn't much wrong at all. Congratulations!
16-Mar-05, Jack Heeley
Are you sure you'll get all those switches right? And what happens when the DDK version changes, and it uses slightly different switches and settings -- With your method, I'm afraid, the switches are embdeed in your VS project? And how about building your driver for different build environments?
The fact of the matter is: NEVER build a driver directly from within VS by attempting to copy the switches and compiler settings. There's no guarantee you'll get it right, and the DDK's setting change from release to release and build environment to build environment.
WHY would you not want to do this the RIGHT WAY and use build, from within Visual Stuido if that's what you want to do. THEN you're assured that everything will always be correct.
10-Mar-05, Peter Viscarola
"building drivers with visual studio"
'But you'll still be using the version of the compiler and linker that Visual Studio provides '
To use visual studio to build drivers: In project settings set 'ignore default directories' for compiler and linker. Set all the driver related defines, includes, linker switches etc.
In Tools-Options-Directories-Executable Files set a path to the DDK bin and move it to the top of the list. Copy BSCMAKE.EXE from the VS bin dir to the DDK bin dir.
Now you can build a driver with browse info etc from VS with EXACTLY the same binary image as using build.exe.
10-Mar-05, matt sykes
"How to set WXPBASE?"
When I tried to build WDM driver under Windwos XP(SP2), I got an error below. error: BASEDIR, W2KBASE, WXPBASE, or WNETBASE environment variable not set.
How to set WXPBASE?
Thank you in advance for help.
10-Feb-05, Jimmy Chen
"Any fix for WXPBASE etc not defined issue?"
16-Nov-04, k mk
09-Aug-04, Thanh Truong
"setting of WXPBASE"
I am trying to build the nothing_wdm project using my Visual C++ version 5 . My Question is what value should I set to the WXPBASE variable ? is it the root directory of the ddk ? if it is so, it does not work . The Visual C++ output this error message :
--------------------Configuration: NOTHING_WDM - Win32 Debug-------------------- OSR DDKBUILD.BAT V5.3 - OSR, Open Systems Resources, Inc. WXP 32 BIT BUILD using WXP DDK error: BASEDIR, W2KBASE, WXPBASE, or WNETBASE environment variable not set.
19-Jun-04, tzachi orpaz
"RE: Proposed fix"
This fix has been incorporated into V5.3 of DDKBUILD.
19-May-03, Scott Noone
This utility will not work, if disk, from which ddkbuild.bat is launched, is different from the disk, where "directory-to-build" is located. In order to fix this, it may be usefull to change the following line in ddkbuild.bat from: ---- ... cd %2 ... ---- to ---- ... cd /D %2 ... ----
04-May-03, Gennady Mayko