If you have not previously setup the Dr.Watson tool to save information about program crashes then refer to 'MustGather setup of error reporting tools for 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 tool will save the log and dump data.
Remove any existing Dr.Watson log and crash files from its output directory (after backing up as appropriate).
These steps must be performed after the crash occurs.
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.
Copy the data saved by the Windows error reporting tool (i.e. Dr.Watson), if it exists,
into the 'ServerConfig.timestamp
' directory.
These files should be located in the Dr.Watson output directory(s) that were configured in the
System preparation section above.
The data files will usually be named drwtsn32.log
and user.dmp
.
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 differently named log files then you should copy these log files from
the IHS_install_root\logs\
directory to the
'ServerConfig.timestamp\files\logs
' directory.
The actual location is specified in plugin-cfg.xml
and
is generated by configuring LogLevel="Trace"
.
Example:
c:\WebSphere\AppServer\logs\http_plugin.log
'Application'
and 'System'
logs:
'Save Log File As...'
'Application'
or 'System'
),
and select a type of 'Event Log (*.evt)'
ServerConfig.timestamp
' directory
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:
'ServerDoc DescribeConfig'
system_info.txt
by the System Information program
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) |
Certain third party software may add a Winsock Service Provider layer which sits between IHS and the TCP/IP network. If this software does not implement some of the Microsoft advanced Winsock functions correctly, such as AcceptEx, it may cause IHS to crash on startup or restart. A possible fix is to add the "Win32DisableAcceptEx" directive to the IHS configuration file. Setting "MaxRequestsPerChild 0" (the recommended default) may also eliminate the crashes. This crash may be accompanied by the following message in the error log:
[warn] (OS 10038)An operation was attempted on something that is not a socket. : setsockopt(SO_UPDATE_ACCEPT_CONTEXT) failed.