Your First Crash

[Author's Note: Each article in this troubleshooting series builds on the previous month's article. In the July issue, I showed you how to use WinDbg to gather information about your IIS servers. This month, I show you how to put into practice all the tips and techniques I've given you so far to troubleshoot an IIS crash.]

Over the past few months, I've introduced you to the Windows 32-bit debugging tools (available for download from http://www.microsoft.com/ddk/debugging) and showed you how to gather important information from your IIS machines. This month, I show you how to put into practice everything you've been reading about. I've created a simple Internet Server API (ISAPI) application that you can download and use to make IIS crash. (I've also included the source code and the symbols for the application.) So let's get started.

Setting Up WinDbg
To begin, copy debug.dll and debug.pdb to your scripts directory (usually C:\inetpub\scripts). Note that to execute a .dll file, you must mark this directory for Execute and set the appropriate NTFS permissions. Make sure that you mark the Default Web Site (or whichever site you want to run this application under) to run in process. To mark the site, open the Microsoft Management Console (MMC) Internet Information Services snap-in (the Internet Information Server snap-in in Windows NT 4.0), right-click the Web site that contains your \scripts virtual directory, then select Properties. Click the Home Directory tab to access the Application Isolation options (the Run in separate memory space options in NT). Set the process isolation to Low (or clear the Run in separate memory space check box in NT), then restart the site.

Now, attach the debugger to the inetinfo.exe process. Start Windows Debugger (WinDbg) by choosing Start, Programs, Debugging Tools For Windows, then select WinDbg. From WinDbg, choose File, Attach to a process. When the list of processes appears, select inetinfo.exe, then click OK. After WinDbg attaches to the process and loads some information, the window in Figure 1, page 2, appears. Notice that the next-to-last line says ntdll!DbgBreakPoint. This line indicates that the process to which WinDbg is attached is currently stopped and that the debugger is waiting for input.

IIS doesn't yet have a problem, so start a log file and tell WinDbg to let IIS run again. The two commands to accomplish these tasks are

.logopen c:\debuglog.txt
g

(You enter these commands in the prompt window—i.e., the field preceded by 0:000>—in WinDbg.) The first command sets up a log file that writes all output from WinDbg to a text file. (Note that the period before this command is necessary to the command.) The second command tells WinDbg to let the process (in this case, inetinfo.exe) start running again. WinDbg then goes into a monitoring mode. After you enter the second command, notice that the prompt window is no longer active. When a fault occurs that trips WinDbg, the prompt window will reappear.

Crashing IIS
Now that IIS is running with WinDbg attached, you can crash it. To crash IIS, open a browser and load the ISAPI .dll file that you put in the \scripts directory (e.g., http://localhost/debug/debug.dll). If you call debug.dll without URL parameters, you'll see the page that Figure 2 shows. Follow the instructions on this page to make debug.dll crash your system. When you run debug.dll in Crash mode, the browser eventually times out and you see the output window that Figure 3 shows.

   Previous  [1]  2  3  Next