I have the following thread stack with a msvcr100!_CxxThrowException.
# ChildEBP RetAddr Args to Child
00 0973ef38 7739bf53 7739610a 00000000 00000000 ntdll!KiFastSystemCallRet
01 0973ef70 7738965e 0019029e 00000000 00000001 user32!NtUserWaitMessage+0xc
02 0973ef98 7739f762 77380000 0016aa20 00000000 user32!InternalDialogBox+0xd0
03 0973f258 7739f047 0973f3b4 00000000 ffffffff user32!SoftModalMessageBox+0x94b
04 0973f3a8 7739eec9 0973f3b4 00000028 00000000 user32!MessageBoxWorker+0x2ba
05 0973f400 773d7d0d 00000000 001aaf18 0019bb60 user32!MessageBoxTimeoutW+0x7a
06 0973f434 773c42c8 00000000 7787b9f0 7786c24c user32!MessageBoxTimeoutA+0x9c
07 0973f454 773c42a4 00000000 7787b9f0 7786c24c user32!MessageBoxExA+0x1b
08 0973f470 7786f265 00000000 7787b9f0 7786c24c user32!MessageBoxA+0x45
09 0973f4a4 7786c20f 7787b9f0 7786c24c 00012010 netman!__crtMessageBoxA+0xf6
0a 0973f4cc 7786f34e 0000000a 00000000 0973f788 netman!_NMSG_WRITE+0x127
0b 0973f4fc 7786d6b6 77ecb7c0 0973f760 77e761b7 netman!abort+0x7
0c 0973f508 77e761b7 0973f788 00000000 00000000 netman!__CxxUnhandledExceptionFilter+0x2f
0d 0973f760 77e792a3 0973f788 77e61ac1 0973f790 kernel32!UnhandledExceptionFilter+0x12a
0e 0973f768 77e61ac1 0973f790 00000000 0973f790 kernel32!BaseThreadStart+0x4a
0f 0973f790 7c828772 0973fb4c 0973ffdc 0973f86c kernel32!_except_handler3+0x61
10 0973f7b4 7c828743 0973fb4c 0973ffdc 0973f86c ntdll!ExecuteHandler2+0x26
11 0973f85c 7c82865c 09737000 0973f86c 00010007 ntdll!ExecuteHandler+0x24
12 0973fb3c 77e4bef7 0973fb4c 0000000f e06d7363 ntdll!RtlRaiseException+0x3d
13 0973fb9c 78ac872d e06d7363 00000001 00000003 kernel32!RaiseException+0x53
14 0973fbd4 0084bb9e 0973fc38 00bd8470 9adbd99a msvcr100!_CxxThrowException+0x48
When I look a the msvcr100!_CxxThrowException frame I see the following information. How can I progressive analyze this dump to determine the cause of the MSVCR exception?
14 0973fbd4 0084bb9e msvcr100!_CxxThrowException+0x48 [f:\dd\vctools\crt_bld\self_x86\crt\prebuild\eh\throw.cpp # 157]
0973fbdc void * pExceptionObject = 0x0973fc38
0973fbe0 struct _s__ThrowInfo * pThrowInfo = 0x00bd8470
0973fbb4 struct EHExceptionRecord ThisException = struct EHExceptionRecord
78ac8734 struct EHExceptionRecord ExceptionTemplate = struct EHExceptionRecord
EDIT: At the time I wrote this answer, I wasn't aware of the better, less complicated approaches suggested by the other posters below. So please scroll down and check their answers out as well!
According to your comments, you can't really analyze the stack trace further than this point.
To at least get details about the exception itself (only if it's a exception you have symbols for, such as one in std), you can do the following:
I prepared a simple test file:
#include <stdexcept>
int main()
{
throw std::runtime_error("Oh noez!");
}
Then I ran it in WinDbg:
CommandLine: Z:\Temp\testexception\bin\Debug\testexception.exe
************* Symbol Path validation summary **************
Response Time (ms) Location
Deferred symsrv*symsrv.dll*c:\users\david\symbols*http://msdl.microsoft.com/download/symbols
Symbol search path is: symsrv*symsrv.dll*c:\users\david\symbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
ModLoad: 00910000 00919000 testexception.exe
ModLoad: 771a0000 7731b000 ntdll.dll
ModLoad: 75b60000 75c40000 C:\WINDOWS\SysWOW64\KERNEL32.DLL
ModLoad: 73ef0000 7406e000 C:\WINDOWS\SysWOW64\KERNELBASE.dll
ModLoad: 0fb60000 0fcd3000 C:\WINDOWS\SysWOW64\MSVCR100D.dll
(4de4.178c): Break instruction exception - code 80000003 (first chance)
eax=00000000 ebx=00000003 ecx=039b0000 edx=00000000 esi=009100e8 edi=00360000
eip=7724ccbc esp=0018f524 ebp=0018f550 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+0x2b:
7724ccbc cc int 3
Processing initial command '.prefer_dml 1'
0:000> .prefer_dml 1
DML versions of commands on by default
0:000> bp ntdll!ExecuteHandler2 <<<<<< This is just to get a stack more similar to yours
0:000> g
(4de4.178c): C++ EH exception - code e06d7363 (first chance)
Breakpoint 0 hit
eax=00000000 ebx=00000000 ecx=64905de5 edx=7722b670 esi=00000000 edi=00000000
eip=7722b62c esp=0018f3cc ebp=0018f490 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!ExecuteHandler2:
7722b62c 55 push ebp
0:000> kb
# ChildEBP RetAddr Args to Child
00 0018f3c8 7722b624 0018f4a8 0018fa4c 0018f4f8 ntdll!ExecuteHandler2
01 0018f490 77218e7f 0018f4a8 0018f4f8 0018f4a8 ntdll!ExecuteHandler+0x24
02 0018f490 73fadad8 0018f4a8 0018f4f8 0018f4a8 ntdll!KiUserExceptionDispatcher+0xf
03<0018f9b0>0fc5cf82 e06d7363 00000001 00000003 KERNELBASE!RaiseException+0x48
*** WARNING: Unable to verify checksum for testexception.exe
04 0018f9f0 00911071 0018fa00 009153a8 00914790 MSVCR100D!_CxxThrowException+0x52
05 0018fa0c 009114df 00000001 00a14f78 00a12358 testexception!main+0x21
06 0018fa5c 0091130f 0018fa78 75b738f4 00360000 testexception!__tmainCRTStartup+0x1bf
07 0018fa64 75b738f4 00360000 75b738d0 380b229d testexception!mainCRTStartup+0xf
08 0018fa78 77205de3 00360000 6488a725 00000000 KERNEL32!BaseThreadInitThunk+0x24
09 0018fac0 77205dae ffffffff 7722b7d2 00000000 ntdll!__RtlUserThreadStart+0x2f
0a 0018fad0 00000000 00911300 00360000 00000000 ntdll!_RtlUserThreadStart+0x1b
0:000> dds 0018f9b0 l6 <<<<<< The address is from the line with RaiseException above, I marked it with < >
0018f9b0 0018f9f0
0018f9b4 0fc5cf82 MSVCR100D!_CxxThrowException+0x52
0018f9b8 e06d7363
0018f9bc 00000001
0018f9c0 00000003
0018f9c4 0018f9e4 <<<<<< This is the address of the arguments array
0:000> dpp 0018f9e4 l3
0018f9e4 19930520
0018f9e8 <0018fa00>00914790 <testexception!std::runtime_error>::`vftable' <<<<<< this is the exception
0018f9ec 009153a8 00000000
0:000> dt 0018fa00 testexception!std::runtime_error <<<<<< remove the `vftable` part (again marked with < > above)
+0x000 __VFN_table : 0x00914790
+0x004 _Mywhat : 0x00a11068 "Oh noez!" <<<<<< Here is our message from the code
+0x008 _Mydofree : 1
#CherryDT's answer is probably fine. I just want to share an alternative approach.
.symfix
.sympath+ <your private symbols>
.reload
.exr -1
dp <parameter 1> L1
ln <result of dp>
dt <type of ln> <parameter 1>
It should look something like this (skipping the symbols parts):
0:000> .exr -1
ExceptionAddress: 7689c41f (KERNELBASE!RaiseException+0x00000058)
ExceptionCode: e06d7363 (C++ EH exception)
ExceptionFlags: 00000001
NumberParameters: 3
Parameter[0]: 19930520
Parameter[1]: 004bfb68
Parameter[2]: 003370b8
0:000> dp 004bfb68 L1
004bfb68 0f5cf1d0
0:000> ln 0f5cf1d0
(0f5cf1d0) MSVCR110D!std::exception::`vftable' | (0f5cf1d8) MSVCR110D!`string'
Exact matches:
MSVCR110D!std::exception::`vftable' = <no type information>
0:000> dt std::exception 004bfb68
SimpleCppCrash!std::exception
+0x000 __VFN_table : 0x0f5cf1d0
+0x004 _Mywhat : 0x0059f410 "Ouch: This application crashed because ..."
+0x008 _Mydofree : 1
If you have trouble with the symbols for MSVCRxxD, I found that a !analyze -v helps (I did not find out what that actually does to fix the problem).
Alternate Approach
$exr_param0,14 are PseudoRegisters for _EXCEPTION_RECORD->ExceptionInformation[15]
ExceptionInformation[2] is pExceptionObject
0:000> da poi($exr_param1+4)
0046ad00 "Oh noez!"
if you use the latest windbg drop you can use the Natvis Expression Evaluator
to view it like this
0:000> dx Debugger.State.DebuggerVariables.curprocess.Threads.First().Stack.Frames[1].LocalVariables.ThisException.params
Debugger.State.DebuggerVariables.curprocess.Threads.First().Stack.Frames[1].LocalVariables.ThisException.params [Type: EHExceptionRecord::EHParameters]
[+0x000] magicNumber : 0x19930520
[+0x004] pExceptionObject : 0x30f9a4 [Type: void *]
[+0x008] pThrowInfo : 0x133728 [Type: _s_ThrowInfo *]
or
0:000> ?? ((stdexcept!std::runtime_error *) #$exr_param1 )->_Data
struct __std_exception_data
+0x000 _What : 0x003dad00 "Oh noez!"
+0x004 _DoFree : 1
Related
Short Version
Application Verifier says there is an access violation when running the code:
var
shi: TShellExecuteInfo;
begin
shi := Default(TShellExecuteInfo);
shi.cbSize := SizeOf(TShellExecuteInfo);
shi.lpFile := PChar('C:\Windows');
ShellExecuteEx(#shi);
end;
What's wrong with it?
Long Version
I'm running my application under the Application Verifier, with the option to detect heap corruption enabled:
Heaps: Checks the heap errors.
During the call to ShellExecuteEx, an exception comes up, indicating that there is heap corruption.
Running inside a debugger allows me to decode the exception:
ExceptionAddress: 0000000074b254ad (KERNELBASE!ParseURLW+0x000000000000002d)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 0000000000000000
Parameter[1]: 0000000008e26fe8
Attempt to read from address 0000000008e26fe8
Running outside a debugger, the application crashes (WerFault takes a post-mortem and the process dies).
What is wrong with the code?
Example
program ShellExecuteTestApp;
{$APPTYPE CONSOLE}
uses
System.SysUtils,
Winapi.ShellAPI;
var
shi: TShellExecuteInfo;
begin
try
shi := Default(TShellExecuteInfo);
shi.cbSize := SizeOf(TShellExecuteInfo);
shi.lpFile := PChar('C:\Windows');
WriteLn('shi.cbSize: '+IntToStr(shi.cbSize));
WriteLn('shi.lpFile: "'+shi.lpFile+'"');
ShellExecuteEx(#shi);
except
on E: Exception do
Writeln(E.ClassName, ': ', E.Message);
end;
end.
Before crashing, it outputs:
shi.cbSize: 60
shi.lpFile: "C:\Windows"
I thought perhaps it was the common bug from CreateProcess, so i made sure the lpFile was writable:
var
file: string;
shi: TShellExecuteInfo;
begin
file := 'C:\Windows';
UniqueString({var} file);
shi := Default(TShellExecuteInfo);
shi.cbSize := SizeOf(TShellExecuteInfo);
shi.lpFile := PChar(file);
ShellExecuteEx(#shi);
end;
Memory dumps
Using a 32-bit build (to keep pointers easier to read), the memory being passed to ShellExecuteEx
00423EBC 0000003C cbSize 60 bytes
00000000 fMask SEE_MASK_DEFAULT
00000000 Wnd null
00000000 lpVerb null
0041C600 lpFile ==> 0x0041C60C
00000000 lpParameters null
00000000 lpDirectory null
00000001 nShow SW_NORMAL
00000000 hInstApp 0
00000000 lpIDList null
00000000 lpClass null
00000000 hkeyClass 0
00000000 dwHotKey 0
00000000 hMonitor null
00000000 hProcess null
With the one pointer to a wide char:
0041C60C 43 00 3A 00 5C 00 57 00 C.:.\.W.
0041C614 69 00 6E 00 64 00 6F 00 i.n.d.o.
0041C61C 77 00 73 00 00 00 00 00 w.s.....
It then calls:
ShellExecuteTestApp.dpr.29: ShellExecuteEx(#shi);
0041C51F 68BC3E4200 push $00423ebc ;push address of shi structure
0041C524 E85BD6FFFF call ShellExecuteEx ;call imported function
Winapi.ShellAPI.pas.1798: function ShellExecuteEx; external shell32 name 'ShellExecuteExW';
00419B84 FF250C444200 jmp dword ptr [$0042440c] ;jump to ShellExecuteW inside shell32
shell32.ShellExecuteExW:
75520060 8BFF mov edi,edi
75520062 55 push ebp
75520063 8BEC mov ebp,esp
75520065 83E4F8 and esp,-$08
75520068 51 push ecx
75520069 53 push ebx
7552006A 56 push esi
7552006B 8B7508 mov esi,[ebp+$08]
7552006E 57 push edi
7552006F 833E3C cmp dword ptr [esi],$3c
75520072 7540 jnz $755200b4
75520074 8B5E04 mov ebx,[esi+$04]
75520077 F7C300011000 test ebx,$00100100
7552007D 7427 jz $755200a6
7552007F 8BCE mov ecx,esi
75520081 E836000000 call $755200bc --> failure is this way
And then there's a lot of stuff i can't follow, until the error finally happens in ParseUrlW:
HRESULT ParseURL(
_In_ LPCTSTR pcszUrl,
_Inout_ PARSEDURL *ppu
);
with dump:
KERNELBASE.ParseURLW:
74B25480 8BFF mov edi,edi
74B25482 55 push ebp
74B25483 8BEC mov ebp,esp ;save stack pointer
74B25485 8B4508 mov eax,[ebp+$08] ;restore pcszUrl into EAX
74B25488 83EC0C sub esp,$0c
74B2548B 85C0 test eax,eax ;test that pcszUrl param supplied
74B2548D 0F8493010000 jz $74b25626
Note: At this moment EAX contains address 0x0908BFE8:
0908BFE8: 00 00 00 00 00 00 00 00 ........
The supplied pcszUrl string is empty? Actually no, the address is invalid. But we don't know that yet until the code tries to touch it
74B25493 57 push edi ;save EDI
74B25494 8B7D0C mov edi,[ebp+$0c] ;get PARSEDURL into edi
74B25497 85FF test edi,edi
74B25499 0F8410630300 jz $74b5b7af
Note: At this moment edi contains 0977FBDC
PARSEDURL structure
0977FBCD 00000018 cbSize 24 bytes
753F5BC0 pszProtocol [uninitialized junk]
0977FEC4 cchProtocol [uninitialized junk]
092ECFC8 pszSuffix [uninitialized junk]
78E6E41E cchSuffix [uninitialized junk]
0977FE98 nScheme [uninitialized junk]
74B2549F 833F18 cmp dword ptr [edi],$18 ;test that struct size is what we expect (24 bytes)
74B254A2 0F8507630300 jnz $74b5b7af
74B254A8 53 push ebx ;save ebx
74B254A9 8BD0 mov edx,eax ;save pcszUrl into edx
74B254AB 33DB xor ebx,ebx
74B254AD 0FB700 movzx eax,[eax] ;Attempt to copy 4 bytes of the string into EAX (access violation)
The code tries to copy the first word from 0x0908BFE8 using Move with Zero-Extend. But that address is invalid, giving the access violation:
access violation at 0x74b254ad: read of address 0x0908bfe8
So somewhere in the code of ShellExecuteExW, it sets up an invalid call to ParseUrlW.
WinDBG
32-bit WinDbg, debugging 32-bit application, with symbols:
*******************************************************************************
* *
* Exception Analysis *
* *
*******************************************************************************
*** ERROR: Module load completed but symbols could not be loaded for image00400000
FAULTING_IP:
KERNELBASE!ParseURLW+2d
74b254ad 0fb700 movzx eax,word ptr [eax]
EXCEPTION_RECORD: ffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 74b254ad (KERNELBASE!ParseURLW+0x0000002d)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000000
Parameter[1]: 07634fe8
Attempt to read from address 07634fe8
CONTEXT: 00000000 -- (.cxr 0x0;r)
eax=07634fe8 ebx=00000000 ecx=07634fe8 edx=07634fe8 esi=00000000 edi=093dfbdc
eip=74b254ad esp=093dfbb4 ebp=093dfbc8 iopl=0 nv up ei pl zr na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010246
KERNELBASE!ParseURLW+0x2d:
74b254ad 0fb700 movzx eax,word ptr [eax] ds:002b:07634fe8=????
FAULTING_THREAD: 00003ff4
DEFAULT_BUCKET_ID: INVALID_POINTER_READ
PROCESS_NAME: image00400000
ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%p referenced memory at 0x%p. The memory could not be %s.
EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%p referenced memory at 0x%p. The memory could not be %s.
EXCEPTION_PARAMETER1: 00000000
EXCEPTION_PARAMETER2: 07634fe8
READ_ADDRESS: 07634fe8
FOLLOWUP_IP:
shell32!GetUrlSchemeW+28
754c66be 85c0 test eax,eax
NTGLOBALFLAG: 2000100
APPLICATION_VERIFIER_FLAGS: 80000001
APP: image00400000
ANALYSIS_VERSION: 6.3.9600.17237 (debuggers(dbg).140716-0327) x86fre
PRIMARY_PROBLEM_CLASS: INVALID_POINTER_READ
BUGCHECK_STR: APPLICATION_FAULT_INVALID_POINTER_READ
LAST_CONTROL_TRANSFER: from 754c66be to 74b254ad
STACK_TEXT:
093dfbc8 754c66be 07634fe8 093dfbdc 00000000 KERNELBASE!ParseURLW+0x2d
093dfbf8 75522df8 0746fff0 07604f68 00000002 shell32!GetUrlSchemeW+0x28
093dfe98 75522b1a 093dfec4 00000000 0746fff0 shell32!CShellExecute::CreateParsingBindCtx+0x1d6
093dfecc 755224da 00000000 0746fff0 00000000 shell32!CShellExecute::ParseOrValidateTargetIdList+0x37
093dfef0 7551fd5a 093dff80 768b983a 07604f68 shell32!CShellExecute::_DoExecute+0x40
093dfef8 768b983a 07604f68 768b9770 768b9770 shell32!<lambda_e76b82c5cb7f9f82cbe0fd97ad5190bf>::<lambda_invoker_stdcall>+0x1a
093dff80 73d08484 0019fd94 73d08460 21439000 shcore!_WrapperThreadProc+0xca
093dff94 772c2fea 0019fd94 25ae5778 00000000 KERNEL32!BaseThreadInitThunk+0x24
093dffdc 772c2fba ffffffff 772dec22 00000000 ntdll!__RtlUserThreadStart+0x2f
093dffec 00000000 768b9770 0019fd94 00000000 ntdll!_RtlUserThreadStart+0x1b
STACK_COMMAND: .cxr 0x0 ; kb
SYMBOL_STACK_INDEX: 1
SYMBOL_NAME: shell32!GetUrlSchemeW+28
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: shell32
IMAGE_NAME: shell32.dll
DEBUG_FLR_IMAGE_TIMESTAMP: 0
FAILURE_BUCKET_ID: INVALID_POINTER_READ_c0000005_shell32.dll!GetUrlSchemeW
BUCKET_ID:
APPLICATION_FAULT_INVALID_POINTER_READ_shell32!GetUrlSchemeW+28
ANALYSIS_SOURCE: UM
FAILURE_ID_HASH_STRING: um:invalid_pointer_read_c0000005_shell32.dll!geturlschemew
FAILURE_ID_HASH: {89d9bcf0-5ef6-4e90-df6b-f05dc028e062}
Followup: MachineOwner
---------
Bonus Reading
Access Violation ShellExecute in delphi7
As #RaymondChen said, it's a bug in Windows 10.
I only encountered it because Application Verifier caught it.
it's a one-in-a-million chance that you'd actually ever encounter it in the wild
Raymond's too modest to accept reputation; so i use his answer as my own.
A code that has been running OK for years started to fail with an Access Violation in KernelBase.dll. I think that some Win10 upgrade must have changed something on that dll.
I found this Question and thanks to the comment of #David Heffernan I added the line
ExecInfo.lpParameters := '';
and that solved the problem.
var
ExecInfo: TShellExecuteInfo;
begin
ExecInfo.cbSize := SizeOf(ExecInfo);
ExecInfo.fMask := SEE_MASK_NOCLOSEPROCESS;
ExecInfo.Wnd := 0; // Handle;
ExecInfo.lpVerb := 'runas';
ExecInfo.lpFile := PChar(sPath + sFileName);
ExecInfo.lpDirectory := PChar(sPath);
ExecInfo.nShow := SW_HIDE;
ExecInfo.lpParameters := ''; //PJR#20210125 Added this line to avoid AccessViolation in KernelBase.dll due to a bug in some version of Win10.
if ShellExecuteEx(#ExecInfo) then
(...)
Even after giving correct PDB symbols I cant see stack trace where it can tell me function calls. Stack text only shows msvcr120. Also this crash occurs on customer machine only. I am wondering if something is missing wrt msvcr120 which we need to install. This is what I can see in windbg:
EXCEPTION_RECORD: ffffffffffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 00007fffc113dd27 (msvcr120+0x000000000006dd27)
ExceptionCode: c0000409 (Security check failure or stack buffer overrun)
ExceptionFlags: 00000001
NumberParameters: 1
Parameter[0]: 0000000000000005
CONTEXT: 0000000000000000 -- (.cxr 0x0;r)
rax=aaaaaaaaaaaaaaaa rbx=0000000000000000 rcx=aaaaaaaaaaaaaaaa
rdx=0000000000000000 rsi=0000000000000000 rdi=0000000000000000
rip=00007fffc113dd27 rsp=000000e40cd261c0 rbp=0000000000000000
r8=0000000000000000 r9=0000000000000000 r10=0000000000000000
r11=aaaaaaaaaaaaaaaa r12=000000e40c3076b0 r13=0000000000000000
r14=000000000000005c r15=000000e40c3051d0
iopl=0 nv up ei pl nz na pe nc
cs=0033 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000202
msvcr120+0x6dd27:
00007fff`c113dd27 cd29 int 29h
PROCESS_NAME: <removed>
ERROR_CODE: (NTSTATUS) 0xc0000409 - The system detected an overrun of a stack-based buffer in this application. This overrun could potentially allow a malicious user to gain control of this application.
EXCEPTION_CODE: (NTSTATUS) 0xc0000409 - The system detected an overrun of a stack-based buffer in this application. This overrun could potentially allow a malicious user to gain control of this application.
EXCEPTION_PARAMETER1: 0000000000000005
NTGLOBALFLAG: 0
APP: <removed>
ANALYSIS_VERSION: 6.3.9600.16384 (debuggers(dbg).130821-1623) amd64fre
FAULTING_THREAD: 0000000000005188
BUGCHECK_STR: APPLICATION_FAULT_INVALID_ARG_FAILURE_SEHOP
PRIMARY_PROBLEM_CLASS: INVALID_ARG_FAILURE_SEHOP
DEFAULT_BUCKET_ID: INVALID_ARG_FAILURE_SEHOP
LAST_CONTROL_TRANSFER: from 0000000000000000 to 00007fffc113dd27
STACK_TEXT:
000000e4`0cd261c0 00000000`00000000 : 00000000`00000000 00000000`00000000 aaaaaaaa`aaaaaaaa 00000000`00000000 : msvcr120+0x6dd27
STACK_COMMAND: ~5s; .ecxr ; kb
FOLLOWUP_IP:
msvcr120+6dd27
00007fff`c113dd27 cd29 int 29h
SYMBOL_STACK_INDEX: 0
SYMBOL_NAME: msvcr120+6dd27
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: msvcr120
IMAGE_NAME: msvcr120.dll
DEBUG_FLR_IMAGE_TIMESTAMP: 524f83ff
FAILURE_BUCKET_ID: INVALID_ARG_FAILURE_SEHOP_c0000409_msvcr120.dll!Unknown
BUCKET_ID: APPLICATION_FAULT_INVALID_ARG_FAILURE_SEHOP_msvcr120+6dd27
ANALYSIS_SOURCE: UM
FAILURE_ID_HASH_STRING: um:invalid_arg_failure_sehop_c0000409_msvcr120.dll!unknown
FAILURE_ID_HASH: {6c95a838-d91e-9c26-c623-f4edddde2886}
Followup: MachineOwner
---------
0:005> k
Child-SP RetAddr Call Site
000000e4`0cd261c0 00000000`00000000 msvcr120+0x6dd27
(Btw I have tried every possible suggestion I found to get stack trace on stackoverflow and other places before asking question)
Based on the output above, you do not have valid symbols for msvcr120. The first step is to try and get those. If you can't get the symbols, or you do get them and still can't get a good stack trace, then you should use dqs and try to manually walk the stack.
my problem is related and very similar to this one:
Analyzing Outlook HANG dump (with GoogleCalendarSync add-in installed)
The problem is, my addin seems to hang sometimes when a new mail arrives (at least that what it seems to happen, also based on the stack info below. The application log tells me something like "Cross Thread Deadlock". My addin is a managed VSTO addin.
Here is the hang dump analsis:
FAULTING_IP:
+0
00000000 ?? ???
EXCEPTION_RECORD: ffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 00000000
ExceptionCode: 80000007 (Wake debugger)
ExceptionFlags: 00000000
NumberParameters: 0
CONTEXT: 00000000 -- (.cxr 0x0;r)
eax=00000000 ebx=00000000 ecx=00000000 edx=00000000 esi=00bd7028 edi=00000000
eip=77bff8d1 esp=0044e44c ebp=0044e4b0 iopl=0 nv up ei pl zr na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00200246
ntdll!ZwWaitForSingleObject+0x15:
77bff8d1 83c404 add esp,4
BUGCHECK_STR: HANG
DEFAULT_BUCKET_ID: APPLICATION_HANG
PROCESS_NAME: OUTLOOK.EXE
ERROR_CODE: (NTSTATUS) 0xcfffffff - <Unable to get error code text>
EXCEPTION_CODE: (NTSTATUS) 0xcfffffff - <Unable to get error code text>
NTGLOBALFLAG: 0
APPLICATION_VERIFIER_FLAGS: 0
APP: outlook.exe
ANALYSIS_VERSION: 6.3.9600.16384 (debuggers(dbg).130821-1623) x86fre
MANAGED_STACK:
(TransitionMU)
0044EA3C 06019026 UNKNOWN!DomainBoundILStubClass.IL_STUB_CLRtoCOM(System.String, System.Object, System.Object)+0x1d6
(TransitionUM)
(TransitionMU)
0044EC2C 06018DD8 UNKNOWN!yasoonBase.Controller.Outlook.OutlookPersistenceSynchronizer.userStore_OnNewMail(System.String)+0x58
(TransitionUM)
(TransitionMU)
0044F01C 642F371D mscorlib_ni!System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(System.Object, System.Object[], System.Object[])+0x5d
0044F040 642EF8FA mscorlib_ni!System.Delegate.DynamicInvokeImpl(System.Object[])+0x76
0044F054 64AE1753 mscorlib_ni!System.Runtime.InteropServices.ComEventsMethod+DelegateWrapper.Invoke(System.Object[])+0x8f
0044F068 64AE08BB mscorlib_ni!System.Runtime.InteropServices.ComEventsMethod.Invoke(System.Object[])+0x2f
0044F080 64AE0194 mscorlib_ni!System.Runtime.InteropServices.ComEventsSink.System.Runtime.InteropServices.NativeMethods.IDispatch.Invoke(Int32, System.Guid ByRef, Int32, System.Runtime.InteropServices.ComTypes.INVOKEKIND, System.Runtime.InteropServices.ComTypes.DISPPARAMS ByRef, IntPtr, IntPtr, IntPtr)+0x168
0044F0C8 64951D11 mscorlib_ni!DomainNeutralILStubClass.IL_STUB_COMtoCLR(Int32, IntPtr, Int32, Int32, IntPtr, Int32, Int32, Int32)+0x29
(TransitionUM)
MANAGED_STACK_COMMAND: _EFN_StackTrace
DERIVED_WAIT_CHAIN:
Dl Eid Cid WaitType
-- --- ------- --------------------------
0 1d24.16e4 Event -->
54 1d24.1e20 SendMessage
WAIT_CHAIN_COMMAND: ~0s;k;;~54s;k;;
BLOCKING_THREAD: 00001e20
PRIMARY_PROBLEM_CLASS: APPLICATION_HANG
LAST_CONTROL_TRANSFER: from 76e0216b to 76df72b9
FAULTING_THREAD: 00000036
STACK_TEXT:
2a9bbd48 76e0216b 003e0fd8 0000c382 00000001 user32!NtUserMessageCall+0x15
2a9bbd88 76df96c5 022c5d90 00000000 25ecd700 user32!SendMessageWorker+0x3c6
2a9bbdac 25ecdaa0 003e0fd8 0000c382 00000001 user32!SendMessageW+0x7f
WARNING: Stack unwind information not available. Following frames may be wrong.
2a9bbdcc 18314b60 1d133da0 00000001 2a9bbe10 redemption!InitExtensionLibrary+0x4b31c
2a9bbdec 1832467f 00bd6ff0 00000001 2a9bbe10 PSTPRX32!PRXServiceEntry+0xdbaf
2a9bbe6c 18324485 2a9bc820 29e66080 00000005 PSTPRX32!PRXServiceEntry+0x1d6ce
2a9bbeb0 18323b3a 2a9bc820 e4c3e839 00000001 PSTPRX32!PRXServiceEntry+0x1d4d4
2a9bbee0 18325c83 2a9bc7e4 2a9bc7e4 00000000 PSTPRX32!PRXServiceEntry+0x1cb89
2a9bbef8 1831a506 00000000 2a9bc7e4 00000000 PSTPRX32!PRXServiceEntry+0x1ecd2
2a9bc740 1289e3c8 29e64ab4 2a9bc7e4 00000000 PSTPRX32!PRXServiceEntry+0x13555
2a9bc75c 1289a277 29e64ab4 2a9bc7e4 26bc23b8 OUTLMIME!CloseAllSockets+0xea20
2a9bc854 128999e7 2a9bc93c 00000fff 210428ad OUTLMIME!CloseAllSockets+0xa8cf
2a9bc8c0 12898d24 2a9bc93c 210428a2 2a9bc9ac OUTLMIME!CloseAllSockets+0xa03f
2a9bc8e8 1289c957 2a9bc93c 210428a2 2a9bc980 OUTLMIME!CloseAllSockets+0x937c
2a9bc98c 1289cc65 1802d2b8 00000003 2a9bc9ac OUTLMIME!CloseAllSockets+0xcfaf
2a9bcdbc 12896de5 00000005 26bc23c0 26e38f18 OUTLMIME!CloseAllSockets+0xd2bd
2a9bd254 12890bb7 00000005 00000005 00000003 OUTLMIME!CloseAllSockets+0x743d
2a9bd278 1289150b 00000005 00000003 26e38f18 OUTLMIME!CloseAllSockets+0x120f
2a9bd2b4 1289128c 00000000 1808dcc0 00000000 OUTLMIME!CloseAllSockets+0x1b63
2a9bf2d8 1288ffd6 00000000 00000401 26e38690 OUTLMIME!CloseAllSockets+0x18e4
2a9bf6fc 1289201a 00000401 00002bc4 00000001 OUTLMIME!CloseAllSockets+0x62e
2a9bf718 76df62fa 00580ad4 00000401 00002bc4 OUTLMIME!CloseAllSockets+0x2672
2a9bf744 76df6d3a 12891fd1 00580ad4 00000401 user32!InternalCallWinProc+0x23
2a9bf7bc 76df77c4 00000000 12891fd1 00580ad4 user32!UserCallWinProcCheckWow+0x109
2a9bf81c 76df7bca 12891fd1 00000001 2a9bfc8c user32!DispatchMessageWorker+0x3bc
2a9bf82c 1831beda 2a9bf844 00000001 29eb58c8 user32!DispatchMessageA+0xf
2a9bfc8c 0f598abc 29e64aa8 29eb58c8 1922eb58 PSTPRX32!PRXServiceEntry+0x14f29
2a9bfcb8 0f598a08 29eb5b80 1922eb58 26b13240 OLMAPI32!MemGetMalloc+0xbed
2a9bfcd4 655b5155 1922ebc8 26b13240 655ac3bb OLMAPI32!MemGetMalloc+0xb39
2a9bfd04 655ab3a2 2a9bfd74 2a9bfd58 00598790 MSO!Ordinal5372+0x66
2a9bfd1c 655a817f 2a9bfd74 00000000 00598790 MSO!Ordinal4578+0x1bc
2a9bfd50 655a6e0d 00000000 655a6e0d 2a9bfd74 MSO!Ordinal630+0x18ed
2a9bfda4 756a336a 00598790 2a9bfdf0 77c19f72 MSO!Ordinal630+0x57b
2a9bfdb0 77c19f72 00598790 5671c62f 00000000 kernel32!BaseThreadInitThunk+0xe
2a9bfdf0 77c19f45 655a6db4 00598790 ffffffff ntdll!__RtlUserThreadStart+0x70
2a9bfe08 00000000 655a6db4 00598790 00000000 ntdll!_RtlUserThreadStart+0x1b
FOLLOWUP_IP:
redemption!InitExtensionLibrary+4b31c
25ecdaa0 c3 ret
SYMBOL_STACK_INDEX: 3
SYMBOL_NAME: redemption!InitExtensionLibrary+4b31c
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: redemption
IMAGE_NAME: redemption.dll
DEBUG_FLR_IMAGE_TIMESTAMP: 52791e66
STACK_COMMAND: ~54s ; kb
BUCKET_ID: HANG_redemption!InitExtensionLibrary+4b31c
FAILURE_BUCKET_ID: APPLICATION_HANG_cfffffff_redemption.dll!InitExtensionLibrary
ANALYSIS_SOURCE: UM
FAILURE_ID_HASH_STRING: um:application_hang_cfffffff_redemption.dll!initextensionlibrary
FAILURE_ID_HASH: {c9d67d3f-8e85-921b-11e8-c7a8dfc70981}
Followup: MachineOwner
The OnNewMail event handler does not very much imho:
void userStore_OnNewMail(string entryID)
{
//Get mail from store & raise event
RDOMail mail = mapiSession.GetMessageFromID(entryID, this.storeEntryId);
var args = new MailEventArguments(mail, ChangeType.New);
this.eventPublisher.RaiseEvent(new MailEvent(args));
}
One thing I noticed - This seems to happen especially on non-default Outlook stores, though this event is not expected to be fired on non-default stores anyway...
What I'm trying to understand, what is the other thread which blocks this one, is there any possibility to get that information?
Any feedback would be highly appreciated ...
Thanks!
I'm tracing dmp file which seems like crashed calling virtual function of broken object instance.
it seems that vft of the broken object pointer pointed wrong address(0x3822a497) and program crashed immediately after call edx to 0x3822a497 (LAST_CONTROL_TRANSFER: from 00ccde67 to 3822a497), and instruction pointer (EIP) couldn't even go one step further. then, shouldn't it be edx=0x3822a497? but both Visual Studio and Windbg indicates edx=0x1e4dcc0.
Can somebody explain how could it happen?
EDIT: I trusted LAST_CONTROL_TRANSFER too much, but still mystery exists. please first see updated suppositions 1,2,3 below and give me a possible scenario.
Result of windbg !analyze -v
Failed calling InternetOpenUrl, GLE=12029
FAULTING_IP:
+8cde67
3822a497 006e00 add byte ptr [esi],ch
EXCEPTION_RECORD: ffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 3822a497
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000001
Parameter[1]: 0138d2cc
Attempt to write to address 0138d2cc
PROCESS_NAME: DDD.exe
ADDITIONAL_DEBUG_TEXT:
Use '!findthebuild' command to search for the target build information.
If the build information is available, run '!findthebuild -s ; .reload' to set symbol path and load symbols.
FAULTING_MODULE: 76df0000 kernel32
DEBUG_FLR_IMAGE_TIMESTAMP: 518275c9
MODULE_NAME: DDD
ERROR_CODE: (NTSTATUS) 0xc0000005 - 0x%08lx
EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - 0x%08lx
EXCEPTION_PARAMETER1: 00000001
EXCEPTION_PARAMETER2: 0138d2cc
WRITE_ADDRESS: 0138d2cc
FOLLOWUP_IP:
DDD+8cde67
00ccde67 ?? ???
FAILED_INSTRUCTION_ADDRESS:
+591b2faf0239d8f4
3822a497 006e00 add byte ptr [esi],ch
MOD_LIST: <ANALYSIS/>
FAULTING_THREAD: 00000650
BUGCHECK_STR: APPLICATION_FAULT_BAD_INSTRUCTION_PTR_INVALID_POINTER_WRITE_WRONG_SYMBOLS
PRIMARY_PROBLEM_CLASS: BAD_INSTRUCTION_PTR
DEFAULT_BUCKET_ID: BAD_INSTRUCTION_PTR
LAST_CONTROL_TRANSFER: from 00ccde67 to 3822a497
STACK_TEXT:
WARNING: Frame IP not in any known module. Following frames may be wrong.
0018cfe0 00ccde67 1a75cb52 00000000 28e86c00 0x3822a497
0018cfe4 1a75cb52 00000000 28e86c00 00000011 DDD+0x8cde67
0018cfe8 00000000 28e86c00 00000011 29b52260 0x1a75cb52
STACK_COMMAND: ~0s; .ecxr ; kb
SYMBOL_STACK_INDEX: 1
SYMBOL_NAME: DDD+8cde67
FOLLOWUP_NAME: MachineOwner
IMAGE_NAME: DDD.exe
BUCKET_ID: WRONG_SYMBOLS
FAILURE_BUCKET_ID: BAD_INSTRUCTION_PTR_c0000005_DDD.exe!Unknown
WATSON_STAGEONE_URL: http://watson.microsoft.com/...
Followup: MachineOwner
---------
0:000>
Result of windbg .excr
0:000> .ecxr
eax=0018d0c8 ebx=78b3b6a8 ecx=00cddb00 edx=01e4dcc0 esi=0138d2cc edi=0018cfc8
eip=3822a497 esp=0018cfe4 ebp=00000002 iopl=0 nv up ei ng nz na po nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00210282
3822a497 006e00 add byte ptr [esi],ch ds:002b:0138d2cc=??
Result of windbg r
Last set context:
eax=0018d0c8 ebx=78b3b6a8 ecx=00cddb00 edx=01e4dcc0 esi=0138d2cc edi=0018cfc8
eip=3822a497 esp=0018cfe4 ebp=00000002 iopl=0 nv up ei ng nz na po nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00210282
3822a497 006e00 add byte ptr [esi],ch ds:002b:0138d2cc=??
Disassembly before LAST_CONTROL_TRANSFER: from 00ccde67 to 3822a497
current_time = timeGetTime();
00CCDE34 call dword ptr [__imp__timeGetTime#0 (17EE5FCh)]
(*it)->proc();
00CCDE3A mov eax,dword ptr [ebx]
00CCDE3C test eax,eax
00CCDE3E je 00CCDFFE
00CCDE44 test edi,edi
00CCDE46 je 00CCDFFE
00CCDE4C cmp dword ptr [eax+4],edi
00CCDE4F ja 00CCDFFE
00CCDE55 cmp edi,dword ptr [eax+8]
00CCDE58 jae 00CCDFFE
00CCDE5E mov ecx,dword ptr [edi]
00CCDE60 mov eax,dword ptr [ecx]
00CCDE62 mov edx,dword ptr [eax+0Ch]
00CCDE65 call edx
00CCDE67 push 0
EDIT
Oh I forgot to put stack state.
stack (esp=0x18cfe4)
0x0018CFA4 00000000 00000000 00000000 00000000 ................
0x0018CFB4 00000000 00000000 00000000 00000000 ................
0x0018CFC4 00000000 fffffd34 000002e4 fffffd34 ....4?..?...4?..
0x0018CFD4 000002cc 00000019 00000000 0018d0c8 ?...........??..
0x0018CFE4 >00ccde67 1a75cb52 00000000 28e86c00 g??.R?u......l?(
0x0018CFF4 00000011 29b52260 00000000 78b3c718 ....`"?).....??x
0x0018D004 29b522a0 00000000 78b3b6ac 29b522a0 ?"?)....???x?"?)
0x0018D014 00000000 78b3b6a8 1a75cb52 00000140 ....???xR?u.#...
0x0018D024 01e4f688 1a75cb52 0018d050 0170d884 ???.R?u.P?..??p.
0x0018D034 ffffffff 0018d05c 0098ec41 1a75cb36 ....\?..A??.6?u.
Disassembly around eip (0x3822A497)
3822A490 54 push esp
3822A491 00 db 00h
3822A492 65 db 65h
3822A493 00 72 00 add byte ptr [edx],dh
3822A496 61 popad
3822A497 00 6E 00 add byte ptr [esi],ch
3822A49A 69 00 74 00 65 00 imul eax,dword ptr [eax],650074h
Memory dump around eip (0x3822A497)
0x3822A480 55da14f5 80000000 00001e08 00000024 ?.?U........$...
0x3822A490 00650054 00610072 0069006e 00650074 T.e.r.a.n.i.t.e.
0x3822A4A0 004e0020 00630065 006c006b 00630061 .N.e.c.k.l.a.c.
0x3822A4B0 00000065 4d747cba 55da14f2 80000000 e...?|tM?.?U....
Obviously this is not valid instructions but wide characters text.
I think it is very likely that callee broke edx information as xwlan said.
( And I thought LAST_CONTROL_TRANSFER is some kind of trustful information. It was just displaying last callstack entry to eip )
But my suppositions still don't make a sense. Can somebody make a scenario that makes sense?
Suppose 1: instruction jumped before 0x3822A497 and executed popad
I think this makes most sense. (e.g. could jumped by some indirection jump/call to pointer to text buffer 0x3822A490)
If so, popad would executed, which pops EDI, ESI, EBP, EBX, EDX, ECX, and EAX from stack.
Then why can't I find these register's values from stack?
For example, if so, shouldn't I see 0x00000002 (ebp), 0x01e4dcc0 (edx) from stack near 0x0018CFE4 (esp)?
Suppose 2: callee was not 0x3822A497 , instruction jumped exactly to 0x3822A497
I think it is very rare case.
If jump was by indirect call/jmp, nothing would pointed to 0x3822A497 which is odd number,
If jump was by relative call/jmp, the call instruction would be near 0x3822A497,
but I can't find such a relative calls when I disassembly from every point near 0x3822A497
and because it has ##, 00, ##, 00, ## pattern of wide character text,
most possible jump instruction jumps to next instruction pointer, for example:
3822A494 72 00 > jb 3822A496
3822A496 61 popad
3822A497 00 6E 00 add byte ptr [esi],ch
Suppose 3: Callee was 0x3822A497
then why edx is not 0x3822A497. (First question)
You're putting too much faith in the call stack, you're likely missing a frame here (probably some sort of FPO related artifact). I suspect that EDX wasn't the bad EIP, it held the address of a valid function that eventually set up the invalid EIP.
If I were you, I would reconstruct EDX at the time of the crash and see what function it is. Then you can try to figure out what that function might have done to trash EIP (probably a stack overflow). If you're feeling lucky/lazy, you could hope that EDX has stayed unmolested and see what, "uf #edx" gets you.
look like stack corruption, "esp=0018cfe4 ebp=00000002", ebp is apparently a bad value.
i'd suggest check the code "00CCDE65 call edx", the edx looks like point to a virtual function, this function and its callee corrupt the stack. dds esp in windbg can help to dump current stack memory to check whether there's any suspicious values, e.g. any string?
Since I started using outlook with GoogleCalendarSync i'm experiencing hangs every once in awhile.
I used ADPlus to create a hang dump of the process (using adplus -hang -pn outlook.exe -o c:\dumps).
When I read the dump via WinDBG I use the command !analyze -v -hang, but I can't figure out what exactly went wrong.
The output of the command is:
*******************************************************************************
* *
* Exception Analysis *
* *
*******************************************************************************
FAULTING_IP:
+1d32faf00ffdf58 00000000 ?? ???
EXCEPTION_RECORD: ffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 00000000 ExceptionCode: 80000007 (Wake debugger)
ExceptionFlags: 00000000 NumberParameters: 0
BUGCHECK_STR: HANG
PROCESS_NAME: OUTLOOK.EXE
ERROR_CODE: (NTSTATUS) 0xcfffffff - <Unable to get error code text>
EXCEPTION_CODE: (NTSTATUS) 0xcfffffff - <Unable to get error code
text>
MOD_LIST: <ANALYSIS/>
NTGLOBALFLAG: 0
APPLICATION_VERIFIER_FLAGS: 0
MANAGED_STACK: !dumpstack -EE OS Thread Id: 0xd60 (37) Current frame:
ChildEBP RetAddr Caller,Callee
DERIVED_WAIT_CHAIN:
Dl Eid Cid WaitType
-- --- ------- -------------------------- 0 ba0.6a4 Thread Handle --> 37 ba0.d60 Event
WAIT_CHAIN_COMMAND: ~0s;k;;~37s;k;;
BLOCKING_THREAD: 00000d60
DEFAULT_BUCKET_ID: APPLICATION_HANG_BlockedOn_EventHandle
PRIMARY_PROBLEM_CLASS: APPLICATION_HANG_BlockedOn_EventHandle
LAST_CONTROL_TRANSFER: from 7c90df5a to 7c90e514
FAULTING_THREAD: 00000025
STACK_TEXT: 11f3f764 7c90df5a 7c8025db 00000458 00000000
ntdll!KiFastSystemCallRet 11f3f768 7c8025db 00000458 00000000 00000000
ntdll!NtWaitForSingleObject+0xc 11f3f7cc 7c802542 00000458 ffffffff
00000000 kernel32!WaitForSingleObjectEx+0xa8 11f3f7e0 77520197
00000458 ffffffff 00192888 kernel32!WaitForSingleObject+0x12 11f3f7fc
77602e50 00192888 001a3ab8 00000000 ole32!GetToSTA+0x6f 11f3f81c
7760208a 11f3f8e4 11f3f9f4 09b148b8
ole32!CRpcChannelBuffer::SwitchAptAndDispatchCall+0xf6 11f3f8fc
7752c982 09b148b8 11f3f9f4 11f3f9e4
ole32!CRpcChannelBuffer::SendReceive2+0xc8 11f3f968 7752c91a 09b148b8
11f3f9f4 11f3f9e4 ole32!CAptRpcChnl::SendReceive+0xab 11f3f9bc
77ef5db5 09b148b8 11f3f9f4 11f3f9e4
ole32!CCtxComChnl::SendReceive+0x113 11f3f9d8 77ef5ead 09b22354
11f3fa20 0600015b rpcrt4!NdrProxySendReceive+0x43 11f3fdbc 77ef5e42
774e6228 774e92da 11f3fdf4 rpcrt4!NdrClientCall2+0x1fa 11f3fddc
77e88519 00000010 00000005 11f3fe04 rpcrt4!ObjectStublessClient+0x8b
11f3fdec 7752d919 09b22354 00000001 145bf7b8 rpcrt4!ObjectStubless+0xf
11f3fe04 7752d8ba 09b22354 00192888 00000001
ole32!RemoteReleaseRifRefHelper+0x84 11f3fe2c 7752c558 09b22354
00192888 00000001 ole32!RemoteReleaseRifRef+0x74 11f3fe84 7752c351
0e8a3cfc 0e8a3cf8 00000000 ole32!CStdMarshal::DisconnectCliIPIDs+0x200
11f3feac 7750c880 00000002 0e8a3da0 0e8a3cf8
ole32!CStdMarshal::Disconnect+0x178 11f3fec8 7750c7ed 0e8a3cf8
11f3fee8 7750c967 ole32!CStdIdentity::~CStdIdentity+0x89 11f3fed4
7750c967 00000001 00440023 00520006 ole32!CStdIdentity::`vector
deleting destructor'+0xd 11f3fee8 77ef5ae8 80000000 11f3ff00 1112f31b
ole32!CStdIdentity::CInternalUnk::Release+0x4c 11f3fef4 1112f31b
0e8bd1fc 11f3ff14 1112a0e4 rpcrt4!IUnknown_Release_Proxy+0x11 WARNING:
Stack unwind information not available. Following frames may be wrong.
11f3ff00 1112a0e4 11f3ff80 00000000 11f3ff80 GoogleCalendarSync+0xf31b
11f3ff14 1112a0b1 00000000 11f3ff80 11f3ffb4 GoogleCalendarSync+0xa0e4
11f3ff24 11137c5e 555047c9 00020048 80578cb2 GoogleCalendarSync+0xa0b1
11f3ffb4 7c80b729 00000301 00440023 00520006
GoogleCalendarSync+0x17c5e 11f3ffec 00000000 111378c0 00000301
00000000 kernel32!BaseThreadStart+0x37
FOLLOWUP_IP: GoogleCalendarSync+f31b 1112f31b 8b5508 mov
edx,dword ptr [ebp+8]
SYMBOL_STACK_INDEX: 15
SYMBOL_NAME: GoogleCalendarSync+f31b
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: GoogleCalendarSync
IMAGE_NAME: GoogleCalendarSync.dll
DEBUG_FLR_IMAGE_TIMESTAMP: 4d9f0466
STACK_COMMAND: ~37s ; kb
BUCKET_ID: HANG_GoogleCalendarSync+f31b
WATSON_IBUCKET: -1362224887
WATSON_IBUCKETTABLE: 1
FAILURE_BUCKET_ID:
APPLICATION_HANG_BlockedOn_EventHandle_cfffffff_GoogleCalendarSync.dll!Unknown
WATSON_STAGEONE_URL:
http://watson.microsoft.com/StageOne/OUTLOOK_EXE/14_0_6117_5001/4f3e2d20/unknown/0_0_0_0/bbbbbbb4/cfffffff/00000000.htm?Retriage=1
Followup: MachineOwner
---------------------------
How can I further investigate this dump? What am I missing?
The thread GoogleCalendarSync is operating in tries to Release a COM object whose apartement model is STA, that is the object lives in a single thread. This kind of object was very popular in the begining of COM, because the COM layer ensures the object won't be accessed from multiple threads in the same time, thus avoiding adding synchronization code in the object implementation.
You can grab the first parameter of GetToSTA (0x00192888 in this case), dump the contents of the memory at this address (dc 0x00192888). In the result, skip the first 2 DWORD : next DWORD should be the target process ID and next one the target thread ID. This target thread is likely to be already blocked in another operation (refer to http://blogs.msdn.com/b/tess/archive/2008/06/12/asp-net-case-study-deadlock-waiting-in-gettosta.aspx if you need a real life example).