<< Windows DDK 1

Tenouk.com >>

---

 

Installing Microsoft Windows Driver Development Kit (DDK) for Microsoft Windows Server 2003 Service Pack 1 (SP1) on Windows XP Pro SP2 Part 2

 

 

Installing Symbols Package

 

As said by Microsoft, the new linker strips all debug information from the SYS file and moves the data into a PDB file. The PDB file should be copied to the symbols directory for debugging. Copying the SYS file will not provide debugging information. If you want the entire set of symbols for Windows Vista, Windows Server 2003, Windows XP, or Windows 2000, then you can download a symbol package and install it on your computer.

 

 

Figure 15: Selecting Windows XP with Service Pack 2 retail symbols for downloading

 

In our case, because we can’t be online all the time, we have downloaded a package for Windows XP SP2 symbols package, create a folder named Symbolsat C:\ and run the executable file (~ 200MB) to install it on C:\Symbols.

 

 

Figure 16: The Windows XP with Service Pack 2 retail symbols self-extraction file

 

 

Figure 17: The Windows XP with Service Pack 2 retail symbols file extraction

 

 

Figure 18: The Windows XP with Service Pack 2 retail symbols License agreement

 

 

Figure 19: The Windows XP with Service Pack 2 retail symbols default installation path

 

 

Figure 20: The Windows XP with Service Pack 2 retail symbols custom directory installation selection

 

 

Figure 21: The Windows XP with Service Pack 2 retail symbols package installation path

 

 

Figure 22: The Windows XP with Service Pack 2 retail symbols files copying in action

 

 

Figure 23: The Windows XP with Service Pack 2 retail symbols package installation is complete

 

 

Figure 24: The Windows XP with Service Pack 2 retail symbols installed directories

 

 

Figure 25: The Windows XP with Service Pack 2 retail symbols PDB files examples

 

After executing windgb, you need to set the path to the symbol files. This path points to the directories with the pdb files of your drivers. You can have different directories by separating them with a semicolon (;). You also need to point to the corresponding PDB files of all the windows components, if you want the call stacks that you'll see to include the functions from the components that are developed by Microsoft.

However, the problem in this case is that the windows PDB files change between service packs, hotfixes, etc. Fortunately, Microsoft has configured a symbol server, which can be used to download the needed files on-demand. This means that you just set the symbol path to the symbol server and windbg downloads only the PDB files that it needs. In order to do this, you need to add an entry to the windbg symbol path that's equal to:

 

SRV*DownstreamStore*http://msdl.microsoft.com/download/symbols

 

In the above line, http://msdl.microsoft.com/download/symbols is the symbol server then you don't need to modify this), and DownstreamStore is the path, where you want the pdb files to be downloaded. This needs to be substituted by a local directory, e.g. C:\Symbols, so the complete entry would be:

 

SRV*c:\Symbols*http://msdl.microsoft.com/download/symbols

 

 

Figure 26: Setting the Symbol File Path

 

 

Figure 27: Setting the PDB Symbol File Path for the on demand download

 

Finally, if you have additional PDB files for the drivers that you are developing in directories C:\mydrivers1, C:\mydrivers1\misc and C:\mydrivers2, the complete symbol path would be:

 

SRV*c:\websymbols*http://msdl.microsoft.com/download/symbols;c:\drivers1;c:\drivers1\misc;d:\drivers2

 

Also, as it can be seen from the above example, the directories in the path aren't recursive, so if you have PDB files both in C:\mydrivers1 and C:\mydrivers1\misc, then you need to include both of them, since the format doesn't imply the latter. In order to set this line, you need to open windbg, go to File → Symbol File Path and paste the line in the textarea. In our case the PDB files already installed under the C:\Symbols directory, so we just point to the directory in the Symbol File Path. Launch the Windbg program.

 

 

Figure 28: Invoking the Symbol File Path setting page

 

 

Figure 29: The Symbol File Path setting page

 

 

Figure 30: Selecting the C:\Symbols as the Symbol File Path

 

 

Figure 31: The Symbol File Path has been set to the local C:\Symbolsdirectory

 

Don’t forget to save the changes that have been done.

 

 

Figure 32: Saving the WinDbg changed workspace

 

More complete information should be found in the Help.

 

 

Figure 33: Invoking the WinDbg Help

 

 

Figure 34: The WinDbg Help

 

Kernel-mode memory dump files can be analyzed by WinDbg. The processor or Windows version that the dump file was created on does not need to match the platform on which KD is being run.

 

Starting the WinDbg

 

To analyze a dump file, start WinDbg with the -z command-line option:

 

windbg -y SymbolPath -i ImagePath -z DumpFileName

The -v option (verbose mode) is also useful. If WinDbg is already running and is in dormant mode, you can open a crash dump by selecting the File → Open Crash Dump menu command or pressing the CTRL+D shortcut key.

 

 

Figure 35: Opening the Windows Crash Dump file

 

When the Open Crash Dump dialog box appears, enter the full path and name of the crash dump file in the File name text box, or use the dialog box to select the proper path and file name. When the proper file has been chosen, click Open.

 

 

Figure 36: Selecting the Windows mini Crush Dump file

 

You can also open a dump file after the debugger is running by using the .opendump (Open Dump File) command, followed with g (Go).

Dump files generally end with the extension .dmp or .mdmp. You can use network shares or Universal Naming Convention (UNC) file names for the memory dump file. Well, it will take a long story to provide examples on how to debug either the user mode or kernel mode and why not you try the following links by Windows device driver developer for more information.

 

1. Windbg basic tutorials.
2. A Crash Dump analysis tutorials.
3. Tips on how to analyze strange Crash Dumps and uninstall the Windows hidden drivers.

 

 

Verifying DDK Installation

 

To verify that you have properly installed the Microsoft Windows Server 2003 Service Pack 1 (SP1) Driver Development Kit (DDK), complete the following steps:

 

1.      Start a Windows XP Checked Build Environment Command Prompt window:

 

• Click the Start button, and then click All Programs.

• Point to Development Kits →  Windows DDK <build number>, point to your selected Windows XXXX, point to Build Environments, and then point to Windows XP (or your chosen Windows OS).

• Click Windows XP Checked Build Environment.

 

 

 

Figure 37: Running the Checked Build Environment for Windows XP

 

2.      At the command prompt, type build –cZ to compile and link the complete set of installed sources. This command can take more than 30 minutes to complete, depending on which DDK components are installed and the system on which the build is being performed.

 

 

Figure 38: Running the buildcommand

 

 

Figure 39: The Checked Build Environment for Windows XP in action

 

 

Figure 40: More action for the Checked Build Environment for Windows XP

 

3.      The build command should complete with no errors and no warnings displayed but here we have some warnings.

 

 

Figure 41: The Checked Build Environment for Windows XP is completed with warnings

 

 

Figure 42: Viewing the DDK samples index files

 

 

Figure 43: The DDK sample index files

 

The Windows DDK contains a variety of build environments for different operating systems and processors. These environments are all named for the binaries that they build, not the operating system that the build occurs on. For example, choose one of the Windows XP build environments to create drivers for Windows XP systems. With one exception, you can use any build environment on any computer. For example, you can use the Windows 2000 build environments on a Windows Server 2003 computer to build binaries that will run on Windows 2000. Or you can use the Windows Server 2003 64-bit build environment on a Windows 2000 Professional computer with an x86 processor to build binaries that will run on an Intel Itanium computer with Windows Server 2003. The one exception is that you cannot build 16-bit binaries (such as virtual device drivers or boot loaders) on an Itanium computer or an x64-based computer. When you install the Windows DDK on a 64-bit computer, the 16-bit build environments will not be available during installation.

 

Free and Checked Build Environments

 

For each platform and operating system, there are two build environments: one for building free binaries and one for building checked binaries. In the free build environment, the Build utility generates a build product that is optimized for release, similar to a retail build created with Microsoft Visual Studio. In the checked build environment, the Build utility generates a build product that has a number of  features that facilitate testing and debugging:

 

• In the checked environment, the Build utility does not optimize the code it creates.

• Checked binaries (products built in the checked environment) typically have extra tests in the code to catch errors.

• The checked environment also defines the DBG preprocessor constant, which controls whether certain debugging routines are called.

• In some checked environments that build binaries for Windows XP and later operating systems, the VERIFIER_DDK_EXTENSIONS environment variable

• might be defined by default. This activates the Call Usage Verifier tool.

 

All drivers should first be compiled and tested in the checked environment. Builds must be recompiled and retested in the free environment after they are complete and have been demonstrated to work. The free and checked build environments are not related to the free and checked builds of the Windows operating system. Building, testing, and debugging a driver is an iterative process that involves the following steps:

 

• Writing the driver code, which should include debugging routines and macros that are flagged for conditional compilation.

• Building a checked version of the driver.

• Testing and debugging a checked version of the driver on a checked build of each target operating system.

• Testing and debugging the free version of the driver on a free build.

• Tuning the performance of the driver on the free build.

• Final testing and verification using the free build.

Download a single pdf file

---

<< Windows DDK 1

Tenouk.com >>