Installing Debugging Tools for Windows. Windows Debugging Tools: diagnose and fix BSOD Debugging tools for windows use

on June 22, 2010

Previously Windbg was available separately to download. But for the latest versions, Microsoft keeps it as part of 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 quick 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

At the time of a critical crash, the Windows operating system interrupts and displays a blue screen of death (BSOD). Content random access memory and all information about the error that occurred is written to the paging file. At the next booting Windows a crash dump with debug information is created based on the saved data. A critical error is generated in the system event log.

Attention! A crash dump is not generated if the disk subsystem fails or critical error appeared at the initial stage of Windows boot.

Types of Windows crash dumps

Using the example of the current operating system Windows 10 (Windows Server 2016), we will consider the main types of memory dumps that the system can create:

Small memory dump(256 KB). This file type contains a minimal amount of information. It only contains the BSOD error message, information about the drivers, the processes that were active at the time of the crash, and which process or kernel thread caused the crash.
Kernel memory dump... Typically small in size - one third of the physical memory. A kernel memory dump is more verbose than a mini dump. It contains information about drivers and programs in kernel mode, includes memory allocated to the Windows kernel and hardware abstraction layer (HAL), and memory allocated to drivers and other programs in kernel mode.
Complete memory dump... Largest in volume and requires memory equal to your system's RAM plus 1MB, required windows to create this file.
Automatic memory dump... Corresponds to the kernel memory dump in terms of information. It differs only in how much space it uses to generate the dump file. This file type did not exist in Windows 7. It was added in Windows 8.
Active memory dump... This type filters out items that cannot determine the cause of the system failure. This was added in Windows 10 and is especially useful if you are using a virtual machine or if your system is a Hyper-V host.

How do I enable memory dump on Windows?

Use Win + Pause to open the system settings window, select " Additional system parameters"(Advanced system settings). In the tab “ Additionally"(Advanced), section" "(Startup and Recovery) click" Options"(Settings). In the window that opens, configure the actions in case of system failure. Check the checkbox “ Write events to the system log(Write an event to the system log), select the type of dump to be generated when the system crashes. If in the check-box “ Replace existing dump file"(Overwrite any existing file) check the box, then the file will be overwritten on every failure. It is better to remove this checkbox, then you will have more information for analysis. Also disable Automatically restart.

In most cases, a small memory dump will suffice to analyze the cause of the BSOD.

Now, when a BSOD occurs, you can analyze the dump file and find the cause of the crashes. The mini dump is saved in the% systemroot% \ minidump folder by default. To analyze the dump file, I recommend using the program WinDBG(Microsoft Kernel Debugger).

Installing WinDBG on Windows

Utility WinDBG is included in " Windows 10 SDK"(Windows 10 SDK). ...

The file is called winsdksetup.exe, size 1.3 MB.

Run the installation and choose what exactly you want to do - install the package on this computer or download it for installation on other computers. Install the package to your local computer.

You can install the entire package, but to install only the debugging tool, select Debugging Tools for Windows.

Once installed, the WinDBG shortcuts can be found in the start menu.

Configuring the association of .dmp files with WinDBG

To open dump files with a simple click, match the .dmp extension with the WinDBG utility.

Open up command line as administrator and run the commands for 64-bit system: cd C: \ Program Files (x86) \ Windows Kits \ 10 \ Debuggers \ x64
windbg.exe –IA
for a 32-bit system:
C: \ Program Files (x86) \ Windows Kits \ 10 \ Debuggers \ x86
windbg.exe –IA
As a result, the file types: .DMP, .HDMP, .MDMP, .KDMP, .WEW - will be associated with WinDBG.

Setting up a Debug Symbol Server in WinDBG

Debug symbols (debug symbols or symbol files) are blocks of data generated during compilation of a program together with an executable file. Such data blocks contain information about the names of variables, called functions, libraries, etc. This data is not needed when executing the program, but useful when debugging it. Microsoft components are compiled with symbols distributed through the Microsoft Symbol Server.

Configure WinDBG to use of Microsoft Symbol Server:

Open WinDBG;
Go to the menu File –> Symbol File Path;
Add a line containing the URL for downloading debug symbols from the Microsoft site and the folder for saving the cache: SRV * E: \ Sym_WinDBG * http: //msdl.microsoft.com/download/symbols In the example, the cache is loaded into the E: \ Sym_WinDBG folder, you can specify any.
Remember to save your changes to the menu File–>Save WorkSpace;

WinDBG will search for symbols in the local folder and, if it does not find the necessary symbols in it, it will automatically download symbols from the specified site. If you want to add your own folder with symbols, you can do it like this:

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

If you don't have an internet connection, download the symbol pack from the Windows Symbol Packages resource first.

Crash dump analysis in WinDBG

The WinDBG debugger opens the dump file and downloads the necessary debugging symbols from a local folder or from the Internet. During this process, you cannot use WinDBG. At the bottom of the window (in the debugger command line), an inscription appears Debugee not connected.

Commands are entered into the command line located at the bottom of the window.

The most important thing to pay attention to is the error code, which is always indicated in a hexadecimal value and looks like 0xXXXXXXXX(indicated in one of the options - STOP:, 02.07.2019 0008F, 0x8F). In our example, the error code is 0x139.

The debugger prompts you to run the! Analyze -v command, just hover your mouse over the link and click. What is this command for?

It performs a preliminary analysis of the memory dump and provides detailed information to start the analysis.
This command will display the STOP code and symbolic name of the error.
It shows the call stack of the commands that resulted in the abnormal termination.
In addition, faults in the IP address, processes and registers are displayed here.
The team can provide ready-made recommendations for solving the problem.

The main points that you should pay attention to when analyzing after running the! Analyze –v command (the listing is incomplete).

1: kd>! Analyze -v

* *
* Bugcheck Analysis *
* *
*****************************************************************************
The symbolic name of the STOP error (BugCheck)
KERNEL_SECURITY_CHECK_FAILURE (139)
Description of the error (A kernel component has corrupted a critical data structure. This corruption could potentially allow an attacker to take control of this machine):

A kernel component has corrupted a critical data structure. The corruption could potentially allow a malicious user to gain control of this machine.
Error arguments:

Arguments:
Arg1: 0000000000000003, A LIST_ENTRY has been corrupted (i.e. double remove).
Arg2: ffffd0003a20d5d0, Address of the trap frame for the exception that caused the bugcheck
Arg3: ffffd0003a20d528, Address of the exception record for the exception that caused the bugcheck
Arg4: 0000000000000000, Reserved
Debugging Details:
------------------

The counter shows how many times the system has crashed with a similar error:

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: FAIL_FAST_CORRUPT_LIST_ENTRY

STOP error code in abbreviated format:

BUGCHECK_STR: 0x139

The process during the execution of which the failure occurred (not necessarily the cause of the error, just at the time of the failure in memory this process was running):

PROCESS_NAME: sqlservr.exe

Error code decryption: The system detected a stack buffer overflow in this application, which could allow an attacker to take control of this application.

ERROR_CODE: (NTSTATUS) 0xc0000409 - The system detected an overrun of a stack-based buffer in this application. This overrun could potentially allow a malicious user to gain control of this application.
EXCEPTION_CODE: (NTSTATUS) 0xc0000409 - The system detected an overrun of a stack-based buffer in this application. This overrun could potentially allow a malicious user to gain control of this application.

Last call on the stack:

LAST_CONTROL_TRANSFER: from fffff8040117d6a9 to fffff8040116b0a0

Call stack at the time of failure:

STACK_TEXT:
ffffd000`3a20d2a8 fffff804`0117d6a9: 00000000`00000139 00000000`00000003 ffffd000`3a20d5d0 ffffd000`3a20d528: nt! KeBugCheckEx
ffffd000`3a20d2b0 fffff804`0117da50: ffffe000`f3ab9080 ffffe000`fc37e001 ffffd000`3a20d5d0 fffff804`0116e2a2: nt! KiBugCheckDispatch + 0x69
ffffd000`3a20d3f0 fffff804`0117c150: 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000: nt! KiFastFailDispatch + 0xd0
ffffd000`3a20d5d0 fffff804`01199482: ffffc000`701ba270 ffffc000`00000001 000000ea`73f68040 fffff804`000006f9: nt! KiRaiseSecurityCheckFailure + 0x3d0
ffffd000`3a20d760 fffff804`014a455d: 00000000`00000001 ffffd000`3a20d941 ffffe000`fcacb000 ffffd000`3a20d951: nt! ?? :: FNODOBFM :: `string" + 0x17252
ffffd000`3a20d8c0 fffff804`013a34ac: 00000000`00000004 00000000`00000000 ffffd000`3a20d9d8 ffffe001`0a34c600: nt! IopSynchronousServiceTail + 0x379
ffffd000`3a20d990 fffff804`0117d313: ffffffff`fffffffe 00000000`00000000 00000000`00000000 000000eb`a0cf1380: nt! NtWriteFile + 0x694
ffffd000`3a20da90 00007ffb`475307da: 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000: nt! KiSystemServiceCopyEnd + 0x13
000000ee`f25ed2b8 00000000`00000000: 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000: 0x00007ffb`475307da

The section of the code where the error occurred:

FOLLOWUP_IP:
nt! KiFastFailDispatch + d0
fffff804`0117da50 c644242000 mov byte ptr, 0
FAULT_INSTR_CODE: 202444c6
SYMBOL_STACK_INDEX: 2
SYMBOL_NAME: nt! KiFastFailDispatch + d0
FOLLOWUP_NAME: MachineOwner

The name of the module in the kernel object table. If the analyzer detects a problematic driver, the name is displayed in the MODULE_NAME and IMAGE_NAME fields:

MODULE_NAME: nt
IMAGE_NAME: ntkrnlmp.exe

1: kd> lmvm nt
Browse full module list
Loaded symbol image file: ntkrnlmp.exe
Mapped memory image file: C: \ ProgramData \ dbg \ sym \ ntoskrnl.exe \ 5A9A2147787000 \ ntoskrnl.exe
Image path: ntkrnlmp.exe
Image name: ntkrnlmp.exe
InternalName: ntkrnlmp.exe
OriginalFilename: ntkrnlmp.exe
ProductVersion: 6.3.9600.18946
FileVersion: 6.3.9600.18946 (winblue_ltsb_escrow.180302-1800)

In the above example, the analysis pointed to the kernel file ntkrnlmp.exe. When the memory dump analysis points to a system driver (like win32k.sys) or a kernel file (like ntkrnlmp.exe in our example), it is most likely this file is not the cause of the problem. Very often it turns out that the problem lies in the device driver, BIOS settings or hardware malfunction.

If you saw that the BSOD was caused by a third-party driver, its name will be specified in the MODULE_NAME and IMAGE_NAME values.

For example:

Image path: \ SystemRoot \ system32 \ drivers \ cmudaxp.sys
Image name: cmudaxp.sys

Open your driver file and check its version. In most cases, the problem with the drivers is solved by updating them.

Debugging Tools for Windows- Debugging operating code tools Windows systems... They are a set of free software from Microsoft designed to debug user-mode and kernel-mode code: applications, drivers, services, kernel modules. The toolkit includes debuggers for console and GUI modes, utilities for working with symbols, files, processes, and utilities for providing 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 they are not available for download in the form of a stand-alone distribution kit and are included in 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 standalone distribution from msdn.microsoft.com. According to the developers, the last and most current version Debugging Tools for Windows is contained in the Windows SDK.

Debugging Tools for Windows are updated and made publicly available quite often, and this process does not depend on the release of operating systems. Therefore, check for new versions periodically.

Let's now see what, in particular, the Debugging Tools for Microsoft Windows:

Debug local applications, services (services), drivers and kernel;
Debug remote applications, services (services), drivers and kernel over the network;
Debug running applications in real time;
Analyze dump files of application memory, kernel and system as a whole;
Work with systems based on x86 / x64 / Itanium architectures;
Debug user-mode and kernel-mode programs;

The following versions of Debugging Tools for Windows are available: 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 the 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 the debugging toolkit on my computer? Often, after all, you are faced with a situation where intervention in working environment highly undesirable! Moreover, the installation of a new product, that is, making changes to the registry / system files, may be completely unacceptable. Examples are mission critical servers. Why don't developers think about an option with portable (portable) versions of applications that do not require installation?
The installation process for the Debugging Tools for Windows package has undergone several changes from version to version. Let's now jump right 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 the section under Windows name 10 and below, see "Windows 10 SDK (10586) and Microsoft Windows 10 Mobile Device Emulator (version 10586.11)".

We click on the item INSTALL SDK... After clicking, download and run the sdksetup.exe file, which initiates the online installation of the Windows SDK. At the initial stage, the installer will check if the .NET Framework package is installed in the system. latest version(currently 4.5). If the package is missing, the installation will be offered and the station will be rebooted upon completion. Immediately after the reboot, at the stage of user authorization, the installation process starts directly from the Windows SDK.

Often, when choosing all the components of a package without exception, errors may occur during the installation process. In this case, it is recommended to install the components selectively, the minimum required set.

After the installation of Debugging Tools for Windows is complete, the location of the debug files for this installation method 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 the installation of versions of the debugging tools for all architectures at once.

Installing Debugging Tools for Windows from the Windows SDK ISO Image

This method involves installing the Debugging Tools for Windows using the complete installation image of the Windows SDK (Software Developers Kit). Until a certain time, download ISO image for the corresponding system could be on the Windows SDK Archive page. However, at the moment, you can get the 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 method of installation using the web installer is quite capricious and often fails. On clean systems, it is installed without problems, however, on sufficiently loaded systems, numerous problems arise. If you have just such a case, then use this method.

Accordingly, on the page it is necessary 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 just below click on the link "Get an ISO image of a DVD disc" ...

When working with the site msdn.microsoft.com, I advise you to use a browser Internet Explorer as there have been cases of competing products inoperability!

Accordingly, it is necessary to choose only when necessary. Usually the bitness of Debugging Tools for Windows is the same as the bitness of the system. I have the systems under investigation, 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, to burn a CD, but this is a rather long and sometimes costly method. I suggest using free utilities for creating 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, taste and color, as they say .. After installation DAEMON Tools Lite, I just double-click on the image file GRMSDKX_EN_DVD.iso and a new virtual CD appears on the system:

Then double click I activate autorun and start the installation of the Windows SDK:

When the turn comes to select the components to be installed from the list, then we disable absolutely all options except those marked in the screenshot. This will help to avoid unnecessary mistakes for us now.

Everything is exactly like that, in the screenshot two options are marked: "Windows Performance Toolkit" and "Debugging Tools for Windows". Choose both, because the Windows Performance Toolkit will definitely come in handy for your work! Further, after clicking the "Next" button, the installation continues as usual. And at the end you will see the inscription "Installation Complete".
At the end of the installation, the working directories of the Debugging Tools for Windows set 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 upon a time, before the integration into the Windows SDK, Debugging Tools for Windows were available as a separate .msi installer, which can still be found now, however, already in the bowels of the Windows SDK distribution kit. Since we already have an ISO image of the Windows SDK in our hands, 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 in 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.

At the end of the installation, the working directories of the Debugging Tools for Windows set 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 Debugging Tools for Windows installation is complete.

additional information

I don’t know what it’s connected with, maybe with my carelessness, but after installing the Debugging Tools for Windows, the installer does not register the path to the directory with the debugger in the Path system 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 the SDK of a different version.

The Debugging Tools for Windows package utilities can work as portable applications, you just need to copy the directory from the working system 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 completely installed the package on a critical system, you can start working right after installation, no reboot is required.

Debugging Tools for Windows Composition

And now, finally, we present the composition of Debugging Tools for Windows:

File	Appointment
adplus.doc	Documentation for the ADPlus utility.
adplus.exe	A console application that automates the cdb debugger to create dumps, log files for one or more processes.
agestore.exe	A utility for removing obsolete files from the repository used by the symbol server or source server.
breakin.exe	A utility that allows you to send a user-defined break combination to processes, similar to pressing CTRL + C.
cdb.exe	A user-mode console debugger.
convertstore.exe	Utility for converting symbols from 2-tier to 3-tier.
dbengprx.exe	Reaper (proxy server) for remote debugging.
dbgrpc.exe	A utility for displaying information about the status of an RPC call.
dbgsrv.exe	Server process used for remote debugging.
dbh.exe	A utility for displaying information about the contents of a symbol file.
dumpchk.exe	Dump check utility. A utility for quickly checking a dump file.
dumpexam.exe	A utility for analyzing a memory dump. The result is displayed in% SystemRoot% \ MEMORY.TXT.
gflags.exe	The editor of the global flags of the system. The utility manages registry keys and other settings.
i386kd.exe	Wrapper for kd. When was it called kd for Windows NT / 2000-based systems for x86 machines? Probably left for compatibility reasons.
ia64kd.exe	Wrapper for kd. When was it called kd 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 kernel debugging connection.
kdsrv.exe	Connection Server for KD. The utility is a small application that starts and waits for remote connections... kd runs on the client and connects to that server for remote debugging. Both server and client must be from the same Debugging Tools assembly.
kill.exe	Utility for terminating processes.
list.exe	A utility for displaying the contents of a file on the screen. In the bundle, this miniature utility turned out to be with one purpose - viewing large text or log files. It takes up little memory space as it loads the text in chunks.
logger.exe	A miniature 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 under investigation.
logviewer.exe	A utility for viewing logs written by the logger.exe debugger.
ntsd.exe	Microsoft NT Symbolic Debugger (NTSD). Debugger, identical to cdb, except that it creates a text box 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, control over public symbols included in the 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	Utility to download symbols from a Microsoft symbol server and create a local symbol cache.
symstore.exe	Utility for creating network or local symbol storage (2-tier / 3-tier). A symbol store is a specialized directory on disk that is built in accordance with a certain structure and contains symbols. In the root directory of symbols, a structure of subfolders is created with names identical to the names of the components. In turn, each of these subfolders contains nested subfolders that have special names obtained by hashing binary files. The symstore utility scans the component folders and adds new components to the symbol store where any client can retrieve them. The symstore is said to be used to retrieve symbols from a 0-tier storage and put them into a 2-tier / 3-tier storage.
tlist.exe	Task viewer. A utility for listing all running processes.
umdh.exe	User-mode dump heap utility. Utility for analyzing the heaps (heap) of the selected process. Allows you to display various options for the heap.
usbview.exe	USB viewer. Utility for viewing USB devices connected to the 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	GUI user-mode and kernel-mode debugger.

Introducing WinDBG - Part 1

Alexander Antipov

WinDBG is a great debugger. It may not have a very user-friendly interface and does not have a black background by default, but it is one of the most powerful and stable debuggers in Windows at the moment. In this article, I'll introduce you to the basics of WinDBG so you can get started with it.

This is the first article in a series on WinDBG. List of all articles included in this cycle:

Part 1 - installation, interface, symbols, remote / local debugging, help system, modules, registers.
Part 2 - Breakpoints.
Part 3 - memory inspection, step by step program debugging, tips and tricks.

In this article we will cover installation and connection to a process, and in the following we will cover breakpoints, step-by-step debugging, and memory inspection.

Installing WinDBG

Compared to Windows 7, the installation process for WinDBG in Windows 8 has undergone minor changes. In this section, we will walk you through installing the debugger for both operating systems.

Installing WinDBG on Windows 8

On Windows 8, WinDBG is included in the Windows Driver Kit (WDK). You can install Visual Studio and the WDK, or separately install the Debugging Tools for Windows 8.1 package, which includes WinDBG.

The installer will ask if you want to install WinDBG locally or download the entire developer package for another computer. The latter is essentially the equivalent of an offline installer, which is great if you want to install the package on other systems in the future.

Figure 1: Selecting an Installation Type

In the next window, you need to uncheck all the items except "Debugging Tools for Windows" and click on the "Download" button.

As soon as the installer finishes 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 included in the Debugging Tools for Windows package, which is included with the Windows SDK and the .Net Framework. You will need to download the installer, and then select "Debugging Tools for Windows" during the installation process.

During installation, I select the Debugging Tools option in the Redistributable Packages section to create a stand-alone installer to facilitate subsequent installations.

Figure 2: Selecting installation options to create a stand-alone installer

Upon completion of the installation, you should have WinDBG installers for different platforms (in the directory c: \ Program Files \ Microsoft SDKs \ Windows \ v7.1 \ Redist \ Debugging Tools for Windows \).

Figure 3: Folder with WinDBG installers for different platforms

WinDBG interface

Figure 4: Appearance of WinDBG

As soon as you first see appearance WinDGB, you will find that the debugger is frighteningly simple. Most of WinDBG's features are learned while debugging the process. 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 has two areas. The first area: a window where the result of command execution 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 out of the box. But one important thing that needs to be configured is the symbols. Symbols are files that are generated with the executable file during compilation of the program and contain debugging information (functions and variable names). Debug information allows you to explore the functionality of your 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 come with the application. In most cases, companies restrict access to such information.

To configure WinDBG to use Microsoft Symbol Server go to File: Symbol File Path and set SRV * C: \ Symbols * http: //msdl.microsoft.com/download/symbols. Of course, it's a little strange that asterisks are used as a separator. After you set up the Microsoft Symbol Server, the symbols are downloaded to the C: \ Symbols folder.

Figure 6: Configuring Microsoft Symbol Server

WinDBG will automatically load symbols for binaries when needed. You can also add your own symbols folder, like this:

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 (a command window will appear when you hook into a 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 will not be superfluous 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 the symbols that can be loaded. You can force the loading of symbols with the ld * command (this can 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 paths:

Hook on an already running process.
Launch the process through WinDBG.

Each method has its own advantages and disadvantages. If, for example, you run the program through WinDBG, then some special debugging options (for example, heap debugging) are available to you, which can lead to the crash of the application. On the other hand, there are also programs that crash when you hook 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 service running under Windows OS, which sets some parameters during startup, so to simplify the debugging process, it is also better to hook to the running process, rather than start the service through the debugger. Some people argue that running a process through the debugger has a serious performance impact. In short, try both and choose what works best for you. If for some reason you prefer a particular method, share your thoughts in the comments!

Process start

If you are debugging a standalone application that is running locally and not networking, you might want to run it through WinDBG. However, this does not mean that you cannot hook onto an already running process. Choose the method that is most convenient for you.

It is not difficult to start the process. Go to "File: Open Executable" and select the executable file you want to debug. You can also provide arguments or set the start directory:

Figure 9: Selecting the executable file for debugging

Process connection

Connecting to an already running process is also not difficult. Note, however, that in some cases it may take a while to find the exact process you want to debug. For example, some browsers create one parent process and then several more processes for each tab. Thus, depending on the crash dump you are debugging, you may want to hook not to the parent process, but to the process associated with the tab.

To hook onto an already running process, go to "File: Attach to a Process" and then select the PID or name of the process. Remember that you need to have the appropriate rights in order to pick up on the process.

Figure 10: Selecting the process to hook onto

If, after connecting, the application has suspended its work, you can use the "Noninvaise" mode by checking the corresponding checkbox.

Debugging a remote process

You may sometimes need to debug a process on a remote system. It would be much more convenient to do this with a local debugger instead of using a virtual machine or RDP. Or maybe you are 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 connect to processes remotely. There are two most common ways to accomplish these tasks.

Existing debug sessions

If you've already started debugging your program locally (by connecting or starting a process through WinDBG), you can enter a specific command and WinDBG will launch a listener to which the remote debugger can connect. 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: A 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: -remote tcp: Port = 5005, Server = USER-PC

Now you can connect from a remote host to an 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: Connecting remotely to a debug session

Once connected, you will receive confirmation on the remote client:

Server started. Client can connect with any of these command lines
0: -remote tcp: Port = 5005, Server = USER-PC
MACHINENAME \ User (tcp 192.168.127.138:13334) connected at Mon Dec 16 09:03:03 2013

and a message to local version debugger:

MACHINENAME \ User (tcp 192.168.127.138:13334) connected at Mon Dec 16 09:03:03 2013

Creating a remote server

You can also create a 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 the remote server

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 by going to the File: Connect to Remote Stub file and entering the following line in the text field: tcp: Port = 5005, Server = 192.168.127.138

Figure 15: Connecting to a 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 the debug server processes (where dbgsrv.exe is running). Now you can hook onto 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 background 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 with 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 the application, you can better understand how it works. In many cases, you will be debugging a specific module loaded by a program, not the executable itself.

After connecting to the process, WinDBG will automatically display the loaded modules. For example, the modules below are shown after I connect to calc.exe:

*** 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 process of debugging, 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 777ba000 LPK C: \ Windows \ system32 \ LPK.dll
777c0000 77860000 ADVAPI32 C: \ Windows \ system32 \ ADVAPI32.dll

You can also find out the load 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 specific module using the! Dh ( 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 of code
C800 size of initialized data
0 size of uninitialized data
510C5 address of entry point
1000 base of code
----- new -----
77550000 image base
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 of image
800 size of 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 address
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
.reloc name
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 connecting to a process, a list of modules is first displayed, and then other messages may appear. For example, when we cling to calc.exe, WinDBG automatically sets a breakpoint (which is just a marker used to stop the application). The breakpoint information is displayed:

(da8.b44): Break instruction exception - code 80000003 (first chance)

This particular message is an exception, namely a first-chance exception. Essentially, an exception is a special condition that occurs during program execution. First-chance exception means that the program stopped immediately after the exception was thrown. 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 prints the state of the processor registers. Registers are special variables inside the processor that store small chunks of information or keep track of the state of something in memory. The processor can process 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 specific register, then we can execute the following command:

0: 005> r eax
eax = 7ffd9000

Information from several registers at the same time can be obtained as follows:

0: 005> r eax, ebp
eax = 7ffd9000 ebp = 02affdc8

Pointer to instruction

The last command is dedicated to executable instructions. Here information is also displayed on the screen, as is the case with the r command, which contains the EIP register. EIP is a register containing the location of the next instruction for the processor to execute. 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 into assembly code and displays it on the screen.

ntdll! DbgBreakPoint:
77663540 cc int 3

stay in touch

In future articles, we'll look at how to use WinDBG in a live environment: breakpoints, step-by-step debugging, and memory scans. Don't switch! J.

These types of faults are usually associated with a faulty driver, which can be difficult to calculate. However, the improved bug tracking system in Windows Vista (and not only in Vista!) Can often lead you to a problematic file. As a result, most people stop frantically trying to work on an unstable computer, saving documents with paranoid regularity and hoping for the best.

At Windows crashes usually a so-called “memory dump” is created. The latter can be investigated with the free debugger Windows tool Debugging Tools, which can direct you to the source of the problem. Therefore, all you need to do is:

Download yourself a debugging tool

You can download Windows Debugging Tools directly from the Microsoft website. The program works with a variety of operating systems from Windows NT 4 to Windows 2008, so you shouldn't have any problems with it. Yes, it cannot be said that it is stable under Windows 7 RC, but according to our tests it still works. Therefore, even an attempt to diagnose the problem from under Windows 7 RC may be successful.

Configure your system

It is necessary that during crashes your computer creates memory dumps, which will later serve as a source of information for the debugger. Therefore, it is important that Windows is configured to generate dumps. To customize your operating system, click right click mouse on Your computer (Computer) and select Properties (Properties). Then click on the Advanced System Settings tab, find the Startup and Recovery Settings subsection and make sure the Write debugging information parameter is set to Kernel memory dump ) or Complete memory dump.

Next, click Start, go to All Programs, select Debugging Tools and launch WinDbg. In the program, go to the File menu and select Symbol File Path ... Then write the following line in the window that opens:

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

The latter defines the path to special data - the so-called "symbols", which can help the debugging tool to identify your faulty file.

After entering the line, click on the OK button. Later, when working with the debugger, this line will download symbols from msdl.microsoft.com and save them to the c: \ symbols folder.

Solve your problem

Now wait for the next crash with a blue screen, and the subsequent completion of the computer restart. Then run WinDbg again (Vista users need to run the program as administrator), click on the File menu, select Open Crash Dump, open the file \ Windows \ MEMORY.DMP, and the program will immediately start analyzing it.

Unfortunately, WinDbg provides very little information about what it does, so you might even think the program is frozen. However, wait. Understand, analyzing, say, 4GB of memory on a not very powerful computer can take some time, up to hours. Therefore, be patient, and it is better to leave the analysis for the night.

However, usually the result is obtained within a few minutes. This is evidenced by the line of the analyzer of the Bugcheck Analysis error, reporting something like "Probably caused by: UACReplace.sys". Translated into Russian, this means that the problem is possibly caused by the UACReplace.sys file. Enter it in a search bar, for example, Google and you will find out its real origin. In particular, if it belongs to one of the programs you have installed or installed driver then you can just try to update her or him. Perhaps this will solve the problems you are having.

I must say that from time to time WinDbg cannot name the file at all, or simply selects one of the Windows DLLs. If this happened for you, then just click on the command window above the status bar and type the command:

Then press Enter. This will provide you with a more detailed report, which may contain information about the possible causes of your troubles.

If this time you are not lucky, do not despair. Debugging is quite difficult, even for experts. So just close WinDbg and run the analyzer again after the next crash. Perhaps this will give you some more information. Good luck!