问题标签 [debugdiag]

是否有一种简单的方法来监视给定的 Windows 进程是否存在明确定义的 .NET 异常（第一次或第二次机会）并在引发该异常时运行 powershell 脚本？我真的不需要进程转储（还）。

我正在尝试使用从 Windows Server 2016 机器上的 w3wp.exe 进程生成的崩溃转储文件在我的 Windows 10 笔记本电脑上运行DebugDiag Analysis (v2.3) ......但应用程序从未通过“转储线程数据”（进度动画继续，所以它不是 GUI 挂起。）

（我不允许在服务器上安装 DebugDiag，因为它是生产机器并归客户端所有。他们允许我更改注册表设置以生成故障转储文件，然后我将其复制到本地计算机。）

IIS-10 正在运行 ASP.Net 4.5.2 Web 应用程序，服务器上的相应事件日志条目（生成崩溃转储文件时）表明存在未处理的 stackoverflow ( 0xc000000fd)。

我已经尝试了所有大小约为 50Mb 的故障转储文件 - 但我最终只是退出了 DebugDiag，因为它从未通过“转储线程数据”。

根据这个问题的唯一答案，一个 400Mb 的文件“可能需要 4-5 分钟才能运行”......但是，我让我的（非常强大的）笔记本电脑运行 50Mb 的分析超过 30 分钟，没有任何进展.

我还看到需要互联网连接- 我可以确认我有一个快速连接，所以这不应该是问题。

如果需要，我可以将文件放在某个地方进行下载，但除非真的有必要，否则不想这样做。

我怀疑是否有人能够提供帮助，但我正在努力寻找如何解决这个问题

我最近正在调试我们的一个应用程序的“挂起”问题。我是该工具的新手，但对我在 DebugDiag 分析中看到的内容有一个特殊的问题。其他问题我会单独发帖。它有一个标题为“以前的 .NET 异常（所有 .NET 堆中的异常）”的部分，其中列出了 5 个异常：

有人可以帮我理解一些事情：

• 该部分的标题是什么意思？“以前的 .NET 异常”？
• 如果抛出异常，为什么它不会出现在日志记录中，为什么应用程序不会中止而不是挂起？我检查了我们的代码是否有任何可能的异常被“吃掉”。
• 为什么没有相关的消息或堆栈跟踪？我获得了 .dmp 文件中所有其他内容的调试信息，包括所有线程的 CLR 堆栈跟踪。有没有更好的方法/工具来确定这些来自哪里？

提前致谢！

我正在通过 DebugDiag 中的转储分析调试我们的一个应用程序的挂起问题。长时间运行（1-2 小时）的 .Net 控制台应用程序并非始终如一地进入一种状态，即它似乎什么都不做但不退出（即挂起）。它正在运行的 VM 上有大量资源，而且它消耗的内存永远不会超过可用内存的 1/4。分析详细说明了线程正在等待什么：

第二组线程像这样：

我对这篇文章的问题是，这是否表明垃圾收集器 (GC) 已被阻止，或者是否可能存在其他问题？需要注意的是，该过程似乎无限期地挂起，有时在我们注意到并杀死/重新启动它之前几个小时。如果 GC 被阻止，我将如何确定使用 dmp 为什么以及在什么对象上？我已经检查了代码，并且任何对象都没有最终确定，我知道这可能是一个来源。也许也有帮助，在 DebugDiag 的“.NET 线程摘要”部分中，只有 1 个线程具有非零 (1)“锁定计数”。

非常感谢您对此的任何想法或建议。

提前致谢！

我一直在监视 IIS 服务器中的工作进程，在应用程序池中的当前请求中，它显示请求花费了时间（超过 100 秒）。例如 url Service/RequestService 时间经过 100000

因为上面的 url 是 wcf 服务的 url 并且有很多操作合约，例如 GetRequest()、GetRequests()、CreateRequest() 等等

我想知道请求调用了什么操作合同，但 IIS 请求监视器没有显示任何详细信息。

我的问题是如何知道使用调试诊断工具调用了服务中的哪些操作合同。我尝试使用调试诊断工具转储并生成分析报告，其中有很多东西，我不确定我在寻找什么信息。

我在 Windows 10 机器上遇到内存泄漏，在调查了从导致问题的进程（WPF 应用程序）中提取的一些转储后，我发现了许多“MS.Internal.Automation.SynchronizedInputProviderWrapper”实例，基本上大多数对象都保存在此类型引用了内存而不是收集的垃圾。

我一直在使用 dotMemory（实例的密钥保留路径）、Visual Studio 2019（用于转储比较）和 WinDbg 进行进一步调查。

根据这个stackoverflow答案： UIAutomation Memory Issue

他们是在 Win 8 RT 和 windows 2012 服务器上修复问题的汇总：https: //support.microsoft.com/en-us/help/2885482/memory-leak-when-using-ui-automation-in-windows- 8

根据微软的说法：请参阅此链接

当使用 UI 自动化框架的多个应用程序同时在基于 Windows 8 的计算机上运行时，会发生内存泄漏，并且您会遇到高 CPU 使用率。

而且我认为这在 Windows 10 上也可能是相同的问题，但找不到解决此问题的修复程序或汇总。

更新：

我对 SuperDump 进行了另一次分析，发现了内存泄漏的潜在解释，但我无法解释调用堆栈：

谢谢

十年前有一个类似的问题，但没有好的答案——希望从那时起事情发生了变化。

我有一个基于 .NET 4.72 的相当多线程的 Winforms 应用程序。我正在使用 Process Explorer Threads 视图查看它，它有很多clr.dll!LogHelp_TerminateOnAssert+0x6835类型调用。我已经设置了符号路径，但它并没有真正为我清除任何东西。

我对应用程序进行了转储，并通过 DebugDiag 和 WinDbg 运行它，并没有看到任何突出的可疑之处。

所以我的问题：

• 我应该关心大量的 LogHelp_TerminateOnAssert 调用吗？
• 应用程序是否泄漏内存？
• 当我在 Visual Studio 中运行应用程序时，是否有过多的异常无法过滤？

我的代码中唯一的条目是!get_FrameReceived该线程的堆栈如下：

循环次数最多的线程的堆栈是这样的：

我正在尝试使用 DebugDiag 创建一个转储，该转储将包含未处理的 .NET 异常的信息。

转储文件的创建似乎依赖于运行代码，我不明白为什么。

这些是我采取的步骤：

1. DebugDiagTest准备一个使用以下代码命名的简单控制台应用程序，它会引发InvalidOperationException异常：

2. 用编译和运行DebugDiagTest.exe true，还不要按任何键；让它等待按键（步骤 4）。

3. 准备一个DebugDiag异常规则（可以按照这篇文章）。

4. 回到 running DebugDiagTest.exe，然后按一些键使其崩溃。

5. 转到 C:\Program Files\DebugDiag\Logs\Crash rule for all instances of DebugDiagTest.exe，您将看到一个.dmp文件。

6. 现在运行DebugDiagTest.exe false，再次转到C:\Program Files\DebugDiag\Logs\Crash rule for all instances of DebugDiagTest.exe，您会看到没有创建任何.dmp文件。

您现在可以随时重新运行DebugDiagTest.exe true，并且每次都会创建转储文件。但是，重新运行DebugDiagTest.exe false永远不会创建转储文件。

我的问题：
为什么运行DebugDiagTest.exe true会创建转储，而DebugDiagTest.exe false不会？

DebugDiag2 生成的报告格式为 HTML，但仅使用文本编辑器似乎无法阅读。我最近分析了一个进程转储，该转储生成了一个报告，该报告会导致我打开它的任何浏览器（IE、Edge、Chrome）崩溃。有没有办法让 DebugDiag2 输出格式为仅文本的报告？