To identify the causes of blue screens(BSOD) needs to analyze the memory dump. In the vast majority of cases, a minidump is enough, which is created by the system in case of critical errors.
This article contains step-by-step instruction for installing and configuring WinDBG - a powerful debugging tool that allows you to identify the true cause of the BSOD.
Step 1 — Setting Up Small Memory Dump Recording
Step 2 — Installing WinDBG
To analyze memory dumps, you will need to install the WinDBG debugger, which is included with the Windows SDK. At the time of writing, the latest available Windows versions SDK:
- Windows 10 SDK (download online installer)
- Windows 8.1 SDK (download online installer)
Step 3 — Mapping .dmp Files to WinDBG
Map your .dmp files to WinDBG to make it easier to read and analyze memory dumps. This will allow you to open dump files from Explorer directly in WinDBG, bypassing its preliminary launch.
Step 4 — Setting Up the Symbol Server to Receive Debug Symbol Files
The installation and initial configuration of WinDBG is now complete. In order to change its appearance, you can go to the menu view- font settings you will find by selecting the item Font, and console window settings in Options.
June 22, 2010
Previously Windbg was available separately to download. But for the latest versions, Microsoft keeps it as part of the Windows SDK. Please find the download links below.
Windows 10
The latest version of Windbg for Windows 7 can be downloaded from the link https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk
Windows 7
Download installers from the above links. Note that this does not download the whole SDK, it's just an installer. once you run the file, you can select which tools you would like to be downloaded. If you are interested only in Windbg, you can exclude everything else and only select ‘Debugging tools’ under ‘Common Utilities’
The above package installs windbg 6.12 version. If you want to quickly install windbg, you can go for older version(6.11) which can be downloaded from
the link given at the end of this post.
Once you do the installation, you can find the program in start menu-> All Programs -> Debugging Tools for Windows -> Windbg
Debugging Tools for Windows- Operating code debugging tools Windows systems. They are a set of freely distributed programs from Microsoft designed for debugging user-mode and kernel-mode code: applications, drivers, services, kernel modules. The toolkit includes console and GUI debuggers, utilities for working with symbols, files, processes, utilities for remote debugging. The toolkit contains utilities with which you can find the causes of failures in various components of the system. Debugging Tools for Windows from a certain moment are not available for download in the form of a standalone distribution and are part of the Windows SDK (Windows Software Development Kit). Instrumental set Windows tools The SDK, in turn, is available as part of the MSDN Subscription Program, or can be freely downloaded as a separate distribution from msdn.microsoft.com. According to the developers, the latest and greatest current version Debugging Tools for Windows is contained in the Windows SDK.
Debugging Tools for Windows are updated and made available to the public quite often and this process does not depend on the release in any way. operating systems. Therefore, periodically check for new versions.
Let's now see what, in particular, the Debugging Tools for Microsoft Windows:
- Debugging local applications, services (services), drivers and kernel;
- Debug over network remote applications, services (services), drivers and kernel;
- Debug running applications in real time;
- Analyze memory dump files of applications, the kernel and the system as a whole;
- Work with systems based on x86/x64/Itanium architectures;
- Debug user-mode and kernel-mode programs;
Available next versions Debugging Tools for Windows: 32-bit x86, Intel Itanium, 64-bit x64. We need two of them: x86 or x64.
There are several ways to install Debugging Tools for Windows, in this article we will consider only the main ones:
- Installation via web installer.
- Installing Debugging Tools for Windows from ISO Windows image SDK.
- Installing Debugging Tools for Windows directly from the dbg_amd64.msi /dbg_x86.msi packages.
It remains unclear at what point, why should I install debugging tools on a computer? Often, after all, you are faced with a situation where intervention in working environment highly undesirable! And even more so since the installation of a new product, that is, making changes to the registry / system files, may be completely unacceptable. Mission-critical servers are examples. Why don't developers consider portable versions of applications that don't require installation?
From version to version, the process of installing the Debugging Tools for Windows package undergoes some changes. Let's now jump straight into the installation process and look at the ways in which the toolkit can be installed.
Installing Debugging Tools for Windows Using the Web Installer
Go to the Windows SDK Archive page and find a section called Windows 10 and below the item "Windows 10 SDK (10586) and Microsoft Windows 10 Mobile Device Emulator (version 10586.11)".
Click on an item INSTALL SDK. After clicking, download and run the sdksetup.exe file, which initiates the process of online installation of the Windows SDK. At the initial stage, the installer will check if the .NET Framework package is installed on the system latest version(in this moment it's 4.5). If the package is missing, the installation will be offered and the station will be rebooted when finished. Immediately after the reboot, at the stage of user authorization, the installation process starts directly with the Windows SDK.
Often, when choosing all the components of the package without exception, errors may occur during the installation process. In this case, it is recommended to install components selectively, the minimum required set.
After the installation of Debugging Tools for Windows is complete, the location of the debugging files when this method our installation will be as follows:
- 64-bit versions: C:\Program Files (x86)\Windows Kits\x.x\Debuggers\x64
- 32-bit versions: C:\Program Files (x86)\Windows Kits\x.x\Debuggers\x86
* where x.x is a specific version of the development kit;
We noticed that versions 8 and higher, the installation paths are noticeably different from the classic ones for everyone previous versions debugging tools?
A huge plus this method Installing Debigging Tools for Windows is to install versions of debugging tools for all architectures at once.
Installing Debugging Tools for Windows from the Windows SDK ISO
This method involves installing Debugging Tools for Windows using the full Windows SDK (Software Developers Kit) installation image. Until a certain time, download iso image for the appropriate system, you could visit the Windows SDK Archive page. However, at the moment, you can get an ISO image of the SDK by running the web installer sdksetup.exe , and selecting the item Download the Windows Software Development Kit in the start window of the installer:
As it was found out, the previous installation method using the web installer is quite capricious and often fails. On clean systems, it installs without problems, but on sufficiently loaded systems, numerous problems arise. If this is the case for you, then use this method.
Accordingly, on the page you need to select the required distribution kit, for me (and I think for many) at the moment it is "Windows SDK for Windows 7 and .NET Framework 4" and a little lower click on the link "Get DVD ISO image" .
When working with the site msdn.microsoft.com, I advise you to use a browser Internet Explorer, because there have been observed cases of non-working of competing products!
Accordingly, it is necessary to choose only as necessary. Usually the bitness of Debugging Tools for Windows is the same as the bitness of the system. My test systems are mostly 64-bit, so in most cases I download the image for the 64-bit system GRMSDKX_EN_DVD.iso .
Then, after downloading the image, we need to somehow work with the existing ISO image. The traditional way is, of course, burning a CD, but this is a rather long and sometimes costly method. I propose to use free utilities to create virtual disk devices in the system. Personally, I prefer to use the DEAMON Tools Lite program for this purpose. Someone may have other preferences, more direct or lightweight utilities, in taste and color, as they say .. After installation DAEMON Tools Lite, I just double-click on the image file GRMSDKX_EN_DVD.iso and I have a new virtual CD in my system:
Then I double-click to activate autoload and run Windows installation SDK:
When the turn comes to select the components to be installed from the list, we disable absolutely all options except those marked in the screenshot. This will help us avoid unnecessary mistakes now.
That's right, the screenshot shows two options: "Windows Performance Toolkit" and "Debugging Tools for Windows". Choose both, because the Windows Performance Toolkit will certainly come in handy in your work! Further, after clicking the "Next" button, the installation continues in the normal mode. And at the end you will see the inscription "Installation Complete".
Upon completion of the installation, the working directories of the Debugging Tools for Windows kit will be as follows:
- For x86 version:
- For x64 version:
This completes the installation of Debugging Tools for Windows.
Installing Debugging Tools for Windows via .msi file
In case of problems during the installation of Debugging Tools for Windows in the two previous ways, we still have one more, the most reliable and time-tested one, which helped out, so to speak, more than once. Once, before integration into the Windows SDK, Debugging Tools for Windows were available as a separate .msi installer, which can still be found, but already in the bowels of the Windows SDK distribution. Since we already have an ISO image of the Windows SDK on hand, we can not mount it into the system, but simply open it using the well-known WinRAR archiver, or any other product that works with the contents of ISO disks.
After opening the image, we need to go to the "Setup" directory located at the root and then select one of the directories:
- To install the 64-bit version: \Setup\WinSDKDebuggingTools_amd64 and unpack the dbg_amd64.msi file from this directory.
- To install the 32-bit version: \Setup\WinSDKDebuggingTools and unpack the dbg_x86.msi file from this directory.
Upon completion of the installation, the working directories of the Debugging Tools for Windows kit will be as follows:
- For x86 version: C:\Program Files (x86)\Debugging Tools for Windows (x86)
- For x64 version: C:\Program Files\Debugging Tools for Windows (x64)
At this point, the installation of Debugging Tools for Windows can be considered completed.
additional information
I don't know what it is connected with, maybe with my inattention, but after installing the Debugging Tools for Windows, the installer does not set the path to the directory with the debugger in the Path system path variable. This imposes certain restrictions on running various debugging tasks directly from the console. Therefore, in the absence of a path, I myself write in the window Environment Variables path to debugging tools:
- C:\Program Files (x86)\Windows Kits\10\Debuggers\x86
- C:\Program Files (x86)\Windows Kits\10\Debuggers\x64
* In your case, the paths may differ both due to the use of an OS of a different bitness, and due to the use of an SDK of a different version.
The utilities of the Debugging Tools for Windows package can work as portable applications, just copy from working system catalog Microsoft Windows Performance Toolkit and use it as a portable version on a production server. But do not forget to take into account the capacity of the system !! Even if you have made a complete installation of the package on a critical system, then you can start working right after installation, no reboot is required.
Debugging Tools for Windows
And now, finally, here is the composition of Debugging Tools for Windows:
| File | Purpose |
|---|---|
| adplus.doc | Documentation for the ADPlus utility. |
| adplus.exe | A console application that automates the work of the cdb debugger to create dumps, log files for one or more processes. |
| agestore.exe | A utility for removing obsolete files from the storage used by the symbol server or source server. |
| breakin.exe | A utility that allows you to send a custom break combination to processes, similar to pressing CTRL+C. |
| cdb.exe | User mode console debugger. |
| convertstore.exe | Utility to convert characters from 2-tier to 3-tier. |
| dbengprx.exe | Ripiter (proxy server) for remote debugging. |
| dbgpc.exe | A utility for displaying information about the status of an RPC call. |
| dbgsrv.exe | The server process used for remote debugging. |
| dbh.exe | A utility for displaying information about the contents of a symbol file. |
| dumpchk.exe | Dump verification utility. A utility for quickly checking a dump file. |
| dumpexam.exe | A utility for analyzing a memory dump. The result is output to %SystemRoot%\MEMORY.TXT . |
| gflags.exe | Editor of global system flags. The utility manages registry keys and other settings. |
| i386kd.exe | Wrapper for kd. Was that what kd was once called for Windows NT/2000 based systems for x86 machines? Probably left for compatibility reasons. |
| ia64kd.exe | Wrapper for kd. Was that what kd was once called for Windows NT/2000 based systems for ia64 machines? Probably left for compatibility reasons. |
| kd.exe | Kernel-mode console debugger. |
| kdbgctrl.exe | Kernel debug management tool. Utility for managing and configuring the kernel debugging connection. |
| kdsrv.exe | Connection server for KD. The utility is a small application that runs and waits for remote connections. kd runs on a client and connects to that server for remote debugging. Both server and client must be from the same Debugging Tools assembly. |
| kill.exe | Utility to end processes. |
| list.exe | A utility for displaying the contents of a file on the screen. This miniature utility was bundled with one purpose - viewing large text or log files. It takes up little memory space, as it loads the text in parts. |
| logger.exe | A tiny debugger that can only work with one process. The utility injects logexts.dll into the process space, which records all function calls and other actions of the program being examined. |
| logviewer.exe | A utility for viewing logs written by the logger.exe debugger. |
| ntsd.exe | Microsoft NT Symbolic Debugger (NTSD). A debugger that is identical to cdb, except that it creates a text window on startup. Like cdb, ntsd is capable of debugging both console applications and graphical applications. |
| pdbcopy.exe | A utility for removing private symbols from a symbol file, controlling public symbols included in a symbol file. |
| remote.exe | Utility for remote debugging and remote control of any KD, CDB and NTSD console debugger. Allows you to run all these console debuggers remotely. |
| rtlist.exe | Remote Task Viewer. The utility is used to list running processes through the DbgSrv server process. |
| symchk.exe | A utility to download symbols from the Microsoft symbol server and create a local symbol cache. |
| symstore.exe | Utility to create a network or local storage characters (2-tier/3-tier). A symbol store is a specialized directory on disk that is built according to a certain structure and contains symbols. In the root directory of the symbols, a subfolder structure is created with names identical to the names of the components. In turn, each of these subfolders contains nested subfolders with special names obtained by hashing binary files. The symstore utility scans component folders and adds new components to the symbol store where any client can retrieve them. The symstore is said to be used to get symbols from the 0-tier storage and put them into the 2-tier/3-tier storage. |
| tlist.exe | Task Viewer. A utility for listing all running processes. |
| umdh.exe | User-mode dump heap utility. A utility for analyzing heaps of a selected process. Allows you to display various options for the heap. |
| usbview.exe | USB viewer. utility to view USB devices connected to a computer. |
| vmdemux.exe | Demultiplexer virtual machine. Creates multiple named pipes for a single COM connection. Channels are used to debug various components of the virtual machine |
| windbg.exe | User mode and kernel mode debugger with GUI. |
Introduction to WinDBG - Part 1
Alexander Antipov
WinDBG is a great debugger. It may not have a very user-friendly interface and no black background by default, but it is one of the most powerful and stable debuggers on Windows at present. In this article, I'll walk you through the basics of WinDBG so you can get started with it.
WinDBG is a great debugger. It may not have a very user-friendly interface and no black background by default, but it is one of the most powerful and stable debuggers on Windows at present. In this article, I'll walk you through the basics of WinDBG so you can get started with it.
This is the first article in a series about WinDBG. List of all articles included in this series:
- Part 1 - installation, interface, symbols, remote/local debugging, help system, modules, registers.
- Part 2 - breakpoints.
- Part 3 - memory inspection, program step-by-step debugging, tips and tricks.
In this article we'll look at mounting and attaching to a process, and in the following ones we'll cover breakpoints, stepping through, and memory inspection.
Installing WinDBG
Compared to Windows 7, the installation process for WinDBG in Windows 8 has changed slightly. In this section, we'll cover installing the debugger for both operating systems.
Installing WinDBG on Windows 8
In Windows 8, WinDBG is included in the Windows Driver Kit (WDK). You can install visual studio and WDK, or install the Debugging Tools for Windows 8.1 package separately, which includes WinDBG.
The installer will ask if you want to install WinDBG locally or download the entire development package for another computer. The latter is essentially the equivalent offline installer, which is very handy if you want to install the package on other systems in the future.
Figure 1: Selecting the installation type
In the next window, you need to uncheck all items except "Debugging Tools for Windows" and click on the "Download" button.
Once the installer has completed its work, go to the directory where the package was downloaded (by default it is c:\Users\Username\Downloads\Windows Kits\8.1\StandaloneSDK) and go through the installation procedure.
Installing WinDBG on Windows 7 and earlier
For Windows 7 and earlier, WinDBG is part of the "Debugging Tools for Windows" package, which is included with the Windows SDK and the .Net Framework. You will be required to download the installer, and then select "Debugging Tools for Windows" during the installation process.
During installation, I select the "Debugging Tools" option under "Redistributable Packages" to create a standalone installer to facilitate subsequent installations.
Figure 2: Selecting installation options to create a standalone installer
Upon completion of the installation, you should have the WinDBG installers for various platforms(in c:\Program Files\Microsoft SDKs\Windows\v7.1\Redist\Debugging Tools for Windows\).
Figure 3: Folder with WinDBG installers for various platforms
WinDBG Interface
Figure 4: Appearance of WinDBG
Once you first see the look and feel of WinDGB, you will realize that the debugger is frighteningly simple. Most of the WinDBG functions are learned during process debugging. Instead of wasting time describing the interface, in the following sections we will only cover the most important points.
The most basic thing you need to know about the debugger interface is the command window, which consists of two areas. The first area: a window where the result of executing commands is displayed. Second area: a small text field for entering commands.
Figure 5: WinDBG Command Window
Symbols
In most cases, WinDBG does not require any special settings and works correctly right out of the box. But one important thing that needs to be tweaked is the symbols. Symbols are files that are generated along with the executable file during program compilation and contain debugging information (functions and variable names). Debug information allows you to explore the functionality of an application while debugging or disassembling. Many Microsoft components are compiled with symbols that are distributed through the Microsoft Symbol Server. With the rest of the executable files, everything is not so rosy - very rarely files with debugging information are bundled with the application. In most cases, companies restrict access to such information.
To configure WinDBG to use Microsoft Symbol Server go to the File:Symbol File Path section and set the path to SRV*C:\Symbols*http://msdl.microsoft.com/download/symbols. Of course, it's a bit odd that asterisks are used as a delimiter. After you set up the Microsoft Symbol Server, the symbols will be downloaded to the C:\Symbols folder.
Figure 6: Microsoft setup Symbol Server
WinDBG will automatically load symbols for binary files when needed. You can also add your own symbols folder like so:
SRV*C:\Symbols*http://msdl.microsoft.com/download/symbols;c:\SomeOtherSymbolFolder
Adding symbols while debugging
If you need to import symbols while debugging, you can do so with .sympath (the command window will appear when you hook into the process). For example, to add the c:\SomeOtherSymbolFolder folder, enter the following command:
0:025> .sympath+ c:\SomeOtherSymbolFolder
Symbol search path is: SRV*C:\Symbols*http://msdl.microsoft.com/download/symbols;c:\SomeOtherSymbolFolder
Expanded Symbol search path is: srv*c:\symbols*http://msdl.microsoft.com/download/symbols;c:\someothersymbolfolder
It's a good idea to reload symbols after adding or changing paths:
0:025> .reload
Reloading current modules
................................................................
...............................................
Checking Loaded Symbols
To see which modules have symbols loaded, you can use the x*! command. Although WinDBG only loads symbols as needed, the x*! will show symbols that can be loaded. You can force symbols to be loaded using the ld * command (this may take some time and you can stop this process by going to Debug:Break).
Now we can see the symbols for each module.
Figure 8: List of symbols
Debugging a local process
When debugging a local process, you have two options:
- Get hooked on already running process.
- Launch process via WinDBG.
Each method has its own advantages and disadvantages. If, say, you run the program through WinDBG, then you have some special debugging options available (for example, heap debugging) that can cause the application to crash. On the other hand, there are also programs that crash when you attach a debugger to them. Some applications (especially malware) check the presence of a debugger in the system during startup and, accordingly, in this case it makes sense to cling to an already running process. Sometimes there is a debugging of a Windows service that sets some parameters at startup time, so to simplify the debugging process, it is also better to hook onto a running process rather than start the service through a debugger. Some people claim that running a process through a debugger has a serious impact on performance. In short, try both and choose what suits you best. If for some reason you prefer a particular method, share your thoughts in the comments!
Starting a process
If you're debugging a standalone application that's running locally and isn't networked, you might want to run it through WinDBG. However, this does not mean that you cannot hook on to an already running process. Choose the most convenient way for you.
Starting the process is not difficult. Go to "File:Open Executable" and select the executable you want to debug. You can also provide arguments or set the start directory:
Figure 9: Selecting an executable for debugging
Process connection
Connecting to an already running process is also not difficult. However, you should note that in some cases it may take time to find exactly the process you want to debug. For example, some browsers create one parent process and then several more processes for each tab. So, depending on the crash dump you're debugging, you might want to hook not to the parent process, but to the process associated with the tab.
To attach to an already running process, go to "File:Attach to a Process" and then select the PID or process name. Remember that you need to have the appropriate rights to hook into the process.
Figure 10: Selecting a process to hook on to
If, after connecting, the application has suspended its work, you can use the "Noninvaise" mode by checking the appropriate box.
Debugging a remote process
You may sometimes need to debug a process on a remote system. It would be much more convenient to handle this task with a local debugger instead of using a virtual machine or RDP. Or maybe you're debugging the LoginUI.exe process, which is only available when the system is locked. In situations like this, you can use the local version of WinDBG and attach to processes remotely. To solve these problems, there are two most common methods.
Existing debug sessions
If you have already started debugging the program locally (by attaching or launching a process through WinDBG), then you can enter a specific command and WinDBG will start a "listener" (listener) that the remote debugger can connect to. To do this, use the .server command:
Server tcp:port=5005
After running the above command, you may see a warning like this:
Figure 11: Warning message that may appear after running the command to create a "listener"
Then WinDBG will report that the server is running:
0:005> .server tcp:port=5005
0:
You can now connect from a remote host to an already existing debug session by going to "File:Connect to a Remote Session" and entering something like this in the text field: tcp:Port=5005,Server=192.168.127.138
Figure 12: Remote connection to the debug session
After connecting, you will receive confirmation on the remote client:
server started. Client can connect with any of these command lines
0:
MACHINENAME\User (tcp 192.168.127.138:13334) connected at Mon Dec 16 09:03:03 2013
and message in local version debugger:
MACHINENAME\User (tcp 192.168.127.138:13334) connected at Mon Dec 16 09:03:03 2013
Create a remote server
You can also create separate server with WinDBG, connect to it remotely and select a process to debug. This can be done using the dbgsrv.exe file where you plan to debug processes. To start such a server, run the following command:
dbgsrv.exe -t tcp:port=5005
Figure 13: Starting a remote server
And again, you may receive a security warning that you should accept:
Figure 14: Security message that may appear during debug server startup
You can connect to the debug server if you go to the "File: Connect to Remote Stub" file and enter the following line in the text field: tcp:Port=5005,Server=192.168.127.138
Figure 15: Connecting to the debug server
After connecting, you will not receive any signals that you have connected, but if you go to "File:Attach to a Process", you will see a list of debug server processes (where dbgsrv.exe is running). Now you can hook into the process as if you were doing it locally.
Help system
The help system in WinDBG is great. In addition to learning something new, you should be able to get help information about a command. Use the .hh command to access the WinDBG help:
You can also get help information for a specific command. For example, to get help on the .reload command, use the following command:
windbg> .hh .reload
Or just go to the "Help:Contents" section.
Modules
While the program is running, various modules are imported that provide the functionality of the application. Therefore, if you know which modules are imported by an application, you can better understand how it works. In many cases, you will be debugging the specific module loaded by the program, not the executable itself.
Once connected to the process, WinDBG will automatically display the loaded modules. For example, below are the modules after I connected to calc.exe:
Microsoft (R) Windows Debugger Version 6.12.0002.633 X86
Copyright (c) Microsoft Corporation. All rights reserved.
*** wait with pending attach
Symbol search path is: SRV*C:\Symbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
ModLoad: 00a70000 00b30000 C:\Windows\system32\calc.exe
ModLoad: 77630000 7776c000 C:\Windows\SYSTEM32\ntdll.dll
ModLoad: 77550000 77624000 C:\Windows\system32\kernel32.dll
ModLoad: 75920000 7596a000 C:\Windows\system32\KERNELBASE.dll
ModLoad: 76410000 77059000 C:\Windows\system32\SHELL32.dll
ModLoad: 77240000 772ec000 C:\Windows\system32\msvcrt.dll
ModLoad: 76300000 76357000 C:\Windows\system32\SHLWAPI.dll
ModLoad: 75cd0000 75d1e000 C:\Windows\system32\GDI32.dll
ModLoad: 75fa0000 76069000 C:\Windows\system32\USER32.dll
ModLoad: 777b0000 777ba000 C:\Windows\system32\LPK.dll
ModLoad: 774b0000 7754d000 C:\Windows\system32\USP10.dll
ModLoad: 73110000 732a0000 C:\Windows\WinSxS\x86_microsoft.windows.gdiplus_
6595b64144ccf1df_1.1.7600.16385_none_72fc7cbf861225ca\gdiplus.dll
ModLoad: 75a80000 75bdc000 C:\Windows\system32\ole32.dll
ModLoad: 76360000 76401000 C:\Windows\system32\RPCRT4.dll
ModLoad: 777c0000 77860000 C:\Windows\system32\ADVAPI32.dll
ModLoad: 75be0000 75bf9000 C:\Windows\SYSTEM32\sechost.dll
ModLoad: 76270000 762ff000 C:\Windows\system32\OLEAUT32.dll
ModLoad: 74590000 745d0000 C:\Windows\system32\UxTheme.dll
ModLoad: 74710000 748ae000 C:\Windows\WinSxS\x86_microsoft.windows.common-
ModLoad: 703d0000 70402000 C:\Windows\system32\WINMM.dll
ModLoad: 74c80000 74c89000 C:\Windows\system32\VERSION.dll
ModLoad: 77770000 7778f000 C:\Windows\system32\IMM32.DLL
ModLoad: 75c00000 75ccc000 C:\Windows\system32\MSCTF.dll
ModLoad: 74130000 7422b000 C:\Windows\system32\WindowsCodecs.dll
ModLoad: 74260000 74273000 C:\Windows\system32\dwmapi.dll
ModLoad: 756d0000 756dc000 C:\Windows\system32\CRYPTBASE.dll
ModLoad: 75e60000 75ee3000 C:\Windows\system32\CLBCatQ.DLL
ModLoad: 6ef10000 6ef4c000 C:\Windows\system32\oleacc.dll
Later in the debugging process, you can display this list again with the lmf command:
0:005>lmf
start end module name
00a70000 00b30000 calc C:\Windows\system32\calc.exe
6ef10000 6ef4c000 oleacc C:\Windows\system32\oleacc.dll
703d0000 70402000 WINMM C:\Windows\system32\WINMM.dll
73110000 732a0000 gdiplus C:\Windows\WinSxS\x86_microsoft.windows.gdiplus_6595b64144ccf1df_
1.1.7600.16385_none_72fc7cbf861225ca\gdiplus.dll
74130000 7422b000 WindowsCodecs C:\Windows\system32\WindowsCodecs.dll
74260000 74273000 dwmapi C:\Windows\system32\dwmapi.dll
74590000 745d0000 UxTheme C:\Windows\system32\UxTheme.dll
74710000 748ae000 COMCTL32 C:\Windows\WinSxS\x86_microsoft.windows.common-
controls_6595b64144ccf1df_6.0.7600.16385_none_421189da2b7fabfc\COMCTL32.dll
74c80000 74c89000 VERSION C:\Windows\system32\VERSION.dll
756d0000 756dc000 CRYPTBASE C:\Windows\system32\CRYPTBASE.dll
75920000 7596a000 KERNELBASE C:\Windows\system32\KERNELBASE.dll
75a80000 75bdc000 ole32 C:\Windows\system32\ole32.dll
75be0000 75bf9000 sechost C:\Windows\SYSTEM32\sechost.dll
75c00000 75ccc000 MSCTF C:\Windows\system32\MSCTF.dll
75cd0000 75d1e000 GDI32 C:\Windows\system32\GDI32.dll
75e60000 75ee3000 CLBCatQ C:\Windows\system32\CLBCatQ.DLL
75fa0000 76069000 USER32 C:\Windows\system32\USER32.dll
76270000 762ff000 OLEAUT32 C:\Windows\system32\OLEAUT32.dll
76300000 76357000 SHLWAPI C:\Windows\system32\SHLWAPI.dll
76360000 76401000 RPCRT4 C:\Windows\system32\RPCRT4.dll
76410000 77059000 SHELL32 C:\Windows\system32\SHELL32.dll
77240000 772ec000 msvcrt C:\Windows\system32\msvcrt.dll
774b0000 7754d000 USP10 C:\Windows\system32\USP10.dll
77550000 77624000 kernel32 C:\Windows\system32\kernel32.dll
77630000 7776c000 ntdll C:\Windows\SYSTEM32\ntdll.dll
77770000 7778f000 IMM32 C:\Windows\system32\IMM32.DLL
777b0000 777ba000LPK C:\Windows\system32\LPK.dll
777c0000 77860000 ADVAPI32 C:\Windows\system32\ADVAPI32.dll
You can also find out the download address for a specific module using the "lmf m" command:
0:005> lmf m kernel32
start end module name
77550000 77624000 kernel32 C:\Windows\system32\kernel32.dll
You can also get information about the image header of a particular module using the !dh extension ( Exclamation point indicates an extension):
0:005> !dh kernel32
File Type:DLL
FILE HEADER VALUES
14C machine (i386)
4 number of sections
4A5BDAAD time date stamp Mon Jul 13 21:09:01 2009
0 file pointer to symbol table
0 number of symbols
E0 size of optional header
2102 characteristics
Executable
32 bit word machine
DLL
OPTIONAL HEADER VALUES
10B magic#
9.00 linker version
C4600 size code
C800 size of initialized data
0 size of uninitialized data
510C5 address of entry point
1000 base code
----- new -----
77550000 imagebase
1000 section alignment
200 file alignment
3 subsystem (Windows CUI)
6.01 operating system version
6.01 image version
6.01 subsystem version
D4000 size image
800 size headers
D5597 checksum
00040000 size of stack reserve
00001000 size of stack commit
00100000 size of heap reserve
00001000 size of heap commit
140 DLL characteristics
dynamic base
NX compatible
B4DA8 [A915] address of Export Directory
BF6C0 [ 1F4] address of Import Directory
C7000 [ 520] address of Resource Directory
0 [ 0] address of Exception Directory
0 [ 0] address of Security Directory
C8000 [B098] address of Base Relocation Directory
C5460 [ 38] address of Debug Directory
0 [ 0] address of Description Directory
0 [ 0] address of Special Directory
0 [ 0] address of Thread Storage Directory
816B8 [ 40] address of Load Configuration Directory
278 [ 408] address of Bound Import Directory
1000 [DE8] address of Import Address Table Directory
0 [ 0] address of Delay Import Directory
0 [ 0] address of COR20 Header Directory
0 [ 0] address of Reserved Directory
SECTION HEADER #1
.text name
C44C1 virtual size
1000 virtual addresses
C4600 size of raw data
800 file pointer to raw data
0 number of relocations
0 number of line numbers
60000020 flags
Code
(no align specified)
Execute Read
Debug Directories(2)
Type Size Address Pointer
cv 25 c549c c4c9c Format: RSDS, guid, 2, kernel32.pdb
(10) 4 c5498 c4c98
SECTION HEADER #2
.data name
FEC virtual size
C6000 virtual address
E00 size of raw data
C4E00 file pointer to raw data
0 file pointer to relocation table
0 file pointer to line numbers
0 number of relocations
0 number of line numbers
C0000040 flags
initialized data
(no align specified)
Read Write
SECTION HEADER #3
.rsrc name
520 virtual size
C7000 virtual address
600 size of raw data
C5C00 file pointer to raw data
0 file pointer to relocation table
0 file pointer to line numbers
0 number of relocations
0 number of line numbers
40000040 flags
initialized data
(no align specified)
Read Only
SECTION HEADER #4
.relocname
B098 virtual size
C8000 virtual address
B200 size of raw data
C6200 file pointer to raw data
0 file pointer to relocation table
0 file pointer to line numbers
0 number of relocations
0 number of line numbers
42000040 flags
initialized data
Discardable
(no align specified)
Read Only
Messages and Exceptions
After attaching to a process, a list of modules is displayed first, and then other messages may appear. For example, when we hook into calc.exe, WinDBG automatically sets a breakpoint (which is just a marker used to stop the application). Breakpoint information is displayed on the screen:
(da8.b44): Break instruction exception - code 80000003 (first chance)
This particular message is an exception, namely the first-chance exception. Essentially, an exception is a special condition that occurs during the execution of a program. First-chance exception means that the program stopped immediately after the exception occurred. Second-chance exception means that after the exception occurs, some operations will be performed, and then the program will stop its work.
Registers
After displaying messages and exceptions, the debugger outputs the state of the processor registers. Registers are special variables within the processor that store small pieces of information or keep track of the state of something in memory. The processor can process the information in these registers very quickly. This is much faster than getting information on the bus from RAM every time.
After connecting to calc.exe, WinDBG automatically displays information about the following registers:
eax=7ffd9000 ebx=00000000 ecx=00000000 edx=776cd23d esi=00000000 edi=00000000
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246
Later, you can duplicate this information again using the r command:
0:005>r
eax=7ffd9000 ebx=00000000 ecx=00000000 edx=776cd23d esi=00000000 edi=00000000
eip=77663540 esp=02affd9c ebp=02affdc8 iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246
ntdll!DbgBreakPoint:
77663540 cc int 3
If we want to get the value of a particular register, we can execute the following command:
0:005> r eax
eax=7ffd9000
Information can be obtained simultaneously from several registers as follows:
0:005> r eax,ebp
eax=7ffd9000 ebp=02affdc8
Pointer to instruction
The last command is about running instructions. Here, information is also displayed, as in the case of the r command, of what contains the EIP register. EIP is a register containing the location next instruction to be executed by the processor. What WinDBG displays is the equivalent of the u eip L1 command, after which WinDBG goes to the address specified in the EIP register, converts this section to assembly code and displays it on the screen.
ntdll!DbgBreakPoint:
77663540 cc int 3
stay in touch
In the following articles, we will look at how to use WinDBG in combat: breakpoints, stepping debugging, and memory viewing. Don't switch! J.