您的最佳选择可能是使用 adplus 捕获挂起的 w3wp 进程的内存转储，然后使用 windbg + sos 扩展来尝试确定挂起的原因。

You can get adplus and Windbg here: http://www.microsoft.com/whdc/devtools/debugging/default.mspx

此外，Tess Ferrandez的博客是学习如何使用Windbg分析内存转储的绝佳信息宝库。她甚至还设有一系列实验室，针对特定情景供您参考。

将此翻译成中文：https://learn.microsoft.com/en-us/archive/blogs/tess/ https://learn.microsoft.com/en-us/archive/blogs/tess/

这可能发生的原因有很多。几年前，我在一个正在进行的Web项目中遇到过这种情况，需要拨打 Microsoft 的电话才能解决。我希望我能给您提供具体的细节，但这是我记得的。

.NET缓存您的Web应用程序中的文件夹。 服务器上有一个注册表键（不记得在哪里），它设置了文件夹限制（信不信由你）。 默认情况下，限制为150个文件夹。 如果您的Web应用程序中有超过这么多的文件夹，并且您尝试访问第151个文件夹，那么它将使IIS崩溃。

Yes this sounds crazy but trust me, I spent weeks with Microsoft until we found out the cause of the crash. The answer at the time was to up the limit in the registry and reboot the server. This was a couple of years ago, and I hope that this was fixed in later updates, but I offer this to you just in case you are using an older version of Server 2003.

对不起，我无法提供更具体的细节，但我只是想让您知道我的经历，以防这听起来像您的问题。

make sure IIS is set to be able to recycle its process automaticly, might help to fix the issue if it is a memory leak. (well ok cope with the problem not fix)

我的建议是给您的应用程序分配自己的应用程序池，这样您就可以百分之百确定是您想要的应用程序拖垮了服务器，当发生这种情况时，应用程序日志说了什么？

从您所提供的信息来看，这似乎是内存泄漏或未关闭的数据库连接/线程问题。

P.s If you are using N2 there was a known issue that when IIS recycled it wouldnt come back up.