outlook - 分析 Outlook HANG 转储(安装了 GoogleCalendarSync 插件)

Question

自从我开始将 Outlook 与 GoogleCalendarSync 结合使用以来，我时不时就会遇到挂起的情况。我使用 ADPlus 创建进程的挂起转储(使用 adplus -hang -pn Outlook.exe -o c:\dumps )。当我通过 WinDBG 读取转储时，我使用命令 !analyze -v -hang，但我无法弄清楚到底出了什么问题。该命令的输出是:

*******************************************************************************
*                                                                             *
*                        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
---------------------------

我如何进一步调查此转储？我错过了什么？

Answer 1

GoogleCalendarSync 正在运行的线程尝试释放一个公寓模型为 STA 的 COM 对象，即该对象位于单个线程中。这种对象在COM诞生之初非常流行，因为COM层保证了该对象不会同时被多个线程访问，从而避免了在对象实现中添加同步代码。

你可以抓取GetToSTA的第一个参数(本例中为0x00192888)，转储该地址(dc 0x00192888)处的内存内容。在结果中，跳过前 2 个 DWORD:下一个 DWORD 应该是目标进程 ID，下一个 DWORD 应该是目标线程 ID。该目标线程可能已在另一个操作中被阻止(如果您需要实际示例，请参阅 http://blogs.msdn.com/b/tess/archive/2008/06/12/asp-net-case-study-deadlock-waiting-in-gettosta.aspx)。