MustGather information for web server crashes (Windows)


System preparation

If you have not previously setup dump tools to save information about program crashes then refer to 'MustGather setup of error reporting dump tools for Microsoft Windows' for information on performing this setup. This setup step must be performed prior to recreating the crash. Make sure you are aware of the directory into which the tools will save log and dump data.

Remove any existing log and crash dump files from the output directory (after backing up as appropriate).


NOTE: You must review the 'Known Windows crashes' section at the bottom of this document before proceeding to make sure your problem can't be solved with one of the solutions documented there.


Obtaining information after the crash occurs

These steps must be performed after the crash occurs.

  1. Gather general system and web server information.

    This information is gathered by running the ihsdiag ServerDoc DescribeConfig tool as described by the instructions in the System and web server information tool documentation.
    This will result in a directory of information named 'ServerConfig.timestamp'.
    That directory should be zipped and sent to IBM using the provided instructions after completing the following steps for obtaining additional information.

  2. Gather crash dump information

    Copy the data (logs and/or crash dump files) saved by the Windows error reporting tool (ex: Dr.Watson), if it exists, into the 'ServerConfig.timestamp' directory.
    These files should be located in the crash dump output directory(s) that were configured in the System preparation section above.
    For earlier Microsoft Windows versions that use Dr.Watson, the data files will usually be named drwtsn32.log and user.dmp.
    For newer Microsoft Windows versions that use the LocalDumps setup, the data files will usually be named liked 'http.exe.4359.dmp'.

  3. Gather any additional error or access log files that might be available.

    The access.log and error.log files will be automatically gathered by the ServerDoc DescribeConfig tool used above, but if the configuration file has been changed to specify different names for these log files then you should copy those log files from the IHS_install_root\logs\ directory to the 'ServerConfig.timestamp\files\logs' directory.

  4. Gather the WebSphere plug-in trace file

    The actual location is specified in plugin-cfg.xml and is generated by configuring LogLevel="Trace".
    Example:
    c:\WebSphere\AppServer\logs\http_plugin.log

  5. Gather Windows Event Viewer information

Recap of information to send to IBM support:

Create a zip file of the 'ServerConfig.timestamp' directory as described in the System and web server information tool documentation. Send this ServerConfig.timestamp.zip containing the following to IBM support for analysis:

Instructions to send diagnostic information to IBM support.


Known Windows crashes:

drwtsn32.log crashes:

In order to identify a known crash from drwtsn32.log, first open the log file in a text editor, e.g. notepad.exe. Move to the bottom of the file, then select Edit/Find, check Match-case, select Direction-Up, and enter the Find-what text "FAULT" (do not include the quotes).

Known crashes can be identified by looking for the text indicated below. It will be either close to the FAULT pointer or in the Function Name of the Stack Back Trace just below the FAULT pointer.

Search text Problem Resolution
ap_die IHS 2.0.42.2: Fixed in APAR PQ85834
IHS 2.0.47: Fixed in IHS 2.0.47.1
gsk_attribute_get_data Fixed in mod_ibm_ssl (not GSKit) at current recommended service levels
In theory could happen on other platforms but so far the crash has only been seen on Windows
gsk_attribute_get_cert_info FPK59158, fixed in Plugin 6.1.0.17 and later
mod_ibm_ssl!updateLibpath PK91197 (IHS 6.0 and 6.1 only)

Other Known Windows crashes: