windbg

While my .Net 3.5 app was running, the Windows Task Manager shown that my app had 16 threads. I collected a memory dump for the process and opened it using WinDbg/SOS. Running the !threads command reveals that I have : ThreadCount: 456 UnstartedThread: 0 BackgroundThread: 6 PendingThread: 0 DeadThread: 449 Hosted Runtime: no Here are the first few lines of the !threads output: ID OSID ThreadOBJ State GC Context Domain Count APT Exception 0 1 2848 004366a8 6020 Enabled 11738178:11738778 0042a9f0 0 STA 2 2 1820 004430e0 b220 Enabled 00000000:00000000 0042a9f0 0 MTA (Finalizer) 7 5 2c38 055d6330

Is there any difference between . and ! ? There are different kinds of commands in WinDbg. Regular commands, e.g. kb apply to the debugging session. E.g. show stack dump etc. Meta commands are prefixed with a dot, e.g. .load . Meta commands apply to the debugger itself. E.g. load extensions, show help and so forth. Extension commands are prefixed with an exclamation mark, e.g. !analyze and !dumpheap are defined in debugger extensions (DLLs that provide additional functionality). Meta command prefixed with dot(.) are designed to configure or query debugger Extension commands are prefixed with

假设我们希望在加载特定的dll时中断调试器，例如，我想启用一些SOS命令，而clr还没有加载，当您遇到程序中过早发生的异常，并且您不能依赖手动尝试在正确的时间中断时，这尤其有用。 例如，在将调试器附加到一个进程之后，我会得到一个错误，因为clr尚未加载 0:000> .loadby sos clr Unable to find module 'clr' 使用 sxe ld 命令，我可以告诉调试器在加载clr时中断. 0:000> sxe ld clr 0:000> g 我马上就明白了： ModLoad : 6f580000 6fc03000 C:\Windows\Microsoft.NET\Framework\v4.0.30319\ clr.dll eax=00000000 ebx=00000000 ecx=00000000 edx=00000000 esi=7efdd000 edi=003cf400 eip=77d7fc42 esp=003cf2d4 ebp=003cf328 iopl=0 nv up ei pl zr na pe nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000246 ntdll!NtMapViewOfSection+0x12: 77d7fc42 83c404 add esp,4

sos.dll/mscordacwks.dll 公共语言运行库（CLR）是执行托管代码的Microsoft.NET框架的核心引擎。简单地说，它通过在托管程序集中使用中间语言和元数据，JIT按需编译代码，构建程序集定义和使用的类型的内存表示，并确保生成的代码是安全的、安全的和可验证的，并在需要时执行。这个引擎本身是用本机代码实现的。当我们想使用本机调试器（如CDB或WinDBG）调试.NET应用程序时（如果我们想使用事后内存转储文件调试它，我们目前做了很多工作），我们必须在本机调试器和托管世界之间使用“桥”，因为本机调试器本身并不理解托管代码。它是本机调试器。 为了提供这个桥，CLR附带了一个调试扩展名SOS.DLL。这理解CLR的内部结构，因此允许我们执行诸如输出托管调用堆栈、转储托管堆等操作。 但是，这些内部数据结构和CLR的详细信息会不时发生变化，因此，从使.NET应用程序工作的CLR的实际内部实现中抽象出此调试器扩展所需的CLR接口是非常有用的。输入mscordacwks.dll。这提供了数据访问组件（DAC），该组件允许SOS.DLL调试器扩展解释维护.NET应用程序状态的内存中数据结构。 如果您在框架文件夹中查看，则应始终看到这些dll的匹配集： 32位的 C:\Windows\Microsoft.NET\Framework\v4.0.30319 64位的 C:

I'm familiar with the WinDBG paradigm. Been reviewing a lot of dump files using WinDBG x64 version. For the most part dump files were .NET 2.0 applications and psscor2.dll. Current WinDBG version I am using is 6.12.0002.633. Recently, I've been trying to open x64 dump IIS dump files generated from a .NET 4.0 application pool using psscor4.dll. Any command I run returns, "Failed to request information" I've mscordacwks.dll from c:\Windows\Microsoft.NET\Framework64\v4.0.30319 on the server Renamed to mscordackwks_AMD64_AMD64_4.0.30319.xxxx.dll. xxxx matches the compiled version in the file Open

This is really driving me crazy. I am using WinDbg as my primary debugger. It is used to debug local service (WinDbg running locally, debugging service on the same machine). The PDB files are stored on local hard drive. Source code is accessed via SMB share. Debugging works in bursts, sometimes it flow well, most of the time I keep seeing the unbelievably annoying "*BUSY*" message, this happens almost every time when I perform a "step-over". Any ideas what I could do to speed things up? Thanks capone This may happens if you have many unqualified breakpoints that track module load events

So I know that a memory address (eg: 12208e6c) is within a specific heap.Using windbg, is there a way to determine what the starting address for this heap is and which function was responsible for allocating it? !address <address> gives you information about the heap an address is contained in: 0:005> !address 03051234 Usage: Heap Base Address: 03050000 End Address: 0307c000 Region Size: 0002c000 State: 00001000 MEM_COMMIT Protect: 00000004 PAGE_READWRITE Type: 00020000 MEM_PRIVATE Allocation Base: 03050000 Allocation Protect: 00000004 PAGE_READWRITE More info: heap owning the address: !heap