I too suspect either nHibernate or that iesa collection is the one causing the problem. Nhibernate is on 1.2 and no use for non-generic or generic emulation bits seem to required any more, but it doesn't help solve this one.
From this box I cannot help more for now but might try later tomorrow, I have opted to try out other pieces after a week of failures.
My thoughts are amd64 2003 R2 install (which should be possible on most even 1-year old boxes) will cause the problem. I have tried varying accounts, user and group changes, sql traces, and more.
The last two assemblies loaded are nHibernate and iesa collection that cause the worker process to terminate, and eventually disable the application pool. Pitty because I really liked the look of your app, perhaps patch can be made by omitting the latter. And I have sent MS a bunch of reports just for fun :-)
Perhaps we can look into this if there was some diagnostic reporting from your end on startup, or I could look further with debugging tools but the former would certainly save time on both ends and pinpoint the offending section.
(off-topic: I am not a huge fan of nHibernate at all but looking around it does seem to cause indirect Fatal Execution Engine errors. Sure we all have learned by now it is the way MSFT has decided to terminate worker processes, provide guidance and so on but IIS or worker process crashing and tools to diagnose those problems are worrying to date. Just thought t is funny considering how much effort they have put in making 'crash' sound like a normal course of operation and testament to that is every blog mentioning 'service unavailable' is problem 'our problem' affecting all pools. Not many blogs talk of even MSFT themselves having the right download for the x64 iisdiag tools ( their debug tools gave issues all day long today)
