问题标签 [memory-dump]

Start ProfilingSCM 门户中有一个非常适合 CPU的优秀按钮。

然后有一些引用Download GC Dump按钮的来源： https ://stackoverflow.com/a/27987593/647845

但这似乎不再可用。

然后是Download memory dump按钮。但是现在我不知道如何/是否可以看到我也使用的类型/引用计数/大小统计信息。

在 C# Azure Web 应用程序中查找内存泄漏的推荐方法是什么？

我为似乎在内核驱动程序中的死锁线程上等待的应用程序强制执行完整的内核转储。我相信我已经确定了有问题的线程，因为它有1920031 个滴答声(0:08:19:12.675)，这大致是应用程序等待的时间。该线程在用户和内核时间上也只花费了0.015 毫秒：

它对同一设备和同一文件有两个待处理的 IRP 。

!findhandle 在该文件上确认 MyApplication.exe 可以访问它。

文件未锁定：

1. 一个线程如何对同一设备和文件拥有两个几乎相同的待处理 IRP？
2. 文件对象如何在两个 IRP 中打开但只有一个打开句柄？

谢谢！

I have a 32-bit memory dump from a .NET 2.0.50727.6421 process that has stopped working correctly. Some of its work is driven from a System.Threading.Timer. The timer is supposed to trigger some processing.

I am thinking the timer may be stopped, but I cannot figure out how to see this from the memory dump.

How can I tell the status of a .NET 2.0 System.Threading.Timer from a memory dump?

I have dumped the timer object. Inside, there is a TimerBase object:

I have dumped the TimerBase object, too. There is a handle inside:

I'm not sure how to inspect the timerHandle. I can look at the raw memory, but this doesn't tell me much:

I am not sure what the handle is pointing to. I tried dumping it as _KTIMER object, but I don't know enough to see if this is the right kind of object, and if it is, what kind of thing it is:

Dumping the handle gives me an error:

I can see there are 9 managed threads:

Thread 0 is the main thread of this Windows service. Thread 2 is the GC finalizer thread.

Thread 4:

Thread 9 is a System.Net.Timer thread:

我看到我的 .NET API（使用 Nancy/OWIN）上的 CPU 和 http 队列增加了。

它在 Azure 上运行，所以我进行了内存转储。

我试图弄清楚如何阅读 DebugDiag 分析报告。

这是警告部分：

我假设“62 个客户端连接”是排队的原因，所以我深入研究了该部分。

对一个 URL 有一些常见的请求，如下所示：

Host Header MyApi:80 GET request for /companies/list HTTP Version HTTP/1.1 SSL Request True Time alive 1 day(s) 03:43:21 QueryString
Request mapped to
HTTP Request State HTR_READING_CLIENT_REQUEST Native Request State NREQ_STATE_PROCESS Client Connection State CCS_STARTUP

但我真的不知道那是什么意思。那是说请求仍然开放，到目前为止需要 1 天吗？它们还出现在“运行时间”部分。

代码正在运行异步/等待，所以我想知道我是否没有正确处理取消等？

谁能给我一些关于如何分析内存转储以诊断高 CPU/队列的建议？

谢谢

我正在尝试在DebugDiag 2.0中创建自定义转储分析规则。我们的代码是一个包含许多程序集的托管 C# 应用程序。每个程序集都有自己的自定义属性，其中包含有关为创建程序集而编译的源文件的修订信息。

我知道可以通过WinDbg命令!savemodule或 !saveallmodules 将模块提取到文件中。然后我可以使用像 JetBrains DotPeek 这样的工具来检查程序集属性。

我想在 DebugDiag 分析期间找到这些属性，并将属性信息转储到 DebugDiag 报告中。在自动分析报告中包含这些属性将帮助我的团队提高效率。

如何使用 DebugDiag 2.0 对象从内存转储中提取托管程序集属性？

我尝试从NetDbgObj调试器对象中获取模块，但我没有看到从那里获取属性的便捷方法：

我可以看到 ClrModule 对象可通过 NetDbgObj.ClrRuntime 对象获得。我可以得到一个 ClrModule 对象，但我不知道该怎么做。、 和有属性MetadataAddress，但我不知道如何处理这些。MetadataLengthMetadataImport

这些属性对象不在托管堆上，因此!dumpheap -type MyAttribute不会返回它们。

程序集属性作为元数据存储在程序集数据的某处。我已经看到了！DumpModule 的输出：

我知道我可以使用 dc 之类的命令转储元数据：

我不知道从这里去哪里。

我在 Linux 机器上有这个文件。对我来说，它看起来像核心转储，与堆转储不同。正确的？

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

如果它是核心转储，它代表什么？我了解 8dbe79c2f000-8dbe79c34000 应该是内存空间。但是这个信息代表什么？

1. 30800604
2. /path../charsets.jar
3. FD:01

我目前正在使用 python 处理由 belkasoft、ftk imager 等应用程序创建的内存转储，它们通常具有扩展名 .mem 或 .dmp，其形式为：

我想可视化这些数据，比如说使用热图或使用曲线可能试图可视化每个字节。如果是 2GB 文件，它将是 2147483648 字节。您将如何读取和处理这种 >= 2GB 的大文件

我一直在尝试类似的东西：

并设法进行一些计算，但速度非常慢我还尝试逐行读取文件，这很快，但再次读取每行的字节并进行一些转换也非常缓慢。我也读过一些关于 numpy loadtxt 的文章，但没有做太多实验，我想先在这里问。

任何可能适合这种情况并使其更有效的想法？

非常感谢

最近我们有一个普通的 Windows 商店应用程序的生产部署。几天前它工作正常，几天后性能非常缓慢。我们的应用程序遵循 Gate keeper 模式，其中商店应用程序点击 Gate keeper 和 Gate keeper 来休息服务和休息服务到数据库（一切都托管在云中）。

经过分析，我们发现 Gatekeeper Web 应用需要更多时间来响应。我们已经为 Web 应用程序进行了内存转储并使用 WinDbg 进行了分析，发现 AAD 访问令牌存在问题，其中锁定计数为 2。附件是从内存转储中获取的结果。

这是获取访问令牌的实际代码（我们使用基于证书的身份验证）

在本地运行此代码时，访问令牌没有任何问题，而且速度很快。仅在生产环境中性能非常慢，并且不确定它与访问令牌或任何其他参数有关。

您能否帮助我们分析我们的代码出了什么问题。

我是windbg的新手，在windows中进行内存分析。我尝试分析内存转储（崩溃转储）它是 x64 系统。

加载所有符号（我的和微软的）后，我输入!analyze -v

这是输出的一部分：

这WRONG_SYMBOLS让我很担心。

我可以确定FAULTING_SOURCE_CODE其中的代码是与崩溃相关的代码吗？

我有下一个工作流程：

1）构建dll和pdb文件。

2）分享dll给客户

3) 分析来自客户的内存转储。

当我跑!analyze -v进去时，WinDbg我得到了（在输出的下面部分）

看起来我们有错误的调试符号RTPLogic.dll。我下载ChkMatch工具。我从windbg

我有与此转储相关的日志，并且我看到我的更改出现在日志中。所以客户在获取 memdump 之前不要忘记安装我的 DLL。我跑ChkMatch

在这种情况下我怎么可能得到错误的调试符号？