What is kernel debugging? Windows Kernel Mode Debugging Tools
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.
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 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.
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.
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. Automatically launch 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 of a Microsoft Windows debugger that does almost everything a real system debugger does, including manipulating symbol tables, handling breakpoints, generating disassembler code, and coordinating with a graphical user interface (GUI). When discussing WDBG, we'll show how breakpoints work and discuss what the various symbol files are.
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.
A debugger (debugger, English debugger from bug) is a 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's debuggers are designed for debugging user-mode applications. A prime example of a user-mode debugger is the Microsoft Visual C++ debugger. 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 running in user mode, including any GUI programs, as well as such unusual applications as Windows 2000 services. In general, this type of debugger supports a graphical user interface (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 the virtual machine approach, the virtual machines themselves provide the full debugging environment and do not 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,
// Allocate a new block of 20 bytes.
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 the Windows 2000 boot loader is doing when loading an application (especially if it has a problem), turning on 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. Windows 2000 services and out-of-process COM servers fall into this category. 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 Windows 2000 desktop.
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 the full path to the debugger in the editable field next to this checkbox.
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
In Windows NT 4, the break key shortcut
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 for 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. An analysis of existing solutions for compliance with the requirements was carried out. In particular, special attention is paid 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: writing program code is performed on a full-fledged computer system, debugging is performed on a debugging system, testing is performed 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. While the kernel mode program code 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 to the hard disk into a page file at any time. 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.
This behavior breaks down if the debugger code is forced to use high 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 freely distributed Debugging Tools for Windows package. The 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 its modular structure, Windows Debugger supports third-party modules called extensions in addition to developer-supplied commands. 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 of the working system on the fly 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 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." The latest version of the operating system to be supported 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 of modern versions of Windows are supported.
Currently, Windows Debugger is the main tool among kernel module developers. It is also used by the Windows operating system kernel team.
chPF OELPFPTSCHE KHLBBOYS RP TBVPFE U PFMBDLPK SDTB U BCHBTYKOSHNY DBNRBNY RBNSFY. lBL RTBCHYMP, CHBN OHTSOP VKDEF ЪBDBFSH PDOP YЪ KHUFTPKUFCH RPDLBYULY, RETEYUYUMEOOSCHI CH ZHBKME /etc/fstab . uvtpu pvtbpch RBNSFY O KHUFTPKUFCHB, OE SCHMSAEYEUS KHUFTPKUFCHBNY RPDLBYULY, OBRTYNET, MEOFSHCH, CH DBOOSCHK NPNEOF OE RPDDETSYCHBAFUS.
Note: yURPMSHHKFE LPNBODH dumpon (8) DMS KHLBBOYS SDTH NEUFB, ZDE OHTsOP UPITBOSFSH BCHBTYKOSHCHE DBNRSCH. rPUME OBUFTPKLY RP LPNBODE swapon (8) TBDEMB RPDLBYULY DPMTSOB VSHFSH CHSHCHBOB RTPZTBNNNB dumpon . pVSHYUOP LFP CHSHRPMOSEPHUS ЪBDBOYEN RETENOOOPK dumpdev CH ZHBKME rc.conf (5). еUMY ЪБДБOB ьФБ RATENEOOBS, FP RPUME UVPS RTY RETCHPK NOPZPRPMSHЪPCHBFEMSHULPK RETEЪBZTHЪLE VHDEF BCHFPNBFYUEULY ЪBRHEEOOB RTPZTBNNNB savecore (8). pOB UPITBOIF BCHBTYKOSHCHK DBNR SDTB CH LBFBMPZ, ЪBDBOOSCHK CH RETENEOOOPK dumpdir ZHBKMB rc.conf . rP KHNPMYUBOYA LBFBMPZPN DMS BCHBTYKOSCHI DBNRPCH SCHMSEFUS /var/crash .
mYVP CHSC NPTSEFE ЪBDBFSH KHUFTPKUFCHP DMS UVTPUB PVTBB RBNSFY SCHOP YUETE RBTBNEFT dump CH UFTPLE config LPOZHYZHTBGYPOOPZP ZHBKMB CHBYEZP SDTB. fBLPK URPUPV YURPMSHЪPCHBFSH OE TELPNEODHEFUS Y PO DPMTSEO YURPMSHЪPCHBFSHUS, FPMSHLP EUMY CHSCH IPFYFE RPMKHYUBFSH BCHBTYKOSHCH PVTBYSH RBNSFY SDTB, LPFPTPPE BCHBTYKOP ЪBCHETYBEF UCHPA TBVPFH RTY ЪBZTHЪLE.
Note: dBMEE FETNYO gdb PYOBYUBEF PFMBDYUYL gdb , ЪBRHEEOOSCHK CH ``TETSINE PFMBDLY SDTB". RETEIPD CH LFPF TETSYN DPUFYZBEFUS ЪBRHULPN gdb U RBTBNEFTPN -k . h TETSYNE PFMBDLY SDTB gdb YЪNEOSEF UCHPЈ RTYZMBYEOYE ABOUT (kgdb) .
Tip: Eumi Chechi yurpmshhef FreeBSD Cetui 3 ymi tbooaa, Cheshchiki DPMTSOSH Cheshrpmeifsh Huyuye PFMBDPZP SDTB LPNBODPK STRIP, Hufbobchmychbfsh PFMSHYP PFMBDPUOP:
# cp kernel kernel.debug # strip -g kernel
bFPF YBZ OE FBL KhTS Y OEPVIPDYN, OP TELPNEODKHEN. (PhP FreeBSD 4th VPMEE RPJDOYI TEMYBI LFPF YBZ CHSHRPMOSEFUS BCHFPNBFYUEULY CH LPOGE RTPGEUUB RPUFTPEOOYS SDTB make .) lPZDB SDTP HUEYEOP, BCHFPNBFYUEULY YMY RTY RPNPEY LPNBOD CHCHYE, CHCH NPTSEFE KHUFBOPCHYFSH EZP PVSHYUOSCHN PVTBBPN, OVTTBCH make install .
ъBNEFSHFE, YuFP CH UFBTSHCHETUISI FreeBSD (DP 3.1, OE CHLMAYUBS LFPF TEMY), YURPMSHKHEFUS SDTB CH ZHTNBFE a.out, RPFPNH YI FBVMYGSH UYNCHPMPCH DPMTSOSCH TBURPMBZBFSHUS RPUFPSOOP CH RBNSFY. u VPMSHYPK FBVMYGEK UYNCHPMPCH CH OE HUEYOOOPN PFMBDPUOPN SDTE LFP YЪMYYOSS FTBFB. rPUMEDOYE TEMYYSH FreeBSD YURPMSHJHAF SDTB CH ZHTNBFE ELF, ZHE LFP OE SCHMSEFUS RTPVMENPK.
eUMY CHSH FEUFYTHEFE OPCHPE SDTP, ULBTSEN, OBVYTBS YNS OPCHPZP SDTB CH RTYZMBYYEOYY UBZTHYUYLB, OP CHBN OHTSOP ЪBZTHTSBFSH Y TBVPFBFSH U DTHZYN SDTPN, YUFPVSH UOPChB CHETOHFSHUS L OPTNBMSHOPNH ZHOLGYPOYTPCHBOYA, ЪBZTHTSBKFE EZP FPMSHLP CH PDOPRPMSHЪPCHBFEMSHULPN TETSYNE RTY RPNPEY ZHMBZB -s , KHLBSCCHBENPZP RTY ЪBZTHЪLE , B ЪBFEN CHSHRPMOYFE FBLYE YBZY:
# fsck -p # mount -a -t ufs # so your filesystem for /var/crash is writable # savecore -N /kernel.panicked /var/crash # exit # ...to multi-user
bFB RPUMEDPCHBFEMSHOPUFSH KHLBSCCHBEF RTPZTBNNE savecore (8) ABOUT YURPMSHЪPCHBOYE DTHZPZP SDTB DMS YЪCHMEYUEOYS UYNCHPMYUEULYI YNEO. YOBYUE POB VHDEF YURPMSHЪPCHBFSH SDTP, TBVPFBAEEE CH DBOOSHCHK NPNEOF Y, ULPTEE CHUEZP, OYUEZP OE UDEMBEF, RPFPNH YuFP BCBTYKOSHCHK PVTB RBNSFY YYNCHPMSCH SDTB VHDHF PFMYUBFSHUS.
b FERETSH, RPUME UVTPUB BCHBTYKOPZP DBNRB, RETEKDYFE CH LBFBMPZ /sys/compile/WHATEVER Y ЪBRKHUFYFE LPNBODH gdb -k . yЪ RTPZTBNNSH gdb UDEMBKFE CHPF SFP:
Symbol-file kernel.debug exec-file /var/crash/kernel.0 core-file /var/crash/vmcore.0 Y CHBMS - CHCH NPTSEFE PFMBTSYCHBFSH BCHBTYKOSHK DBNR, YURPMSHЪHS YUIPDOSCH FELUFSCH SDTB FPYuOP FBLCE, LBL CHSHCH LFP DEM BEFE AT MAVPC DTHZPK RTPZTBNNPK.
chPF TsKHTOBM LPNBOD UEBOUB TBVPFSH gdb, YMMAUFTYTHAEIK bfh RTPGEDHTH. dMYOOSCH UFTPLY VSHMY TBPTCHBOSH DMS KHMHYUYEOYS YUYFBVEMSHOPUFY Y DMS KHDPVUFCHB UFTPLY VSHCHMY RTPOKHNETPCHBOSHCH. CHUE PUFBMSHOPE SCHMSEFUS FTBUUYTPCHLPK PYYVLY, TEBMSHOP CHPOYLOKHCHYEK PE CHTENS TBVPFSCH OBD DTBKCHETPN LPOUPMY pcvt.
1:Script started on Fri Dec 30 23:15:22 1994 2: # cd /sys/compile/URIAH 3: # gdb -k kernel /var/crash/vmcore.1 4:Reading symbol data from /usr/src/ sys/compile/URIAH/kernel ...done. 5:IdlePTD 1f3000 6:panic: because you said to! 7:current pcb at 1e3f70 8:Reading in symbols for ../../i386/i386/machdep.c...done. 9: (kgdb) where 10:#0 boot (arghowto=256) (../../i386/i386/machdep.c line 767) 11:#1 0xf0115159 in panic () 12:#2 0xf01955bd in diediedie ( ) (../../i386/i386/machdep.c line 698) 13:#3 0xf010185e in db_fncall () 14:#4 0xf0101586 in db_command (-266509132, -266509516, -267381073) 15:#5 0x f0101711 in db_command_loop () 16:#6 0xf01040a0 in db_trap () 17:#7 0xf0192976 in kdb_trap (12, 0, -272630436, -266743723) 18:#8 0xf019d2eb in trap_fatal (...) 19:#9 0xf0 19ce60 in trap_pfault ( ...) 20:#10 0xf019cb2f in trap (...) 21:#11 0xf01932a1 in exception:calltrap () 22:#12 0xf0191503 in cnopen (...) 23:#13 0xf0132c34 in spec_open () 24: #14 0xf012d014 in vn_open () 25:#15 0xf012a183 in open () 26:#16 0xf019d4eb in syscall (...) 27: (kgdb) up 10 28:Reading in symbols for ../../i386/i386 /trap.c...done. 29:#10 0xf019cb2f in trap (frame=(tf_es = -260440048, tf_ds = 16, tf_\ 30:edi = 3072, tf_esi = -266445372, tf_ebp = -272630356, tf_isp = -27\ 31:2630396, t f_ebx = - 266427884, tf_edx = 12, tf_ecx = -266427884, tf\ 32:_eax = 64772224, tf_trapno = 12, tf_err = -272695296, tf_eip = -26\ 33:6672343, tf_cs = -26646936 8, tf_eflags = 66066, tf_esp = 3072, tf_\ 34:ss = -266427884)) (../../i386/i386/trap.c line 283) 35:283 (void) trap_pfault(&frame, FALSE); 36: (kgdb) frame frame->tf_ebp frame->tf_eip 37:Reading in symbols for ../../i386/isa/pcvt/pcvt_drv.c...done. 38:#0 0xf01ae729 in pcopen (dev=3072, flag=3, mode=8192, p=(struct p\ 39:roc *) 0xf07c0c00) (../../i386/isa/pcvt/pcvt_drv.c line 403) 40:403 return ((*linesw.l_open)(dev, tp)); 41: (kgdb) list 42:398 43:399 tp->t_state |= TS_CARR_ON; 44:400 tp->t_cflag |= CLOCAL; /* cannot be a modem (:-) */ 45:401 46:402 #if PCVT_NETBSD || (PCVT_FREEBSD >= 200) 47:403 return ((*linesw.l_open)(dev, tp)); 48:404 #else 49:405 return ((*linesw.l_open)(dev, tp, flag)); 50:406 #endif /* PCVT_NETBSD || (PCVT_FREEBSD >= 200) */ 51:407 ) 52: (kgdb) print tp 53:Reading in symbols for ../../i386/i386/cons.c...done. 54:$1 = (struct tty *) 0x1bae 55: (kgdb) print tp->t_line 56:$2 = 1767990816 57: (kgdb) up 58:#1 0xf0191503 in cnopen (dev=0x00000000, flag=3, mode=8192 , p=(st\ 59:ruct proc *) 0xf07c0c00) (../../i386/i386/cons.c line 126) 60: return ((*cdevsw.d_open)(dev, flag, mode, p) ); 61: (kgdb) up 62:#2 0xf0132c34 in spec_open () 63: (kgdb) up 64:#3 0xf012d014 in vn_open () 65: (kgdb) up 66:#4 0xf012a183 in open () 67: (kgdb) up 68:#5 0xf019d4eb in syscall (frame=(tf_es = 39, tf_ds = 39, tf_edi =\ 69: 2158592, tf_esi = 0, tf_ebp = -272638436, tf_isp = -272629788, tf\ 70:_ebx = 7086 , tf_edx = 1, tf_ecx = 0, tf_eax = 5, tf_trapno = 582, \71:tf_err = 582, tf_eip = 75749, tf_cs = 31, tf_eflags = 582, tf_esp \72:= -272638456, tf_ss = 39)) (. ./../i386/i386/trap.c line 673) 73:673 error = (*callp->sy_call)(p, args, rval); 74: (kgdb) up 75:Initial frame selected; you cannot go up. 76: (kgdb) quit 77: # exit 78:exit 79: 80:Script done on Fri Dec 30 23:18:04 1994
lPNNEOFBTYY L CHSHCHYYERTYCHEDEOOPNH TSHTOBMKH:
UFTPLB 6:
ьФП DBNR, CHSFSHCHK RTY RPNPEY DDB (UNPFTY OITSE), RPPFPNH LPNNEOFBTYK L BCHBTYKOPNH PUFBOPCHH YNEEF YNEOOP CHYD ``because you said to!'' Y FTBUUYTPCHLB UFELB ZMHVPLB; PDOBLP YOBYUBMSHOPK RTYYUYOPK RETEIPDB CH DDB VSHMB BCHBTYKOBS PUFBOPCHLB RTY CHPOYLOPCHEOYA PYYVLY UFTBOIGSC RBNSFY.
UFTPLB 20:
lFP NEUFPOBIPTSDEOOYE ZHKHOLGYY trap() CH FTBUUYTPCHLE UFELB.
UFTPLB 36:
rTYOKHDIFEMSHOPE YURPMSHЪPCHBOIE OPChPK ZTBOYGSCH UFELB; FERTSH LFP OE OHTSOP. rTEDRPMBZBEFUS, YuFP ZTBOYGSCH UFELB KHLBSCCHBAF ABOUT RTBCHYMSHOP TBURPMPTSEOYE, DBCE CH UMHUBE BCHBTYKOPZP PUFBOPCHB. zMSDS ABOUT UFTPLH YUIPDOPZP LPDB 403, NPTsOP ULBBFSH, YuFP CHEUSHNB CHETPSFOP, YuFP MYVP CHYOPCHBF DPUFHR RP KHLBBFEMA ``tp"", MYVP VSHM CHSHCHIPD ЪB ZТBOYGSC NBUUYCHB.
UFTPLB 52:
rPIPTSE, YuFP CHYOPCHBF KHLBBFEMSH, OP ON SCHMSEFUS DPRKHUFYNSCHN BDTEUPN.
UFTPLB 56:
pDOBLP, PYUECHYDOP, YuFP PO KHLBSHCHCHBEF ABOUT NHUPT, FBL YuFP NSCH OBYMY OBYKH PYYVLH! (DMS FEI, LFP OE ЪOBLPN U LFPC YUBUFSHHA LPDB: tp->t_line UMHTSYF DMS ITBOEOYS TETSYNB LBOBMMB LPOUPMSHOPZP KHUFTPKUFCHB, Y LFP DPMTSOP VShchFSH DPUFBFPYuOP NBMEOSHLPE GEMPE YUYUMP. )