Exploring IIS Log File analyzer ReadLogs (6)

More common analysis information
(Prepared by qingapple studio)

This section discusses the different outputs that you may see in log files, how they will help you debug applications, and how to make them more effective.

When you look at the raw logs generated by the IIS debugger, you will notice that there are many lines before you reach the access conflict in the log. This is because the debugger obtains and displays information at any time. This information and its meaning are discussed below.

-----

NTSD ModLoad: 77720000 77731000 C: winntsystem32mip. dll

-----

LDR: Automatic DLL Relocation in inetinfo.exe

LDR: Dll scod32.dll base 10000000 relocated due to collision with C: Program FilesCommon FilesSystemADOmsader15.dll

NTSD ModLoad: 04800000 0489f000 C: WINNTSYSTEM32scod32. dll

-----

NTSD: C ++ EH Exception

-----

NTSD: exception number c000008f

-----

The first output of the above example is NTSD ModLoad, which means that Inetinfo gets a request for the code of the given module (or DLL) and loads the DLL into the memory. Some DLL files are stored in the memory during the entire session. Some DLL will be uninstalled once the call to them ends. If you need it again, reload the DLL. For more information about this, see Chapter 19th of Jeffrey Richter's book 'write applications for Microsoft Windows, version 4 (Microsoft Press ).

Now let's take a closer look at what actually happened in the second set of output above. When the editor creates a DLL, it specifies a default reference address. If possible, this is the address for future DLL loading. After being loaded to the DLL, the location information of all exposed functions in the DLL does not need to be converted, and the call is faster. A conflict occurs because there is another DLL in the same memory space. In this case, find another location to load the DLL, and then perform the conversion required to call the function.

Next, you will see an ntsd c ++ accident. This is an error because it is not in the debugger. A c ++ is also known as "the first opportunity accident ". It means (In layman's opinion) when this accident occurs, Windows NT gives the DLL with this code a chance to correct its own problem (in programming it becomes an "unexpected operation "). This is usually completed by using try/catch t packaging in C ++. A Package refers to a piece of code, which wraps a part of the code and allows you to isolate it. In the try/catch packaging, if the code in the try part causes an accident, the catch/catch T code is called to solve this problem. If the problem can be solved, the above error will not cause system failure.

The last entry you see is the same as the C ++ accident, but the accident you see is handled by the operating system. An unexpected number can sometimes be converted into meaningful text, and ReadLogs tries to automatically convert every unexpected number it gets. For this information, see the error section.

To be honest, the above section only briefly explains what happened. In Jeffrey Richter's book 'write applications for Microsoft Windows '(version 4, Microsoft Press), the entire chapter is related.

Create a debugging File
This part involves two questions: How to build a debug version of an application and how to enhance the output. Both discussions are strictly related to Microsoft Visual C ++ 5th and 6. However, other C compilers, Java, and Visual Basic have the same functions.

First, let's see how to build the debugging version of the client code you want to debug. Load the project file to Microsoft Developer Studio and complete the following steps:

1. Click create activation configuration in the create menu.

2. Select debug configuration from the dialog box and click OK.

3. Click settings in the project menu, and then click the connection tab.

4. From the category drop-down box, click debug. In the debugging information section, select the dual format.

5. the PDB debugging file is generated in two formats: Common Object File Format (COFF) and Microsoft information. CDB uses the COFF symbol file, so this step allows CDB to read your symbol.

6. re-create the project file, and copy the DLL and the corresponding PDB files to the appropriate location of the Web server from the debugging directory.

Note: PDB and DLL should be in the same path. Now you should have the symbols used by CDB.

Now you can add some output strings to make it more interesting. Remember that all information is ended with logs before the debugger is wrong. You can also add content to the output information of the Code. For example, if the DLL is connected to the database, you want to know whether the connection is implemented. In this case, you can ask the DLL to write the connection status to the debugger or point it to the value of some variables. All you need to do is use an API called OutputDebugString. This function is used to write strings to the attached debugger. You can use wsprintf () to format the program information into a string, and then pass the string to OutputDebugString. In this way, the string is displayed in the debugging window whenever the code is run. If a debugger is not attached, Windows NT ignores this command and the program runs normally.

Now let's look at a real situation. Suppose you have a DLL that seems to have caused a stack conflict, but you cannot be sure which function in the DLL causes the problem. If you place OutputDebugString at the beginning and end of each function, it is like "Entering" and "Exiting". Check the log to see the last called function. This is not necessarily a function that causes errors, but you can start searching here. You can also use OutputDebugString to monitor variables or other content in DLL.

Conclusion
Microsoft technical support successfully solved many problems with an unexpected monitor. Together with ReadLogs, the accident monitor provides a powerful tool for diagnosing exceptions on the server. Although this tool does not solve every accident, it provides more information about failure than the Log Mechanism of the server.