Looks ProcDump dumps a post mortem dump of the wrong thread. Made ProcDump the JIT-debugger:
C:\>procdump -ma -i c:\mydumps
Made a test program C++ MFC:
int* ptr = 0;
switch(message) {
...
case IDM_CRASH:
*ptr = 23;
break;
...
Selecting the Crash item from the menu (of the program ProcDumpTest.exe), the application crashes and a dump is made. The dump however shows (windbg) a stack and an instruction pointer (eip = 7c90e514) of an unexpected thread. How to get the stack trace of thread where the error occurred?
00400000 - 004a0000 ProdDumpTest.exe
07c90000 - 07c9b000 ntdll.dll
Got the same problem in a more serious case. Thanks for any help! GMore
After the .reload /f command, the !analyze -v showed the correct information. Thanks for the help.
Related
I have been trying to get a w3wp crash dump to see the crash callstack. I got two dumps but both of them have a single thread in them - seems almost like AppDomain has been recycled already and there is nothing useful left in the process when the dump was saved.
Command used: "procdump -mm -e -n 1 -l pt <PID>"
Also tried -ma for full dump but result is the same:
0:000> ~
. 0 Id: fa4.1dc8 Suspend: -1 Teb: 000000b1`77a78000 Unfrozen
I am not sure if I am missing something in the command, or IIS does not provide usable managed dumps when capturing them with procdump - any inputs are highly appreciated!
Additional detail: I was seeing STACK_OVERFLOW exception being logged by the procdump, which - apparently needs different method to capture useful dump. See my own answer below for details.
It only took few hours - hopefully this will save some time for others like me.
Found a way to do this:
procdump -mm -e 1 -l -f C00000FD.STACK_OVERFLOW -g <PID>
It works! Thanks to the unknown fellow member whose hint lead me to this. I was reading too many pages and missed saving the page link to post acknowledgement here.
I couldn't find a precise answer so I've decided to ask.
I've been reading the "Inside Windows Debugging" and in the sample it tells me to set a breakpoint on the kernel32!CreateProcessW.
But before that it uses the .symfix debugger command to set the debugger symbols search path to point to the Microsoft online symbols server. When I try to set the breakpoint I get an error that it cannot resolve the function (or something like that). It looks like this.
0:000> bp kernel32!CreateProcessW
Couldn't resolve error at 'kernel32!CreateProcessW'
It's probably because there's no "kernel32!CreateProcessW" in the list below.
0:000> x kernel32!CreateProcess*
76b90cb9 KERNEL32!CreateProcessWithTokenW (void)
76b90d84 KERNEL32!CreateProcessAsUserW (void)
76b90d84 KERNEL32!CreateProcessWithLogonW (void)
76b4e225 KERNEL32!CreateProcessWStub = <no type information>
76b72e04 KERNEL32!CreateProcessInternalAStub = <no type information>
76b72e15 KERNEL32!CreateProcessInternalWStub = <no type information>
76b72de2 KERNEL32!CreateProcessAStub = <no type information>
76b72df3 KERNEL32!CreateProcessAsUserWStub = <no type information>
Everything goes fine if I set the breakpoint to kernel32!CreateProcessWStub but I wondered why I couldn't find and set the breakpoint to the kernel32!CreateProcessW.
This book probably focuses on a reader who's using Windows 7. I'm using Windows 8.1 and thought maybe that kernel32!CreateProcessW got deprecated...
I'm extremely new to this field and apologize if this is a completely stupid question. But thanks for reading it anyway.
CreateProcessW is definitely NOT deprecated. Furthermore, the only documented entry point is still in kernel32.dll, so for all intents and purposes, you should continue calling CreateProcessW through kernel32.dll, and not through kernelbase.dll.
Here is some more details to help understand what you are observing. Windows team often moves code around, and for the last few releases they had strong habit of breaking larger DLL's into smaller ones, which includes kernel32, ole32, user32, gdi32 to name a few. It is not new, Raymond Chen wrote about this in 2006. However the mechanism Raymond describes is based on forwarders, while what you see here with kernel32!CreateProcessW is a stub, i.e. the function that calls kernelbase!CreateProcessW and then returns:
0:014> u kernel32!CreateProcessWStub l14
KERNEL32!CreateProcessWStub:
00007ffd`83cf58a8 4c8bdc mov r11,rsp
00007ffd`83cf58ab 4883ec58 sub rsp,58h
00007ffd`83cf58af 488b8424a8000000 mov rax,qword ptr [rsp+0A8h]
00007ffd`83cf58b7 498943f0 mov qword ptr [r11-10h],rax
... skip ...
00007ffd`83cf58f5 ff1555871100 call qword ptr [KERNEL32!_imp_CreateProcessW (00007ffd`83e0e050)]
00007ffd`83cf58fb 4883c458 add rsp,58h
00007ffd`83cf58ff c3 ret
The function called as you can see is kernelbase!CreateProcessW
0:014> ln poi kernel32!_imp_CreateProcessW
(00007ffd`82f92604) KERNELBASE!CreateProcessW | (00007ffd`82f926d0) KERNELBASE!MakeLocHashNode
Exact matches:
KERNELBASE!CreateProcessW (no parameter info)
I this case I don't know why Windows folks decided to use a stub rather than a forwarder, to me it seems it would be more efficient to simply forward a call, like most of the other refactoring, was done.
Kernel32.dll in Windows 8.1 still contains export symbol CreateProcessW. Command link /dump /exports prints out all export symbols:
c:\>link /dump /exports c:\Windows\System32\kernel32.dll | findstr CreateProcessW
220 DB 000058A8 CreateProcessW = CreateProcessWStub
You can use the same command to determine where you should set a breakpoint to. Similarly for forwarded exports:
c:\>link /dump /exports c:\Windows\System32\kernel32.dll | findstr EnterCriticalSection
298 129 EnterCriticalSection (forwarded to NTDLL.RtlEnterCriticalSection)
1418 589 TryEnterCriticalSection (forwarded to NTDLL.RtlTryEnterCriticalSection)
The reason why WinDbg cannot resolve symbol kernel32!CreateProcess, is probably just a bug in WinDbg. In this case, the symbols is not part of .PDB file, but contained in a special section in PE image, and apparently WinDbg does not handle that. What is interesting is that if .PDB file is not available, WinDbg is happy to use export table of PE image:
0:014> .sympath .
0:014> .reload
Reloading current modules ....
0:014> x kernel32!CreateProcessW
00007ffd`83cf58a8 <b>KERNEL32!CreateProcessW</b> (no parameter info)
Apparently, WinDbg decides to use either PDB symbols or export symbols, but not both.
It is very common for me to query the meaning of an NTSTATUS value.
However, I always get nothing by the WinDBG command !error like the following:
kd> !error 0xC0000008 1
Error code: (NTSTATUS) 0xC0000008 - Unable to get error code text
Why does the WinDBG command !error not work as expected?
Thanks in advance.
PS. 0xC0000008 indicates STATUS_INVALID_HANDLE
Probably you should set locale
for example:
0: kd> .locale ".1251"
http://perfect-coding.blogspot.ru/2011/06/windbg-error-extension-and-locale.html
How can I automatically see current 10 instructions whenever my program stopped by breakpoint in gdb?
(not machine instruction but high level instruction e.g
int a = 10;
int b = 12;
...
print("a = %d, b = %d\n");
To do this manually, I have to use 'list' command to see the instructions.
What command should I use?
Thanks
In addition to using tui or an Emacs gud mode, you could define hook-stop:
(gdb) define hook-stop
>list
>end
In the book "Rootkit Arsenal" page 84 (Chapter 3) mentions:
..., we can view the contents of the
target machine's descriptor registers
using the command with the 0x100 mask:
kd> rM 0x100
and a paragraph below:
Note that the same task can be
accomplished by specifying the GDTR
components explicitly: kd> r gdtr ....
I run Windbg on my Win XP (inside VMWare) and choose the Kernel Debug -> Local.
My problem is in case of first command, windbg errors with:
lkd> rM 0x100
^ Operation not supported in current debug session 'rM 0x100'
and in the second command:
lkd> r gdtr
^ Bad register error in 'r gdtr'
Can anyone guide me ?
Right, you can't look at registers in a local kernel debug session. LiveKD works and you can also get the address indirectly through the PCR (!pcr).
-scott
I think I've found the solution:
Use two computers for kernel debugging instead of Local Kernel Debug.
(I used VMWare and am debugging through the COM port/named pipe)
I am thinking why this facility/feature (Local Kernel Debugging) is there if it's not complete ?