分析Outlook HANG转储(安装了GoogleCalendarSync加载项)

时间:2012-10-22 09:24:25

标签: outlook windbg dump hang

自从我开始在GoogleCalendarSync中使用outlook时,我偶尔会遇到挂起。 我使用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
---------------------------

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

1 个答案:

答案 0 :(得分:2)

GoogleCalendarSync正在运行的线程尝试释放其对象模型为STA的COM对象,即对象位于单个线程中。这种对象在COM的开头非常流行,因为COM层确保不会同时从多个线程访问对象,从而避免在对象实现中添加同步代码。

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