The Shibboleth V2 IdP and SP software have reached End of Life and are no longer supported. This documentation is available for historical purposes only. See the IDP v4 and SP v3 wiki spaces for current documentation on the supported versions.

NativeSPDebuggingWindows

Owned by Scott Cantor
Last updated: Jul 01, 2008 by Former user (Deleted)Version comment
2 min read

There are two main concerns here:

  • Getting a stack trace when a process crashes.
  • Switching to the debug build of the SP.

Dr. Watson

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:

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\debug and <installroot>\bin\debug instead of the primary lib/bin directories.
  2. 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.
  3. 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.)
  4. Reboot and fix any issues preventing the software from loading.