Is it possible that an exception in an aspx application of one application pool can cause problems for other application pools as well?
I have experienced problems with an IIS v7.5 where whole IIS got unresponsive after some application error and all http requests have timed out. However, the log files are not revealing much information about such an issue during the downtime.
If yes, under what circumstances might this happen?
Not typically, but it depends on the reason for the exceptions, and whether the root cause is in (or is breaking) a shared resource.
In a typical, shared-nothing, default-web-site world, each W3WP has its own memory space, handle table and associated resources, and these are unique to the process. One crashes, nobody cares. (Aside: Actually, if it's really the default web site i.e. static content only, a crash would be stunningly weird and a good indicator that something really wrong is happening on the box).
If the web app chooses to use resources (say, a database table, or a file somewhere on disk) and multiple web apps consume the same resource, then a problem in one can indirectly lead to a problem in others.
For example: that massively expensive SQL query you launched in process A, which you didn't catch the timeout exception from, is still tying up the same poor database server used by processes B C and D, which are heading for a timeout too...
Or, if a web app makes HTTP calls to another App Pool on the same box, then yeah, that's a clear dependency and a clear case where there's a problem!
But generally, where there's a case where everything goes wrong all at once, if you're running more than one web application they're unlikely the cause... the cause is more likely to be some other software, 90% of the time with a kernel mode component, running on the box.
Key examples are: Stuff which relies on SMB shares (i.e. content on \server\share ), particularly when the target is a non-Windows SMB emulator (so not bug compatible) or another interesting IO filter driver is in use... which neatly brings us to antivirus and filter drivers of that nature... K-mode drivers pick up file access, reroute the request via a u-mode process which gets busy or crossed up, causing a delay on k-mode IO, causing endless fun). (Honourable mention to authentication difficulties caused by auth infrastructure outages).
Still, this is all just guesswork without any data, so the best first step is to grab memory dumps (DebugDiag or Task Manager), feed them to DebugDiag or a friendly Windbg-capable frolleague, and get them to try to identify whether there's a user-mode cause for the delay.
If there isn't, then you move to k-mode troubleshooting, and things get a bit messier (most commonly, bluescreening the box to get a k-mode crash dump while weirdness is afoot).
