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.
Related
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
Hi I'm trying to use WinDbg to look at a memory.dmp kernel dump file with the aim of diagnosing a crash. When I open the crash file and get the symbols I get the message
BugCheck A, {2, ff, 4e, fffff801a42ebff2}
CompressedPageDataReader warning: failed to get _SM_PAGE_KEY symbol.
CompressedPageDataReader warning: failed to get _SM_PAGE_KEY symbol.
Probably caused by : ntkrnlmp.exe ( nt!KxWaitForLockOwnerShipWithIrql+12 )
Followup: MachineOwner
---------
0: kd> .reload
Loading Kernel Symbols
..................................CompressedPageDataReader warning: failed to get _SM_PAGE_KEY symbol.
Loading User Symbols
PEB is paged out (Peb.Ldr = 000000e1`114f4018). Type ".hh dbgerr001" for details
Which I assume means it can't load some of the symbols. When I try the !vad process to fix the PEB page error I get
0: kd> !vad 000000e1114f4018 1
VAD # ffffca0f084164e0
Start VPN e111400 End VPN e1115ff Control Area 0000000000000000
FirstProtoPte 0000000000000000 LastPte f943916c00000002 Commit Charge 21 (0n33)
Secured.Flink 0 Blink 0 Banked/Extend 0
File Offset 50005
ViewUnmap NoChange PrivateMemory READWRITE
which doesn't correspond to what the internet tells me the result should be.
when I try the !process method I get
0: kd> !process 000000e1114f4018 1
Searching for Process with Cid == e1114f4018
Invalid Handle: 0x114f4018
***Could not retrieve process handle from the Cid table. Searching...
which also is an error which doesn't load the symbols either. What is wrong? In either the symbol loading or the crash itself if there is enough info.
NOTE: I've tried the solutions from the MSDN page and they dont work as noted. Part of the problem is I don't know if I'm using the 000000e1`114f4018 address I'm given in the PEB paged out error message correctly in the command.
NOTE 2: Here is a link to the crash report from WinDBG. If someone can figure out the cause and explain how they figured it out that would be dandy.
https://www.scribd.com/document/326672131/Crash-Archive
The PEB being paged out is normal. In order for the PEB to be present, the dump must be a full memory dump and the corresponding pages must be resident at the time of the crash.
This mostly doesn't matter because the PEB contains user mode state (user loaded modules, command line, environment variables, etc.) which generally isn't interesting for a kernel mode crash.
What IS interesting is the !analyze -v output, including the kernel mode stack of the faulting thread. Based on what you have provided, we can at least see the crash code:
BugCheck A, {2, ff, 4e, fffff801a42ebff2}
Bugcheck A is an IRQL_NOT_LESS_OR_EQUAL, which means you have an invalid pointer dereference at an elevated IRQL (>= DISPATCH_LEVEL). The first argument is the bad address ("2") and the second argument is the IRQL ("0xFF" - this is WinDbg speak for "interrupts disabled on the processor").
In summary this means that someone has dereferenced address "2", which clearly isn't a good thing. It happened to happen with interrupts disabled on the processor, so you get an IRQL_NOT_LESS_OR_EQUAL. The trick then is to look at the call stack and faulting instruction and figure out where the "2" came from.
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.
I am debugging a program using WinDbg.
At the crash site, the last two frames of call stack are:
ChildEBP RetAddr
WARNING: Stack unwind information not available. Following frames may be wrong.
0251bfe8 6031f8da npdf!ProvideCoreHFT2+0x24db0
0251c000 011eb7a5 npdf!ProvideCoreHFT2+0x5ac1a
...
I want to find out how frame 1 calls frame 0. Since the return address of frame 0 is 6031f8da, I opened the disassembly window and jump to that location, the code are:
...
6031f8d5 e8a6d0ffff call npdf!ProvideCoreHFT2+0x57cc0 (6031c980)
6031f8da 5f pop edi
...
My question is that the call instruction right before the return address calls npdf!ProvideCoreHFT2+0x57cc0, while the function in frame 0 is actually npdf!ProvideCoreHFT2+0x24db0. Why such inconsistency exists? How should I proceed?
Thank you very much!
I'm trying to find a stack overflow in a project on MSP430, and found that it occurs mainly when an IRQ occurs after the stack is pretty full.
I've set a breakpoint on a stack pointer write with a value that is smaller than the start address of the stack, and the CPU halts in the IRQ handler.
The call stack display in IAR C-SPY then terminates at the handler function, however I'd be interested in what is below this, as this is what filled the stack.
Is there a way to display the call stack below the current interrupt handler?
If the interrupt handler is written in C, this should work correctly, as the generated CFI (call frame information) should be correct even for interrupt functions.
However, if this (for some reason) should not work, or if the interrupt routine is written in assembler (without proper CFI directives), you can use a little trick. You can manually modify the PC and SP registers in the register window by retrieving the PC from the stack and by "backing up" the SP the amount that it was adjusted inside the function. After this, the debugger will display the function that was executing when the interrupt occurred.
Note, in the traditional MSP430 core, the PC is stored as a plain 16 bit value. However, in the MSP430X core the 20 bits are a bit intertwined with the status register, see the architecture manual for details.