Exploring IIS Log File analyzer ReadLogs (2)

View and configure ReadLogs Information
Author: qingapple studio Compilation

Let's continue with the content in the previous article. Here we will introduce some other viewing content provided by ReadLogs.

Move in stream
Sometimes, you may want to view other streams in addition to faulty streams. ReadLogs provides multiple methods for moving in the stream. For example, you can use the fault stack and Related Control in the log file analyzer (see figure 3 ).


Figure 3 fault stack and Related Control

The method for moving fault stacks and related controls in the stream is as follows:

1. Click the fault stack to return to the fault stream stack according to any command in the analyzer.

2. Click <move to the previous stack.

3. Click> move to the next stack.

4. Click the number of stacks currently displayed in the edit box and move them in the list using the up and down arrow keys on the keyboard.

5. Select a specific stream Stack from the drop-down list and jump to a specific stack.

One of the reasons for checking other streams is to eliminate the 100% CPU utilization problem. At this time, one processor (or multiple processors) runs at 100%, and the computer seems to have paused. If you know that a stream is using all CPU cycles when a fault occurs, select this stream from the drop-down list to see what happened at that time. If you are interested in knowing what else the system is doing when a fault occurs, you can move between many streams.

View DLL
When you click DLL in the main window of the log file analyzer, the main output window displays a list of currently loaded DLL files. Based on the DLL start address, ReadLogs classifies the list numbers. The List displays the starting address (also called the baseline address), ending address, and DLL name (including the path ). If a DLL appears in the list, this file is called at least once during IIS running. Used for the accident monitor! Inetdbg. mod command to obtain the list of loaded DLL.

If you select the "Hide Microsoft Files" check box, ReadLogs will view the DLL version information, list the DLL whose "company name" field value is not equal to "Microsoft" or that has no version information. When a fault occurs, you can use this option to quickly check which third-party DLL files are loaded.

The log file contains the version information of each available DLL. If you select the start address of the DLL, the main information window displays the available version information. If the unexpected monitor cannot obtain version information, the main information window displays "no available version information ". Use the accident monitor! Inetdbg. ver command to obtain the installed DLL version information.

View Error
When you click an error in the main window of the log file analyzer, the main output window displays a list of errors found in the log file. The list contains warnings (such as symbol mismatch), errors (such as the symbol cannot be loaded), and NTSD errors. For more information, see "Understanding locks.

Note: The accident monitor does not use external commands to capture errors. The error is displayed in the entire log.

NTSD Error
There are many errors in this form in the log: "NTSD: Exception Number xxxxxxxx ". These are error codes specific to Windows NT, IIS, or applications. Generally, these errors are insufficient for session interruption. They indicate that some operations failed, but they did not cause serious server faults. Sometimes these errors also represent actual problems, but most of the time they only point out some small problems that should be handled when the server recovers to a stable State.

When ReadLogs encounters an NTSD error, it tries to solve the problem and displays the corresponding information. ReadLogs uses a built-in Windows NT application programming interface (API) Call to solve these problems. It passes an 8-bit error code to the Microsoft Win32 API FormatMessage () function, which is located in the Error List of Windows NT. If the system finds this code, Windows NT will respond with this error explanation. You can also use a copy of Windows C header file Winerror. h to view these errors. If ReadLogs cannot solve this error, it usually indicates that an application-specific error code (or even IIS) occurs, and ReadLogs does not have permission to use this error code.

Understanding locks
First, let's discuss the concept and importance of the following locks. Each time a stream (a piece of code) needs to be used independently, a lock is generated. The stream requests a lock. If yes, the system will lock the stream. The lock code cannot be used in other parts of the system. The lock is useful when a data stream is written to a file and it requires that no other data is written to the file at the same time. When the stream ends, the lock is released. This often happens. In a well-written multi-stream application, this is a very common component. Note that although a specific lock can only be owned by one stream at a time, a stream can have many locks.

So far, everything looks good. However, when two or more streams have locks but need to wait for each other to end, the problem arises. This problem is similar to a real legal issue in Texas: When two trains encounter at a fork in a railway, both of them should be completely stopped, but one cannot pass, and the other cannot. This is called a deadlock.

This is one of several situations where you need to manually pick up the wrong session. When you encounter a deadlock, the server seems to have paused. A manual pick-up error will pile up the information you need to solve the problem. If you have a manually picked Error Log and you suspect it is a deadlock problem, click "Lock" to restore the information. If the lock window is blank, you may not have loaded the appropriate symbol (only when the Ntdll. dll symbol is correct ,! Locks command is valid), maybe this is not caused by a deadlock.

When you click lock, the main output window displays a list Of all locks found in the log, as well as the ID of the stream and the number of locks. When you select the ID of the stream, the main information window displays the window of the stream with the lock. Using this information and the following sample scenario, you can determine whether it is a deadlock problem. Use the accident monitor! The locks command to obtain the lock information. Sample output for this scenario is listed below:

CritSec ftpsvc2! G_csServiceEntryLock + 0 at 6833dd68

LockCount 0

RecursionCount 1

OwningThread a7

EntryCount 0

ContentionCount 0

* ** Locked

CritSec isatq! AtqActiveContextList + a8 at 68629100

LockCount 2

RecursionCount 1

OwningThread a3

EntryCount 2

ContentionCount 2

* ** Locked

CritSec + 24e750 at 24e750

LockCount 6

RecursionCount 1

OwningThread a9

EntryCount 6

ContentionCount 6

* ** Locked

In the above example, let's take a look at the second lock. We can see that the stream to which it belongs is a3. In ~ * This stream can be found in the output of the kb command. Now it is stream 4:

4 id: 97. a3 Suspend: 0 Teb 7ffd9000 Unfrozen

ChildEBP RetAddr Args to Child

014cfe64 77f6cc7b 00000460 00000000 00000000 ntdll! NtWaitForSingleObject + 0xb

014cfed8 77f67456 0024e750 6833adb8 0024e750 ntdll! RtlpWaitForCriticalSection + 0xaa

014cfee0 6833adb8 0024e750 80000000 01f21cb8 ntdll! RtlEnterCriticalSection + 0x46

014cfef4 6833ad8f 01f21cb8 000a41f0 014cff20 ftpsvc2! DereferenceUserDataAndKill + 0x24

014cff04 6833324a 01f21cb8 00000000 00000079 ftpsvc2! ProcessUserAsyncIoCompletion + 0x2a

014cff20 68627260 01f21e0c 00000000 00000079 ftpsvc2! ProcessAtqCompletion + 0x32

014cff40 686249a5 000a41f0 00000001 686290e8 isatq! I _TimeOutContext + 0x87

014cff5c 68621ea7 00000000 00000001 0000001e isatq! AtqProcessTimeoutOfRequests_33 + 0x4f

014cff70 68621e66 68629148 000ad1b8 686230c0 isatq! I _AtqTimeOutWorker + 0x30

014cff7c 686230c0 00000000 00000001 000c000a isatq! I _AtqTimeoutCompletion + 0x38

014cffb8 77f04f2c 00000000 00000001 000c000a isatq! SchedulerThread_297 + 0x2f

00000001 000003e6 00000000 00000001 000c000a kernel32! BaseThreadStart + 0x51

Once you find the stream location, you will see that it has called the WaitForCriticalSection function, which means that it not only has a lock, but also waits for an object that is locked by others. Check the first parameter called by WaitForCriticalSection to see what locks the object. Now, it is waiting for 24e750. Now you turn! For the output of the locks command, see the third Critical section:

CritSec + 24e750 at 24e750

LockCount 6

RecursionCount 1

OwningThread a9

EntryCount 6

ContentionCount 6

* ** Locked

Now you see stream 4 (which has the second lock) is waiting for the third lock. This is also possible, because when the third lock is released, you can continue to process it. Now let's analyze the third lock-the stream to which it belongs is a9. Use ~ * View the output of kb. You can see that:

6 id: 97. a9 Suspend: 0 Teb 7ffd7000 Unfrozen

ChildEBP RetAddr Args to Child

0155fe38 77f6cc7b 00000414 00000000 00000000 ntdll! NtWaitForSingleObject + 0xb

0155 feac 77f67456 68629100 6862142e 68629100 ntdll! RtlpWaitForCriticalSection + 0xaa

0155feb4 6862142e 68629100 0009f238 686222e1 ntdll! RtlEnterCriticalSection + 0x46

0155fec0 686222e1 0009f25c 00000001 0009f238 isatq! ATQ_CONTEXT_LISTHEAD _ RemoveFromList + 0xb

0155fed0 68621412 0009f238 686213d1 0009f238 isatq! ATQ_CONTEXT _ Cle