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

Popular posts from this blog

c++ - Difference between pre and post decrement in recursive function argument -

php - Nothing but 'run(); ' when browsing to my local project, how do I fix this? -

php - How can I echo out this array? -