问题标签 [sos]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
c# - WinDbg/SOS: !SyncBlk 输出说明
我正在查找由 SOS 的 !SyncBlk 命令生成的输出的描述。
特别是我在“MonitorHeld”列上没有找到有用的解释。此列显示一系列故障转储中的高值。
例子:
谁能解释“MonitorHeld”栏中的“99”?
有没有人链接到该命令的完整参考文档?
谢谢,亚历克斯
.net - sos.dll 返回的对象大小与内存中进程大小不匹配
我已使用以下 sos 命令枚举正在运行的 asp 应用程序(托管在 windows xp 4 GB 机器上)中特定类型的所有实例。
这会枚举 gc gen2 中给定类型的所有对象。
平均对象大小似乎约为 500 KB,大约有 2000 个对象。仅此一项就增加了大约 1 GB 的内存,而我在任务管理器中的 asp 进程内存仅显示大约 700 MB。还有一点是我没有考虑我正在使用的其他加载对象。
此外,以上所有对象都是不会被垃圾收集的根对象。不确定此命令是否错误,或者对于 sos 返回的大小不匹配以及任务管理器中显示的内容是否有任何其他解释?
在此先感谢
Bharath K.
c# - 如何以匿名方法破坏 WinDbg?
标题有点说明了一切。通常的 SOS 命令!bpmd没有名字就没有多大用处。
我的一些想法:
- 转储每个方法,然后在找到相应的 MethodDesc 时
使用!bpmd -md
- 据我所知,在现实世界的使用中不实用。即使我编写了一个宏来将转储限制为匿名类型/方法,也没有明显的方法可以将它们区分开来。
- 使用 Reflector 转储 MSIL 名称
- 在处理动态程序集和/或 Reflection.Emit 时没有帮助。Visual Studio 无法在此类场景中读取本地变量是我首先转向 Windbg 的全部原因......
- 在VS中设置断点,等待它命中,然后使用无创技巧更改为Windbg
- 尝试从 VS 分离会导致它挂起(与应用程序一起)。我认为这是因为托管调试器是通过线程注入实现的“软”调试器,而不是标准的“硬”调试器。或者它可能只是 Silverlight 特有的一个 VS 错误(我几乎不会遇到第一个)。
- 在已知调用匿名方法的其他位置设置断点,然后单步执行
- 我的备用计划,但如果此问答揭示了更好的方法,我宁愿不采用它
.net - 如何在堆栈上查看我的托管对象?
我在 VisualStudio 中使用 SOS.dll 来调试我的 C# 程序。程序如下。
调试命令是!DumpStackObjects。
在 Visual Studio 的即时窗口中输入“!dso”命令后,结果如下:
操作系统线程 ID:0xf6c (3948)
ESP/REG 对象名称
为什么什么都没有?我认为应该有 args i 和局部变量 j。
感谢您回答我的幼稚问题...
garbage-collection - 垃圾收集器如何决定何时杀死 WeakReferences 持有的对象?
我有一个对象,我相信它仅由 WeakReference 持有。我已经使用 SOS 和 SOSEX 追踪了它的参考持有人,并且两者都确认是这种情况(我不是 SOS 专家,所以我在这一点上可能是错误的)。
WeakReferences 的标准解释是 GC 在扫描时会忽略它们。尽管如此,我的对象在调用 GC.Collect(GC.MaxGeneration, GCCollectionMode.Forced) 后仍然存在。
仅使用 WeakReference 引用的对象是否有可能在该集合中存在?有没有更彻底的收藏可以强制?或者,我是否应该重新审视我的信念,即对对象的唯一引用是弱的?
更新和结论
根本原因是堆栈上有一个锁定对象的引用。目前尚不清楚为什么 SOS 和 SOSEX 都没有显示该参考。用户错误总是有可能的。
在诊断根本原因的过程中,我确实做了几个实验,证明对第二代对象的弱引用可以持续很长时间。但是,WRd 2nd gen 对象将无法在 GC.Collect(GC.MaxGeneration, GCCollectionMode.Forced) 中存活。
visual-studio - 自动化 VisualStudio 即时窗口
我正在尝试自动化打开托管应用程序的崩溃转储和检索堆栈跟踪的过程。Windgb 有时可以工作,但让它加载正确版本的 sos.dll 是一场噩梦,除非处理转储的机器实际上与发生转储的机器相同。
另一方面,Visual Studio 可以简单地完成这项工作。我打开转储,转到即时窗口,然后键入
一切都很好。
我可以在 Visual Studio 中编写此过程的脚本吗?如果没有,Visual Studio 使用的后端调试器是否与 Windbg 相同?
visual-studio - 是否可以实现 GC.GetAliveInstancesOf()(用于调试)?
我知道这个问题之前已经回答过了,但我想提出一个不同的问题。
是否有任何可以想象的方式来实现 GC.GetAliveInstancesOf(),可以在 Visual Studio Debug Watch 窗口中进行评估?Sasha Goldstein 在本文中展示了一种解决方案,但它要求您要查询的每个类都继承自特定的基类。
我要强调一下,我只想在调试期间使用此方法,所以我不在乎 GC 可能会在运行时更改对象在内存中的地址。
一个想法可能是以某种方式利用 SOS 的!dumpheap –type 命令,并做一些魔术来创建一个临时变量并让它指向 SOS 打印的内存地址。
有没有人有一个有效的解决方案?
silverlight - Silverlight SOS(罢工之子)文档
Silverlight 的 SOS 是否有任何 Microsoft 甚至非官方文档。除了一些网络帖子之外,我在 MSDN 上看到了零文档。甚至 CLR 版本的 SOS 的官方文档似乎也很难找到,这篇古老的文章提到了一个 sos.htm 文件,它包含在 windows SDK 中,但它似乎不再存在。使用 SOS 调试 Silverlight 的任何指针?我找到了以下博客文章,但正在寻找更多信息:
http://davybrion.com/blog/2009/08/finding-memory-leaks-in-silverlight-with-windbg/
http://www.ningzhang.org/2008/12/19/silverlight-debugging-with- windbg-and-sos/
http://debuggingblog.com/wp/2009/07/07/windbg-extension-sos-in-clr-40net-framework-40-ctp-net-runtime-dll-renamed-and- sos-commands-just-got-richer/
http://www.netfxharmonics.com/label/debugging
http://blogs.msdn.com/b/tess/archive/2008/08/21/debugging-silverlight-applications -with-windbg-and-sos-dll.aspx
http://blogs.msdn.com/b/delay/archive/2009/03/11/where-s-your-leak-at-using-windbg-sos-和-gcroot-to-diagnose-a-net-memory-leak.aspx
http://blogs.msdn.com/b/delay/archive/2009/03/09/controls-are-like-diapers-you-don-t-want-a-leaky-one-implementing-the-weakevent-带有弱事件侦听器类的银光模式.aspx
clr - 如何将 CLR 方法表条目与 MethodDesc 匹配?
使用 sos,我可以获得特定类的方法表条目列表:
但我无法弄清楚 sos 如何将表条目与MethodDesc
- 在内存中的方法表周围戳一下只会给出指向 JIT 存根的条目值。我不知道你怎么MethodDesc
能从那里得到 s 。有人有想法么?
.net-4.0 - “请求 ThreadStore 失败” - WinDbg 调试实时进程
我正在调试 PresentationHost.exe 的实时进程(不是转储)。它曾经工作正常,但几天前突然我收到上述错误消息。!Threads, !pe,几乎所有的 SOS 命令都不起作用。
我只记得我在收到该错误之前安装了 Visual Studio 2010 和 .NET Framework 4.0。有关系吗?
更新:
我自己无法重现我遇到的问题。可能我正在使用 64 位调试器调试 32 位进程,或者使用 .NET 2.0 SOS 调试 .NET 4 进程,反之亦然,或者同时使用位数和 DLL 版本。
抱歉,这个问题可能无效。