问题标签 [debugdiag]

最近，我收到了一批新的转储，以识别我们的 3 个 WCF 服务中的 HighMemory 使用情况。托管在 64Bit AppPool 和 Windows Server 2012 上。

1. 应用一：
   ProcessUp 时间：22 天
   GC 堆使用量：2.69 Gb
   加载模块：220 Mb 已
   提交内存：3.08 Gb 本
   机内存：2 Gb
   

识别为大 GC 堆使用的问题是由于未关闭的 WCF 客户端代理对象。其中几乎占 2.26 Gb，其余用于 GC 堆中的缓存。

2. 应用程序二：
   ProcessUp 时间：9 小时
   GC 堆使用量：4.43 Gb
   缓存大小：2.45 Gb
   加载模块：224 Mb 已
   提交内存：5.13 Gb 本
   机内存堆：2 Gb
   

被确定为大多数对象属于 System.Web.CaheEntry 的问题，因为它们是由于缓存大小过大。Gc 堆上 2.2 Gb 的 String 对象具有 CacheRef 根对象的根。

3. 应用三：
   缓存大小：950 Mb
   GC 堆：1.2 Gb 本
   机堆：2 Gb
   

我们最近升级到 Windows Server 2012，我也有旧的转储。这些转储不显示同一应用程序的本机堆。它只有大约 90 Mb。

我还使用 WinDbg 通过 !heap -s 命令探索本机堆。它显示了非常小的本机堆大小，如下所示。

我只是很困惑为什么 DebugDiag 2.0 在每个 WCF 服务中都显示 2Gb 的本机堆。我的理解是 !heap -s 也应该转储相同的本机堆，并且它应该与调试诊断报告图匹配。报告还显示以千 TBytes 为单位的值。

谁能解释我为什么 WinDbg 命令 !heap -s 和 DebugDiag 报告是变化的。或者我对上述命令的了解不正确。

我还使用 Pykd 脚本转储本机对象统计信息。其中没有显示大量的对象。

另外，上述输出中的外部碎片 99%（3 个空闲块）是什么意思。据我了解，碎片化内存的连续内存块较少。但未能将其与百分比联系起来。

编辑 1：应用程序 2：

应用三：

我有几个.dmp文件，其中包含从托管在 IIS 中的 .NET 应用程序捕获的内存，我想通过某种分析器运行它们，该分析器将告诉我哪些方法导致我们的应用程序无法解释的高内存利用率。

我已经尝试过 DebugDiag 分析以及 Visual Studio 附带的工具。我可以设法在内存中生成对象列表，但我不知道哪种方法正在生成对象。

谁能指导我使用一个可以轻松帮助我解决这个问题的应用程序，或者甚至可以指导我如何使用 DebugDiag 或 Visual Studio 来做到这一点？

我已经尽可能多地使用谷歌，但我根本没有成功找到我正在寻找的答案。如果需要的话，我愿意购买工具，但我想确认购买的任何东西实际上都能够回答我的问题。

我当前的应用程序包含 3 层-Web 层-应用层-数据库

在对 100 个用户进行测试时，我们发现 App 层的 cpu 接近 90%，而 Web 服务器和数据库服务器运行良好。

我无法弄清楚是什么代码导致 CPU 使用率高。主要是我们在那里进行 CRUD 操作。我们以 DTO 的形式获取输入，我们将它们传输到实体中（使用实体框架），添加/更新/删除到数据库中。在 Get 操作的情况下，我们将数据获取到 EF 实体中，将它们存储在 DTO 中，然后将 DTO 发送给客户端。

我曾尝试使用 DebugDiag，但找不到任何有用的信息。

以下是服务器的配置：

Web 服务器（数量 = 1）处理器 Intel Xeon CPU X5675 @3.07 GHz 2.19 GHz

核心数（虚拟） 8

内存 8GB

操作系统 Windows Sever 2012 标准版

处理器类型 64 位

安装的软件 NET Framework 4.5

应用服务器（数量 = 1）处理器 Intel Xeon CPU X5675 @3.07 GHz 3.07 GHz

核心数（虚拟） 8

内存 8GB

操作系统 Windows Sever 2012 标准版

处理器类型 64 位

安装的软件 NET Framework 4.5

DB 服务器（数量 =1）处理器 Intel Xeon CPU E7-4830v2 @ 2.20 GHz 2.19 GHz

核心数（虚拟） 8

内存 8GB

操作系统 Windows Sever 2012 标准版

处理器类型 64 位

安装的软件 Microsoft SQL Sever 2014

我们有一个 C# Windows 服务，它运行一个拆分为多个任务的进程。大多数任务使用 WCF 联系 Web 服务以针对数据库执行工作。服务的任务在多个线程中运行。

一位客户向我们提出了一个支持案例，称 Windows 服务偶尔无法响应，需要重新启动。我从 Windows 服务获得了内存转储。我运行DebugDiag 2.0来分析转储文件。

DebugDiag 报告的摘要中有一个有趣的条目：

WindowsService.DMP 中的以下线程正在尝试发出 HttpWebRequest，但它们似乎并未在远程服务器上等待响应（例如，不是“在线”）。这些请求中的一个或多个正在使用其最大可用连接数的至少一半。

( 17 18 27 31 32 33 42 ) 12.07% 的线程被阻塞（7 个线程）

如果许多线程都处于这种状态，则通常表明限制限制（即“maxconnection”设置）已用尽。单击左侧列表中的任何线程以查看它正在等待的 WebRequest 的限制详细信息。

如有必要，您可以通过修改应用程序配置文件中的 'maxconnection' 参数（请参阅<connectionManagement>Element）或以编程方式修改适当的 ConnectionLimit 属性（请参阅管理连接）来增加可用连接的数量。

我跳到线程 17 并看到了这个：

线程 17 - 系统 ID 4612

入口点 mscorwks!Thread::intermediateThreadProc 创建时间 9/10/2015 10:13:14 AM 在用户模式下花费的时间 0 天 00:00:00.000 在内核模式下花费的时间 0 天 00:00:00.000

该线程正在尝试发出 HttpWebRequest，但是它们似乎没有在远程服务器上等待响应（例如，不是“在线”）。这些请求中的一个或多个正在使用其最大可用连接数的至少一半。

警告，至少有一半的可用连接正在使用中

HttpRequest URI：http://WebServer/MyWebSite/SubDir/MyService.svc ServicePoint - ConnectionLimit：48 CurrentConnections：44

HttpWebRequest 对象是一个环回地址，但连接限制仍然适用于此 webrequest 对象，因为已定义连接限制（通过在 processModel 部分中将 autoconfig 设置为 true 或通过在 connectionManagement 部分中添加 * 条目

.NET 调用堆栈如下：

我看到了它提出的建议，并已开始研究它们。我的问题是：

为什么 DebugDiag 说线程似乎没有在等待服务器响应？

查看.NET Reference Source，请求似乎已成功提交，服务似乎正在等待响应。

更新

进入正常调用后，我确实看到一个调用堆栈在 ws2_2 处等待，如下面的 Puneet Gupta 所建议：

所以通常，它将等待来自 Windows 套接字的响应。在这种情况下，线程可能正在等待连接变为可用于处理请求——如其他 DebugDiag 消息所示。

服务器：Windows 2012r2 Debug Diagnostic Tool v2.1 update 1

调试器附加到应用程序池。我已经确认它是该站点的正确池。池崩溃，但是永远不会生成转储文件。

“由于为该应用程序池提供服务的进程中出现一系列故障，应用程序池 '' 将被自动禁用。”

该规则只是简单地设置为查看应用程序池，而不是捕获第一次机会异常。我试过几次删除并重新添加它，但它永远不会生成转储。

我检查了它生成的调试日志，这是在池崩溃之前生成的最后一个异常：

警告：帧 IP 不在任何已知模块中。以下框架可能是错误的。0x0 0x0 0x0

编辑：想要添加转储确实为第一次机会异常生成。当试图抓住第二次机会或实际导致崩溃的机会时，这似乎只是一个问题。

编辑 2：每个请求的调试日志之一的最后几行：

异常与此相关

我试图通过分析由 DebugDiag 2.1.0.7 创建的转储来调试由 .NET 4.6 MVC5 应用程序引起的一些 CPU 问题。我发现即使在加载自定义 .pdb 符号后，我仍然没有在生成的报告中获得堆栈跟踪信息：

报告显示的错误是

我注意到 DebugDiag 1.2 版不支持 .NET 4.0+。DebugDiag 2.1 可能不支持 .NET 4.6？

CefSharp Winforms 版本 43.0.0.0，libcef.dll 3.2357.1287。

在文本框中选择文本，然后在屏幕键盘上按下一个键（在普通键盘上不会发生），我有时会在 libcef.dll 中遇到堆栈溢出。

我正在扯掉头发，试图找出原因。让我慢下来的一件事是无法将正确的 pdb 文件连接到 dll。尽管从CefBuilds下载了它的所有变体。

我有各种故障转储，想知道是否有其他人有解决此类问题的经验。WinDBG 也可以是中文的，DebugDiag 更容易理解，但如果没有有效的 pdb 文件，也根本没有任何用处。

我无法在 winform 示例应用程序中重新创建该问题，因此它对我们来说绝对是本地的，所以我目前正在将代码从左到右和中心剥离以隔离原因，但非常感谢有关如何将 pdb 文件加载到 debugdiag 的一些指导停止这个：

尽管如此：

libcef.dll 版本：

对于任何感兴趣的人，这是当前崩溃线程的堆栈跟踪：

……………………………………………………………………………………………………………………………………………………………………

我想主要问题是有人知道是什么导致堆栈溢出吗？（此问题存在于winform示例应用程序中的41.0.0，现在只存在于我们自己的应用程序中的43.0.0）。

第二个问题是为什么 pdb 文件没有在 debugdiag 中加载。

编辑。我在 32 位编译，似乎没有 32 位版本的 libcef.dll v3.2357.1287 的 pdb 文件。事实上，根据 cefbuilds.com 这个文件是不存在的。

When I attempt to do a performance analysis on a dump file with DebugDiag 2.1, I get a NullReferenceException with the following stack trace in the report:

The application being analysed is running .Net 4.5.2. Does anyone have a solution?

尝试使用 debugdiag2 update 2 对任何 Windows 商店应用程序（包括内置应用程序）进行“监控泄漏”失败。

我收到“无法监视...中的泄漏。请确保每个人都具有...leaktest.dll 的读取和执行权限”消息。

我已经按照指示更改了权限，并遵循了以下建议：

使用 DebugDiag 和 LeakTrack 对 Windows 应用商店应用程序中的本机内存泄漏进行故障排除

但没有运气。

适用于非商店应用程序。

有人有这个工作吗？

每次调用特定方法时，我都会尝试使用调试诊断工具来创建 Minidump。

我从简单的控制台应用程序开始：

然后我在 DebugDiag 中创建规则以在每次Program.Main调用时创建 minidump： 不幸的是，它不起作用，在 DebugDiag 日志中我收到消息：

我已经在 DebugDiag 中设置了符号服务器，并使用 WinDBG 检查了此配置：

有没有人有什么建议？

PS。我尝试调试的应用程序是 64 位的。我尝试将当前进程目录（带有 pdb 文件）添加到符号路径，并使用各种格式的断点表达式（如Module!Class::Methodor Module.dll!Class.Method(OtherType)）但没有成功。