windbg

Can I trust local variable value when analyzing a dump with Windbg?

北慕城南 提交于 2019-12-11 07:25:39
问题 I see strange things like a pointer values changing the values (0 or something valid) between 2 calls with no change. Same with a enum values. The values are simply forwarded, no chances to be modified. The dump is minidunp. 回答1: You can use dv /V to reveal if a local variable is living in a register. Like here: 0:000> dv /v @ecx this = 0x0018fe10 To get rid of this, you must remove optimization when compiling. 回答2: Optimized build I assume? The problem is that the CPU doesn't deal in

Display callstack without method names

爷,独闯天下 提交于 2019-12-11 06:56:11
问题 In WinDbg, I can get the callstack using the k command. For DLLs without symbols, it displays an incorrect method name and a large offset, e.g. 0018f9f0 77641148 syncSourceDll_x86!CreateTimerSyncBridge+0xc76a Since I don't have symbols, I have to give this information to the developer of the DLL. I don't know who will work on the bug and how much debugging knowledge he has. I want to avoid that the developer thinks the problem is in the CreateTimerSyncBridge() method. Is there a way to get

Lost in WinDbg with 64-bit dump on 32-bit machine

☆樱花仙子☆ 提交于 2019-12-11 06:29:07
问题 I'm a newbie with WinDbg and got this dump from the WER ReportQueue folder on a 64-bit Windows 2008 Server. I need to examine the dump and want to do so on my developer machine on which I've installed the Debugging Tools for Windows package. When I try to load SOS I got the following error which I've never seen before: 0:035> .loadby sos mscorwks The call to LoadLibrary(C:\Windows\Microsoft.NET\Framework64\v2.0.50727\sos) failed, Win32 error 126 "The specified module could not be found."

Windows singly linked list (_SINGLE_LIST_ENTRY)

末鹿安然 提交于 2019-12-11 06:12:43
问题 I'm just doing some debugging on a Windows 7 crash dump, and I've come across a singly-linked list that I'm not able to fully understand. Here's the output from WinDBG: dt _GENERAL_LOOKASIDE_POOL fffff80002a14800 -b .... 0x000 SingleListHead: _SINGLE_LIST_ENTRY +0x000 Next: 0x0000000000220001 .... From what I've been reading, it seems that each singly linked list begins with a list head, which contains a pointer to the first element in the list, or null if the list is empty. Microsoft state:

Can I disable the “Unable to read dynamic function table entry” message in WinDbg?

佐手、 提交于 2019-12-11 05:49:30
问题 I'm working with a program that generates a lot of code at runtime, and seems not to produce any unwind data for it. (I don't have source code for this program; I'm writing a plugin for it.) When the program hangs, I break into it with WinDbg, and try to get a stack trace for all threads with ~* k . As well as the stack traces, I also get pages and pages (and pages, and more) of messages along the line of Unable to read dynamic function table entry at 00000000`2450b580 This takes a long time

Is there a Windbg command for retrieving the module_name of a dump?

|▌冷眼眸甩不掉的悲伤 提交于 2019-12-11 05:18:34
问题 I'm working with windbg , using a script that I found somewhere on the internet, for investigating dump files. That script launches two commands: one to determine all symbols, present in the dump (at least that's what I think), and one for showing the memory addresses and types of all variables. The first command: x /2 *!* The result contains entries like: 0042da68 <application>!CMap<int,int,CStringArray *,CStringArray *> ... 74c06448 mfc110u!CStringArray The second command is more

Is it possible to fix a full memory dump so that running .imgscan /l will no longer be required?

天大地大妈咪最大 提交于 2019-12-11 04:11:02
问题 For some reason I have started receiving dumps from production that require running .imgscan /l first. Now I tend to run small queries against the dump using CDB invoked from a powershell script. However, running .imgscan /l every time takes considerable amount of time. Is it possible to fix the dump in a way that renders .imgscan /l unnecessary? P.S. I think there is another problem with the need to run .imgscan /l - DebugDiag does not seem to understand such dumps. 来源: https://stackoverflow

Why locals and parameters show no data on the stackframe when using sos.dll to debug .net app?

北慕城南 提交于 2019-12-11 03:25:55
问题 My .net 4 asp.net application is processing a request, but the request is timeout, so I get a dump and try to debug the live app online( revised: just analyse the dump file, not attatch to the live process of the app.). I find a thread that consumes the request costs 1 min 5 sec. I go through the stack of that thread. I want to try to find out the parameters and local variables, but the command output shows no data, only some of the local variables have value. May I know why this happened?

call stack and disassembly doubt

本秂侑毒 提交于 2019-12-11 02:56:06
问题 Three doubts 1) Suppose I get the call stack as below user32.dll!_InternalCallWinProc@20() + 0x28 bytes user32.dll!_UserCallWinProcCheckWow@32() + 0xb7 bytes user32.dll!_CallWindowProcAorW@24() + 0x51 bytes user32.dll!_CallWindowProcW@20() + 0x1b bytes Now what are the bytes mentioned at the end of each function? Like for first statement what is 0x28 bytes. 2) How to put breakpoint on a windows system dll in VS ? In windbg I can search for a particular function of windows system dll as >x

Setting up visual studio c++ debugger to support symbols for modules loaded from memory

不想你离开。 提交于 2019-12-11 02:38:29
问题 Im using the following code to load a DLL from the memory onto another running executable. debugging the following module with the common methods wont work as the debugger is unable to locate the appropriate PDB files, not to mention make it aware that the DLL was actually loaded to the process. i managed to set it somehow working with windbg by: specifying the debugger where the module is located in the memory and its length using .reload [DLLLocationInMemory]=0x10000000,[DllSizeInMemory