0

I have a larger .NET Application where I get impossible stack traces of the form

...
System.Windows.Forms.Control.OnParentVisibleChanged(System.EventArgs)                                                                   
System.Windows.Forms.Control.OnVisibleChanged(System.EventArgs)                                                                         
System.Windows.Forms.Control.WmShowWindow(System.Windows.Forms.Message ByRef)                                                           
System.Windows.Forms.Control.WndProc(System.Windows.Forms.Message ByRef)                                                                
System.Windows.Forms.NativeWindow.Callback(IntPtr, Int32, IntPtr, IntPtr)                                                               
DomainBoundILStubClass.IL_STUB_ReversePInvoke(Int64, Int32, Int64, Int64)                                                               
MS.Win32.UnsafeNativeMethods.CallWindowProc(IntPtr, IntPtr, Int32, IntPtr, IntPtr)                                                      
MS.Win32.HwndSubclass.SubclassWndProc(IntPtr, Int32, IntPtr, IntPtr)                                                                    
System.Threading.Monitor.Enter(System.Object) 
...

The Win32 Stack looks like this

...
System_Windows_Forms_ni+0x9e89d2
clr!UMThunkStub+0x6e
user32!UserCallWinProcCheckWow+0x2f8
user32!CallWindowProcW+0x8e
WindowsBase_ni+0x1632e2
WindowsBase_ni+0x323e42
clr!UMThunkStub+0x6e
user32!UserCallWinProcCheckWow+0x2f8
user32!DispatchClientMessage+0x9c
user32!_fnDWORD+0x33
ntdll!KiUserCallbackDispatcherContinue
win32u!NtUserPeekMessage+0x14
user32!_PeekMessage+0x43
user32!PeekMessageW+0x143
combase!CCliModalLoop::MyPeekMessage+0x53 [onecore\com\combase\dcomrem\callctrl.cxx @ 2925] 
combase!CCliModalLoop::PeekRPCAndDDEMessage+0x49 [onecore\com\combase\dcomrem\callctrl.cxx @ 2607] 
combase!CCliModalLoop::BlockFn+0x2c5 [onecore\com\combase\dcomrem\callctrl.cxx @ 2103] 
combase!ClassicSTAThreadWaitForHandles+0xa5 [onecore\com\combase\dcomrem\classicsta.cpp @ 51] 
combase!CoWaitForMultipleHandles+0x76 [onecore\com\combase\dcomrem\sync.cxx @ 123] 
clr!MsgWaitHelper+0x8e
clr!Thread::DoAppropriateWaitWorker+0x2e6
clr!Thread::DoAppropriateWait+0x7d
clr!CLREventBase::WaitEx+0xb6
clr!AwareLock::EnterEpilogHelper+0x104
clr!AwareLock::EnterEpilog+0x62
clr!JITutil_MonEnterWorker+0x132
...

According to the docs PeekMessage will not pump and immediately return. But the call stacks above teach me otherwise. I am aware of the .NET concept of SynchronizationContext but I find it highly unusual that a random lock statement can cause application reentrancy. Does PeekMessage pump always WM_SHOW messages? What I could decipher is that during window close of a larger window hierarchy some child windows are notified with a (hide?) message which is pumped. The question is what can I do against this? Are there any guidelines out there how that should be handled?

Alois Kraus
  • 13,229
  • 1
  • 38
  • 64
  • 1
    Do any of the details under "Reentrancy and Locking" here explain the issue: https://learn.microsoft.com/en-us/dotnet/desktop/wpf/advanced/threading-model?view=netframeworkdesktop-4.8#reentrancy-and-locking? – Iridium Oct 10 '22 at 07:40
  • 1
    [`CoWaitForMultipleHandles()`](https://learn.microsoft.com/en-us/windows/win32/api/combaseapi/nf-combaseapi-cowaitformultiplehandles) is the thing that pumps messages. It can be called from [quite a few blocking operations](https://stackoverflow.com/questions/21571598/which-blocking-operations-cause-an-sta-thread-to-pump-com-messages). – Matthew Watson Oct 10 '22 at 08:13
  • @Iridium: The problem are not dispatcher related issues which are interesting but unfortunately not the problem. The article is very interesting but covers not the issue shown here. – Alois Kraus Oct 10 '22 at 10:29
  • @MatthewWatson: That is exactly the issue, but what can I do do prevent reentrancy? – Alois Kraus Oct 10 '22 at 10:48
  • Alas, I don't have the answer. This is quite a hard problem to fix... – Matthew Watson Oct 10 '22 at 15:49

0 Answers0