我有一个旧版 ASP.NET 网站，其中包含 230 多个独特的 .ASPX 文件。该网站每天有数十万次点击，涉及许多不同的文件。它泄漏内存，导致全天定期进程回收（Windows 事件 ID 5117：为应用程序池“%2”提供服务的进程 ID 为“%1”的工作进程已请求回收，因为它已达到其私有字节内存限制。）
我已经测试了 30 个最常访问的页面并修复了其中几个页面中的内存泄漏，从而带来了显着的改进。这些页面的负载测试表明它们不再泄漏。但这留下了 200 多页仍未被检查。但是有 200 多个文件要检查，我想知道是否没有什么可以做的更有条理或更聪明的事情。
例如，是否有可以添加到 Global.asax 中的 Application_BeginRequest 或 Application_EndRequest 事件处理程序的工具？如果有，具体应该监控什么？示例代码和/或讨论将是最有帮助的。
您可以用来组织并首先堵住最大漏洞的最佳工具是 windbg。
它带有 windows sdk
这是一个参考
http://msdn.microsoft.com/en-us/library/windows/hardware/ff551063(v=vs.85).aspx
刚开始习惯这些命令可能有点困难，但这是你想要做的。
1. Install windbg on a machine that is running the site
2. Load test all the pages and get the memory usage way up
3. (optional) Force garbage collection with gccollect()
4. Attach to w3wp.exe with windbg
5. load your symbols (.pdbs and the clr and sos)
6. dump the memory (!dumpheap -stat)
这将按内存中对象的数量向您显示排序列表。当您有泄漏时，您会开始堆积大量相同的物体。
您需要深入挖掘才能获得这些对象的大小
1. The first number in the row will be the method table copy this number
2. Dump the method table (!dumpheap -mt #######)
3. Choose a single objects ID from the first column and copy this number
4. Get the size of the object (!objsize #######)
（对象数）X（单个对象的大小）=泄漏的大小
找到占用空间最多的类并首先插入它们。
这也可能有帮助 - CLR 分析器 http://www.microsoft.com/en-us/download/details.aspx?id=14727