c# - Wpf application hang on main thread without obvious locks -
i have peculiar response windbg. i've got hang in wpf application , collected dump file. when run command "!analyze -v -hang" have following response.
bugcheck_str: hang default_bucket_id: application_hang_self process_name: tis.shell.exe error_code: (ntstatus) 0xcfffffff - <unable error code text> exception_code: (ntstatus) 0xcfffffff - <unable 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: 75a315f7 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
we can see primary problem class is: application_hang_self, , main thread waiting on handle owned main thread. other threads waiting main. no other blocking locks, critical section, mutexes etc... thread state of main is:
!threadstate 00000ef0 gc on transitions legal join yield requested hijacked gc background unstarted dead
top of stack on main thread goes:
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
my question is: how can be? kind of kernel or cross-process hang, , how can confirm it? note hang analysis marks windowsbase_ni faulty module. tried google application_hang_self no luck.
it's not lock problem, , it's not main thread hanging (technically).
the stack shows you're trying thread.join() part of rcw::initialize.
so thread sleeping , waiting thread.join() finish.
techinically it's other thread should looking at. reason it's not finishing.
Comments
Post a Comment