单个服务器在尝试回收时有时会留下僵尸 w3wp.exe 进程。新进程正常生成，一切似乎都正常，只是旧进程仍然存在并占用内存。任务管理器报告只剩下一个线程，与通常有 40 到 70 个线程的活动线程相差甚远。
我使用 ProcDump 进行了完整的内存转储，以便在 WinDbg 中进一步分析。该机器是 Server 2008 R2 x64 8 核机器，WinDbg 表示：
Windows 7 Version 7600 MP (8 procs) Free x64
加载 sos 后，托管线程的打印输出显示以下内容：
0:000> !threads
ThreadCount: 19
UnstartedThread: 0
BackgroundThread: 19
PendingThread: 0
DeadThread: 0
Hosted Runtime: no
PreEmptive Lock
ID OSID ThreadOBJ State GC GC Alloc Context Domain Count APT Exception
XXXX 1 9d0 000000000209b4c0 8220 Enabled 0000000000000000:0000000000000000 000000000208e770 0 Ukn
XXXX 2 c60 00000000020c3130 b220 Enabled 000000013fbe5ed0:000000013fbe7da8 000000000208e770 0 MTA (Finalizer)
XXXX 3 a24 00000000020f0d60 880a220 Enabled 0000000000000000:0000000000000000 000000000208e770 0 MTA (Threadpool Completion Port)
XXXX 4 97c 0000000002105180 80a220 Enabled 0000000000000000:0000000000000000 000000000208e770 0 MTA (Threadpool Completion Port)
XXXX 5 c28 000000000210bfe0 1220 Enabled 0000000000000000:0000000000000000 000000000208e770 0 Ukn
XXXX 6 d40 00000000053f9080 180b220 Enabled 00000001bfe75d20:00000001bfe767c8 000000000208e770 0 MTA (Threadpool Worker)
XXXX 7 c18 00000000053f9b30 180b220 Enabled 00000000fff95880:00000000fff97210 000000000208e770 0 MTA (Threadpool Worker)
XXXX 8 f7c 00000000053fa5e0 180b220 Enabled 000000011fbea268:000000011fbea920 000000000208e770 0 MTA (Threadpool Worker)
XXXX 9 91c 00000000053fb090 180b220 Enabled 00000001dfc39138:00000001dfc39670 000000000208e770 0 MTA (Threadpool Worker)
XXXX a fb0 00000000053fbd20 180b220 Enabled 00000000fff922b0:00000000fff93210 000000000208e770 0 MTA (Threadpool Worker)
XXXX b fc8 00000000053fc9b0 180b220 Enabled 0000000160053ea0:0000000160054778 000000000208e770 0 MTA (Threadpool Worker)
XXXX c 538 00000000053fd460 180b220 Enabled 000000017fd8fc98:000000017fd911f8 000000000208e770 0 MTA (Threadpool Worker)
XXXX d 604 00000000053fdf10 180b220 Enabled 000000019fd7aa78:000000019fd7c648 000000000208e770 0 MTA (Threadpool Worker)
0 f 2cc 0000000005514c60 220 Enabled 0000000000000000:0000000000000000 000000000208e770 0 Ukn
XXXX 10 9bc 00000000020a90c0 220 Enabled 0000000000000000:0000000000000000 000000000208e770 0 Ukn
XXXX 11 9c0 00000000056b7a00 220 Enabled 0000000000000000:0000000000000000 000000000208e770 0 Ukn
XXXX e 9d4 00000000056b7fd0 220 Enabled 0000000000000000:0000000000000000 000000000208e770 0 Ukn
XXXX 12 9d8 00000000056b85a0 220 Enabled 0000000000000000:0000000000000000 000000000208e770 0 Ukn
XXXX 13 cb8 00000000056b8b70 220 Enabled 0000000000000000:0000000000000000 000000000208e770 0 Ukn
然而更令人感兴趣的可能是剩余的单个非托管线程的堆栈回溯的输出：
0:000> ~* kb 2000
. 0 Id: 85c.2cc Suspend: -1 Teb: 000007ff`fffd3000 Unfrozen
RetAddr : Args to Child : Call Site
000007fe`fdcc1843 : 00000000`00fd6b60 00000000`00fd6b60 ffffffff`ffffffff 00000000`77bc04a0 : ntdll!ZwClose+0xa
00000000`77ab2c41 : 00000000`77bc1670 00000000`00000000 00000000`77bc04a0 7fffffff`ffffffff : KERNELBASE!CloseHandle+0x13
000007fe`f56537c6 : 00000000`00000000 00000000`00000000 00000000`012da080 000007fe`f5442eac : kernel32!CloseHandleImplementation+0x3d
000007fe`f54443d2 : 00000000`00000007 000007fe`f5443d3c 00000000`00000000 00000000`77bc9997 : httpapi!HttpCloseRequestQueue+0xa
000007fe`f54444c3 : 00000000`00000000 00000000`012e6900 00000000`00000000 00000000`77bd5afa : w3dt!UL_APP_POOL::Cleanup+0x62
000007fe`f549384a : 00000000`012da080 00000000`00c93a28 00000000`012e6900 00000000`00000000 : w3dt!WP_CONTEXT::CleanupOutstandingRequests+0x83
000007fe`f549417a : 00000000`00000000 00000000`0000ffff 00000000`00000000 00000000`77bcf9fd : iiscore!W3_SERVER::StopListen+0x4a
000007fe`f562b5bf : 00000000`012d2f30 00000000`00000000 00000000`00000000 00000000`0000ffff : iiscore!IISCORE_PROTOCOL_MANAGER::StopListenerChannel+0x5a
000007fe`f5626e8f : 00000000`012d2f30 00000000`00000000 00000000`00424380 00000000`00000000 : w3wphost!LISTENER_CHANNEL_STOP_WORKITEM::ExecuteWorkItem+0x7b
00000000`77bcf8eb : 00000000`021782b0 00000000`021782b0 00000000`00000000 00000000`00000001 : w3wphost!W3WP_HOST::ExecuteWorkItem+0xf
00000000`77bc9d9f : 00000000`00000000 00000000`012d2f30 00000000`00424380 00000000`010aa528 : ntdll!RtlpTpWorkCallback+0x16b
00000000`77aaf56d : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!TppWorkerThread+0x5ff
00000000`77be3281 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : kernel32!BaseThreadInitThunk+0xd
00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!RtlUserThreadStart+0x1d
从堆栈跟踪中可以明显看出，w3wp 进程正在尝试关闭并执行其清理任务，但由于某种原因，ntdll!ZwClose 挂起了。它已经挂起了好几天，没有任何变化 - 除了内存使用量增加外，没有明显的副作用。
w3wp 进程不会一直挂起，我还没有找到可重现的模式。与此同时，还有什么进一步调试的建议吗？
答案1
令人印象深刻的研究。
检查 RSCA 以查看它是否仍具有该应用程序池的句柄，并可以告诉您是否仍有正在运行的页面。它可能会找到一种模式或线索。您可以在 IIS 的顶层深入研究它并打开“工作进程”，然后双击应用程序池（如果它出现在那里）。
答案2
该问题是否在网站新版本部署时同时出现？
当工作进程关闭时，对象会被从内存中清除。如果开发人员编写了在对象“完成”/“处置”时运行的代码，并且此代码抛出异常，则不会从内存中删除该对象。如果您无法从内存中删除所有对象，这可能会阻止关闭工作进程。
然后就是为什么它不是每次都发生的问题。可能是因为此代码位于系统中不经常使用的部分，因此导致此问题的对象类型并不总是存在。
测试的方法是：
- 启动系统
- 使用一小部分
- 手动回收应用程序池
- 检查僵尸进程
- 如果没有，请检查系统的其他部分
- ....
您还可以向开发人员核实他们是否有用于清理对象的特殊代码。
答案3
在 IIS 7.0 中，WWW 服务不再管理工作进程，而是作为 HTTP 侦听器 HTTP.sys 的侦听适配器，WWW 服务作为侦听适配器主要负责配置 HTTP.sys，在配置发生变化时更新 HTTP.sys，以及在请求进入请求队列时通知 WAS。
您在此服务器上具体运行什么？应用程序池，它们是集成模式还是经典模式？