How can I remove breakpoint ntdll!DbgBreakPoint+0x1 in WinDbg - windbg

I'm debugging a program that's crashing with WinDbg set as my post-mortem debugger. I have set a breakpoint at address 77f7f571. When it's triggered, I used to get the following:
*** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\WINDOWS\System32\ntdll.dll -
ntdll!DbgBreakPoint+0x1:
Then I followed the instructions from http://www.osronline.com/ShowThread.cfm?link=178221, and now I just get
ntdll!DbgBreakPoint+0x1:
I'd like to remove this breakpoint, but I can't get it to list or delete. There's no output for bl, nor for bc or bd:
0:002> bl
0:002> bc *
0:002> bd *

This is not a line based breakpoint but looks like a manual call to DebugBreak() like in the following program:
#include "stdafx.h"
#include "windows.h"
int _tmain()
{
DebugBreak();
return 0;
}
Internally, the method will throw an exception. To control whether WinDbg stops due to the exception, use sxe bpe to stop and sxi bpe to ignore the exception.
To try this, compile above application and run it under WinDbg (Ctrl+E). At the inital breakpoint, take over the control:
(1c2c.6a8): Break instruction exception - code 80000003 (first chance)
eax=00000000 ebx=00000000 ecx=779d0000 edx=0020e218 esi=fffffffe edi=00000000
eip=773e12fb esp=0038f9e8 ebp=0038fa14 iopl=0 nv up ei pl zr na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000246
ntdll!LdrpDoDebuggerBreak+0x2c:
773e12fb cc int 3
0:000> sxe bpe; g
(1c2c.6a8): Break instruction exception - code 80000003 (first chance)
*** WARNING: Unable to verify checksum for DebugBreak.exe
eax=cccccccc ebx=7efde000 ecx=00000000 edx=00000001 esi=0038fd44 edi=0038fe10
eip=74d5322c esp=0038fd40 ebp=0038fe10 iopl=0 nv up ei pl nz na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000206
KERNELBASE!DebugBreak+0x2:
74d5322c cc int 3
0:000> g
eax=00000000 ebx=00000000 ecx=00000000 edx=00000000 esi=77442100 edi=774420c0
eip=7735fd02 esp=0038fd78 ebp=0038fd94 iopl=0 nv up ei pl zr na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000246
ntdll!ZwTerminateProcess+0x12:
7735fd02 83c404 add esp,4
After this experiment, type .restart. Then repeat the experiment with sxi bpe:
(109c.1c1c): Break instruction exception - code 80000003 (first chance)
eax=00000000 ebx=00000000 ecx=be9e0000 edx=0009e028 esi=fffffffe edi=00000000
eip=773e12fb esp=002ff890 ebp=002ff8bc iopl=0 nv up ei pl zr na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000246
ntdll!LdrpDoDebuggerBreak+0x2c:
773e12fb cc int 3
0:000> sxi bpe; g
eax=00000000 ebx=00000000 ecx=00000000 edx=00000000 esi=77442100 edi=774420c0
eip=7735fd02 esp=002ffc20 ebp=002ffc3c iopl=0 nv up ei pl zr na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000246
ntdll!ZwTerminateProcess+0x12:
7735fd02 83c404 add esp,4
As you can see, WinDbg did not stop at KERNELBASE!DebugBreak+0x2 due to the exception any more.

Related

How to set an exception using masm64?

How can i access the exception chain (SEH) using masm64?
Using masm32, I get the first exception looking into fs:[0]
But when I checked in Windbg if fs:[0] still pointed at the first exception in x64, I figured that it wasn't.
I'd like to set an exception in x64 the same way I did in x86. Is it feasible (maybe looking at gs register)?
If this is coding related then you use
ml64seh PROC FRAME:ExceptionFilter
this adds your exception handler to .PDATA section RUNTIME_FUNCTION
if this is how to find this exception handler in windbg when the exception has been raised
use !exchain command
or if you want to find it before executing a specific function use .fnent command
a sample for x64 seh and finding it in windbg is as follows
;assemble and link with
;ml64 /Zi ml64seh.asm /link /debug /entry:ml64seh /subsystem:console
.data
safeplace DWORD ?
.code
ExceptionFilter PROC
jmp Handler
ExceptionFilter ENDP
PUBLIC ml64seh
ml64seh PROC FRAME:ExceptionFilter
.ENDPROLOG
mov rax, 0
mov [rax], rax ;access violation
jmp exit
Handler::
lea rax, safeplace
mov [r8+078h], rax ; replacing rax in exception handler so access is possible
mov rax, 0
ret
Exit:
ret
ml64seh ENDP
END
run without stopping in windbg
:\>cdb -g ml64seh.exe
(2aa0.3024): Access violation - code c0000005 (first chance)
ml64seh!ml64seh+0x7:
00007ff7`0e3b1029 488900 mov qword ptr [rax],rax ds:00000000`00000000=????????????????
0:000>
it crashed and broke now locating exception handlers
0:000> .fnent .
Debugger function entry 0000020b`e36c47a8 for:
(00007ff7`0e3b1022) ml64seh!ml64seh+0x7 | (00007ff7`0e3b32b0) ml64seh!$xdatasym
BeginAddress = 00000000`00001022
EndAddress = 00000000`00001042
UnwindInfoAddress = 00000000`000032b0
Unwind info at 00007ff7`0e3b32b0, c bytes
version 1, flags 3, prolog 0, codes 0
handler routine: ml64seh!ILT+0(ExceptionFilter) (00007ff7`0e3b1005), data 0 <<<<<<<<<
0:000> !exchain
3 stack frames, scanning for handlers...
Frame 0x00: ml64seh!ml64seh+0x7 (00007ff7`0e3b1029)
ehandler ml64seh!ILT+0(ExceptionFilter) (00007ff7`0e3b1005) <<<<<<<<<<<<
Frame 0x02: ntdll!RtlUserThreadStart+0x21 (00007ffe`213c26a1)
ehandler ntdll!_C_specific_handler (00007ffe`213fc720)
0:000>
lets see if we go to the handler and return back to re access the faulting place
0:000> bp .
0:000> bp 00007ff7`0e3b1005
0:000> bl
0 e 00007ff7`0e3b1029 0001 (0001) 0:**** ml64seh!ml64seh+0x7
1 e 00007ff7`0e3b1005 0001 (0001) 0:**** ml64seh!ILT+0(ExceptionFilter)
0:000> g
Breakpoint 1 hit
ml64seh!ILT+0(ExceptionFilter):
00007ff7`0e3b1005 e916000000 jmp ml64seh!ExceptionFilter (00007ff7`0e3b1020)
0:000> g
Breakpoint 0 hit
ml64seh!ml64seh+0x7: is accessible now
00007ff7`0e3b1029 488900 mov qword ptr [rax],rax ds:00007ff7`0e3b4000=0000000000000000
0:000>
btw you can use dumpbin or linker to spit out all the unwindinfos in a specific binary using -unwindinfo switch
:\>dumpbin /unwindinfo ml64seh.exe
Microsoft (R) COFF/PE Dumper Version 14.29.30146.0
Copyright (C) Microsoft Corporation. All rights reserved.
Dump of file ml64seh.exe
File Type: EXECUTABLE IMAGE
Function Table (1)
Begin End Info Function Name
00000000 00001022 00001042 000032B0 ml64seh
Unwind version: 1
Unwind flags: EHANDLER UHANDLER
Size of prologue: 0x00
Count of codes: 0
Handler: 00001005 #ILT+0(ExceptionFilter)

How to debug the BSOD with invalid memory reference, specifically, why RSI was set to 0

My Windows 10 laptop has been BSODing recently, almost daily, around the time I am not using it (this is a work PC, so the issue happens from like 10pm to 6am). The crash dumps all look the same:
IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 0000000000002d30, memory referenced
Arg2: 00000000000000ff, IRQL
Arg3: 00000000000000e8, bitfield :
bit 0 : value 0 = read operation, 1 = write operation
bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4: fffff8011be4e0ff, address which referenced memory
...
DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT
BUGCHECK_STR: AV
PROCESS_NAME: System
...
LAST_CONTROL_TRANSFER: from fffff8011bf6bba9 to fffff8011bf59dc0
STACK_TEXT:
fffff801`1dc625c8 fffff801`1bf6bba9 : 00000000`0000000a 00000000`00002d30 00000000`000000ff 00000000`000000e8 : nt!KeBugCheckEx
fffff801`1dc625d0 fffff801`1bf6855a : 0000006b`b0e5bb5a fffff801`1dc62940 00000000`00000002 fffff801`1bf3aecc : nt!KiBugCheckDispatch+0x69
fffff801`1dc62710 fffff801`1be4e0ff : 00000000`00000000 fffff801`1bfed7b6 ffffe001`9510d010 ffffe001`97fc14f0 : nt!KiPageFault+0x51a
fffff801`1dc628a0 fffff801`1be4d31b : 00000000`00000000 00000000`00000002 00000000`00000000 00000000`00000000 : nt!PpmIdleExecuteTransition+0xc2f
fffff801`1dc62b00 fffff801`1bf5d24c : 00000000`00000000 fffff801`1c126180 fffff801`1c19c740 ffffe001`9355c080 : nt!PoIdle+0x33b
fffff801`1dc62c60 00000000`00000000 : fffff801`1dc63000 fffff801`1dc5d000 00000000`00000000 00000000`00000000 : nt!KiIdleLoop+0x2c
0: kd> .trap fffff801`1dc62710
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000000 rbx=0000000000000000 rcx=0000000000000012
rdx=0000000000000000 rsi=0000000000000000 rdi=0000000000000000
rip=fffff8011be4e0ff rsp=fffff8011dc628a0 rbp=0000000000000000
r8=0000000000000000 r9=0000000000000000 r10=0000000000000000
r11=0000000000000000 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up di ng nz na po nc
nt!PpmIdleExecuteTransition+0xc2f:
fffff801`1be4e0ff 0fb686302d0000 movzx eax,byte ptr [rsi+2D30h] ds:00000000`00002d30=??
And if I am not mistaken, I should look into why RSI was set to 0 before the fault happened. And the "u" command shows a "call qword ptr [rbp+198h]" instruction may have preceded the fault.
0: kd> ub rip L13
nt!PpmIdleExecuteTransition+0xbe3:
fffff801`1be4e0b3 4032ff xor dil,dil
fffff801`1be4e0b6 0fb686302d0000 movzx eax,byte ptr [rsi+2D30h]
fffff801`1be4e0bd a801 test al,1
fffff801`1be4e0bf 740f je nt!PpmIdleExecuteTransition+0xc00 (fffff801`1be4e0d0)
fffff801`1be4e0c1 a808 test al,8
fffff801`1be4e0c3 750b jne nt!PpmIdleExecuteTransition+0xc00 (fffff801`1be4e0d0)
fffff801`1be4e0c5 33c0 xor eax,eax
fffff801`1be4e0c7 b948000000 mov ecx,48h
fffff801`1be4e0cc 33d2 xor edx,edx
fffff801`1be4e0ce 0f30 wrmsr
fffff801`1be4e0d0 488b8518030000 mov rax,qword ptr [rbp+318h]
fffff801`1be4e0d7 458bc4 mov r8d,r12d
fffff801`1be4e0da 448b8d0c030000 mov r9d,dword ptr [rbp+30Ch]
fffff801`1be4e0e1 8b54244c mov edx,dword ptr [rsp+4Ch]
fffff801`1be4e0e5 488b8c2480000000 mov rcx,qword ptr [rsp+80h]
fffff801`1be4e0ed 4889442420 mov qword ptr [rsp+20h],rax
fffff801`1be4e0f2 ff9598010000 call qword ptr [rbp+198h]
fffff801`1be4e0f8 448be0 mov r12d,eax
fffff801`1be4e0fb 89442444 mov dword ptr [rsp+44h],eax
0: kd> u rip
nt!PpmIdleExecuteTransition+0xc2f:
fffff801`1be4e0ff 0fb686302d0000 movzx eax,byte ptr [rsi+2D30h]
fffff801`1be4e106 a801 test al,1
fffff801`1be4e108 7418 je nt!PpmIdleExecuteTransition+0xc52 (fffff801`1be4e122)
fffff801`1be4e10a a808 test al,8
fffff801`1be4e10c 7514 jne nt!PpmIdleExecuteTransition+0xc52 (fffff801`1be4e122)
fffff801`1be4e10e 41b801000000 mov r8d,1
fffff801`1be4e114 33d2 xor edx,edx
fffff801`1be4e116 418bc0 mov eax,r8d
Appreciate your guidance as to how to debug this BSOD further. My troubleshooting direction may be false, in which case I am all ears for your insights. Thanks in advance!

Use register for .NET sosex extension

Is there any way to display the object contents using !mdt (SOSEX extension) but using a register?
I am aware if you do !mdt 299281 (display the object in that address if any) but what about if I want to do !mdt edx (register instead of hex number)?
Yes, just use #edx. Here's an example with eax:
0:004> r
eax=023c3e64 ebx=00000000 ecx=00000000 edx=773af1da esi=00000000 edi=00000000
eip=7732000c esp=04acfe88 ebp=04acfeb4 iopl=0 nv up ei pl zr na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000246
ntdll!DbgBreakPoint:
7732000c cc int 3
0:004> !mdt #eax
023c3e64 (System.Globalization.CultureData)
sRealName:023c1228 (System.String)
sWindowsName:023c1228 (System.String)
sName:023c1228 (System.String)
sParent:023c1228 (System.String)
[...]

Windbg Crash Dump Stack Trace Keeps Every Over Function

So I have a crash dump, and using WinDbg, I am able to get the stack trace. However, it appears to be skipping every other function. For instance if the actual code is:
void a()
{
b();
}
void b()
{
c();
}
void c(){}
The stack trace would have a, and c in the stack frame and not b. Is this expected behavior, and is there something I can do to see the entire stack trace? I have using the command "kn" to view the stack trace.
The compiler may optimize the code. One optimization is to inline methods so that call and ret statements and everything related (push, pop etc.) are removed.
For demonstration purposes, I have added a std::cout statement to your code which we can identify so that the full code now reads
#include "stdafx.h"
#include <iostream>
void c()
{
std::cout << "Hello world";
}
void b()
{
c();
}
void a()
{
b();
}
int _tmain(int argc, _TCHAR* argv[])
{
a();
return 0;
}
Walkthrough in debug build
In a typical debug build, there are no optimizations and you can see the methods. To follow the example, start WinDbg first and run the executable via File/Open executable....
0:000> .symfix e:\debug\symbols
0:000> lm
start end module name
010d0000 010f3000 OptimizedInlined (deferred)
...
0:000> ld OptimizedInlined
Symbols loaded for OptimizedInlined
0:000> x OptimizedInlined!c
010e50c0 OptimizedInlined!c (void)
0:000> bp OptimizedInlined!c
0:000> bl
0 e 010e50c0 0001 (0001) 0:**** OptimizedInlined!c
0:000> g
Breakpoint 0 hit
eax=cccccccc ebx=7efde000 ecx=00000000 edx=00000001 esi=00000000 edi=003ffa00
eip=010e50c0 esp=003ff930 ebp=003ffa00 iopl=0 nv up ei pl nz na po nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000202
OptimizedInlined!c:
010e50c0 55 push ebp
0:000> u eip L18
OptimizedInlined!c [e:\...\optimizedinlined.cpp # 8]:
010e50c0 55 push ebp
010e50c1 8bec mov ebp,esp
010e50c3 81ecc0000000 sub esp,0C0h
010e50c9 53 push ebx
010e50ca 56 push esi
010e50cb 57 push edi
010e50cc 8dbd40ffffff lea edi,[ebp-0C0h]
010e50d2 b930000000 mov ecx,30h
010e50d7 b8cccccccc mov eax,0CCCCCCCCh
010e50dc f3ab rep stos dword ptr es:[edi]
010e50de 6854ca0e01 push offset OptimizedInlined!`string' (010eca54)
010e50e3 a1e4000f01 mov eax,dword ptr [OptimizedInlined!_imp_?coutstd (010f00e4)]
010e50e8 50 push eax
010e50e9 e8c9c1ffff call OptimizedInlined!ILT+690(??$?6U?$char_traitsDstdstdYAAAV?$basic_ostreamDU?$char_traitsDstd (010e12b7)
010e50ee 83c408 add esp,8
010e50f1 5f pop edi
010e50f2 5e pop esi
010e50f3 5b pop ebx
010e50f4 81c4c0000000 add esp,0C0h
010e50fa 3bec cmp ebp,esp
010e50fc e838c2ffff call OptimizedInlined!ILT+820(__RTC_CheckEsp) (010e1339)
010e5101 8be5 mov esp,ebp
010e5103 5d pop ebp
010e5104 c3 ret
Walkthrough release build
In the release build, see how things change. The WinDbg commands are the same, but the methods c(), b() and a() cannot be found. The std::cout method call has been inlined into wmain():
0:000> .symfix e:\debug\symbols
0:000> lm
start end module name
01360000 01367000 OptimizedInlined (deferred)
...
0:000> ld OptimizedInlined
Symbols loaded for OptimizedInlined
0:000> x OptimizedInlined!c
0:000> x OptimizedInlined!b
0:000> x OptimizedInlined!a
0:000> x OptimizedInlined!wmain
013612a0 OptimizedInlined!wmain (int, wchar_t **)
0:000> bp OptimizedInlined!wmain
0:000> bl
0 e 013612a0 0001 (0001) 0:**** OptimizedInlined!wmain
0:000> g
Breakpoint 0 hit
eax=6142f628 ebx=00000000 ecx=0087a6e8 edx=0019def8 esi=00000001 edi=00000000
eip=013612a0 esp=0042f8f8 ebp=0042f934 iopl=0 nv up ei pl zr na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000246
OptimizedInlined!wmain:
013612a0 8b0d44303601 mov ecx,dword ptr [OptimizedInlined!_imp_?coutstd (01363044)] ds:002b:01363044={MSVCP120!std::cout (646c6198)}
0:000> u eip L4
OptimizedInlined!wmain [e:\...\optimizedinlined.cpp # 23]:
013612a0 8b0d44303601 mov ecx,dword ptr [OptimizedInlined!_imp_?coutstd (01363044)]
013612a6 e895040000 call OptimizedInlined!std::operator<<<std::char_traits<char> > (01361740)
013612ab 33c0 xor eax,eax
013612ad c3 ret
Like already mentioned by Lieven. this is a case where compiler is making function calls inline.
There are 2 things that i would suggest:
a. If you have control over the code and build environment. Build a non-optimized/debug version of the code. This will ensure that compiler does not inline functions on its own.
b. In WinDBG you can see the disassembly under View --> Disassembly. Here you can see that code for function b() is actually in lined under a().
In case you are comfortable with assembly debugging you can get the value of locals as well :)

How to find the source of an 'Access Violation'

To put in a nutshell, I have a C# application doing lots of mciSendString calls ( via dllimport ) to control wav files playback ( essentially open, play, pause, stop, status, close ). And after running for a while, the application crashes without notice with an 'access violation'.
Even though I'm running the app from my vs2012, the exception is not caught by visual studio. Even with the 'force break on an exception' option, I've had no luck in debugging this from the vs2012. So instead I've setup WER to generate me crash dumps and I am using windbg with psscor2.dll plugin to debug it.
Then in sequence, using the following commands, this is what I get ( shorten to the essential for readability purposes ) :
$>.ecxr
eax=00000001 ebx=00000000 ecx=00000401 edx=00000000 esi=049725b8 edi=00000002
eip=4e88159e esp=0a4efa38 ebp=0a4efa54 iopl=0 nv up ei pl nz ac pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010216
<Unloaded_mciwave.dll>+0x159e:
4e88159e ?? ???
$>~*kb
# 19 Id: 105c.28cc Suspend: 1 Teb: 7ef06000
Unfrozen
user32!NtUserGetMessage+0x15
user32!GetMessageA+0xa1
winmm!mciwindow+0x102
kernel32!BaseThreadInitThunk+0xe
ntdll!__RtlUserThreadStart+0x70
ntdll!_RtlUserThreadStart+0x1b
# 30 Id: 105c.15f8 Suspend: 0 Teb: 7ef1b000 Unfrozen
ntdll!ZwWaitForMultipleObjects+0x15
KERNELBASE!WaitForMultipleObjectsEx+0x100
kernel32!WaitForMultipleObjectsExImplementation+0xe0
kernel32!WaitForMultipleObjects+0x18
kernel32!WerpReportFaultInternal+0x186
kernel32!WerpReportFault+0x70
kernel32!BasepReportFault+0x20
kernel32!UnhandledExceptionFilter+0x1af
ntdll!__RtlUserThreadStart+0x62
ntdll!_EH4_CallFilterFunc+0x12
ntdll!_except_handler4+0x8e
ntdll!ExecuteHandler2+0x26
ntdll!ExecuteHandler+0x24
ntdll!RtlDispatchException+0x127
ntdll!KiUserExceptionDispatcher+0xf
WARNING: Frame IP not in any known module. Following frames may be wrong.
<Unloaded_mciwave.dll>+0x159e
# 31 Id: 105c.2310 Suspend: 1 Teb: 7ef00000 Unfrozen
user32!NtUserGetMessage+0x15
user32!GetMessageW+0x33
mciwave!TaskBlock+0x1d
mciwave!PlayFile+0xcb
mciwave!mwTask+0x98
winmm!mmStartTask+0x22
kernel32!BaseThreadInitThunk+0xe
ntdll!__RtlUserThreadStart+0x70
ntdll!_RtlUserThreadStart+0x1b:
$>!analyze -v
FAULTING_IP:
mciwave_4e880000!TaskBlock+1d
4e88159e ?? ???
EXCEPTION_RECORD: ffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 4e88159e (mciwave_4e880000!TaskBlock+0x0000001d)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000008
Parameter[1]: 4e88159e
Attempt to execute non-executable address 4e88159e
PROCESS_NAME: Titan.vshost.exe
ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s.
EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s.
EXCEPTION_PARAMETER1: 00000008
EXCEPTION_PARAMETER2: 4e88159e
WRITE_ADDRESS: 4e88159e
FOLLOWUP_IP:
mciwave_4e880000!TaskBlock+1d
4e88159e ?? ???
MOD_LIST: <ANALYSIS/>
NTGLOBALFLAG: 0
APPLICATION_VERIFIER_FLAGS: 0
MANAGED_STACK: !dumpstack -EE
OS Thread Id: 0x15f8 (30)
====> Exception cxr#a4ef750
FAULTING_THREAD: 000015f8
BUGCHECK_STR: APPLICATION_FAULT_SOFTWARE_NX_FAULT_CODE_WRONG_SYMBOLS
PRIMARY_PROBLEM_CLASS: SOFTWARE_NX_FAULT_CODE
DEFAULT_BUCKET_ID: SOFTWARE_NX_FAULT_CODE
LAST_CONTROL_TRANSFER: from 4e881999 to 4e88159e
STACK_TEXT:
0a4efa54 4e881999 0a4efa88 078db198 078db1a4 mciwave_4e880000!TaskBlock+0x1d
0a4efa68 74370ae5 00038edc 00000000 00000000 mciwave_4e880000!mwTask+0x45
0a4efa88 7670338a 078db198 0a4efad4 76f99f72 winmm!mmStartTask+0x22
0a4efa94 76f99f72 078db198 79f84a28 00000000 kernel32!BaseThreadInitThunk+0xe
0a4efad4 76f99f45 74370ac3 078db198 00000000 ntdll!__RtlUserThreadStart+0x70
0a4efaec 00000000 74370ac3 078db198 00000000 ntdll!_RtlUserThreadStart+0x1b
SYMBOL_STACK_INDEX: 0
SYMBOL_NAME: mciwave!TaskBlock+1d
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: mciwave_4e880000
IMAGE_NAME: mciwave.dll
DEBUG_FLR_IMAGE_TIMESTAMP: 4a5bcb4a
STACK_COMMAND: ~30s; .ecxr ; kb
FAILURE_BUCKET_ID: SOFTWARE_NX_FAULT_CODE_c0000005_mciwave.dll!TaskBlock
BUCKET_ID: APPLICATION_FAULT_SOFTWARE_NX_FAULT_CODE_WRONG_SYMBOLS_mciwave!TaskBlock+1d
Followup: MachineOwner
---------
Exception seems to happen in thread #30 in Unloaded_mciwave.dll, but I have no idea how to push further the debugging.. How can I get a better idea of what's going ??
How can I get what's happening between these two lines ?
ntdll!KiUserExceptionDispatcher+0xf
--> WARNING: Frame IP not in any known module. Following frames may be wrong.
<Unloaded_mciwave.dll>+0x159e
Thank you for your help in advance.
You should get more details by reloading the DLL in the Debugger.
For that you need to do:
lmvm mciwave.dll
start end module name
Unloaded modules:
e6510000 e6548000 mciwave.dll
Timestamp: Fri Oct 14 12:00:00 2011 (4E98E6E2)
Checksum: 0003E937
ImageSize: 00038000
You need to set up the Symbol and Exe-Path so the debugger can find the DLL and PDB (which shouldn't be a problem if you have it in your machine). Then you can do
.reload mciwave.dll=e6510000,00038000
DBGHELP: <path>\mciwave.dll - OK
Now if you do !analyze -v again, it should give you the correct call stack.