There are two main concerns here:
- Getting a stack trace when a process crashes.
- Switching to the debug build of the SP.
The tool involved in getting stack traces after a crash is Dr. Watson (drwtsn32.exe). On most newer servers, Dr. Watson is configured to silently trap crashes rather than report them visually with a dialog box (the way you're used to on a Windows desktop).
When it works, there's not much to it, you can run the program after a crash and see a log of the failure in its list. You may need to adjust some Dr. Watson options to get the right set of information logged, mainly the thread dump and stack trace.
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.
Some possible reasons:
- 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)
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.
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:
- Edit your system path to point to
<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
- Reboot and fix any issues preventing the software from loading.