isapi filter crashes after upgrade to sp2.2 on win2003
I had fully working SP 2.1, I did full uninstall/restart/install from
the new msi package.
after restart the IIS worker process immediately started crashing
every time with the error in
app. log (not including the localized messages):
Application Failure w3wp.exe 6.0.3790.3959 in msvcr90.dll 9.0.30729.1
at offset 00067892
and system log:
w3svc, event id 1011, data: 8007006d
w3svc, event id 1009, w3wp.exe process exit code: 0xc0000417
after replacing the shib. binaries with devel versions, i got this
error in popup:
Microsoft Visual C++ Debug Library : Debug Assertion Failed!
(Press Retry to debug the application)
I was unable to get further debugging info here. I dont have nor plan
to install VS2008. After trying with Debug Diagnostic Tools 1.1, the
errors moved to debugger itself (dbghost.exe crashing).
I managed to analyze the crash dump post-mortem from the non-debug
binaries with the following trace:
The configuration of the machine is:
Windows Server 2003 R2 Standard Ed., IIS 6.0, MSIE 8, php 5.2.9, mysql 5.
4-core xeon w/ HT, 4GB ram.
I've tested the new 2.2 release on WinXP SP3 + IIS 5.1 without
encountering this problem.
The shibd service started without problems and actually the error is
the same whether the service is running or not.
RE: isapi filter crashes after upgrade to sp2.2 on win2003
Pavel Krejčí wrote on 2009-06-18:
> I had fully working SP 2.1, I did full uninstall/restart/install from
> the new msi package.
> after restart the IIS worker process immediately started crashing
> every time with the error in
99% of the time that's a permissions issue. The reason I advocate the
postinstall package for IIS installs is that it's less likely to reintroduce
permission errors to a working system. I'll try and make that point stronger
in the page.
> I managed to analyze the crash dump post-mortem from the non-debug
> binaries with the following trace:
That's in the logging code, which would indicate to me that it might not
have permissions to create or write to the native.log file. Check the rights
IIS has to var\log\shibboleth.
Of course, IIS runs under about 6 different identities seemingly based on
> The shibd service started without problems and actually the error is
> the same whether the service is running or not.
They aren't the same process, and shibd runs as local system in most cases,
which has broader file rights than IIS tends to.
Also, I had planned to look into trying to prevent the crash by reproducing
that and seeing if I could fix the logging code, but nobody filed a bug on
it, so it didn't get done.
2009/6/18 Scott Cantor <[hidden email]>:
> That's in the logging code, which would indicate to me that it might not
> have permissions to create or write to the native.log file. Check the rights
> IIS has to var\log\shibboleth.
> Of course, IIS runs under about 6 different identities seemingly based on
> moon phase.
Thanks for tip, that was right on spot.
IIS6 in native mode uses 3 identities by default:
- w3svc service - local system, which is unlikely to cause perms. problems
- w3wp worker proces - network service. It can be configured to
anything for any given applicaton (pool). shibboleth isapi filter runs
as part of this process.
- script engines (ie. php, everything configured in the extension
mappings) - they use impersonation by default, which means
IUSR_machinename when run as anonymous. I think the shibboleth isapi
dll runs as this when invoked as .sso handler. It can be also
configured in metabase to run w/o impersonation, ie. to use w3wp
identity (CreateProcessAsUser property).
In my case, the network service acc. somehow didnt have writing
permisions to native.log. Fixing that solved the problem.