windbg

Fastest way to break in WinDbg for specific exception? .net 4.0 app

由 自古美人都是妖i 提交于 2019-12-13 01:55:02
问题 Folks, Debugging a .net 4.0 app using WinDbg (I'm a beginner to WinDbg). I'm trying to break when I hit a stack overflow: (NTSTATUS) 0xc00000fd – A new guard page for the stack cannot be created Unfortunately, this overflow happens about 2-hours into a long-running process and logs tells me that it doesn't always happen at the same time/place. If I attach to the process in the debugger, the program runs terribly slow...it might take a few days to hit the bug! Is there a way to speed up the

ASP.NET Memory Leak - OracleCommand Object

由 こ雲淡風輕ζ 提交于 2019-12-12 22:19:31
问题 I have a memory leak and I am having a really hard time trying to figure out where the problem is. The ASP.NET process is raising to 1GB every now and then. I have followed the instructions on this page (http://humblecoder.co.uk/tag/windbg) and the !gcroot command returns the following (last x lines). I have looked at all my OracleConnections and OracleCommands and they appear to be closed and disposed correctly: 6523dfd4 282 28200 System.Data.SqlClient.SqlParameter 0e90d850 548 28496 System

What do the 'size' numbers mean in the windbg !heap output?

由 …衆ロ難τιáo~ 提交于 2019-12-12 21:23:13
问题 I see output like this in my DMP file: Heap entries for Segment00 in Heap 00150000 00150640: 00640 . 00040 [01] - busy (40) 00150680: 00040 . 01808 [01] - busy (1800) 00151e88: 01808 . 00210 [01] - busy (208) 00152098: 00210 . 00228 [00] 001522c0: 00228 . 00030 [01] - busy (22) 001522f0: 00030 . 00018 [01] - busy (10) 00152308: 00018 . 00048 [01] - busy (3c) The WinDbg docs say this: Heap entries for Segment00 in Heap 250000 0x01 - HEAP_ENTRY_BUSY 0x02 - HEAP_ENTRY_EXTRA_PRESENT 0x04 - HEAP

【逆向】WinDbg常用命令与技巧

由 老子叫甜甜 提交于 2019-12-12 18:37:34
前言 本文用于记录WinDbg的一些常用命令和使用技巧，WinDbg是一个强大的windows调试器，除了文中记录的内容外，其它内容会在用到时进行更新。另外你可以“F1”或使用“.hh”命令打开debugger.chm以获取完整的调试器文档。 主题界面 https://www.cnblogs.com/SunsetR/p/12026080.html 命令概述 WinDbg中的调试命令，分为三种：基本命令，元命令和扩展命令。 基本命令 ：是调试器自带的基本调试命令，命令 不分大小写 。 元命令 ：是调试器自带的，元命令总是以 “.” 开头。 扩展命令 ：是外部加入的，总是以感叹号 “!” 开头。 扩展命令从动态连接库中导出，一般以DLL文件名来代表一类扩展命令集。 使用如下命令可以列出对应的命令集合： 1 // 获取基础命令列表 2 0:000> ? 3 4 Open debugger.chm for complete debugger documentation 5 6 B[C|D|E][<bps>] - clear/disable/enable breakpoint(s) 7 BL - list breakpoints 8 BA <access> <size> <addr> - set processor breakpoint 9 BP <address> - set soft

How do symbols affect call stack walking?

由 本小妞迷上赌 提交于 2019-12-12 11:27:22
问题 I'm trying to analyze a crash dump with windbg, and I'm getting inconstant crash dumps depending on what symbols are loaded. My simple understanding is that the symbols only help point to what the stack is referring to, but the stack itself is unchanged. That's obviously wrong, but now I don't know what the heck I'm looking at. Heres a call stack with all symbols loaded: 0:000> kn # ChildEBP RetAddr 00 0012e120 7d61f60f ntdll!ZwGetContextThread+0x12 01 0012e130 000f0005 ntdll!RtlFreeHeap

Why 'this' pointer changes its value while stepping through the code?

由 ＊爱你＆永不变心＊ 提交于 2019-12-12 11:01:29
问题 I am debugging a crash and I noticed as a step through the debugger, this pointer changes its value and after 3 steps it finally get the value 0x00000001 and application crashes. Now the 0x00000001 value is obviously wrong but should I really expect this value to change as I step through the debugger? Below is the constructor I am debugging where it crashes. I have included the value of this pointer in comments with each step and as you can see it jumps around quite a bit. CADOCommand:

Where can I find the pde extension written by Andrew Richards for WinDBG?

由 眉间皱痕 提交于 2019-12-12 10:16:00
问题 I saw it mentioned on a few resources on the web, but I cannot find it. It does not seem to be included with WinDBG distribution. 回答1: There is a public OneDrive that contains a ZIP file of it: https://onedrive.live.com/?authkey=%21AJeSzeiu8SQ7T4w&id=DAE128BD454CF957%217152&cid=DAE128BD454CF957 来源： https://stackoverflow.com/questions/46353441/where-can-i-find-the-pde-extension-written-by-andrew-richards-for-windbg

How to solve this error that is shown on Windbg?

由 大兔子大兔子 提交于 2019-12-12 09:43:48
问题 I've loaded a .exe and it gave this error: Microsoft (R) Windows Debugger Version 6.12.0002.633 X86 Copyright (c) Microsoft Corporation. All rights reserved. CommandLine: "C:\Users\Public\SoundLog\Code\Código Python\SoundLog\dist\SoundLog.exe" Symbol search path is: *** Invalid *** **************************************************************************** * Symbol loading may be unreliable without a symbol search path. * * Use .symfix to have the debugger choose a symbol path. * * After

what does <unclassified> mean in windbg !address output

由 微笑、不失礼 提交于 2019-12-12 09:42:25
问题 Example: 0:074> !address -summary --- Usage Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal Free 90919 7ec`34659000 ( 7.923 Tb) 99.03% <unclassified> 95426 12`3c3e9000 ( 72.941 Gb) 92.12% 0.89% Heap 744 1`7ee50000 ( 5.983 Gb) 7.56% 0.07% Image 4303 0`0f890000 ( 248.563 Mb) 0.31% 0.00% Stack 225 0`00de9000 ( 13.910 Mb) 0.02% 0.00% TEB 75 0`00096000 ( 600.000 kb) 0.00% 0.00% ActivationContextData 28 0`00025000 ( 148.000 kb) 0.00% 0.00% NlsTables 1 0`00023000 (

Do I need a WOW64 dump for GDI Handle analysis?

由 邮差的信 提交于 2019-12-12 08:38:42
问题 I'm debugging a potential GDI Handle Leak. Thanks to @Alois Kraus, there is a WinDbg script which performs a handle count. From my debugging sessions, especially for .NET, I find that usually, it's better to have 32-bit dumps of 32-bit processes and 64-bit dumps of 64-bit processes. Unfortunately, with 2 crash dumps I received, the script does not work. Looking deeper into it, I found out that the GdiSharedHandleTable is null in those dumps: 0:000> dt ntdll!_PEB GdiSharedHandleTable @$peb
订阅 windbg