Remote debugging
When the debugger and the process being debug are not on the same computer, it is called remote debugging. Remote commissioning can be done in two ways. One way is to connect a debugger to a remote process by proxy; another way is to run debug programs on remote computers, while sharing debuggers on the local computer . In this case, the agent runs on a remote system, and the debugger runs on the local system; the agent is connected to the process, read the process of the process, and transfer it to the local debugger. The advantage of using the remote debugging of the agent is that the installation is simple and fast. A disadvantage is that it is prone to network issues, sometimes caused by agents on the remote computer to crash. Because the symbols are only installed on the local computer, they may not match the symbols on the remote computer. Therefore, remote debugging may be quite slow.
Remote.exe tools are required to use the remote debugging of the shared command line, which is distributed with the Windows 2000 Customer Diagnostic and Support Tools CD. The Remote.exe tool can be run as a server or as a client. Use a named pipe connection server and client. WSREMOTE.EXE is a socket / variant of Remote.exe. Remote.exe allows sharing stdin (standard input) and STDOUT. On a remote computer, you can use the following command to run the server instance of the remote computer:
Remote / S Application PiPENAME
On the local computer, you can use the following command to run Remote.exe as a client:
Remote / C Machinename PiPename
This setting is very reliable and can tolerate the network failure.
User dump debugging
When an exception occurs, the user dump will create a snapshot of the process of the process on the hard disk. Windows NT has a tool called Drwatson that is capable of creating a user dump when an exception occurs. There is also a debugging tool called User Mode Process Dump. You can configure the user dump tool to monitor an exception of a particular process. You can then view this user dump file such as Windbg, which is easy to analyze it without having to adjust real-time processes.
Use debugger
Use NTSD
The NTSD debugger requires the user to specify a process to be connected at startup. With TLIST or PVIEWER, you can get a process ID of an existing process and type NTSD -P PID to debug this process. NTSD command line uses the following syntax:
NTSD [options] imagefile
Among them, imagefile is the image name to debug, Options is one of the following options:
Table 1. NTSD image file option
Option Description-2 Open a new window of the application for debug Character mode -D to redirect the output redirection to the debug terminal -G to automatically pass the first breakpoint -G to immediately exit O. when termination of the subroutine Debugging of multiple processes, the default value is a process-V-V-V-V-V-V-V-V-gene that is derived by the debugger derived by the debugger.
For example, suppose INetInfo.exe's process ID is 104. Type the following command Connect the NTSD debugger to the INetInfo process (IIS).
NTSD -P 104
You can also use NTSD to start a new process for debugging. For example, NTSD NOTEPAD.EXE will start a new notepad.exe process and establish it with it.
Once connected to a process, you can use a variety of commands to view the stack, set breakpoints, dump memory, and so on.
Table 2. General Command Command Meaning ~ A list of all threads Shows the stack trajectory of all threads to display the stack track of the current thread to display the stack track R of all threads Displays the current frame register output U disassembled code and displays the process name and offset D [ TYPE] [
Windbg
Start WindBG. On the Debug menu, click Attach to A Process, select the process you want to debug from the list, and then click Select. Windbg lists the DLL related to the INetInfo process in the command window and displays whether to load symbols for a particular DLL. The inetinfo.exe application (IIS) that is debugging is stopped. To start it again, type G in the Command window. Type ~ * KB in the command window. The stack of all threads in this process is listed. To change the path to the symbol, click Options on the View menu. In the Windows Debugger Options dialog box, click the Symbols tab, specify the path to the symbol file in the Debug Symbols Search path text box, and then click the OK button. Type KB in the Command window. At this point, the stack of the current thread is listed. Another way to see the stack of the current thread is to view the Call Stack window by clicking Call Stack on the View menu. Type LM in the command window. At this point, all modules (DLLs) in the process include their names and load base sites. Type Q to exit in the command window.
Use IIS Exception Monitor
In the following example, use IIS Exception Monitor to connect to the INetInfo (IIS) process, and debug this process.
Click Start, point to Programs, point to IIS Exception Monitor, and then click IIS Exception Monitor. In the Welcome dialog box, click Next. In the Check Sumbols dialog, if you choose Yes, the wizard will find the files used by IIS and determine if there is a match in /% systemroot% / symbols / dll directory. You can also select Use Alternate Symbol Path for Exception Monitoring to specify a different symbol path. Select Yes. Check IIS Symbols installed and click Next. In the Verify Symbols dialog box, check which DLL does not match the symbols in your system. You can also select the Determine Which Symbol Packages CAN BE Installed from Microsoft's Internet Site check box to download symbols from Microsoft's Internet site. This will bring you to the download page. For our example, aunt, assume that you have installed the symbols correctly, click Next. Note: The Verify Symbols dialog box uses CheckSym.exe to get its symbolic information. Checksym.exe is located in the C: / IXCPTMON / BIN directory. In the Process Options dialog, you will find three options. In-Process options refers to the IIS application running in the INetInfo process (low "in IIS 5.0). The Out-of-Process option refers to the IIS application that is running in your own / shared process space ("high" and "in" in IIS 5.0 "and" in "), and those running as a server package in MTS / COM s component. The Other Process option is essentially any other process running in the system. If you register a component under MTS as "Server Application / Package", it will run in the Dllhost.exe process (MTX.exe in Windows NT 4.0). This way, several instances of DLLHOST.EXE will be run for each application. If you need to debug a component of interest, you must first find the DLLHOST.exe instance that this component is running, and then connect to the instance. An Out-of-Process is a useful feature that it can list all the components registered with MTS / COM by the application name / package name, so it is eliminated that you find the correct DLLHOST.EXE instance and connect to this instance. trouble. For our example, select In-Process option, then click Next. The Session Options dialog is popped up. If you select Automatic, you will generate a log file as long as you have an abnormality. If you choose Manual, you will be prompted to enter ports, usernames, and passwords so that technical support engineers can interactively solve your problem. This option should be mainly used if you are solving a problem with technical support. If MANUAL occurs, once there is an exception, the web server will be suspended and cannot receive any web request until this server is restarted or canceled. If you want the IIS Exception Monitor to continue monitoring the event after writing the log and restarting the process, select the Enable Recursive Mode check box.
If you want to receive a pop-up message when IIS Exception Monitor encounters an exception, or you have installed the CDO and SMTP service, check the Notify Admin check box. Specifies a fully qualified email address to receive an email message with an attachment with a .dbl file format while detecting an exception. Check the Schedule this session check box, you can book an Exception Monitor session so that it runs at the specified time or system starts. This requires the installation plan task. This option is not available if the scheduled task is not installed. For our example, select the Automatic option and click Next. In the Start Monitoring dialog, click Run THIS MONITORING Session, then click Next. The Session Status dialog lists all processes that have previously monitored or now are being monitored. Click Finish. You will see a command prompt window for "IIS_
When IIS Exception Monitor is installed, log reader readlogs.exe will also install. You can use Readlogs to open the original .dbl log file you have just generated.
Figure 3. READLOG dialog
When Readlogs opens the log file, it displays the stack of abnormal threads. If the symbol is installed correctly, Readlogs will resolve the function name and display them in the Function column, as shown in the figure above. The function name is separated from the "!" Symbol between the DLL name. For example, the function name OutputDebugStringA in the figure is resident in the Kernel32 DLL.
In the analyzer, you can always see the stack of failed threads by clicking the Fault Stack button. You can scroll through the stack list using the << and >> buttons. You can also choose any of the commands in the drop-down list choose a command. If you don't want to watch Microsoft files, you can hide them. This helps you quickly confirm if there is a third-party DLL included in the process. In addition to listing the stack, the log file also contains information about the following: Loaded DLL or module, any lock and its thread ID, and detected errors.
Click the DLLS button, you can list all DLLs loaded in this process.
You can list all errors when the process is running with an Erroors button, including warnings. You can also customize IIS Exception Monitor to capture some errors.
Click the LOCKS button to display a list of the lock and its thread ID. As long as a thread wants to access a resource in exclusive way, this thread will require locking this resource. When two or more threads simultaneously lock a particular resource and wait for another thread to abandon the lock, it will appear as "dead lock". You can check the lock list and the threads they have to determine the possible source of deadlock problems.
By clicking the P.T.c. (the Prior to Crash) button, you can list the last 20 line log before the process fails.
By clicking the Report button, a copy of all information can also be pasted into the clipboard in the report format.
By clicking the Sys Info button, you can display some useful information about the system that can be used to debug.
You can customize your needs to meet your needs by clicking the CONFIG button.
Use User Mode Process Dump Tool
The User Mode Process Dump tool is connected to a particular process and dump the memory of the process to the hard disk when an exception occurs. First, you must run the setup.exe under the C: / Program files / debuggers / bin / userdump / directory to install the USER Mode Process Dump service. The User Mode Process Dump installer is installed as part of the DBGPLUS kit installation.
In the Welcome dialog box, click Next. In the Confirmation dialog, click Finish. The installer installed a control panel icon called Process Dump that can be used to configure the User Dump service. Double-click the Process Dump icon to call up the User Mode Process Dump Configuration dialog. Click New and enter the name of the application you want to monitor by the user dump tool. By creating rules, you can customize the tool to capture some exceptions. Click Rules.
If an exception occurs in the process being monitored, it will dump the memory of the process to the hard disk. Unlike IIS Exception Monitor, the User Mode Process Dump tool does not restart IIS service after dump processes.
In the Windbg debugger, you can open and analyze this created user dump to determine the cause of the fault:
Start WindBG. In the File menu, click Open Crash Dump and select this fault dump file. In the Command window, type G (GO) Start debugging this process. See the stack of failed, type KV.
Which process is debugged?
It is not easy to determine which process to be connected and commissioned. Just as discussed in the "Structure" of Internet Information Server earlier, you can use components and IIS applications. The following table should connect which process should be connected according to the component type and IIS configuration.
Table 3. Component type and IIS configuration
IIS applications for IIS applications for component type online processing IIS applications share the IIS application (IIS 5.0 Only) IIS Application (IIS 5.0 Only) or components in the application or components that are not belong to MTS / COM connection IIS The application resides in the package / application of the MTX / DLLHOST instance server package / component in the application connects the IIS component to the MTX / DLLHOST instance of the package / application in it.
When you try to debug MTS / COM next component or IIS application, this component or IIS application is installed as a server package / application, debugging will become abnormal. Several server package / applications that may run in a single system, each with its own MTX.exe or DLLHOST.EXE. Which one is what you need? The primary task is to identify the PID of the process of loading the component you want to debug. You can use IIS Exception Monitor to get this information, select the Out-of-Process option in the Process Options page.
The Select Out-of-Process Application page appears, where you can view the process listed by the application name / package name so that it is easy to determine which PID to connect.
Frequently asked questions during debugging
The most common issues in distributed web applications are:
ASP 0115 - Access Conflict <
