[Bug 36461] Multiple .NET 4.0 applications fail on startup, WPF message dispatcher unexpectedly receives messages during 'CoWaitForMultipleHandles' call with 'COWAIT_ALERTABLE' flag (Visual Studio 2010, BgmHkClient)
wine-bugs at winehq.org
wine-bugs at winehq.org
Sat Jul 4 09:21:54 CDT 2015
https://bugs.winehq.org/show_bug.cgi?id=36461
Anastasius Focht <focht at gmx.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |dotnet
CC| |focht at gmx.net
Component|-unknown |ole32
Summary|BgmHkClient crash when |Multiple .NET 4.0
|clicking on login form |applications fail on
| |startup, WPF message
| |dispatcher unexpectedly
| |receives messages during
| |'CoWaitForMultipleHandles'
| |call with
| |'COWAIT_ALERTABLE' flag
| |(Visual Studio 2010,
| |BgmHkClient)
--- Comment #1 from Anastasius Focht <focht at gmx.net> ---
Hello folks,
confirming.
Looks like it's still bug 32568
The one-time IDE startup test after the patchset went in was likely not enough
- no message by coincidence.
Using this bug as continuation for real fix.
Trace log:
--- snip ---
$ pwd
/home/focht/.wine/drive_c/Program Files/Microsoft Visual Studio
10.0/Common7/IDE
$ WINEDEBUG=+tid,+seh,+loaddll,+process,+ole,+msg,+win wine ./VCExpress.exe >>
log.txt 2>&1
...
002c:trace:msg:RegisterWindowMessageW L"DispatcherProcessQueue" ret=c05f
...
0042:trace:msg:PostMessageW hwnd 0x3009c msg c05f ("DispatcherProcessQueue") wp
0 lp 0
...
0042:trace:msg:peek_message got type 6 msg c05f ("DispatcherProcessQueue") hwnd
0x3009c wp 0 lp 0
0042:trace:ole:CoWaitForMultipleHandles received message whilst waiting for
RPC: 0xc05f
0042:trace:ole:CoWaitForMultipleHandles waiting for rpc completion or window
message
0042:trace:ole:CoWaitForMultipleHandles -- 0x00000000
...
0042:trace:msg:PostMessageW hwnd 0x3009c msg c05f ("DispatcherProcessQueue") wp
0 lp 0
...
0042:trace:win:WIN_CreateWindowEx L"MediaContextNotificationWindow"
L"HwndWrapper[DefaultDomain;;37171c55-eba2-4a9f-a17a-9e738544739d]" ex=00000000
style=80000000 0,0 0x0 parent=(nil) menu=(nil) inst=(nil) params=(nil)
...
0042:trace:win:WIN_CreateWindowEx hwnd 0x100a0 cs 0,0 0x0
0042:trace:win:WIN_SetWindowLong 0x100a0 -4 1037e02 W
...
0042:trace:win:WIN_CreateWindowEx created window 0x100a0
0042:fixme:msg:ChangeWindowMessageFilter c069 00000001
...
0042:trace:ole:CoWaitForMultipleHandles (0x00000002, 0xffffffff, 1, 0x648b9d0,
0xfedcdd8)
0042:trace:ole:CoWaitForMultipleHandles waiting for rpc completion or window
message
0042:trace:msg:peek_message got type 6 msg c05f ("DispatcherProcessQueue") hwnd
0x3009c wp 0 lp 0
0042:trace:ole:CoWaitForMultipleHandles received message whilst waiting for
RPC: 0xc05f
0042:trace:seh:raise_exception code=e0434352 flags=1 addr=0x7b845bc5
ip=7b845bc5 tid=0042
0042:trace:seh:raise_exception info[0]=80131509
0042:trace:seh:raise_exception info[1]=00000000
0042:trace:seh:raise_exception info[2]=00000000
0042:trace:seh:raise_exception info[3]=00000000
0042:trace:seh:raise_exception info[4]=79140000
0042:trace:seh:raise_exception eax=7b832a0d ebx=00000005 ecx=00000014
edx=0fedc724 esi=0fedc7d4 edi=064868b8
0042:trace:seh:raise_exception ebp=0fedc768 esp=0fedc704 cs=0023 ds=002b
es=002b fs=0063 gs=006b flags=00200283
...
Unhandled Exception:
System.InvalidOperationException: Dispatcher processing has been suspended, but
messages are still being processed.
at System.Windows.Threading.Dispatcher.WndProcHook(IntPtr hwnd, Int32 msg,
IntPtr wParam, IntPtr lParam, Boolean& handled)
at MS.Win32.HwndWrapper.WndProc(IntPtr hwnd, Int32 msg, IntPtr wParam,
IntPtr lParam, Boolean& handled)
at MS.Win32.HwndSubclass.DispatcherCallbackOperation(Object o)
at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate
callback, Object args, Int32 numArgs)
at MS.Internal.Threading.ExceptionFilterHelper.TryCatchWhen(Object source,
Delegate method, Object args, Int32 numArgs, Delegate catchHandler)
at System.Windows.Threading.Dispatcher.WrappedInvoke(Delegate callback,
Object args, Int32 numArgs, Delegate catchHandler)
at System.Windows.Threading.Dispatcher.InvokeImpl(DispatcherPriority
priority, TimeSpan timeout, Delegate method, Object args, Int32 numArgs)
at MS.Win32.HwndSubclass.SubclassWndProc(IntPtr hwnd, Int32 msg, IntPtr
wParam, IntPtr lParam)
at System.Threading.Monitor.ReliableEnter(Object obj, Boolean& lockTaken)
at System.Threading.Monitor.Enter(Object obj, Boolean& lockTaken)
at System.Windows.FrameworkTemplate.LoadContent(DependencyObject container,
List`1 affectedChildren)
at System.Windows.StyleHelper.ApplyTemplateContent(UncommonField`1
dataField, DependencyObject container, FrameworkElementFactory templateRoot,
Int32 lastChildIndex, HybridDictionary childIndexFromChildID, FrameworkTemplate
frameworkTemplate)
at System.Windows.FrameworkTemplate.ApplyTemplateContent(UncommonField`1
templateDataField, FrameworkElement container)
at System.Windows.FrameworkElement.ApplyTemplate()
at System.Windows.FrameworkElement.MeasureCore(Size availableSize)
...
--- snip ---
Debugger:
--- snip ---
...
Stopped on breakpoint 1 at 0x7e9d05eb CoWaitForMultipleHandles
[/home/focht/projects/wine/wine.repo/src/dlls/ole32/compobj.c:4424] in ole32
4424 {
Wine-dbg>c
Unhandled exception: 0xe0434352 in 32-bit code (0x7b845bc5).
Register dump:
CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b
EIP:7b845bc5 ESP:087fce34 EBP:087fce98 EFLAGS:00200283( - -- I S - - -C)
EAX:7b832a0d EBX:00000005 ECX:00000014 EDX:087fce54
ESI:087fcf04 EDI:04c74de0
Stack dump:
0x087fce34: 087fcf04 00000014 ffffffff e0434352
0x087fce44: 00000001 00000000 7b845bc5 00000005
0x087fce54: 80131509 00000000 00000000 00000000
0x087fce64: 79140000 087fcf04 003a24b0 02000059
0x087fce74: 087fce84 79150579 087fce8c 02000059
0x087fce84: 087fce90 7915bc5e 003ec828 087fcea0
Backtrace:
=>0 0x7b845bc5 RaiseException+0x81(code=<couldn't compute location>,
flags=<couldn't compute location>, nbargs=<couldn't compute location>,
args=<couldn't compute location>)
[/home/focht/projects/wine/wine.repo/src/dlls/kernel32/except.c:84] in kernel32
(0x087fce98)
1 0x791cac08 in clr (+0x8ac07) (0x087fcf38)
2 0x791cae41 in clr (+0x8ae40) (0x087fcff8)
3 0x08572032 (0x087fd038)
4 0x05da58c1 (0x087fd084)
5 0x05da57dd (0x087fd0a4)
6 0x05da569d (0x087fd0c0)
7 0x05da5520 (0x087fd100)
8 0x05da5105 (0x087fd124)
9 0x05da4a9d (0x087fd164)
10 0x05da42d9 (0x087fd1b4)
11 0x01022ed8 (0x087fd1e8)
12 0x7e8d1d46 WINPROC_wrapper+0x19() in user32 (0x087fd218)
13 0x7e8d1eab call_window_proc+0xbc(hwnd=0x3007a, msg=0xc05d, wp=0, lp=0,
result=0x87fd388, arg=0x103826a)
[/home/focht/projects/wine/wine.repo/src/dlls/user32/winproc.c:245] in user32
(0x087fd258)
14 0x7e8d3fd7 WINPROC_call_window+0x150(hwnd=0x3007a, msg=0xc05d, wParam=0,
lParam=0, result=0x87fd388, unicode=0x1, mapping=WMCHAR_MAP_DISPATCHMESSAGE)
[/home/focht/projects/wine/wine.repo/src/dlls/user32/winproc.c:901] in user32
(0x087fd2a8)
15 0x7e898178 DispatchMessageW+0x1ad(msg=<couldn't compute location>)
[/home/focht/projects/wine/wine.repo/src/dlls/user32/message.c:4023] in user32
(0x087fd3b8)
16 0x7e9d09ba CoWaitForMultipleHandles+0x3ce(dwFlags=<couldn't compute
location>, dwTimeout=<couldn't compute location>, cHandles=<couldn't compute
location>, pHandles=<couldn't compute location>, lpdwindex=<couldn't compute
location>) [/home/focht/projects/wine/wine.repo/src/dlls/ole32/compobj.c:4516]
in ole32 (0x087fd4b8)
17 0x792074f3 in clr (+0xc74f2) (0x087fd52c)
18 0x7920747f in clr (+0xc747e) (0x087fd54c)
19 0x791f4dd8 in clr (+0xb4dd7) (0x087fd5e0)
20 0x791f4e99 in clr (+0xb4e98) (0x087fd64c)
21 0x791f4f17 in clr (+0xb4f16) (0x087fd6a0)
...
--- snip ---
Some articles that might be of interest:
http://blogs.msdn.com/b/cbrumme/archive/2003/04/17/51361.aspx ("Managed
blocking")
--- quote ---
...
While a thread in a Single-Threaded Apartment (STA) blocks, we will pump
certain messages for you. Message pumping during blocking is one of the black
arts at Microsoft. Pumping too much can cause reentrancy that invalidates
assumptions made by your application. Pumping too little causes deadlocks.
Starting with Windows 2000, OLE32 exposes CoWaitForMultipleHandles so that you
can pump “just the right amount.” On lower operating systems, the CLR uses
MsgWaitForMultipleHandles / PeekMessage / MsgWaitForMultipleHandlesEx and
whatever else is available on that version of the operating system to try to
mirror the behavior of CoWaitForMultipleHandles. The net effect is that we
will always pump COM calls waiting to get into your STA. And any SendMessages
to any windows will be serviced. But most PostMessages will be delayed until
you have finished blocking.
The degree of pumping that’s happening has been painfully tuned to be
appropriate to WindowsForms, non-GUI console apps, ASP compatibility mode using
an STA threadpool on the server, and all the other traditional STA scenarios.
However, in the future we know we’re going to be revisiting this. The
underlying operating system is evolving and there are some big changes underway
in this area. Believe me, you don’t want to be doing this stuff yourself. The
CLR should be insulating you from this pain.
--- quote ---
http://blogs.msdn.com/b/timng/archive/2006/09/06/743795.aspx ("COM,
Re-entrancy, and Message Pumping")
--- quote ---
We then switched to using CoWaitForMultipleHandles because it looked promising;
it would block and pump messages when messages came in. But the kicker here was
that we have custom message filtering and dispatching code, and this code was
being skipped if we called CoWaitForMultipleHandles. In the end, we had to use
MsgWaitForMultipleObjects and call the custom message handler when a message
came in. Only when we did that did we get the right behavior.
--- quote ---
$ wine --version
wine-1.7.46-193-g8b566b1
Regards
--
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.
More information about the wine-bugs
mailing list