...
If you're not getting any crashes logged (and you have reason to think either the shibd service or the web server is crashing), you may need to look into whether Dr. Watson is enabled or do some additional research to find out why the crashes aren't logged.
...
- http://support.microsoft.com/kb/836080/en-us
- Dr. Watson isn't enabled: run "drwatsn32.exe -i" to install/enable it as the default debugger.
- Something's wrong with the registry key controlling debugging (see http://support.microsoft.com/kb/188296)
IIS crashes
Unfortunately, I don't think IIS tends to produce Watson events when it crashes, particularly if the crash is isolated in an AppPool process, which is usually the case on IIS6. I found a blog article with some links to tools that may be relevant to getting information about such crashes, but more research is needed.
Debug Build
In most cases, a stack trace without symbols is only partially helpful. To actually debug the problem, you may need to produce a stack trace with the debug version of the software, which is included with the installation package.
To switch to it, follow these steps:1.
- Edit your system path to point to
<installroot>\lib\debugand<installroot>\bin\debuginstead of the primary lib/bin directories.
...
- Edit the Shibboleth Daemon service definition to reference
<installroot>\sbin\debug\shibd.exe. You can do this by editing the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\shibd_Default and changing the ImagePath value.
...
- Change the references to the web server filter/extension/module to load the debug version of the appropriate DLL. This is server-dependent. (For IIS, you'll need to modify the filter definition and the script extension DLL mapped to ".sso" to point to
<installroot>\lib\debug\shibboleth\isapi_shib.dll.)
...
- Reboot and fix any issues preventing the software from loading.