问题标签 [debugdiag]

我有一个 MVC5 应用程序，它使用各种 nugets（autofac、devextreme、automapper、实体框架）。我有 15 个其他 MVC 应用程序，它们也使用所有这些并且工作正常，但是这个......

在本地，无论是在 IISExpress 还是 IIS (Windows 10) 上，它都可以正常工作。但是，当我将它部署到 Windows 2019 时，它会在启动时挂起。它似乎陷入了某种内存占用循环。没有任何 http 请求返回，并且在运行应用程序池 30 秒后使用超过 2GB 的内存，而本地它使用最大 200MB。

没有任何内容记录到 EventLog。

我添加了日志记录（serilog）和跟踪无济于事......我的启动代码（global.asax / startup.cs）成功运行并退出......然后什么都没有......第一个http请求挂起并且所有随后的队列。

我不知道下一步该往哪里看。我最后的祝福是安装 DebugDiag 并创建一个转储 -分析在这里

我不是 DebugDiag / Dump 专家，这一切都在告诉我，每个线程都在等待垃圾收集......嗯......没有帮助......

有人可以看看转储分析并告诉我下一步我能做什么/发生了什么？

我有一个 .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 调试诊断工具时做错了什么（如果有的话）？我面临的问题真的是一个错误吗？是否应该在数据收集期间创建几个暂停的进程？如何解决此问题并使其正常工作，以便我可以使用它来调查我的问题？

我尝试使用 DebugDiag 收集多个转储以了解 CPU 使用情况，但每次我尝试分析转储时，无论是服务器上的小型转储，还是我的工作站上的完整转储，都会生成如下报告：

没有什么比这更低了。DebugDiag 似乎总是无法读取转储文件。有什么办法可以纠正这种情况，还是我应该继续看其他工具？

我正在尝试在 Windows 2012 R2 服务器上的 IIS 应用程序池中调试高 CPU 使用率。我已安装 DebugDiag v2 Update 3 并在其 CPU 使用率超过指定阈值时收集 IIS 应用程序池的转储。

我能够生成 11 个转储 - 10 个迷你转储和 1 个完整转储。但是，当我打开 DebugDiag 分析工具并加载任何（或所有）转储文件并执行 PerfAnalysis 时，无论我尝试什么，它总是会失败并显示错误 System.ArgumentException。我已尝试多次执行此操作，但每次尝试分析文件时仍然遇到相同的错误。

有没有人能够成功地进行性能分析？我尝试了崩溃分析，它似乎工作正常；只有性能分析出错了。

这是我每次尝试进行 PerfAnalysis 时看到的错误类型：

概括：

• 为了发现 32 位进程中的内存泄漏源，收集了一系列内存转储。
• 尝试使用调试诊断分析转储在两小时后失败，报告超时异常。
• 在 DebugDiag.Analysis.exe.config 中提供“AnalysisCompletedTimeout”参数并指定 4 小时的超时确实可以成功阻止报告超时异常。相反，2 小时后，我看到生成了一个完全空的报告。

似乎我试图解决超时问题的尝试只是部分成功。我的问题是就如何使分析成功生成分析报告征求建议。

更多细节：

根据要求，客户向我们提供了一系列用于 32 位 COM+ 服务器应用程序的内存转储。这个想法是使用 LeakTrack dll 来帮助追踪在此过程中观察到的一些内存泄漏的来源。

启动调试诊断分析工具，并添加转储文件。选中“MemoryAnalysis”复选框后，开始分析。两小时后，分析工具会显示一个报告问题的消息框：

在使用 JetBrains dotPeek 浏览了 DebugDiag 分析工具程序集后，我对 DebugDiag.Analysis.exe.config 进行了更改，以尝试将超时设置更改为 4 小时：

重试分析后，该工具再次工作约 2 小时。完成后，Internet Explorer 会启动它的报告，结果证明是完全空白的。检查 DebugDiag 报告文件夹会发现 .mht 报告文件的大小为 0 字节。但是，这次没有显示“超时异常”消息框。

所以我的问题是：为什么没有生成报告？是否需要添加/修改其他配置设置以允许报告完成，无论是在调试诊断分析主机进程中还是在调用 (UI) 进程中？

为了尝试查看可能出现的其他问题，我确实在分​​析进行后将 windbg 附加到进程 DebugDiag.x86AnalysisHost.exe。我希望我能够看到其他异常情况的证据，这些情况可以为正在发生的事情提供线索。然而，该过程似乎以受控方式退出，没有表现出异常情况。

欢迎提出下一步去哪里的建议。

我在服务器中使用 DebugDiag 分析工具为 1.74 GB 的转储文件生成报告，它运行了一天以上，无法生成报告。我还尝试在单独的计算机（本地）上运行该工具

https://www.iis.net/learn/troubleshoot/performance-issues/troubleshooting-high-cpu-in-an-iis-7x-application-pool

它在“预加载符号文件（这可能需要一段时间）”处停止

我有一个 6GB 的转储文件，用于我生成的 IIS 进程，在处理的“运行分析”阶段，我在 60 秒限制后从该工具收到“由于超时而取消”消息。

有没有办法增加超时？

我们正面临 IIS 的问题。我们托管在 IIS 8.5 上的 .net 4.5 Web API 应用程序停止提供响应。如果我们查看工作进程，请求会排队。IIS 阻止对同一 URL 的任何后续请求。

服务器上的内存和 CPU 使用率受到控制。事件查看器没有任何错误。为了调查这个问题，我们在问题期间进行了内存转储，并通过 DebugDiag 工具运行它。

该报告表明某种僵局。

我不确定如何调查此问题。我对 DebugDiag 工具一无所知。请建议。

我在 IIS 10 上运行的 ASP.Net 应用程序遇到了一些问题，因为它有时会崩溃，给我一个通用的 WebException，其中没有更多数据。

我正在关注这篇文章以使用 Debug Diag Tool 获取内存转储，以便我可以更深入地了解正在发生的事情。但是在配置规则并激活它之后，我从我的站点收到了 503，当我禁用规则时，一切都恢复正常了。

对可能发生的事情有任何想法吗？

我有一个 .net 4.5 ASP.NET WebAPI 应用程序。在具有 4 个 CPU 的 8gig VM 上使用 1 个工作人员在 IIS 中部署。

我最近对其进行了更改（升级了 ServiceStack.Interfaces、ServiceStack.Common、ServiceStack.Redis 和一堆依赖项）并开始注意到部署此应用程序的 IIS 应用程序池大约每小时回收一次（几分钟或几分钟）。

我的应用程序日志中没有任何内容显示任何类型的问题。我使用 telegraf 收集指标，但我根本没有看到内存指标增加，就我查看的所有指标而言，一切看起来绝对正常，然后应用程序池回收。

我查看了事件查看器并按 WAS 源过滤了日志，并查看了 ID 为 5011 的事件。据我所知，这基本上意味着 IIS 工作程序崩溃。

因此，我使用了 DebugDiag 并在我的本地机器上运行它，并将应用程序部署在我的机器上（我可以在本地重现该问题）。它运行了一段时间，最后在事件查看器中得到了相同的事件。查看了来自 DebugDiag 的崩溃分析日志，我看到的只是一堆异常记录，但在崩溃之前没有任何具体内容。

在这一点上，我不完全确定我还能做些什么来找出导致崩溃的原因，所以希望有更多关于我可以做些什么来获得更多透明度的建议。

我认为正在发生的事情是，与我的一个依赖项和一些升级的软件包存在一些不兼容，这会导致抛出异常，该异常不会被任何东西处理并使 IIS 工作程序崩溃。

我的应用程序运行良好，所有 API 端点功能都没有问题，内存没有增加，CPU 很好。据我所知，崩溃之前没有任何问题。

想知道是否有人知道任何技巧来查找导致崩溃的原因和/或处理它，防止此异常逃逸并使工作人员崩溃。