App pool crash / filter unloaded - ShibSP 2.5.1 on Windows 2008 Server SP2

[Adam Cohen]

So Im afraid this was a bit of a red herring, the error reported is not directly related to my symptom of shib not protecting the desired directory…that is now resolved and had something to do with my lack of understanding how IIS treat paths and sites differently.   

However, there's still the error reported when either the AppPool or Website is recycled through IIS Manager which is not impacting operations.     I made the entire c:\opt\shibboleth-sp directory writeable by Everyone, which didn't resolve the error.  I also captured an event on the System log that corresponds to the previously reported messages from the Application log:
A process serving application pool 'DefaultAppPool' suffered a fatal communication error with the Windows Process Activation Service. The process id was '5828'. The data field contains the error number.

On Mar 4, 2013, at 10:17 AM, "Cantor, Scott" <cantor.2 at osu.edu> wrote:

> On 3/4/13 12:58 PM, "Adam Cohen" <adamcohen at berkeley.edu> wrote:
> 
>> Definitely getting output in native.log, e.g:
> 
> Are there readable and writeable directories in var/cache/shibboleth and
> var/run/shibboleth?
> 
> Try turning up logging also to DEBUG in native.logger.
> 
>> Also event viewer is noticing when the app pool is recycled - it's
>> interesting that the sequence of errors is: filter shutdown/w3wp
>> fault/filter initialized
> 
> Hmm, actually what it might be doing is failing "gracefully" to initialize
> and that's somehow causing the crash. I'd have to see if I can simulate
> that. That would point to a problem creating files or what have you and it
> returning out of the startup routine with a failure.
> 
>> Im happy to setup debug and try to capture the stack trace but need a
>> pointer to the procedure.
> 
> I don't know how to get a trace on anything recent, I don't use Windows
> much anymore. Getting the debug files used is mostly a lot of path
> changes. You'd change the system path to add debug on the end of the lib
> directory, and then the path to the filter and extension inside IIS. I
> would ignore the Service control definition for shibd and let it fail, and
> just run shibd from the command line out of sbin/debug/shibd -console
> 
> But I'd focus on the logging first. The chances of it not being
> permissions are extremely low. So at the end of that day, that's what
> you're going to have to find.
> 
> -- Scott
> 
> 
> --
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net