Wpf 应用程序在没有明显锁定的情况下挂在主线程上

Question

我收到 WinDbg 的特殊响应。我已经挂在 wpf 应用程序中并收集了转储文件。当我运行命令“!analyze -v -hang”时，我有以下响应。

BUGCHECK_STR:  HANG

DEFAULT_BUCKET_ID:  APPLICATION_HANG_SELF

PROCESS_NAME:  Tis.Shell.exe

ERROR_CODE: (NTSTATUS) 0xcfffffff - <Unable to get error code text>

EXCEPTION_CODE: (NTSTATUS) 0xcfffffff - <Unable to get error code text>

NTGLOBALFLAG:  200 

DERIVED_WAIT_CHAIN:  

Dl Eid Cid     WaitType
-- --- ------- --------------------------
   0   fc8.ef0 Thread Handle          (Self) 

WAIT_CHAIN_COMMAND:  ~0s;k;;

BLOCKING_THREAD:  00000ef0

PRIMARY_PROBLEM_CLASS:  APPLICATION_HANG_SELF

LAST_CONTROL_TRANSFER:  from 75a315f7 to 77bb015d

FOLLOWUP_IP: 
WindowsBase_ni+e1c98
72ff1c98 c6460801        mov     byte ptr [esi+8],1

SYMBOL_STACK_INDEX:  3

SYMBOL_NAME:  windowsbase_ni+e1c98

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: WindowsBase_ni

IMAGE_NAME:  WindowsBase.ni.dll

DEBUG_FLR_IMAGE_TIMESTAMP:  52313189

STACK_COMMAND:  ~0s ; kb

BUCKET_ID:  HANG_windowsbase_ni+e1c98

FAILURE_BUCKET_ID:  APPLICATION_HANG_SELF_cfffffff_WindowsBase.ni.dll!Unknown

ANALYSIS_SOURCE:  UM

FAILURE_ID_HASH_STRING:  um:application_hang_self_cfffffff_windowsbase.ni.dll!unknown

FAILURE_ID_HASH:  {b32a7311-97ad-f51e-943e-db0acf2773fa}

Followup: MachineOwner

我们可以看到主要问题 class 是：APPLICATION_HANG_SELF，主线程正在等待主线程拥有的句柄。其他线程只是在等待 main。没有其他阻塞锁、临界区、互斥锁等…… main 的线程状态为：

!ThreadState 00000ef0
    GC On Transitions
    Legal to Join
    Yield Requested
    Hijacked by the GC
    Background
    Unstarted
    Dead

主线程的栈顶是：

STACK_TEXT:  
002e0b5c 75a315f7 00000001 002e0bac 00000001 ntdll!ZwWaitForMultipleObjects+0x15
002e0bf8 75ed19f8 002e0bac 002e0c20 00000000 KERNELBASE!WaitForMultipleObjectsEx+0x100
002e0c40 72ff1c98 00000001 7efde000 00000000 kernel32!WaitForMultipleObjectsExImplementation+0xe0
002e0c90 72fe49f2 00000000 00000001 00000000 WindowsBase_ni+0xe1c98
002e0ca8 72fcb91d 00000000 00000001 00000000 WindowsBase_ni+0xd49f2
002e0cc0 6cebcf5a 00000001 00000000 002e0ce4 WindowsBase_ni+0xbb91d
002e0cd0 6db63de2 00000001 00000000 006d0bd8 mscorlib_ni+0x38cf5a
002e0ce4 6db73315 002e0d8c 002e0d28 6dcb2c66 clr!CallDescrWorkerInternal+0x34
002e0d38 6db76cdf 002e0e28 00000000 00000004 clr!CallDescrWorkerWithHandler+0x6b
002e0dc0 6dc0d8d4 002e0e5c 00f6c713 00000001 clr!MethodDescCallSite::CallTargetWorker+0x152
002e0ea0 6dbf0a64 002e0ed8 00000001 002e0fd8 clr!Thread::DoSyncContextWait+0xb4
002e0f30 6dccc90c 00000001 002e0fd8 00000000 clr!Thread::DoAppropriateWaitWorker+0x100
002e0f9c 6dc5ea37 00000001 002e0fd8 00000000 clr!Thread::DoAppropriateWait+0x64
002e0fec 6dc5eae1 00000001 006d0bd8 00f6ddd3 clr!Thread::JoinEx+0xc2
002e1460 6dc16962 1996a760 00000ebd 6ceff040 clr!RCW::Initialize+0x3ba
002e14a4 6dc169e9 00000000 6ceff040 00f6dd6f clr!RCW::CreateRCWInternal+0xd6
002e14dc 6dc1656d 00000000 6ceff040 00f6dcdb clr!RCW::CreateRCW+0x2b
002e1568 6dc16c4e 00000000 002e1594 002e16bc clr!COMInterfaceMarshaler::CreateObjectRef+0xb7
002e1630 6dc15a78 002e16bc 72fff7c0 00000000 clr!COMInterfaceMarshaler::FindOrCreateObjectRefInternal+0x272
002e1b00 6dc15c6f 00000000 72fff7c0 00000000 clr!GetObjectRefFromComIP+0x40b
002e1b20 6dc15bcc 72fff7c0 00000000 00000000 clr!UnmarshalObjectFromInterface+0x3c
002e1bc4 73147126 00000000 00000000 6b212854 clr!StubHelpers::InterfaceMarshaler__ConvertToManaged+0xeb
002e1bf8 6db6421e 199bbe40 96a76000 002e1e18 WindowsBase_ni+0x237126
002e1c20 6dbf6fbf 73147100 6b212854 002e1cb4 clr!COMToCLRDispatchHelper+0x6b
002e1c8c 76392d7f 1996a820 1996a760 00000000 clr!COMToCLRWorker+0x3e6
002e1cd8 76393ce0 00000001 00000002 1996a77c msctf!CInputContext::_NotifyEndEdit+0x13b
002e1ce8 76392c61 00000002 002e1d2c 00000002 msctf!CInputContext::_SynchAppChanges+0x76
002e1d00 76392c21 1996a77c 00000002 00000000 msctf!CInputContext::OnLockGranted+0x3d
002e1d18 7314b96f 199b6c24 00000002 00da93b2 msctf!CACPWrap::OnLockGranted+0x7d
002e1d80 6bbd30bd 1ae292ec 1ae292ec 002e1dd0 WindowsBase_ni+0x23b96f
002e1d90 6bbd2ef8 170f8f78 170f8f14 1ae292ec PresentationFramework_ni+0xd330bd
002e1dd0 6b21291a 00000008 00000000 0c77c468 PresentationFramework_ni+0xd32ef8
002e1de4 731534ba 002e1f08 6b2128b4 002e1f4c PresentationFramework_ni+0x37291a
002e1e0c 6db6421e 002e1f08 002ef1d8 6dcbff59 WindowsBase_ni+0x2434ba
002e1e30 6dbf6fbf 731534a4 6b2128b4 002e1ec8 clr!COMToCLRDispatchHelper+0x6b
002e1ea0 76392e3d 002e1f34 199b6c20 1b14978c clr!COMToCLRWorker+0x3e6
002e1ed4 76392e11 199b6c20 00000002 002e1f08 msctf!CACPWrap::RequestLock+0x17
002e1ef0 763a1cd4 199b6c20 00000002 002e1f08 msctf!SafeRequestLock+0x1c
002e1f0c 763a1c94 00000001 002e1f24 763a1c6c msctf!CInputContext::_OnSelectionChangeInternal+0x3a
002e1f18 763a1c6c 1996a77c 002e1f84 72fec378 msctf!CInputContext::OnSelectionChange+0x22
002e1f24 72fec378 199b6c24 00da93b2 6db6abc8 msctf!CACPWrap::OnSelectionChange+0x1e
002e1f84 6bbd2374 002e1fa0 6bde4a15 1b14978c WindowsBase_ni+0xdc378
002e1f8c 6bde4a15 1b14978c 170f9174 002e1fcc PresentationFramework_ni+0xd32374
002e1fa0 6b1e29dc 00000000 170f9174 00000001 PresentationFramework_ni+0xf44a15

我的问题是：这怎么可能？这是某种内核或跨进程挂起，我如何确认？请注意，挂起分析将 WindowsBase_ni 标记为故障模块。尝试 google APPLICATION_HANG_SELF 但没有成功。

Answer 1

不是锁的问题，也不是主线程挂了（技术上）。

堆栈显示您正在尝试执行 thread.Join() 作为 RCW::Initialize 的一部分.

所以线程正在休眠并等待 thread.join() 完成。
所以从技术上讲，这是您应该查看的其他线程。由于某种原因，它没有完成。

Wpf 应用程序在没有明显锁定的情况下挂在主线程上

Wpf application hang on main thread without obvious locks

c#

wpf

multithreading

windbg

freeze