我有一个 .NET 多线程应用程序。它通过网络接收和发送大量的UDP数据包，并进行大量的计算。
我每天都打开这个应用程序，它在整个工作时间窗口都运行。并发线程数（通过任务管理器检查）通常在60到90之间变化。CPU使用率变化很大，并且偶尔会出现一些峰值，使服务器的CPU使用率达到100%。但我会说应用程序的平均 CPU 使用率很低，不到 5%。
有时，在某些随机的日子里，通常当接收到的数据包数量比平时多时，这个应用程序的并发线程数会增加到 ~250 并且服务器的 CPU 使用率保持在 100% 不变。该应用程序没有使用全部 100%（因为在此服务器上运行了其他应用程序），但它使用了所有可用的 CPU，使总利用率达到 100%。
线程的数量不会不断增加，就像出现某种死锁或内存泄漏一样。但它也不会随着时间的推移而减少。该进程使用的内存也不会随着时间的推移而增加，保持在没有发生问题的日子的相同水平。
我相信源代码上可能有一些错误会触发某种无限循环或类似的东西。
根据这篇文章，我尝试使用 Microsoft 的调试分析工具 v2 Update 3，但我遇到了一些问题，我将在下面描述：
1）我按照上面链接上的所有说明进行操作。我能够创建并激活规则以检测高 CPU 使用率。
2）但是，当问题开始发生时，我在任务管理器上看到许多新进程正在创建（与我的应用程序的进程同名），一次一个但按顺序创建，所有这些都具有状态“暂停”。需要明确的是：这些新的暂停进程不是由我的应用程序生成的，它们是由调试诊断收集工具在开始收集转储文件的数据时生成的。
3) 查看 DebugDiag 2 Collection 工具主对话框，然后我看到规则的状态为“已完成”，即使没有明确停用规则并且问题仍然存在。
4）然后我使用DebugDiag 2分析工具分析生成的转储文件。我选择“Performance Analyzers/PerfAnalysis”和所有转储文件，然后开始分析。
5) 分析结果如下：
我不认为这个System.ArgumentException与我的应用程序无关。我认为异常是在分析工具内部引发的，就像检查堆栈跟踪时一样。例如，我不知道在数据收集步骤期间生成了多个同名进程这一事实是否会导致分析工具尝试在字典中添加具有相同键的多个记录。
事实是，这个问题使我无法找出问题的原因。我知道还有其他分析工具，例如 DotTrace 和 ANTS，但在迁移到商业工具之前，我真的更喜欢使用免费工具。我什至联系了CodeTrack的开发人员，它是免费的，看起来是个不错的工具，但他给我的提示和建议对我来说并不容易理解，因为：
- 我的应用程序在生产服务器上运行。
- 在测试机器中模拟生产环境并不简单，因为我使用实时市场数据来为应用程序提供数据。
- 在有人建议使用 Visual Studio 自己的分析工具之前，生产服务器没有安装 VS（而且我不打算在它们上安装它）。
所以，我想我真正的问题是：有谁知道我在使用 MS 调试诊断工具时做错了什么（如果有的话）？我面临的问题真的是一个错误吗？是否应该在数据收集期间创建几个暂停的进程？如何解决此问题并使其正常工作，以便我可以使用它来调查我的问题？