分析Outlook HANG转储(安装了GoogleCalendarSync加载项) [英] Analyzing Outlook HANG dump (with GoogleCalendarSync add-in installed)
问题描述
自从我开始将Outlook与GoogleCalendarSync结合使用以来，我偶尔会遇到挂起的情况.
我使用ADPlus创建了该进程的挂起转储(使用adplus -hang -pn outlook.exe -o c:\dumps).
当我通过WinDBG读取转储时，我使用命令!analyze -v -hang，但是我无法弄清楚到底出了什么问题.
该命令的输出为:
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?
推荐答案
正在运行的线程GoogleCalendarSync试图释放其分离模型为STA的COM对象，即该对象位于单个线程中.这种对象在COM的开始阶段就很流行，因为COM层可确保不会同时从多个线程访问该对象，从而避免在对象实现中添加同步代码.
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.
您可以获取GetToSTA的第一个参数(在这种情况下为0x00192888)，将内存的内容转储到该地址(dc 0x00192888).结果，跳过前两个DWORD:下一个DWORD应该是目标进程ID，下一个是目标线程ID.此目标线程可能已在另一操作中被阻止(请参阅
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).
这篇关于分析Outlook HANG转储(安装了GoogleCalendarSync加载项)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
