windbg

Is 0x0000ffff the default load count of a dll in windows?

由 时光毁灭记忆、已成空白 提交于 2019-12-10 10:09:22
问题 Using windbg, got the list of dlls with load count by !dlls command. Observed that the load count is 0x0000ffff for many loaded dlls. Is that a default value ? Is that mean anything else ? 0x00262fa8: C:\WINDOWS\system32\ole32.dll Base 0x774e0000 EntryPoint 0x774fd0b9 Size 0x0013d000 Flags 0x80084006` LoadCount 0x0000ffff TlsIndex 0x00000000 LDRP_STATIC_LINK LDRP_IMAGE_DLL LDR**strong text**P_ENTRY_PROCESSED LDRP_PROCESS_ATTACH_CALLED 回答1: From The Covert Way to find the Reference Count of

WinDbg常用命令系列---!runaway

由 狂风中的少年 提交于 2019-12-10 10:09:11
简介 !runaway扩展显示有关每个线程使用的时间的信息。 使用形式 !runaway [Flags] 参数 Flags 指定要显示的信息类型。 标志 可以是以下位的任意组合。 默认值为 0x1。 位 0 (0x1) 使调试器以显示每个线程使用的用户时间量。 位 1 (0x2) 使调试器以显示每个线程使用的内核时间量。 位 2 (0x4) 使调试器以显示每个线程创建以来已经过去的时间量。 支持环境 Windows 2000 Uext.dll Ntsdexts.dll Windows XP 及更高版本 Uext.dll Ntsdexts.dll 说明 这个扩展是一种快速的方法，可以找出哪些线程正在失控地旋转或占用太多的CPU时间。 显示标识每个线程由调试器的内部线程编号和线程 ID 以十六进制格式。 调试器 Id 也会显示。 下面是一个例子： 0:001> !runaway 7 User Mode Time Thread Time 0:55c 0:00:00.0093 1:1a4 0:00:00.0000 Kernel Mode Time Thread Time 0:55c 0:00:00.0140 1:1a4 0:00:00.0000 Elapsed Time Thread Time 0:55c 0:00:43.0533 1:1a4 0:00:25.0876 来源： https:

How to debug a Windows Store app that crashes on a customer's machine?

由 雨燕双飞 提交于 2019-12-10 10:06:08
问题 I got a support email from a customer saying his app crashes when it starts and all he gets is a message like: (App Name) ran into a problem You can send info to Microsoft about what went wrong to help improve this app. Files that will be sent to Microsoft C:\Users\User_Name\AppData\Local\Temp\WER####.tmp.appcompat.txt C:\Users\User_Name\AppData\Local\Temp\WER####.tmp.hdmp I thought - Microsoft isn't going to help them really with my silly app. They should send the dump file to me for

How can the stack be broken at the very start of application

由 孤人 提交于 2019-12-10 09:42:37
问题 The stack frame pointer (EBP) should always point to where the previous stack frame was right but why is that not the case in my application! That would indicate something is really wrong..hard to believe! I created multiple simple demo applications where the stack pointer always points to the previous stack frame but I can't make sense of why this is not the case in this application and it is happening when my application is just starting up! The following is my call stack 0:000> k #

Windbg分析DMP文件

由 北城以北 提交于 2019-12-10 04:12:21
1、提取Dump格式文件 　　有两种方式： 　　第一种，程序崩溃时，启动任务管理器，选择崩溃的*.exe进程，右键选择创建转储文件，通过 　开始—运行—输入 %temp% --确定--在打开Temp窗口中即可找到*.dmp文件。 　　第二种，通过windbg生成dump 文件。 　　步骤： 　　 1） 打开Windbg并将之Attach 到crash的程序进程 　　2） 输入产生dump 文件的命令 　　Windbg产生dump 文件的命令是 .dump ，可以选择不同的参数来生成不同类型的dump文件。 　　选项(1)： /m 　　　　命令行示例：.dump /m C:\dumps\*.dmp 　　　　注解： 缺省选项，生成标准的minidump， 转储文件通常较小，便于在网络上通过邮件或其他方式传输。 这种文件的信息量较少， 　　　　　　　只包含系统信息、加载的模块（DLL）信息、 进程信息和线程信息。 　　　　选项(2)： /ma 　　　　命令行示例：.dump /ma C:\dumps\*.dmp 　　　　注解： 带有尽量多选项的minidump（包括完整的内存内容、句柄、未加载的模块，等等），文件很大(第一种方法产生的DMP文件 　　　　　　　大小与此相同)，但如果条件允许（本机调试，局域网环境）， 推荐使用这中dump。 　　　　选项(3)：/mFhutwd 　　　

Is my heap fragmented

由 三世轮回 提交于 2019-12-10 02:35:03
问题 0:000> !dumpheap -stat total 1755874 objects Statistics: MT Count TotalSize Class Name 7b9b0c64 1 12 System.Windows.Forms.Layout.TableLayout+ColumnSpanComparer .... 7933303c 14006 4926456 System.Collections.Hashtable+bucket[] 65246e00 804 4982192 System.Data.RBTree`1+Node[[System.Int32, mscorlib]][] 054c55f0 44240 5662720 DevExpress.Utils.AppearanceObject 793040bc 98823 7613156 System.Object[] 793308ec 293700 55820016 System.String 002435f0 50315 138631888 Free Total 1755874 objects

WinDbg常用命令系列---!uniqstack

由 こ雲淡風輕ζ 提交于 2019-12-09 19:48:54
简介 这个!uniqstack扩展 扩展显示的所有线程的堆栈的所有当前进程，不包括显示为具有重复项的堆栈中。 使用形式 ! uniqstack [ -b | -v | -p ] [ -n ] 参数 -b 将导致显示以包括前三个参数传递给每个函数。 -v 将导致显示以包括帧指针省略 (FPO) 信息。 在基于 x86 的处理器中，还会显示的调用约定信息。 -p 将导致显示堆栈跟踪中包含每个函数的完整参数。 此列表将包括每个参数的数据类型、 名称和值。 这要求的完整符号信息。 -n 导致要显示的帧号码。 环境支持 Windows 2000 Uext.dll Windows XP 及更高版本 Uext.dll 说明 此扩展是类似于 k、 kb、 kc、 kd、 kp、 kP，kv （显示堆栈回溯） 命令，只不过它不会显示重复的堆栈。 这个！uniqstack命令枚举了所有的线程调用堆栈并消除了重复，这样您就可以一眼就知道这几百个线程在做什么。 0:021> !uniqstack Processing 22 threads, please wait . 0 Id: 464.ca8 Suspend: 1 Teb: 7f9dd000 Unfrozen Start: SillyThreadPool!ILT+120(_wmainCRTStartup) (00ed107d) Priority: 0

WinDbg and .Net x64 Assembly : Step-By-Step Walkthrough for hitting a breakpoint in a C# source

由 梦想与她 提交于 2019-12-09 19:43:57
问题 I am having very hard times using WinDbg to track a simple object reference in a C# Forms App. I have found a very nice tuto by Chris Lovett : GCRoot Demo on using "SOS" in VS' Immediate Window Unfortunately, I am debugging an x64 App and recompiling my App into 32-bit will bias the test conditions I am willing to recreate. Trying to load SOS in an x64 Assembly results, as expected, in the following error : Error during command: extension C:\Windows\Microsoft.NET\Framework64\v4.0.30319\sos

WinDbg常用命令系列---!findstack

由 浪尽此生 提交于 2019-12-09 19:41:24
简介 !findstack扩展查找所有包含指定的符号或模块的堆栈。此命令搜索线程调用堆栈中的特定符号，并显示匹配的线程。 使用形式 !findstack Symbol [ DisplayLevel ] !findstack -? 参数 Symbol 指定符号或模块。 DisplayLevel 指定显示内容。这可以是以下任何一个值。默认值为1 0 显示仅包含每个线程的线程 ID 符号 。 1 显示线程 ID 和包含每个线程的帧 符号 。 2 将显示包含每个线程的整个线程堆栈 符号 。 -? 在调试器命令窗口中显示此扩展的一些简要帮助文本。 说明 内核模式此扩展还显示有关堆栈，包括每个线程的状态的简短摘要信息。 此扩展的输出的一些示例如下： 0:023> !uext.findstack wininet Thread 009, 2 frame(s) match * 06 03eaffac 771d9263 wininet!ICAsyncThread::SelectThread+0x22a * 07 03eaffb4 7c80b50b wininet!ICAsyncThread::SelectThreadWrapper+0xd Thread 011, 2 frame(s) match * 04 03f6ffb0 771cda1d wininet!AUTO_PROXY_DLLS:

How to display managed objects with certain value in one of the fields in WinDbg using SOS (or SOSEX)?

由 佐手、 提交于 2019-12-09 18:29:31
问题 My problem is this: 0:000> !DumpHeap -type Microsoft.Internal.ReadLock -stat ------------------------------ Heap 0 total 0 objects ------------------------------ Heap 1 total 0 objects ------------------------------ Heap 2 total 0 objects ------------------------------ Heap 3 total 0 objects ------------------------------ total 0 objects Statistics: MT Count TotalSize Class Name 000007fef3d14088 74247 2375904 Microsoft.Internal.ReadLock Total 74247 objects The way I read this output is that I
订阅 windbg