I know I am dealing with a managed thread but I have never managed to get !clrstack to work. I always get:
0:000> !clrstack
OS Thread Id: 0xaabb (0)
Child SP IP Call Site
GetFrameContext failed: 1
00000000 00000000
Admittedly I could use !dumpstack but I can't figure out how to make it show the arguments. It only shows ChildEBP, Return Address and the function name. Besides it mixes managed and unmanaged calls and I'd like to focus only on the managed portions.
UPDATE
As requested by Thomas, !clrstack -i returns:
0:000> !clrstack -i
Loaded c:\cache\mscordbi.dll\53489464110000\mscordbi.dll
Loaded c:\cache\mscordacwks_x86_x86_4.0.30319.34209.dll\5348961E69d000\mscordacwks_x86_x86_4.0.30319.34209.dll
Dumping managed stack and managed variables using ICorDebug.
=================================================================
Child SP IP Call Site
003ad0bc 77d1f8e1 [NativeStackFrame]
Stack walk complete.
Its progress :-)
Please post the output from !dumpstack or k to double check the callstack, you know the !clrstack only display the managed code call stack, however sometimes , if the managed thread finished this work, it would be waited in the CLR code(semaphore) if you use the thread pool, and the remain call stack become totally unmanaged call stack.so !clrstack display nothing for it.
Related
I have set a breakpoint in nt!ntWriteFile from Windbg. I'm using kernel debugging and I want to get the user stack + kernel stack trace when certain program (for example, notepad.exe) ends up calling this API. When the breakpoint kicks in I do the following:
.reload /user
K
but the result is similar to this (in this case notepad.exe is the current process):
# ChildEBP RetAddr
00 8f5a8c34 76e96c73 nt!NtWriteFile
01 8f5a8c38 badb0d00 ntdll!KiFastSystemCall+0x3
02 8f5a8c3c 0320ef04 0xbadb0d00
03 8f5a8c40 00000000 0x320ef04
My question are:
What is 0xbadb0d00? I always see this address.
Is the address 0x320ef04 the function on user land (inside notepad.exe in this case) from which the call begins? In this case, would that be the full stack trace (user stack + kernel stack).
Is there another easier way to get this?
Thank you.
Updated:
As I read in this link (thanks to Thomas Weller) 0xbadb0d00 is used to initialize uninitialized memory in some circumstances. Now I have even more doubts. Why does the stack trace show uninitialized memory? Why notepad.exe stack-trace does not appear in the output if I'm in its context?
The Windows host I'm debugging is a Windows 7 32 bits.
I have crash dumps that have WerpReportFault() in their stack and they really don't look the way I expect them to.
My expectation
If have seen WerpReportFault()along with 0x80000003 breakpoints and I was able to use WinDbg to re-dump with different exception pointers, taken from the second argument passed to WerpReportFault().
I'm very sure that has worked before, since I even recommended that in my answer over there. There are also other sites suggesting this technique, e.g. James Ross
My current observations
The dumps I'm analyzing have an "ordinary exception" inside, e.g. an access violation:
0:000> .exr -1
ExceptionAddress: 53ec8b55
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000000
Parameter[1]: 53ec8b55
Attempt to read from address 53ec8b55
But they still have WerpReportFault() as the stack:
0:000> k
ChildEBP RetAddr
0018f25c 74c4171a ntdll!NtWaitForMultipleObjects+0x15
0018f2f8 75181a08 KERNELBASE!WaitForMultipleObjectsEx+0x100
0018f340 75184200 kernel32!WaitForMultipleObjectsExImplementation+0xe0
0018f35c 751a80ec kernel32!WaitForMultipleObjects+0x18
0018f3c8 751a7fab kernel32!WerpReportFaultInternal+0x186
0018f3dc 751a78a0 kernel32!WerpReportFault+0x70
0018f3ec 751a781f kernel32!BasepReportFault+0x20
0018f478 7295fa2e kernel32!UnhandledExceptionFilter+0x1af
Argument 2 does not seem to be a good exception pointer to be used in the .dump command.
0:000> kb
ChildEBP RetAddr Args to Child
[...]
0018f3dc 751a78a0 0018f4a0 00000001 0018f478 kernel32!WerpReportFault+0x70
[...]
Question
What causes the problems I have and how do I get around it? I know it must be possible, because !analyze -v can tell me the real call stack.
Is it due to Visual Basic 6 and the unhandled exception filter?
0018f478 7295fa2e 00000000 72a2bd04 0018f4a8 kernel32!UnhandledExceptionFilter+0x1af
0018ff80 00440fe2 00443860 7518338a 7efde000 msvbvm60!Zombie_Release+0x10fd5
I really want to have a nice call stack, since all my manual debugging and all my scripts are broken which rely on k and !clrstack and similar. They can't deal with WerpReportFault() on the stack.
All the dumps are 32 bit, as you can imagine from the VB6 dependency.
Such a problem is caused by a wrong context. It seems to be set to the normal context record. To set it to the exception context, use .ecxr. To switch back to the normal context (which you see), use .cxr
I am trying to set a breakpoint into a Windows service that starts at boot time. Because of an unfortunate mistake on my end, the service forces the machine into a reboot loop: this means that I can't get to a stable state from which I could deploy a fix, and obviously I can't try to debug the service at a more convenient time.
I can use windbg in kernel mode. I'd very much like to break when the service hits the wmain function, but I'm having issues with that.
Up to now, I found that I can stop when the image is loaded by using the following commands:
!gflag +ksl
sxe ld MyServiceExecutable.exe
The problem is that once it breaks, I find myself in an empty process, in which I am apparently unable to set breakpoints. bm MyServiceExecutable!wmain says that it can't find the symbol and that the breakpoint will be "deferred", but it is effectively never set or reached. Setting a breakpoint on KERNEL32!BaseThreadInitThunk seems to work more or less at random across all the processes running and I didn't have a lot of luck with it to stop in my service so far.
Alright, this might not the best way to do it, but it worked. MSFTs, please correct me if I'm doing something dumb!
The first part was good:
kd> !gflag +ksl
New NtGlobalFlag contents: 0x00440000
ksl - Enable loading of kernel debugger symbols
ece - Enable close exception
kd> sxe ld MyServiceExecutable.exe
kd> g
In kernel mode, sxe ld will stop the first time the executable is loaded only.
When the debugger stops again, we're inside the freshly created process. We don't need the gflag anymore:
kd> !gflag -ksl
New NtGlobalFlag contents: 0x00400000
ece - Enable close exception
Though we're going to need the EPROCESS pointer. We can get it with .process or !process -1 0, but it is already in the $proc pseudo-register:
kd> r $proc
$proc=0011223344556677
kd> .process
Implicit process is now 00112233`44556677
From this point it's possible to set breakpoints on nt symbols, so let's use NtMapViewOfSection as it's called for each dll loaded.
kd> bp /p #$proc nt!NtMapViewOfSection
kd> g
On the next stop ntdll should be loaded (check with kn if it's on the stack, .reload /user if necessary), so you can set a breakpoint on RtlUserThreadStart. Also, we are overwriting breakpoint 0, because since we don't need to break on NtMapViewOfSection anymore(it would just be a nuisance).
kd> bp0 /p #$proc ntdll!RtlUserThreadStart
kd> g
All symbols should have been loaded by the time the first user thread starts, so you're free to set your breakpoint wherever you want.
kd> .reload /user
kd> bp /p #$proc MyServiceExecutable!wmain
kd> g
Use the technique that MS describes for debugging winlogon which involves using the kernel mode and user mode debuggers in tandem. See "Debugging WinLogon" in the debugger.chm file that comes with the "Debugging Tools for Windows" download.
I have a legacy application that I am trying to debug which schedules a background task like this:
err = QueueUserWorkItem(
Foo,
NULL,
WT_EXECUTEINIOTHREAD);
I can see that my function Foo is never executed (i put a breakpoint on the function and it is never hit). So i thought lets see if we have any IO thread avaialble for the function ever or not. But sadly i dont know how to list such threads in windbg. Can anyone help me here please. I am doing this debugging in user mode.
Load sos: .loadby sos clr or .loadby sos mscorwks
Dump the threads: !Threads
Pick an interesting thread: ~<thread number>s (eg: ~13s) Then show the stack: !DumpStack
You could also try !EEStack to show all the threads (can be information overload).
Does anyone know how I can list all threads in WinDbg while kernel debugging. I have found older references that say '~' but that does not work.
Specifically I am looking to the find the ID of a thread that caused an event, namely a breakpoint.
Thanks.
~ only works in user mode. To list all threads on the system, it's !process 0 1 as I recall (it's been awhile).
"Specifically I am looking to the find the ID of a thread that caused an event, namely a breakpoint."
This statement doesn't make much sense to do from kernel mode. Can you descrive more about what your scenario is?
Edit: Ah, now I get it. You want to know which thread you're currently in right now. Give !thread a go.
You can always use the #$thread pseudo register to reference the current thread object:
0: kd> r #$thread
$thread=fffff80002c02cc0
If you want the ID of the thread, you'll need to dig it out of the ETHREAD. Luckily, the #$thread is typed as a pointer to an ETHREAD if you're using the C++ evaluator:
0: kd> ?? #$thread->Cid
struct _CLIENT_ID
+0x000 UniqueProcess : 0x00000000`00001408 Void
+0x008 UniqueThread : 0x00000000`0000144c Void
-scott