The stack in Figure 3 is the most important stack to remember because it shows that the Asynchronous Thread Queue (ATQ) has at least one thread (the current thread) listening for an incoming request, which means that IIS can handle a static request (e.g., .htm, .jpg). For information about the ATQ, see "Diagnosing Problems in IIS," May 2001. If your server appears to be hung completely (i.e., it serves no files) and you see this thread stack in a dump file taken from the server at the time of the hang, you can be sure that incoming requests aren't making it to IIS and that a network or connectivity problem is occurring.
Here's another basic command with which you should be familiar. Type the command
!sympath
in the prompt window, then press Enter. You'll receive a response showing the path to your symbol files. If you want to change the path or add another path, you can do so by typing the !sympath command followed by the paths you want. You just separate multiple paths by a semicolon (;). After you've entered a new symbol path, you need to make the current dump file start reading from the new path. To make the dump file read the new path, type
.reload
in the prompt window. Notice the period (.) at the beginning of the command. You must include the period for the command to work.
Another useful command is lm, which lists all loaded modules in memory. With this list, you can see exactly which modules are running. This list often shows modules that you thought had been removed (e.g., Internet Server API—ISAPI—filters). Figure 4, page 3, shows sample (incomplete) output from running the lm command on the inetinfo.exe dump file.
Notice that you get a start column, an end column, a module name column, and a column that displays information about the symbol file for the module. Note that this list doesn't tell you whether the module is an .exe file, a .dll file, and so on. The start column tells you where in memory the module is loaded. The end column tells you where the module's code stops. By looking at the list in Figure 4, the VBScript entry tells you that IIS has loaded an Active Server Pages (ASP) page that contains VBScript. The msjava entry is the runtime for Java applications. You also know that you're looking at the in-process IIS dump because inetinfo.exe is loaded. That is, if a module appears in the list, you know that it was loaded in this process. User mode dumps (such as the one in this example) show information only about the one process in which the dump was created. Thus, you know that you're looking at the inetinfo.exe process because this process is the only one that contains this module in the list of loaded modules.
You can also gather information about specific modules. If you want more information about a specific module, type the command
!lmi <module name>
in the prompt window. You'll receive header information about the module, including the date and time, which can often tell you whether you're running an older version of a program and need to upgrade. Figure 5 shows details about the VBScript module.
As you can see in Figure 5, the date for vbscript.dll is June 9, 2000. A security patch dated March 2001 exists for Windows Script Host (WSH) 5.5 and WSH 5.1. (Note that VBScript ships with WSH, and I recommend updating vbscript.dll by installing the latest version of WSH.) See the Microsoft article "IE can Divulge Location of Cached Content" at http://www.microsoft.com/technet/security/bulletin/ms01-015.asp.) I need to apply this fix because my DLL isn't up-to-date. The sidebar "Common Windbg Commands," page 3, lists other commands that you can use on your dump files.
Here's a command that's a bit tricky, but you'll get the hang of it after you've run it a few times. (The output from this command, which Figure 6 shows, is long; I've omitted quite a bit.) I'll point out the things you want to look for. To find out what scripts are currently running, type
0:000> dt asp!g_ScriptManager r
in the prompt window. Three linked lists contain the information that you need to determine which scripts are running:
- m_htFSQ—contains the list of scripts that are cached but not currently in use (callout A in Figure 6)
- m_htRSL—contains the list of running scripts (callout B)
- m_hTPLL—contains the list of script engines (callout C)
Next Month
Many other commands are available, and you can learn much more from dump files than I show you here. As I present scenarios in future articles, I'll point out what commands are necessary to retrieve the data you want. For now, experiment with the commands listed in the Help file and in the sidebar, and see what you can learn from them. When this column resumes in the September issue, I'll jump into the first scenario and work through it to resolution.
Note: To keep the Disassembly window from popping up as you work, choose Automatically Open Disassembly from the Window menu to prevent Windbg from reopening the window during the current Windbg session. Unfortunately, Windbg doesn't remember the Automatically Open Disassembly setting when you close the tool, so you need to disable the setting each time you open Windbg.