To debug the kernel, you must connect to your computer using a null modem cable or modem connection. The computer performing debugging will be called “Host”, and the problem computer will be called “Target”.
Both computers must be running the same version of Windows, and the symbol files for the Target computer must be installed on the Host computer. The symbol files are provided on the Windows installation CD in the Support\Debug directory.
To enable debugging, you must make changes to the BOOT.INI file on the Target computer.
1. Change the attributes of the BOOT.INI file:
attrib c:\boot.ini –r –s
2. Edit this file and into the line Windows startup add the /debug parameter (to tell the system to boot into RAM kernel debugger booting Windows). Additional parameters are /Debugport, which tells the system which COM port must be used (COM2 by default) and /Baudrate - to specify the data transfer rate (the default is 19200 baud, but it is better to use 9600). For example:
multi(0)disk(0)rdisk(0)partition(0)\WINDOWS="Windows NT" /debug /debugport=com2 /baudrate=9600
3. Save the file.
4. Set the previous BOOT.INI file attributes:
attrib c:\boot.ini +r +s
In this example, the Target computer allowed a connection through COM2 at 9600 bps.
The Host computer must be configured with the settings required for debugging. In addition, the symbol files must be installed. To install them, go to the \support\debug directory on the installation CD and enter the following command:
expndsym
For example:
expndsym f: d:\symbols
Installation may take some time. Remember that if service packs have been installed on the Target computer, the symbol files for those packages must also be installed on the Host computer. Symbol files for update packages can be downloaded from the Microsoft website.
The next step is to set up the environment variables needed for debugging, such as variables indicating the location of symbol files, etc. The following is a description of these variables.
Description of system variables
The definition of these variables can be placed in batch file in order to avoid entering the corresponding commands at each boot:
echo off
set_nt_debug_port=com2
set_nt_debug_baud_rate=9600
set _nt_symbol_path=d:\symbols\i386
set _nt_log_file_open=d:\debug\logs\debug.log
Now you need to copy the kernel debugging software, which is located in the support\debug\ directory<процессор>on the installation CD (support\debug\I386). The easiest way is to copy the entire directory, since it is small in size (about 2.5 MB). For the I386 platform, a debugger is used, which is supplied as the I386KD.EXE file. The debugger is launched using the I386KD command. To enter a command, press the key combination
Kernel mode debuggers sit between the CPU and the operating system. This means that when you stop the kernel mode debugger, the operating system also stops completely. It is not difficult to imagine that the transition operating system to hard stop is useful when you are working with timers and timing issues. However, with the exception of one debugger, which will be discussed below (in the "SoftlCE Debugger" section of this chapter), you cannot debug user-mode code using kernel-mode debuggers.
There are not many kernel mode debuggers. Here are some of them: Windows 80386 Debugger (WDEB386), Kernel Debugger (1386KD), WinDBG and SoftlCE. Each of these debuggers is briefly described in the following sections.
Debugger WDBEB386
WDEB386 is a Windows 98 kernel mode debugger distributed as part of the Platform SDK. This debugger is only useful for developers writing virtual drivers. Windows devices 98 (VxD). Like most kernel mode debuggers for Windows operating systems, the WDEB386 debugger requires two machines and a null modem cable to operate. Two machines are needed because the part of the debugger that runs on the target machine has limited access to its hardware so that it sends its output and receives commands from the other machine.
The WDEB386 debugger has interesting story. It started out as an internal background tool for Microsoft during the Windows 3.0 era. It was difficult to use and did not have enough support for debugging source code and other nice properties that the Visual C++ debuggers spoiled us with Visual Basic.
"Dot" (DOT) commands are the most important feature WDEB386. Through interrupt INT 41, the WDEB386 can be expanded to add commands. This extensibility allows VxD driver authors to create custom debugging commands that give them easy access to information in their virtual devices. Debug Windows version 98 supports a variety of DOT commands that allow you to observe the exact state of the operating system at any point in the debugging process.
Debugger I386KD
Windows 2000 differs from Windows 98 in that the actual working part of the kernel mode debugger is the NTOSKRNL part. EXE - file of the main operating kernel Windows systems 2000. This debugger is available in both free (release) and tested (debug) operating system configurations. To enable kernel mode debugging, set the bootloader option /DEBUG to BOOT. INI and, additionally, the bootloader option /DEBUGPORT, if you need to set the kernel mode debugger communication port to a value other than the default (COM1). I386KD runs on its own machine and communicates with Windows machine 2000 via a null modem cable.
Kernel mode debugger NTOSKRNL. The EXE does only enough to control the CPU so that the operating system can be debugged. Most of the debugging work - symbol processing, extended breakpoints and disassembly - is done on the 1386KD side. One Windows time The NT 4 Device Driver Kit (DDK) documented the protocol used in the null modem cable. However, Microsoft no longer documents it.
The power of the 1386KD is obvious when you look at all the commands it offers to access the internal state of Windows 2000. Knowing how device drivers work in Windows 2000 will help a programmer monitor the output of many commands. Despite all its power, i386KD is almost never used because it is a console application, which is very tedious to use for baseline debugging.
How to start the kernel debugger?
Master's answer:
There is one very important component in the software development process - debugging. Towards application programs it is carried out by tools that run in user mode and are often built into the IDE. In order to be able to debug, for example, drivers, you need to run the kernel debugger.
You need to start the cmd command processor. Open the Start menu on the taskbar. In the window that appears, click on the “Run…” item. The “Run Program” window will appear. In the text box, enter cmd, then click OK.
Now create backup copy boot.ini file. First find out the installation path of the current copies of Windows, using the command: echo %SystemRoot%
Next, go to the disk with the installed operating system by entering the device letters, followed by a colon. Using the cd command, go to the root directory. Now, using the attrib command, remove the "hidden", "read-only" and "system" attributes from the boot.ini file. Use the copy command to create a backup copy, and then set the attributes in place.
To display the current list of boot options, use the bootcfg /query command. Look through the list and determine the element on the basis of which new settings will be created with the ability to debug in kernel mode. The boot entry ID should be remembered.
Use the bootcfg/copy command to create a boot entry. To specify the ID of the record you will copy, use the /id parameter. Using the /d option, specify the name of the entry that will be displayed. Now you need to go back to the list of boot options using the bootcfg /query command, and look at the ID of the added entry.
Now you need to enable options for launching the kernel debugger in the previously created boot entry. If you will be debugging on the target machine, you just need to add the /debug option.
If you want to perform remote debugging by connecting the target computer via a com port to the host machine, then use the /port and /baud options to specify the port number and baud rate.
If you will be performing remote debugging via a FireWire cable (IEEE 1394 interface), then use the /dbg1394 option to enable the corresponding mode and the /ch option to specify the channel number.
To ensure that the changes have been made, check your boot files using the bootcfg command with the /query parameter. After executing the exit command, close the shell window.
If necessary, change the operating system boot settings. Open the Control Panel through the Start menu, and in it open the System item. In the “System Properties” window that opens, select the “Advanced” tab. In this tab, select the section called “Boot and Recovery” and click on the “Options” button. In the “Boot and Recovery” window that appears, you need to activate the “Display list of operating systems” option. Close both dialog boxes with the OK button.
Restart your computer. Select boot with debugger. Log in and start working on the target machine or start debugging remotely. Use tools such as WinDbg and KD.
Introduction
1. Types of Windows debuggers
2. User mode debuggers
3. Kernel mode debuggers
3.1 WDEB386 Debugger
3.2 Debugger I386KD
3.3 Win DBG Debugger
3.4 SoftICE Debugger
4. General debugging issue
5. Automatic start applications in the debugger
5.1 Interrupt shortcut keys
Conclusion
Literature
Introduction
Learning how software tools work is the most difficult part of the debugging process. Only by understanding the capabilities and limitations of tools can you get more out of them and spend less time debugging. In general, debuggers are extremely useful, but can lead to rather subtle problems that lead the programmer to a dead end. This chapter shows what a debugger is and how various debuggers work on Win32 operating systems (Microsoft's 32-bit Windows operating systems).
At the same time, we will focus on those special properties of debuggers in general that are enabled when some software process is running under the control of the latter. It also explains how you can enhance certain features of 32-bit Windows operating systems to make debugging easier. Two proprietary debuggers will be presented, the source code for which can be found on the accompanying CD. The first (MinDBG) has sufficient capabilities to be called a debugger. The second (WDBG) is an example debugger Microsoft Windows, which does almost everything a real system debugger does, including manipulating symbol tables, handling breakpoints, generating disassembler code, and coordinating with the graphical user interface (GUI). When discussing WDBG, we'll show how breakpoints work and discuss what breakpoints are. various files symbols (symbol files).
Before moving on to the main material of this chapter, let's define two standard terms that will be used frequently in this book: main (or base) debugger (debugger) and subordinate debugger (debuggee). In simple terms, a master debugger is a process that can debug-control another process, and a slave debugger is a process that runs underneath the master debugger. On some operating systems, the main debugger is called the parent process, and the slave debugger is called the child process.
Debugger (debugger, English debugger from bug) - computer program, designed to find errors in other programs, operating system kernels, SQL queries and other types of code. The debugger allows you to trace, monitor, set or change variable values as code runs, set and remove breakpoints or stopping conditions, and more.
Most developers are more familiar with user-mode debuggers. Not surprisingly, this mode debuggers are designed for debugging user-mode applications. A prime example of a user mode debugger is the debugger Microsoft Visual C++. Kernel mode debuggers, as their name suggests, are debuggers that allow you to debug the operating system kernel. They are used primarily by those who write (and debug, of course) device drivers.
2. User mode debuggers
User-mode debuggers are designed to debug any application that runs in user mode, including any GUI programs, as well as such unusual applications as Windows 2000 services. In general, debuggers of this type support GUI user (GUI1). The main feature of such debuggers is that they use the Win32 debug application programming interface (debug API). Because the operating system marks a slave debugger as "running in special mode," you can use the IsDebuggerPresent API function to find out whether your process is running under a debugger.
When supplying the Win32 debugging API, there is an implied convention: once a process is running under the debugging API (and thus makes it a slave process), the main debugger cannot detach from that process. This symbiotic relationship means that if the master debugger exits, the slave debugger exits as well. The master debugger is limited to debugging only the slave debugger and any processes it spawns (if the master debugger supports child processes).
GUI - Graphical User Interface. - Per.
For interpreted languages and run-time systems that use a virtual machine approach, a complete debugging environment is provided themselves virtual machines, and they don't use the Win32 debugging API. Some examples of these types of environments are the Java virtual machines (JVMs) from Microsoft or Sun, the scripting environment for Web applications from Microsoft, and the p-code interpreter in Microsoft Visual Basic.
debugger kernel operating system
We'll get to debugging in Visual Basic in Chapter 7, but be aware that the Visual Basic p-code interface is not documented. We won't delve into Java and scripting debugging interfaces; those topics are beyond the scope of this book. For more information on debugging and profiling the Microsoft JVM, see Debugging and Profiling Java Applications on MSDN. The set of such interfaces is very rich and varied and allows you to completely control the operation of the JVM. For information about writing a script debugger, see the MSDN topic "Active Script Debugging API Objects." Like the JVM, script debugger objects provide a rich interface for script access and documentation.
A surprising number of programs use the Win32 debugging API. These include: the Visual C++ debugger, which is covered in detail in Chapters 5 and 6; the Windows debugger (WinDBG), which is discussed in the next section (on the kernel-mode debugger); BoundsChecker program from Compuware NuMega; Platform SDK HeapWalker program; Platform SDK Depends program; Borland Delphi and C++ Builder debuggers, as well as the NT Symbolic Debugger (NTSD). I'm sure there are many more.
3. Kernel mode debuggers
Kernel mode debuggers sit between the CPU and the operating system. This means that when you stop the kernel mode debugger, the operating system also stops completely. It's easy to see that bringing the operating system to a hard stop is useful when you're working on timers and timing issues. However, with the exception of one debugger, which will be discussed below (in the "SoftlCE Debugger" section of this chapter), you cannot debug user-mode code using kernel-mode debuggers.
There are not many kernel mode debuggers. Here are some of them: Windows 80386 Debugger (WDEB386), Kernel Debugger (1386KD), WinDBG and SoftlCE. Each of these debuggers is briefly described in the following sections.
3.1 WDEB386 Debugger
WDEB386 is a Windows 98 kernel mode debugger distributed as part of the Platform SDK. This debugger is only useful for developers writing Windows 98 virtual device drivers (VxD). Like most kernel mode debuggers for Windows operating systems, the WDEB386 debugger requires two machines and a null modem cable to operate. Two machines are needed because the part of the debugger that runs on the target machine has limited access to its hardware, so it sends its output to and receives commands from the other machine.
The WDEB386 debugger has an interesting history. It started out as an internal background tool for Microsoft during the Windows 3.0 era. It was difficult to use and lacked sufficient support for source code debugging and other nice features that the Visual C++ and Visual Basic debuggers had spoiled us with.
"Dot" (DOT) commands are the most important feature of the WDEB386. Through interrupt INT 41, the WDEB386 can be expanded to add commands. This extensibility allows VxD driver authors to create custom debugging commands that give them easy access to information in their virtual devices. The debug version of Windows 98 supports many DOT commands that allow you to observe the exact state of the operating system at any point in the debugging process.
3.2 Debugger I386KD
Windows 2000 differs from Windows 98 in that the actual working part of the kernel mode debugger is the NTOSKRNL part. EXE - the file of the main kernel of the Windows 2000 operating system. This debugger is available in both free (release) and tested (debug) operating system configurations. To enable kernel mode debugging, set the bootloader option /DEBUG to BOOT. INI and, additionally, the bootloader option /DEBUGPORT, if you need to set the kernel mode debugger communication port to a value other than the default (COM1). I386KD runs on its own machine and communicates with the Windows 2000 machine via a null modem cable.
Kernel mode debugger NTOSKRNL. The EXE does only enough to control the CPU so that the operating system can be debugged. Most of the debugging work - symbol processing, extended breakpoints and disassembly - is done on the 1386KD side. At one time, the Windows NT 4 Device Driver Kit (DDK) documented the protocol used in the null modem cable. However, Microsoft no longer documents it.
The power of the 1386KD is obvious when you look at all the commands it offers to access the internal state of Windows 2000. Knowing how device drivers work in Windows 2000 will help a programmer monitor the output of many commands. Despite all its power, i386KD is almost never used because it is a console application, which is very tedious to use for baseline debugging.
3.3 Win DBG Debugger
WinDBG is a debugger that comes as part of the Platform SDK. You can also download it from #"897008.files/image001.gif">
Figure 1. Output of the GFLAGS program. EXE
Listing 4-1. Example of Windows 2000 heap destruction
void main (void)
HANDLE hHeap = HeapCreate (0, 128, 0);
// Allocate memory for a block of 10 bytes.
LPVOID pMem = HeapAlloc(hHeap, 0.10);
// Write 12 bytes into a 10-byte block (heap overflow).
memset (pMem, OxAC,
// Distribute new block 20 bytes in size.
LPVOID pMem2 = HeapAlloc(hHeap, 0, 20);
// Write 1 byte to the second block.
char * pUnder = (char *) ((DWORD) pMem2 - 1);
// Free the first block. This appeal to HeapFree will be
// trigger a breakpoint in the debug heap code
// operating system.
HeapFree(hHeap, 0, pMem);
// Free the second block. Note that this call will not
// issue error messages
HeapFree(hHeap, 0, pMem2);
// Free the dummy block. Note that this call will not
// issue error messages
If you check the same boxes as in Fig. 4.1 and repeat the execution of HEAPER. EXE, you will get the following, more verbose output:
PAGEHEAP: process 0x490 created debug heap 00430000
(flags 0xl, 50, 25, 0, 0): process 0x490 created debug heap 00CF0000
(flags Oxl, 50, 25, 0, - 0): process 0x490 created debug heap 01600000
(flags Oxl, 50, 25, 0, 0): Tail fill corruption detected:at 0x01606FF0size 0x0000000Asize 0x00000010at Ox01606FFA: Attempt to reference block which is not allocated
The contents of the listing are explained by the names of the flags set by the Global Flags panel.
Discussing the GFLAGS program. EXE, I want to point out one very useful option - Show Loader Snaps. If you check this box and run the application, you will see what is called a snapshot of the application, which shows where Windows 2000 loads the DLL files and how it begins organizing the import. If you need to see exactly what is doing Windows boot loader 2000 when loading an application (especially if there is a problem with it), then enabling this option can be a very useful step. For more information on bootloader snapshots, see Matt Pietrek's "Under the Hood" column in the September 1999 issue of Microsoft Systems Journal.
5. Automatically launch applications in the debugger
The most difficult types of applications to debug are those that are launched by another process. This category is attacked Windows services 2000 and out-of-process COM servers (COM out-of-process servers). To force a debugger to attach to a process, in many cases you can use the DebugBreak API function. In two cases, however, this function will not work. First, it sometimes doesn't work with Windows 2000 services. If you need to debug the startup of a service, calling DebugBreak will attach the debugger, but by the time the debugger starts, the service may have timed out and Windows 2000 will stop it. Secondly, DebugBreak will not work when you need to debug an out-of-process COM server. If you call DebugBreak, the COM error handler will catch the breakpoint exception and terminate the COM server. Fortunately, Windows 2000 allows you to specify that the application should start in the debugger. This property allows you to start debugging right from the first instruction. However, before you enable this property for a Windows 2000 service, make sure that the service is configured to communicate with the worker Windows table 2000.
The Run with Debugger property can be enabled in two ways. The easiest one is to run the GFLAGS utility. EXE and select the radio button ImageFile Options(see Fig. 4.1). After entering in the editable field I mageFileName program binary file name check box Debugger in Group Image DebuggerOptions) and enter in the editable field next to this checkbox full path to the debugger.
A more difficult method: you need to manually set the necessary parameters in the appropriate registry sections (using the RegEdit editor). Under_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NTXCurrent Version\Image Tile Execution Options
create a subkey whose name is the same as the file name of your application. For example, if the application name is FOO. EXE, then the registry subkey name is also FOO. EXE. In this subkey, create a new string parameter named Debugger. In the Edit String Parameter dialog box, type the full (including directory path) file name of the debugger you selected. If you specified GFLAGS. EXE and set some global options, you will notice the string value GiobaiFiag in your application key.
Now when you start your application, the debugger is automatically loaded and launched. Command line options for the debugger can also be specified in the Debugger string parameter (following the debugger program name). For example, in order to use the WinDBG debugger and automatically initiate debugging as soon as WinDBG starts, you need to enter the value d: \platform sdk\bin\windbg in the dialog box for changing the Debugger string parameter. exe-g.
5.1 Interrupt shortcut keys
Sometimes you need to quickly jump into the debugger. If you are debugging console applications, then keystrokes
A useful feature of both Windows 2000 and Windows NT 4 is the ability to switch to the debugger at any time, also in GUI applications. When running under the debugger, pressing the key
On Windows NT 4 shortcut key interrupts
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\AeDebug
Set the userDebuggerHotKey parameter to the key code (VK_*). For example, to use the key
Conclusion
We looked at the basic features of debugging, its types and types, the general issue of debugging, as well as errors and how to detect them.
Existing debuggers play an important role in software development when searching logical errors, providing a wide range of tools including source code support, application execution tracing, dynamic memory modification, etc. etc.
Literature
1.. aspx?.aspx?id=553022>
2. https://ru. wikipedia.org/wiki/%D0%9E%D1%82%D0%BB%D0%B0%D0%B4%D1%87%D0%B8%D0%BA
http://bourabai. kz/alg/debug4. htm
4. Kostyukhin K. - DEBUGING REAL TIME SYSTEMS. Review
- Authors:
Barinov S.S., Shevchenko O.G.
- Year:
- Source:
Informatics and computer technologies / Materials of the VI international scientific and technical conference of students, graduate students and young scientists - November 23-25, 2010, Donetsk, DonNTU. - 2010. - 448 p.
annotation
A comparative analysis of debugging user mode and kernel mode in relation to the Microsoft Windows operating system is provided, the differences and problems of organizing debugging of the latter are highlighted. Based on the results obtained, the basic requirements for building kernel mode debuggers in the event of emergency and interactive debugging are formulated. Analysis carried out existing solutions for compliance with requirements. In particular, Special attention dedicated to the Microsoft Windows Debugger.
Main part
Debugging is the process of identifying and eliminating the causes of errors in software. In some projects, debugging takes up to 50% of the total development time. Debugging can be greatly simplified by using specialized tools that are constantly being improved. The main such tool is a debugger, which allows you to control the execution of software, monitor its progress and interfere with it. Kernel debugging tools are primarily used by driver developers.
Application software development tools offer the programmer a wide range of possibilities. Any integrated development environment includes the ability to debug without the need to use third party utilities. If we are talking about system software and driver development in particular, then due to its specifics, the development process is extremely difficult and little automated. All development phases, including debugging, are separate. To carry out each of them, special conditions are required: the writing of program code is carried out on a full scale computer system, debugging - on a debug system, testing - depending on the circumstances, etc. The kernel mode debugger itself is more difficult to learn and, accordingly, less friendly.
In general, we can talk about the lack of kernel debugging tools. Although such means are available, there is often no talk about alternatives. For example, the Microsoft Windows Debugger has a very high entry threshold. Many programmers talk about the first negative experience when meeting it, and most of its capabilities remain unclaimed.
Based on the structure of the virtual address space, if an application makes an error that causes the application to write data to an arbitrary memory location, the application will only damage its own memory and will not affect the operation of other applications and the operating system. Whereas program code kernel mode is able to damage important data structures of the operating system, which will inevitably lead to a general failure. An ineffectively written driver can also cause serious degradation of the entire operating system.
- Modern debuggers provide the following basic functions:
- debugging at the source code level;
- execution management;
- viewing and changing memory;
- viewing and changing the contents of processor registers;
- viewing the call stack.
To make it easier to work with disassembled code, the so-called. debugging symbols. While the linker is running, in addition to the image of the executable file, a data file can also be created containing information that is not required when executing the program, but is extremely useful when debugging it: names of functions, global variables, descriptions of structures. Debugging symbols are available for all Windows operating system executables.
Execution control refers to the ability to interrupt and resume execution of program code upon reaching a specified command in the program code. If the program code is executed in step-by-step mode, an interrupt occurs for each programming language token or when exiting a subroutine. In free execution, execution interruptions occur in predetermined sections of code - places where breakpoints are set.
When interrupting kernel mode code, the following dilemma arises. The debugger uses a user interface to interact with the programmer. Those. at least the visible part of the debugger runs in user mode and naturally uses an application programming interface (Windows API), which in turn relies on kernel mode modules, to build it. Thus, pausing kernel mode code can result in a deadlock: the system will stop responding to user requests.
To access kernel memory, parts of the debugger must also run in kernel mode. This leads to two problems at once, which are an obvious consequence of organizing memory in the processor's protected mode.
The first problem concerns the translation of virtual memory addresses. Drivers constantly interact with user-mode applications by accessing their memory. The Windows operating system translates virtual addresses into physical ones based on the concept of thread context. Thread context is a structure that reflects the state of a thread and includes, in particular, a set of registers and some other information. When control is transferred to another thread, a context switch occurs, which saves information about one thread and restores information about another. When a thread's context is switched to another process's thread, the page directory used to translate virtual addresses into physical ones also switches.
The peculiarity is that when dispatching system calls, the Windows operating system does not switch the context. This allows kernel-mode code to use user-mode virtual addresses.
The situation is different when dispatching interrupts or executing system threads. An interrupt can occur at any time, so there is no way to predict which thread context will be used. System threads do not belong to any process and cannot translate user-mode virtual addresses. It follows that user mode memory cannot be accessed in these situations.
The second problem is accessing relocatable memory. Most of the information in memory is relocatable and can be moved from physical memory on HDD to a page file. If a page is accessed that is not in physical memory, the processor would normally generate a Page Fault interrupt, which would be handled by the memory manager, resulting in the page being read from the page file and loaded into physical memory.
The described behavior breaks down if the debugger code is forced to use high level interrupt request levels (IRQL). If the IRQL matches or exceeds the IRQL of the memory manager, the latter will not be able to load the missing page, because the operating system will block the Page Fault interrupt. This will cause the operating system to crash.
Debugging is usually divided into interactive and emergency. In interactive local debugging, the debugger runs on the same system as the debugger. In interactive remote debugging, the debugger and the debug object run on different systems. When debugging kernel code, the system must be controlled starting from the first stages of its boot, when the network is not yet functioning, therefore, simple serial interfaces such as COM, FireWire, USB are used to communicate between systems. Recently, thanks to the development trends of software virtualization at different levels of abstraction, virtual machines are increasingly being used. The guest OS acts as the debug OS, the hosted OS includes a debugger user interface.
Therefore, emergency debugging does not require the debugging tool to be installed on the test computer. The Windows operating system distribution includes mechanisms for implementing emergency debugging. Before rebooting, the operating system can save information about its state, which the developer can analyze and find out the reason. Such information saved to a file is called a memory dump.
Basic kernel mode debugging tools are provided by the Windows operating system manufacturer itself as part of the free Debugging Tools package. for Windows" Tools include graphical and console debuggers WinDbg and KD respectively (hereinafter referred to as Windows Debugger). The work of these debuggers is based on mechanisms provided by the operating system developers and embedded in its kernel.
The main mode for Windows Debugger is command interpreter mode. Thanks to the modular structure, along with those supplied by the developers Windows commands Debugger supports third party modules called extensions. In fact, most built-in commands are also packaged as extensions.
Windows Debugger is focused on remote interactive and emergency debugging, which, when used, reveals all its capabilities. At the same time, full local interactive debugging is not supported: the debugger only allows you to view some kernel structures.
There is an extension module for Windows Debugger called LiveKD, created by Mark Russinovich, which in a sense implements local interactive debugging. LiveKD creates a memory dump on the fly working system and uses it for debugging.
The Debugging Tools for Windows package is regularly updated and supports all modern Windows operating systems.
The SoftICE kernel debugger, produced by Compuware in the DriverStudio software package, has traditionally been an alternative to the Debugging Tools for Windows package. A distinctive feature of SoftICE was the implementation of local interactive debugging on a supported hardware. The debugger could almost completely control the operation of the operating system.
As of April 3, 2006, sales of the DriverStudio family of products were discontinued due to "a variety of technical and business issues, as well as general market conditions." Latest version The operating system for which support has been implemented is Windows XP Service Pack 2. Typically, service packs do not change the application interface of the operating system, but system call numbers and other undocumented information may change. The SoftICE debugger relied on hard-coded addresses of internal data structures. As a result, compatibility was broken with the release of Service Pack 3. Obviously, later versions of the Windows operating system are also not supported.
Syser Kernel Debugger was created by a small Chinese company Sysersoft as a replacement for the SoftICE debugger. The first final version was released in 2007. Like SoftICE, Syser Kernel Debugger is capable of interactive debugging on a running system. Only 32-bit editions are supported modern versions Windows.
On this moment Windows Debugger is a staple tool among kernel module developers. It is also used by the Windows operating system kernel team.
Loading...