IIS 7.5 - Default App Pool crash - Shibboleth SP

[Chris Glaubig]

Hello all,



I am not sure if this is the right list to be emailing issues. If not then
please let me know.



I have a few Windows Server 2008R2 machines that have Shibboleth SP 2.5.0
(Run as 32-bit enabled) installed on them.

Every once in awhile, the IIS Default Application Pool will stop. As soon
as I log into IIS and start it again, everything works again.



I get the following log entries into the shibd.log:

2014-09-05 16:21:28 ERROR Shibboleth.Listener [31]: socket call (unknown)
resulted in error (0): No error

2014-09-05 16:21:28 ERROR Shibboleth.Listener [31]: I/O failure processing
request on socket (420)

2014-09-05 16:21:28 ERROR Shibboleth.Listener [32]: error reading size of
input message





I also get some Event Viewer errors:

1) Faulting application name: w3wp.exe, version: 7.5.7601.17514, time stamp:
0x4ce7a5f8. Faulting module name: ntdll.dll, version: 6.1.7601.17514, time
stamp: 0x4ce7ba58

2) The description for Event ID 7701 from source Shibboleth ISAPI Filter
cannot be found. Either the component that raises this event is not
installed on your local computer or the installation is corrupted. You can
install or repair the component on the local computer.





Does anybody have some leads on how to reproduce this issue? I've found
some issues described online that might be related, but I don't want to
start testing fixes until I'm able to reproduce this issue.

Thanks,

-Chris

[Cantor, Scott]

That just mean the client socket disconnected, which is self-evident if
the web server crashes.

Post by Chris Glaubig
1) Faulting application name: w3wp.exe, version: 7.5.7601.17514, time
6.1.7601.17514, time stamp: 0x4ce7ba58
2) The description for Event ID 7701 from source Shibboleth ISAPI Filter
cannot be found.

The second is not the log message, you omitted the message. It's probably
just noting the filter restarting when the pool restarts.

Post by Chris Glaubig
Does anybody have some leads on how to reproduce this issue? I¹ve found
some issues described online that might be related, but I don¹t want to
start testing fixes until I¹m able to reproduce this issue.

Not reproduce, no. If there were a reproducible issue, I'd have fixed it.
It's very hard on Windows to get a stack trace from the crashes, and
without the debugging symbols there's not much information in them anyway.
If the issue is reproducible, then I can just debug it locally. Without
that, I don't have the time to even think about looking at it.

-- Scott

[Cantor, Scott]

Don't know what your use cases are, but if you have a variety of IdPs, I
would probably try and correlate crashes to activity from a particular IdP
as a starting point.

-- Scott