Exploring IIS Log File analyzer ReadLogs (5)

CDB command used by the accident Monitor
(Prepared by qingapple studio)

Some commands used by the accident monitor are useful during debugging. The following are the commands and their related outputs.

Kv command
The First Command run by the accident monitor is Kv. It shows the function call back stack of the stream activated at the time of pick-up error. Read this stack from the bottom to the top: The top function is the last function called, and the bottom function is the first function called by the stream.

Output sample (x86 Platform ):

ChildEBP RetAddr Args to Child

00f8fdf8 53d0f7f3 003070ac 00307078 00306d48 0x1000113c [Stdcall: 0]

00f8fe5c 53d0ad45 00306ee4 00f8ff0c 00f8ff4c w3svc! AddFilterResponseHeaders + 0x26

00f8ff20 53d01ce6 00f8ff4c 00f8ff68 003154b0 w3svc! HTTP_REQUEST _ DoDirList + 0x2f7

00f8ff50 53d01f56 00f8ff68 00315478 00315460 w3svc! & Amp; 127; ole32_NULL_THUNK_DATA + 0x96e

00f8ff6c 53d04adb 00000166 00000000 00000001 w3svc! & Amp; 127; ole32_NULL_THUNK_DATA + 0 xbde

00f8ff88 539895d0 00315460 00000166 00000000 w3svc! HTTP_REQ_BASE _ 'vftable + 0x1fd3

00f8ffb8 77f04f2c abcdef01 776a2254 00000028 infocomm! AtqPoolThread + 0x1c8

00f8ffec 00000000 53989408 abcdef01 00000000 kernel32! BaseThreadStart + 0x51

Output sample (alpha Platform ):

Callee-SP Return-RA Call Site

0815ffc0 77e6f5b8: ntdll! DbgBreakPoint + 0x4

0815ffc0 77e6cc48: KERNEL32! DebugBreak + 0x8

0815ffd0 00000000: KERNEL32! BaseThreadStart + 0x60

The function call return stack lists all functions activated in a given stream. Function 1 calls function 2, function 2 finally calls function 3, and so on. When the last called function finishes its work, it "expands", or returns the function that calls it; after the function is completed, the function that calls it is returned, and so on. The call return stack lists what is called and how the code returns after the function is correctly run. Because this stack is a fault stack, you can know the access conflicts of the functions listed at the top of the stack. However, this does not necessarily indicate that this function has caused actual problems. The problem may be caused by another function passing an incorrect pointer to the stack or even a different stream. You can see the details in the heap and stack conflicts.

Note that the command at the top of the stack does not list the invocation commands When the file is not loaded with symbols. When the stack is loaded to ReadLogs, it tries to break down this function call into a friendly name by using the list of loaded modules. First, it obtains the memory address for calling (0x1000113c), and then looks for the DLL containing the memory address.

! Inetdbg. mod
An extension added to the CDB by the IIS debugger is the Inetdbg. dll file. If this file exists in the Windows NT directory (or local debugging directory), then CDB can use this command. If you add one before this extension command! Then, CDB looks for the DLL and passes the command to the extension. In this case, you call the Inetdbg extension and pass it in the mod command. This command accumulates the list of all currently loaded modules in the Inetinfo memory space and returns the following information (this is an omitted list ):

Output sample:

Start End Entry Path

01000000 01006000 01001122 C: WINNTSystem32inetsrvinetinfo.exe

77f60000 77fbc00000000000 C: WINNTSystem32tdll. dll

78000000 78047000 7800546d C: WINNTsystem32MSVCRT. dll

77f00000 77f5e000 77f01000 C: WINNTsystem32KERNEL32. dll

77dc0000 77dfe000 77dc1000 C: WINNTsystem32ADVAPI32. dll

77e70000 77ec1000 77e7a2a2 C: WINNTsystem32USER32. dll

77ed0000 77efc00000000000 C: WINNTsystem32GDI32. dll

10000000 10024000 10001650 C: InetPubscriptsselfdestruct. dll

This information is useful if you want to determine what code is running in Inetinfo memory space. In the previous kv command, Your function is not broken down. To break it down, you need to use the memory address-0x1000113c to check whether it is within the starting address and ending address range of Selfdestruct. dll.

! Inetdbg. ver
Another extension that Inetdbg can use is the ver command. This command lists all the version information extracted from the loaded DLL. Most DLL version information is in the header of the actual file. This extension tries to get the information from here:

Output sample:

Module @ 0x01000000 = inetinfo.exe

DwFileFlags = 0x00000000 (FREE)

CompanyName = Microsoft Corporation

FileDescription = Internet Information Services Application V1.0

FileVersion = 4.00

InternalName = INETINFO. EXE

LegalCopyright = Copyright (C) Microsoft Corp. 1981-1996

OriginalFilename = INETINFO. EXE

ProductName = Microsoft (R) Windows NT (TM)

Operating System ProductVersion = 4.00

Module @ 0x77f60000 = ntdll. dll

DwFileFlags = 0x00000000 (FREE)

CompanyName = Microsoft Corporation

FileDescription = NT Layer DLL

FileVersion = 4.00

InternalName = ntdll. dll

LegalCopyright = Copyright (C) Microsoft Corp. 1981-1996

OriginalFilename = ntdll. dll

ProductName = Microsoft (R) Windows NT (TM)

Operating System ProductVersion = 4.00

In this example, the problematic DLL (Selfdestruct. dll) is not listed ). Inetdbg. mod cannot display any DLL information that cannot be restored. ReadLogs compares the file names of each entry in the ver command with the entries here, and adds the obtained version information to all the DLL files in the list. If no available version information is available, ReadLogs simply adds the phrase "no available version information for this DLL ". ReadLogs uses the output of this command to display version information. This information is useful if you want to determine whether you are running an appropriate version of a given DLL.

Note: On some machines running Windows NT Service Pace (SP) 4, the ver command fails completely. If you want to obtain the appropriate version information, run this command twice. In this case, ReadLogs looks for a version that does not contain any error output and uses this setting to display the version information. If both operations fail, ReadLogs cannot display version information.

~ * Kb
~ * The kb command indicates that the debugger saves a set of copies of stacks (same as kv) for each stream in the memory space ). (~ The Command says "select a stream"; * The Command says "all streams", and then you can add any command you want to run on all streams, which is kb ). You can use this command to see what happened when a conflict occurred. If you are troubleshooting 100% CPU utilization and deadlock, you can also use this information. Each stack has the same analysis method as the kv stack.

Run the debugger. You can use this information to eliminate 100% CPU usage faults and run a Performance Monitor log where you capture the flow counter. For a 100% CPU utilization problem, you can manually pick an error for the debugger and stop the PerfMon log. By analyzing the PerfMon log, you get the number of the stream that is using the CPU. You can also ~ * The kb command lists the streams with the same number using ReadLogs (or manually check the debug log file ). This will tell you what the stream is doing and point out who the "criminal" is.

Note: To capture the output of a stream, you must use the PerfMon log function. The log can be started only when the 100% utilization rate occurs. You can only view the stream in the chart and get the wrong stream number.

U eip-50 eip + 20 (on x86 platform only)
This u command instructs the debugger to display assembly code that exists within the provided address range. At this time, you are the code that goes from the request to the 20 bytes that the EIP points to before the 50 bytes that the Extended Instruction Pointer (EIP) Register points. The EIP register usually points to the next line of the code to be executed. You can see what code is doing in the Age of conflict.

Output sample (scaling ):

Ntdll! RtlpWaitForCriticalSection + 0x45:

77f6cc16 0000 add [eax], al

77f6cc18 008b0d805afa add [ebx + 0xfa5a800d], cl

77f6cc1e 7739 ja ntdll! RtlpWaitForCriticalSection + 0x88 (77f6cc59)

77f6cc20 48 dec eax

77f6cc21 2475 and al, 0x75

77f6cc23 2333 and esi, [ebx]

77f6cc25 c0894604894608 ror byte ptr [ecx + 0x46890446], 0x8

77f6cc2c 89460c mov [esi + 0xc], eax

77f6cc2f 894610 mov [esi + 0x10], eax

! Locks
This! The information displayed by the locks command is about which part of the currently running code is marked as a key part (CS ). For more information about CS, see the section on understanding locks.

Output sample:

CritSec w3svc! MDIDMappingTable + 100 at 68c2b1b0

LockCount 0

RecursionCount 1

OwningThread 156

EntryCount 0

ContentionCount 0

* ** Locked

! Inetdbg. atq-g
The information displayed by the atq command is related to the non-synchronous IIS stream queue. Streaming queuing is a unique feature of IIS. When a new request enters IIS, it needs to process a stream. Because creating a stream is expensive in terms of time and CPU usage, IIS maintains a set of workflows to process incoming requests at any time. IIS manages