Debugging a mysterious IIS crash

I have an ASP.NET MVC web application which integrates a C# managed library of ours that loads unmanaged plugins to do some file processing. These unmanaged plugins in-turn rely on a few 3rd party libraries to do their dirty work; some of which are causing IIS to crash.

We use the exact same library in a desktop application which is able to process the files just fine. The files also process just fine when running under the Cassini web server that comes with Visual Studio 2008 (IIS and Cassini are running off the same folder on my local box).

I've done a Crash Analysis with Debug Diagnostic (img) which I'm not able to extract any useful information from.

I used procexp a bit to see if there where any failed file or registry access attempts that might be causing an issue but came up short. I didn't see any but could have easily missed them considering the number of lines produced in that kind of logging.

I configured the application pool to use a domain account and made that account an Admin on my box thinking it might be a permission issue but no luck. Are there other access restrictions in IIS that I'm not aware of?

Suggestions? Articles? Tools? Voodoo?

EDIT: I was able to debug this down to the 3rd party library's initialization routine. Since the l开发者_如何学编程ibrary works fine running under other hosts I suspected either a permissions issue or memory issue. It turned out to be a stack size limitation when running under IIS. See Stack sizes in IIS - affects ASP.NET

Sounds like you should try and enable 32-bit applications in the application pool. Interop doesn't play nicely with binaries compiled for 32-bit if you're running 64-bit.