There are two main concerns here:
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:
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:
<installroot>\lib\debug
and <installroot>\bin\debug
instead of the primary lib/bin directories.<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.<installroot>\lib\debug\shibboleth\isapi_shib.dll
.)