Chapter 1 Windows 2000 support for debugging technology
Translation: kendiv (fcczj@263.net)
Update:
Friday, January 14, 2005
Home page:
http://www.orgon.com/w2k_internals/
This book electronic version of the download address:
http://www.volynkin.com/references.htm
Disclaimer: Please indicate the source and guarantee the integrity of the article, and all rights to the translation.
I hope that these translations can help everyone, my E text is not very strong, so the speed of translation is not very fast, I try to guarantee the least daily increase in new translation, I will still come back frequently. Some modifications, in addition, in translation, some non-technical content, I will omit or do not translate (low level, the translation is laborious, huh). I hope everyone will advise.
To all the people in the world who never stopped ask "why"
Although many of the contents in this book are called "undocumented", some of them can only be obtained by tapping the code of the operating system. Windows 2000 DDK (Device Driver Kit) provides a powerful debugger to complete this work. This chapter will introduce from the establishment of a perfect debugging environment. When reading the subsequent chapters, you will often use the kernel debugger to dig all the features within the operating system. If you are very bored by the kernel, you may make a debug tool. Therefore, this chapter will also introduce documentation and unadoculated information about the Windows 2000 debug interface, including the details of the Microsoft Symbol File. The features of this chapter provide two sample libraries and example programs for listing processes, processes, and system modules, and hidden in Windows 2000 symbol files. As a special gain, at the end of this chapter, you will get the first public document on the PDB (Microsoft Program Database).
Establish a debugging environment
"Hey, I don't want to debug the Windows 2000 program. Before this, I want to write a first!" When you read this title, you may shout this. "Very right!" I said, "This is what you should do!" But why do you want to start this trip this time? The answer is simple: the debugger is the back door of the system. Of course, this is not the main purpose of debugger developers. However, when you track the execution of the code or your program is completed, any excellent debugger must tell you some useful system information. Just report a 8-bit crash address pointing to the 4GB address space, then let you go alone, what happened, it is impossible to accept it. The debugger should at least tell you the code in which module is executed in the final error code, and it is also ideally, it should also tell you the name of the function that makes your program. Therefore, the debugger usually must know the system information than the programming manual, you can use this information to study the internal conditions of the system.
Windows 2000 provides two debuggers: windbg.exe (pronunciation is very like "Windbag", translation: Windbag refers to empty talks in slang) A Win32 GUI program and i386kd.exe a command line mode for equivalent functionality program. I have used these two programs at the same time, and finally determine i386kd.exe is the best one because it has a very powerful option. However, it seems that windbg.exe seems to have improved recently. However, all examples in this book are related to i386kd.exe. As you guess, I386 prefix indicates the target platform (Intel 386 processor family, including Pentium) Kd is an abbreviation for the Kernel Debugger. The Windows 2000 kernel debugger is a very powerful tool. For example, he knows how to use the Symbol file in the Windows 2000 installation of the CD, so you can give the relevant symbolic information of almost any address in the system memory (which is very valuable). Moreover, it can also refactors binary code, display the 16-encycloped dump data of memory information in a variety of formats, and even display some layout of kernel key structures. There is a detailed documentation of its command line interface in the debugger's online help. Prepare a crash dump (CRASH DUMP)
These are good news. The bad news is that you must do some preparations before the kernel debugger obey you. The first obstacle is that debugging usually involves two separate computers (together via lines), one of which runs debuggers, and another is used to debug. However, if there is no need to debug in real time, then there is a simple method that you do not need the second machine. For example, if a wrong program throws an unprocessed exception, the NT Blue Screen of Death (BSOD), you can choose to save the memory image before the crash into a file, After startup, check this crash dump file. This technology is often called Post Mortem (afterward check) in Latin, Post Mortem means "after DEATH". This approach is one of the preferred methods of this book. Here, our main task is to study system memory. In most cases, memory data is from a snapshot (Snapshot) that is still working, or from the system crashes. However, some interesting information requires inside the system that is working through the drivers of the kernel mode to be observed, and this topic is retained in the following sections.
A crash dump is just written to write the current memory data into a disk file. Therefore, the size of a complete crash dump file is usually as large as the physics of the system (in fact, it will be slightly small). Crash Dumps are generated by a special program in the kernel is generated during processing fatal errors. However, this routine is not immediately written to the target file immediately. This is a good processing method, because after the system crashes, the disk file system may not work properly. Therefore, the memory image is first copied to the page file memory, which is part of the system memory manager. Therefore, you should add your page file size to at least twice the physical memory. double? Is it not enough? Of course, it is enough to store crash dumps. To know, when starting, the system will try to copy the crash dump image to the actual disk file, which means that if the system cannot release the page files occupied by the image data in time, it may be exhausted all Virtual Memory. Typically, the system will handle this situation, which will crazy read and write disks and throw a warning of "virtual memory short". As long as you expect the probability of the blue screen, set the page files enough, which will save you a lot of time. To this, you should open the Windows 2000 control panel, change the following settings:
l Add the size of the page file to at least twice the size of the physical memory.
l Next, configure the system to generate a crash dump file when the blue screen occurs. In the System Properties dialog box, select the advanced page, and then click Start and Recovery buttons to check the write debugging information option. You should choose to complete the memory dump option in the drop-down list. Enter a file name and path in the dump file dialog, and the dump file will be copied from the page file to this file you specified. % SystemRoot% / Memory.dmp is the default setting.
Let the system crash
When setting a Crash Dump, it is time to do the most disgust in the Windows 2000 system programmer: Start to crash! Usually, as long as the Sword of Damicis hangs on your head (usually when there is a few hours from the deadline), you will see the horrible blue screen. Now, you volunteered to let the system crash, but you may not find a problem with the software to complete this "work". Try to try David Solomon's elegant trick mentioned in his "Inside Windows NT":
"How can I have a crash dump file? I only need to use the Kill.exe tool in the Windows NT resource tool, KILL off Win32 Subsystem Process (CSRSS.exe) or Windows NT Login Process (Winlogon.exe ), You must have administrator privileges (Solomon [1998], P.23.)
Magical, amazing! This trick cannot work on Windows 2000! The first feeling, it is very busy, but from another angle, this is a good news. When you know a small tool that Microsoft's own officially released, you can easily destroy the system, how would you think? In fact, Microsoft closes this security vulnerability very right. However, we now need a way to make the system crash. At this point, think about the ancient and simple NT rules: "if anything seems to be imphoties in the win32 World Just Write a kernel-mode driver, and it will work out all right!" Windows 2000 is very cautious managing Win32 program. It constructs a wall between the application and the kernel, any attempt to span this border, will be solved unrecognizable. This is a good news for the stability of the system, but it is not a good news for those who need to deal with hardware. Think about DOS, any programs there can be directly touching hardware, in this regard, WINDOWS 2000 is some excessive. But this does not mean that it is impossible to access hardware in Windows 2000. Different, this access is limited to a special type of module-kernel mode driver (kernel-mode driver). I can tell you, now I will briefly introduce the Kernel-Mode Driver programming technology (this is the content of the third chapter). At the moment, this is enough to explain that Kernel-Mode Driver makes the system crash are very easy. When the driver is wrong, Windows 2000 does not provide an error recovery mechanism, which leads to a blue screen even if it is not intended to execute an illegal operation. Of course, the simplest and dangerous minimal illegal action is to read an invalid memory address. Since the system displays all memory access through the null pointer, this is a common error in C programming, and reads an empty pointer is the ideal action that makes the system crash. W2K_KILL.sys driver in the sample code is done. This is a very simple program, and it is also the first Kernel-Mode Driver that appears in this book.
Listing 1-1 is part of W2K_KILL.C, showing error code that triggered a blue screen. When writing such meaningless code, you need to pay attention to the Optimizer built in Visual C / C may offset your efforts, which track all the code and attempt to eliminate any parties with side effects. In the following example, the optimizer does not work because driverentry () insists that there will be any return value to the 0 address. This means that this value will be stored in the EAX register of the CPU. The easiest way is the MOV EAX, [0] instruction, which will throw our expectations.
NTSTATUS DRIVERENTRY (PDRIVER_OBJECT PDRIVEROBJECT,
PUNICODE_STRING PUREGISTRYPATH)
{
Return * ((ntstatus *) 0); // read through null pointer
}
Listing 1-1 a Null Pointer Read Operation in keNel-mode Crashs the system
The W2K_Load.exe program appears in Chapter 3, used to load and launch the W2K_KILL.SYS driver. If you do Kill, you will get your Windows 2000 system in your spirit, please follow the steps below:
l Turn off all applications
l Inconduating a disc inserting this book
l Select running in the start menu
l Enter d: / bin / w2k_load w2k_kill.sys, replace D:, then click OK, W2k_Load.exe will try to load the W2k_kill.sys file (located in the CD / BIN directory) after clicking under). Then DriveEntry () started, the blue screen appeared, as shown in Figure 1-3, you will see that a counter will gradually increase from 0 to 100 when the memory data is documented to the page file memory. If you select the automatic restart in the startup and recovery dialog, the system will restart immediately after the crash dump is complete. When the system is waiting for the login state, take a moment until the hard drive is no longer blinking. This is because the crash dump data is copied from the page file to disk files, especially when your physical memory is large. At this time, the interference system, for example, premature closing of the system, which may generate an invalid crash dump file.
In Figure 1-3, it can be seen that the name of the module containing the error code is displayed (W2K_KILL.SYS), as well as the command address (0xBecc3000) that causes an exception. This address may be different from your system because it varies with hardware configuration. The loading address of the driver is usually uncertain, and the DLL load address is similar. Please write down the displayed address ---- Later installation and configuration kernel debugger is you still need it.
A little tip: deliberately let the system crash should not be what you have every day. Although there is a problem with W2K_KILL.sys itself is harmless, it may not be so lucky at the moment it execute. If another thread is doing some important things when reading an empty pointer, the system may shut down before the thread has the opportunity to clean up. For example, after restart, the event desktop will tend to complain that there are some abhorrent things, it needs to be recovered. Therefore, before you make the system crashes, you should carefully prosecute the system affected important data and ensure that the data in all Cache is written to disk. Note that authors and publishers do not be responsible for the damage caused by W2K_KILL.sys drivers.
Translation: Dharoles Greek legendary Sudu King Di'Nessios's courtier Destiny
Installation symbol file
After you restart, you have a snapshot for a Windows 2000 system, including a problematic kernel-mode driver (captured when reading the null pointer). Observe this snapshot file and the actual system memory is the same. Of course, this snapshot file is the same as the animal dead body - no longer reacts to the outside world, but you don't need to worry now. Next you need to install the symbol file required by the kernel debugger, you will use it when you analyze the crash file.
MSDN users can find these symbol files on the Windows 2000 Customer Suuport - Diagnostic Tools CD. Insert the disc, use IE to open the DBG.htm file on the disc, you will see a lot of installation options. If you run the Windows 2000 of Free Build, you'd better install Retail Symbols. For Checked Build, you can choose to install Debug Symbols. The installer will copy some .dbg and .pdb files from Symbols.cab to the system symbol file directory. The default system symbol file directory is:% SystemRoot% / Symbols. % Systemroot% environment variable represents the installation directory of Windows 2000.
At startup, the Windows 2000 kernel debugger will try to find a symbol file through the path indicated by the environment variable _nt_symbol_path, so it is best to define the variable correctly. Translation:
You can now check and download the latest symbol files with the Symchk.exe tool, which is installed with the Debugging Tools for Windows package.
Microsoft's documentation should point to where _nt_symbol_path should point to where to say a little fuzzy. In the DDK's kernel debugging section, it is mentioned that the symbol subdirectory, which is a C: / WinNT / Symbols, or an equivalent directory. In the documentation of the SDK about the DBGHELP.DLL library, the description of the symbol path is slightly different:
"The library needs to use the symbol search path to locate .dll, .exe, or .sys corresponding to the debug symbol (.dbg file). It adds / dll, / exe, or / sys after the path. For example, the .dll symbol file is located : C: /winnt/symbols/dll ,.exe file path is: C: / Winnt / Symbols / EXE "
. . . . . .
"If you set the _nt_symbol_path environment variable, the symbol manager searches the symbol file in order as follows:
1. Application current work directory
2. _NT_SYMBOL_PATH directory
3. _NT_ALT_SYMBOL_PATH instructions
4. Systmeroot instruction catalog
"
This seems to set the _nt_symbol_path to c: / Winnt seems to be better than C: / Winnt / Symbols, in order to determine which statement is correct. I tried these two ways, I am very happy that they can work properly.
Configure kernel debugger
The final step of building a debug environment is to install and configure the kernel debugger. If you have already installed Windows 2000 DDK, you can find the debugger in the / ntddk / bin directory. The executable file of the kernel debugger is I386kd.exe. Another method is to install from the Windows 2000 Customer Support --- Diagnostic Tools CD.
In order to use the collapse dump file we get before, you need to use the -z option of i368kd. Examples are as follows:
I386kd -z c: /winnt/memory.dmf
After successfully opened our Crash Dump, you will see that the Dongdong, KD> prompt shown in Figure 1-7 will appear, which means that the kernel debugger is ready to accept commands. Before starting, check if the symbol search path is correct. The list of startup information is listed, indicating that the debugger has loaded three extensions DLL. One powerful feature of i386kd.exe is its expansion mechanism, which allows third parties to expand their basic functions with separate DLLs. For these extended commands, you must add it in front of it! Number to distinguish between built-in commands.
As shown in Figure 1-7, I entered an built-in command: u Becc3000, u 's meaning is "unassembel", BECC3000 is the 16-en-authorized address that starts to reflect. By default, 16 binders are used, but you can also change this default via command. The command is: N 10, and then the default all numbers are 10-based. You can use the 0x prefix to indicate that this is a 16-based number. The address BECC3000 is where W2k_kill.sys causing the system crash. Please use the address you see when you are blue screen. If everything is correct, you will see the MOV EAX, [00000000] instruction, as shown above. If you don't see it, you may not use the correct crash dump file. MOV EAX, [00000000] The instruction represents a 32-bit value to the CPU register EAX from the virtual address (also referred to as a linear address) 0x00000000, which is obviously in the list 1-1 * (NTSTATUS *) 0) expression Implementation, equivalent to the operation of reading the empty pointer. There is no exception handling routine for such errors, so the system will display kmode_exception_not_handled on the blue screen, as shown in Figure 1-3. If you want to know more about this error message, please refer to "The NT Instems Resources 1999B). ....................to be continued..................
