我不完全确定去哪里寻求帮助，所以我想我会尝试 stackoverflow，因为它通常可以回答我所有编程相关问题的大约 90%。
简而言之，我有一个正在泄漏内存的开源 .NET 应用程序。从某种意义上说，这可能不是真正的内存泄漏，当应用程序关闭时，我怀疑内存被回收，但在它运行时，它不断分配更多内存而不释放它。最终，aSystem.OutOfMemoryException被抛出。
为了调试问题，我按照本文推荐的步骤操作，并生成了下图，其中红色是 .NET/CLR 内存“#Bytes in all Heaps”，绿色是带有 Windows 性能监视器工具的进程“Private Bytes” （请注意，绿线已按比例缩小以更接近红线，因为只有线条的形状对我很重要）：性能监视器输出。
我将图像作为托管内存泄漏的证据，然后使用 Windows 的调试诊断工具来尝试定位泄漏源（如文章中所述）。然而，我从 Debug Diagnostic Tool 得到的报告非常奇特。
基本上，我在应用程序运行时每 5 秒尝试收集一次“完整 UserDump”的每次尝试都被垃圾收集器当时始终处于垃圾收集周期的中间这一事实所挫败，导致调试诊断输出错误并防止其收集任何有用的 .NET 内存相关信息的工具。
现在我被卡住了，我知道我有一个托管内存泄漏，但我不知道如何缩小它的范围。我也对垃圾收集器如何总是处于收集周期的中间感到困惑，这让我想知道垃圾收集线程是否以某种方式被阻塞，阻止它释放内存和/或退出垃圾收集周期。
性能监视器图的某些部分分配的 .NET 内存略有下降，因此垃圾收集器不会永远卡住，但大部分时间肯定都卡住了，否则调试诊断应该能够做到用户转储。
几个问题：
.NET 应用程序中的垃圾收集器是否有可能在尝试释放一些内存时卡住，也许是从一些编码不佳的析构函数/终结器或其他东西？
我可以使用什么策略来继续缩小问题的来源？
