http://bugs.winehq.org/show_bug.cgi?id=18640
Summary: .NET 3.0 WPF requires IDirect3D9Ex to be functional Product: Wine Version: 1.1.22 Platform: Other OS/Version: other Status: UNCONFIRMED Severity: normal Priority: P2 Component: directx-d3d AssignedTo: wine-bugs@winehq.org ReportedBy: focht@gmx.net
Hello,
another one, rotting on harddisk half a year now (since first .NET 3.0 voyage) - before it gets lost.
--- snip --- ... fixme:d3d9:IDirect3D9ExImpl_GetAdapterLUID (0x17b328)->(0, 0x1814d0) fixme:d3d9:IDirect3D9ExImpl_GetAdapterDisplayModeEx (0x17b328)->(0, 0x181568, 0x181580): Stub! fixme:seh:RtlCaptureStackBackTrace (2, 3, 0x533546e4, (nil)) stub! ... err:ntdll:vDbgPrintExWithPrefix 65: MIL FAILURE: Unexpected HRESULT 0x88760827 in caller: Could not create display set. fixme:d3d9:IDirect3D9ExImpl_GetAdapterLUID (0x17a388)->(0, 0x19bcc0) fixme:d3d9:IDirect3D9ExImpl_GetAdapterDisplayModeEx (0x17a388)->(0, 0x19bd58, 0x19bd70): Stub! fixme:seh:RtlCaptureStackBackTrace (2, 3, 0x533547a4, (nil)) stub! err:ntdll:vDbgPrintExWithPrefix 65: MIL FAILURE: Unexpected HRESULT 0x88760827 in caller: The render thread failed unexpectedly. fixme:seh:RtlCaptureStackBackTrace (2, 3, 0x533548ac, (nil)) stub! ... fixme:shell:URL_ParseUrl failed to parse L"PresentationFramework.resources" ... fixme:advapi:RegisterEventSourceW ((null),L".NET Runtime 2.0 Error Reporting"): stub fixme:advapi:ReportEventW (0xcafe4242,0x0001,0x0000,0x00001388,(nil),0x000b,0x00000102,0x3009a1b4,0x6cc5c4): stub err:eventlog:ReportEventW L"clr20r3" err:eventlog:ReportEventW L"viewer.exe" err:eventlog:ReportEventW L"1.0.0.0" err:eventlog:ReportEventW L"473fefa6" err:eventlog:ReportEventW L"presentationframework" err:eventlog:ReportEventW L"3.0.0.0" err:eventlog:ReportEventW L"45398c20" err:eventlog:ReportEventW L"6496" err:eventlog:ReportEventW L"be" err:eventlog:ReportEventW L"system.windows.markup.xamlparse" err:eventlog:ReportEventW L"NIL" fixme:advapi:DeregisterEventSource (0xcafe4242) stub ... Unhandled Exception: System.Windows.Markup.XamlParseException: Cannot create instance of 'MainWindow' defined in assembly 'Viewer, Version=1.0.0.0, Culture=neutral, PublicKeyToken=963dca5fb49a45ad'. Exception has been thrown by the target of an invocation. Error in markup file 'MainWindow.xaml'. ---> System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.Windows.Markup.XamlParseException: 'Menu' object cannot be added to 'Grid'. Exception from HRESULT: 0x88980406 Error at object 'System.Windows.Controls.Menu' in markup file 'Viewer;component/mainwindow.xaml'. ---> System.Runtime.InteropServices.COMException (0x88980406): Exception from HRESULT: 0x88980406 at MS.Internal.HRESULT.Check(Int32 hr) at System.Windows.Media.Composition.DUCE.Channel.SyncFlush() at System.Windows.Media.MediaContext.CompleteRender() at System.Windows.Media.MediaContext.CreateChannels() at System.Windows.Media.MediaSystem.ConnectChannels(MediaContext mc) at System.Windows.Media.MediaContext..ctor(Dispatcher dispatcher) at System.Windows.Media.MediaContext.From(Dispatcher dispatcher) at System.Windows.Media.VisualCollection.Add(Visual visual) at System.Windows.Controls.UIElementCollection.AddInternal(UIElement element) at System.Windows.Controls.UIElementCollection.Add(UIElement element) at System.Windows.Controls.UIElementCollection.System.Collections.IList.Add(Object value) at System.Windows.Markup.BamlRecordReader.AddToContentProperty(Object container, Object contentProperty, Object value) ... --- snip ---
IDirect3D9ExImpl_GetAdapterLUID IDirect3D9ExImpl_GetAdapterDisplayModeEx
currently return D3DERR_DRIVERINTERNALERROR
Regards
http://bugs.winehq.org/show_bug.cgi?id=18640
Louis Lenders xerox_xerox2000@yahoo.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW CC| |xerox_xerox2000@yahoo.co.uk Ever Confirmed|0 |1
--- Comment #1 from Louis Lenders xerox_xerox2000@yahoo.co.uk 2009-05-27 12:55:11 --- this affsects probably all .net 3.0 apps. Time ago i did some testing of very simple .net 3.0 apps (http://www.nabble.com/Running-a-simple-.Net-3.0-application.-td21465019.html).
Can you also work around this bug by disabling d3d9?
http://bugs.winehq.org/show_bug.cgi?id=18640
--- Comment #2 from Anastasius Focht focht@gmx.net 2009-05-27 17:16:00 --- Hello,
--- quote --- Can you also work around this bug by disabling d3d9? --- quote ---
Milcore, the vector-based and remoteable composition layer which sits between WPF and D3D will then fall back to classic GDI rendering, losing most performance and HW supported effects WPF stands for.
--- snip --- ... 0039:Call KERNEL32.OutputDebugStringW(5323d708 L"WARNING: MILCore: Direct3D 9 is not installed or load failed.\n") ret=5323d6df 0039:Ret KERNEL32.OutputDebugStringW() retval=ffffffff ret=5323d6df ... --- snip ---
Unfortunately enforcing GDI fall back currently won't help with most (GUI rich) apps. Many examples I tested seem to suffer from the infamous "renderer thread failures" before they die:
--- snip --- ... err:ntdll:vDbgPrintExWithPrefix 65: MIL FAILURE: Unexpected HRESULT 0x8007007e in caller: intermediate rendering error fixme:seh:RtlCaptureStackBackTrace (2, 3, 0x533548f4, (nil)) stub! fixme:seh:RtlCaptureStackBackTrace (2, 3, 0x5335490c, (nil)) stub! fixme:seh:RtlCaptureStackBackTrace (2, 3, 0x53354924, (nil)) stub! fixme:seh:RtlCaptureStackBackTrace (2, 3, 0x5335493c, (nil)) stub! fixme:seh:RtlCaptureStackBackTrace (2, 3, 0x53354954, (nil)) stub! fixme:seh:RtlCaptureStackBackTrace (2, 3, 0x5335496c, (nil)) stub! err:ntdll:vDbgPrintExWithPrefix 65: MIL FAILURE: Unexpected HRESULT 0x8007007e in caller: The render thread failed unexpectedly. --- snip ---
Two threads are running (one can see the interface calls between them using +snoop): an UI thread and the render thread. The render thread is the MIL work horse and does all the (time consuming) rendering. The UI thread (app) passes the commands to the render thread that tell what needs to be rendered and how.
From what I've read in MSDN/blogs these threads can be run separated on
different machines to support remote desktop scenarios where compact data structures are passed between machines and rendered on target.
One gets a lot of hits g00gling for: "An unspecified error occurred on the render thread." Can be caused by quite different things ... from what I've seen so far in trace logs it happens during GDI rendering/processing of commands so it might be bad input from UI.
Regards
http://bugs.winehq.org/show_bug.cgi?id=18640
--- Comment #3 from Anastasius Focht focht@gmx.net 2009-05-27 17:49:14 --- Hello,
regarding the missing stubs from the posting in mailing list:
--- snip --- gdi32.GdiEntry13 kernel32.WerRegisterMemoryBlock ntdll.NtSecureConnectPort ntdll.RtlEnumerateGenericTableWithoutSplaying ntdll.RtlIsGenericTableEmpty --- snip ---
gdi32.GdiEntry13 -> filed as bug 18638 ntdll.NtSecureConnectPort -> filed as bug 18639
kernel32.WerRegisterMemoryBlock:
http://msdn.microsoft.com/en-us/library/bb513620.aspx
--- quote MSDN --- If you use this function to register a memory block, the operating system will add the memory block information to the dump file at the time of the crash or hang. --- quote MSDN ---
Looking at trace log and comparing the addresses passed into RtlCaptureStackBackTrace() and WerRegisterMemoryBlock() stub in case .NET frameworks encounters error, the only purpose seems to ensure the captured stackframes will be part of the dump (same memory area). Because Wine doesn't provide RtlCaptureStackBackTrace() as of now, WerRegisterMemoryBlock() isn't needed. Failure to GetProcAddress() seems harmless. But you might of course send a stub if you like.
From testing with stubs, RtlIsGenericTableEmpty() is only needed if
RtlEnumerateGenericTableWithoutSplaying() really returns useful data (!NULL).
You could open another bug for that so it can be discussed further. Actually it could be quite possible that earlier render thread problem stem from the fact that current RtlInitializeGenericTable() is a stub and RtlEnumerateGenericTableWithoutSplaying() becoming a stub.
Regards
http://bugs.winehq.org/show_bug.cgi?id=18640
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|.NET 3.0 WPF requires |.NET 3.0 WPF MILCore (Media |IDirect3D9Ex to be |Integration Layer) requires |functional |IDirect3D9Ex for HW | |accelerated support
--- Comment #4 from Anastasius Focht focht@gmx.net 2009-05-27 18:49:18 --- Hello,
changed summary to better reflect the issue. Actually I'd like to leave the severity at "normal" as I consider it an important feature and GDI fallback only a workaround (when render thread problems get fixed).
Regards
http://bugs.winehq.org/show_bug.cgi?id=18640
--- Comment #5 from Henri Verbeet hverbeet@gmail.com 2009-05-28 02:47:26 --- Created an attachment (id=21374) --> (http://bugs.winehq.org/attachment.cgi?id=21374) patch
Does this make it any better? (Just hacks, of course.)
http://bugs.winehq.org/show_bug.cgi?id=18640
--- Comment #6 from Anastasius Focht focht@gmx.net 2009-05-28 15:07:06 --- Created an attachment (id=21388) --> (http://bugs.winehq.org/attachment.cgi?id=21388) Deadlock between main UI app thread and MILCore renderer thread
Hello,
well it deadlocks between main UI app thread and renderer thread...
--- snip --- ... 0038:trace:d3d9:IDirect3D9Impl_GetAdapterCount 0x172090 0038:trace:d3d9:IDirect3D9Impl_AddRef (0x172090) : AddRef from 2 0038:trace:d3d9:IDirect3D9Impl_GetAdapterCount 0x172090 0038:trace:d3d9:IDirect3D9Impl_GetDeviceCaps (0x172090) Relay 0 1 0x33ce408 0038:trace:d3d9:IDirect3D9Impl_GetDeviceCaps (0x172090) returning 0x33ce408 0038:trace:d3d9:IDirect3D9Impl_CheckDeviceType (0x172090)->(0, 1, 22, 22, true 0038:trace:d3d9:IDirect3D9Impl_QueryInterface Returning IDirect3D9Ex interface at 0x172090 0038:trace:d3d9:IDirect3D9Impl_AddRef (0x172090) : AddRef from 3 0038:warn:d3d9:IDirect3D9Impl_QueryInterface (0x172090)->({02177241-69fc-400c-8ff1-93a44df6861d},0x33ce52c),not found 0038:trace:d3d9:IDirect3D9Impl_CreateDevice (0x172090) Relay 0038:trace:d3d9:IDirect3D9Impl_GetAdapterCount 0x172090 0038:trace:d3d9:device_parent_WineD3DDeviceCreated iface 0x17eadc, device 0x1cb800 0038:trace:d3d9:IDirect3D9Impl_CreateDevice (0x172090) : Created Device 0x17ead8 0038:trace:d3d9:device_parent_CreateSwapChain iface 0x17eadc, present_parameters 0x1940f8, swapchain 0x33ce14c 0038:trace:d3d9:IDirect3DDevice9Impl_CreateAdditionalSwapChain (0x17ead8) Relay 0038:trace:d3d9:device_parent_CreateRenderTarget iface 0x17eadc, superior 0x194d98, width 1, height 1, format 0x3, multisample_type 0, multisample_quality 0, lockable 1, surface 0x1dd6dc 0038:trace:d3d9:IDirect3DDevice9Impl_CreateRenderTarget Relay 0038:trace:d3d9:IDirect3DDevice9Impl_CreateSurface (0x17ead8) Relay 0038:trace:d3d9:IDirect3DDevice9Impl_CreateSurface (0x17ead8) : w(1) h(1) fmt(22) surf@0x787096b4 0038:trace:d3d9:IDirect3DDevice9Impl_AddRef (0x17ead8) : AddRef from 1 0038:trace:d3d9:IDirect3DDevice9Impl_CreateSurface (0x17ead8) : Created surface 0x194db8 0038:trace:d3d9:IDirect3DSurface9Impl_Release (0x194db8) 0038:trace:d3d9:IDirect3DSurface9Impl_Release (0x194db8) : ReleaseRef to 0 0038:trace:d3d9:IDirect3DDevice9Impl_Release (0x17ead8) : ReleaseRef to 1 0038:fixme:d3d:WineD3D_ChoosePixelFormat Add OpenGL context recreation support to SetDepthStencilSurface <hang here> --- snip ---
I attached the backtrace of relevant threads at the time of the deadlock. NOTE: the console snippet from above and winedbg backtraces are from different runs (different TIDs).
The interesting ones are: thread 0022 (UI thread) vs. thread 0033 (renderer thread) I talked about in comment #2
thread 0022:
Looks like the managed UI main app thread which synchronously waits for command to be completed - signaled using event from renderer thread I think.
thread 0033:
The renderer thread. When the d3d9 device is created, the window handle created by main UI thread is passed. The pixel format is propagated synchronously to target window. Because the target (thread 0022) waits for event without pumping messages it deadlocks.
Regards
http://bugs.winehq.org/show_bug.cgi?id=18640
--- Comment #7 from Henri Verbeet hverbeet@gmail.com 2009-05-29 08:22:52 --- I guess we can't call SendMessage from SetPixelFormat, although a test to confirm that wouldn't hurt. That would make it an opengl/winex11.drv issue. I'm not sure when/if I'll be able to look into that.
http://bugs.winehq.org/show_bug.cgi?id=18640
Louis Lenders xerox_xerox2000@yahoo.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download URL| |http://www.brothersoft.com/ | |games/valil.chess.html Platform|Other |PC OS/Version|other |Linux
--- Comment #8 from Louis Lenders xerox_xerox2000@yahoo.co.uk 2009-11-30 16:13:41 --- Added a sample application download link that show the bug behaviour (app needs native windowscodecs.dll as well, + creation of registry key HKLM\Software\Microsoft\Windows NT\CurrentVersion\ProfileList\S-1-5-4 already covered by other bugreports)
http://bugs.winehq.org/show_bug.cgi?id=18640
--- Comment #9 from Henri Verbeet hverbeet@gmail.com 2009-12-07 06:12:23 --- For what it's worth, GetAdapterLUID() should be implemented since ed73f0a1b04acff312a261ea8b409255337520d2.
http://bugs.winehq.org/show_bug.cgi?id=18640
Andras Kovacs andras@csevego.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |andras@csevego.net
--- Comment #10 from Andras Kovacs andras@csevego.net 2009-12-08 16:49:04 --- (In reply to comment #9)
For what it's worth, GetAdapterLUID() should be implemented since ed73f0a1b04acff312a261ea8b409255337520d2.
same as before.
http://bugs.winehq.org/show_bug.cgi?id=18640
--- Comment #11 from Louis Lenders xerox_xerox2000@yahoo.co.uk 2010-03-14 16:14:24 --- anyone knows a temporary hack for this bug? I'm trying to run autocad 2010 trial, and this bug is really a showstopper :(
http://bugs.winehq.org/show_bug.cgi?id=18640
--- Comment #12 from Louis Lenders xerox_xerox2000@yahoo.co.uk 2010-03-19 07:36:52 --- Created an attachment (id=26889) --> (http://bugs.winehq.org/attachment.cgi?id=26889) possible fix for the seconde problem
found a possible fix, the SendMessage call boils down to calling the function set_win_format, removing the Sendmessage like in attached patch fixes the bug and is basically a no_op
Henri, any chance you send the first patch you made?
http://bugs.winehq.org/show_bug.cgi?id=18640
--- Comment #13 from Henri Verbeet hverbeet@gmail.com 2010-03-19 07:46:02 --- (In reply to comment #12)
found a possible fix, the SendMessage call boils down to calling the function set_win_format, removing the Sendmessage like in attached patch fixes the bug and is basically a no_op
Only if the window is on the same thread we are, but in that case we wouldn't deadlock in the first place. Perhaps SendNotifyMessage() could work there, but I don't know that code very well. Really, what this bug needs most at this point are tests.
Henri, any chance you send the first patch you made?
The GetAdapterLUID() part should already be fixed in current git. I may be able to do something about GetAdapterDisplayModeEx() next week.
http://bugs.winehq.org/show_bug.cgi?id=18640
Louis Lenders xerox_xerox2000@yahoo.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #21374|0 |1 is obsolete| |
--- Comment #14 from Louis Lenders xerox_xerox2000@yahoo.co.uk 2010-07-10 05:16:50 --- Created an attachment (id=29494) --> (http://bugs.winehq.org/attachment.cgi?id=29494) patch
I added some tests for GetAdapterDisplayModeEx yesterday. The attached patch makes most tests pass, but the format returned by GetAdapterDisplayMode doesn't match the one returned by GetAdapterDisplayModeEx. I'll investigate further in a few days
http://bugs.winehq.org/show_bug.cgi?id=18640
--- Comment #15 from Henri Verbeet hverbeet@gmail.com 2010-07-10 05:48:15 --- (In reply to comment #14)
Created an attachment (id=29494)
--> (http://bugs.winehq.org/attachment.cgi?id=29494) [details]
patch
I added some tests for GetAdapterDisplayModeEx yesterday. The attached patch makes most tests pass, but the format returned by GetAdapterDisplayMode doesn't match the one returned by GetAdapterDisplayModeEx. I'll investigate further in a few days
You'd need to do "mode->Format = d3dformat_from_wined3dformat(m.Format)" to convert the wined3d format to something that makes sense to d3d9.
However, the way this should be implemented is that IWineD3DImpl_GetAdapterDisplayMode() should be extended to return rotation and scanline ordering, then implement IDirect3D9ExImpl_GetAdapterDisplayModeEx() on top of IWineD3DImpl_GetAdapterDisplayMode(), and IDirect3D9Impl_GetAdapterDisplayMode() on top of IDirect3D9ExImpl_GetAdapterDisplayModeEx().
http://bugs.winehq.org/show_bug.cgi?id=18640
--- Comment #16 from Louis Lenders xerox_xerox2000@yahoo.co.uk 2010-07-10 09:38:09 ---
However, the way this should be implemented is that IWineD3DImpl_GetAdapterDisplayMode() should be extended to return rotation and scanline ordering,
Any idea how to retrieve the scanline ordering?
then implement IDirect3D9ExImpl_GetAdapterDisplayModeEx() on
top of IWineD3DImpl_GetAdapterDisplayMode(), and IDirect3D9Impl_GetAdapterDisplayMode() on top of IDirect3D9ExImpl_GetAdapterDisplayModeEx().
Ok, thanks for the info, i'll see if i can put something together later (if noone beats me to it)
http://bugs.winehq.org/show_bug.cgi?id=18640
--- Comment #17 from Henri Verbeet hverbeet@gmail.com 2010-07-10 10:44:32 --- (In reply to comment #16)
However, the way this should be implemented is that IWineD3DImpl_GetAdapterDisplayMode() should be extended to return rotation and scanline ordering,
Any idea how to retrieve the scanline ordering?
No, but I haven't really looked for it either.
http://bugs.winehq.org/show_bug.cgi?id=18640
--- Comment #18 from Louis Lenders xerox_xerox2000@yahoo.co.uk 2010-07-17 05:43:00 --- Created an attachment (id=29643) --> (http://bugs.winehq.org/attachment.cgi?id=29643) partially implement GetAdpaterDisplayModeEx
Here's an attempt to implement it on top of wined3d. I've extended IWineD3DGetAdapterDisplayMode with an extra parameter, to pass back the ScanLineOrdering and Rotation. This removes almost all of the todo_wine's except the last one, but that's because wine's EnumDisplDevicesEx doesn't support yet retrieving info about rotated displays;
http://bugs.winehq.org/show_bug.cgi?id=18640
--- Comment #19 from Louis Lenders xerox_xerox2000@yahoo.co.uk 2010-07-22 03:31:34 --- Created an attachment (id=29770) --> (http://bugs.winehq.org/attachment.cgi?id=29770) patch 1
here's a new series of patches. I extended IWindeD3DGetAdapterDisplayMode to look more similar to ID3D9GetAdapterDisplayModeEx.
http://bugs.winehq.org/show_bug.cgi?id=18640
--- Comment #20 from Louis Lenders xerox_xerox2000@yahoo.co.uk 2010-07-22 03:31:56 --- Created an attachment (id=29771) --> (http://bugs.winehq.org/attachment.cgi?id=29771) patch 2
http://bugs.winehq.org/show_bug.cgi?id=18640
--- Comment #21 from Louis Lenders xerox_xerox2000@yahoo.co.uk 2010-07-22 03:32:21 --- Created an attachment (id=29772) --> (http://bugs.winehq.org/attachment.cgi?id=29772) patch 3
http://bugs.winehq.org/show_bug.cgi?id=18640
--- Comment #22 from Louis Lenders xerox_xerox2000@yahoo.co.uk 2010-07-22 03:32:39 --- Created an attachment (id=29773) --> (http://bugs.winehq.org/attachment.cgi?id=29773) patch 4
http://bugs.winehq.org/show_bug.cgi?id=18640
--- Comment #23 from Henri Verbeet hverbeet@gmail.com 2010-07-22 08:12:35 --- (In reply to comment #19)
Created an attachment (id=29770)
--> (http://bugs.winehq.org/attachment.cgi?id=29770) [details]
patch 1
here's a new series of patches. I extended IWindeD3DGetAdapterDisplayMode to look more similar to ID3D9GetAdapterDisplayModeEx.
- hr = IWineD3D_GetAdapterDisplayMode(This->WineD3D, Adapter, (WINED3DDISPLAYMODE *) pMode);
- hr = IWineD3D_GetAdapterDisplayMode(This->WineD3D, Adapter, (WINED3DDISPLAYMODE *) pMode, NULL);
It's not *that* easy. The WINED3DDISPLAYMODE and D3DDISPLAYMODE structures are now incompatible.
http://bugs.winehq.org/show_bug.cgi?id=18640
--- Comment #24 from Louis Lenders xerox_xerox2000@yahoo.co.uk 2010-07-22 10:27:46 --- (In reply to comment #23)
(In reply to comment #19)
Created an attachment (id=29770)
--> (http://bugs.winehq.org/attachment.cgi?id=29770) [details] [details]
patch 1
here's a new series of patches. I extended IWindeD3DGetAdapterDisplayMode to look more similar to ID3D9GetAdapterDisplayModeEx.
- hr = IWineD3D_GetAdapterDisplayMode(This->WineD3D, Adapter, (WINED3DDISPLAYMODE *) pMode);
- hr = IWineD3D_GetAdapterDisplayMode(This->WineD3D, Adapter, (WINED3DDISPLAYMODE *) pMode, NULL);
It's not *that* easy. The WINED3DDISPLAYMODE and D3DDISPLAYMODE structures are now incompatible.
oops yeah, i remember that's why i created a seperate structure for WINED3DDISPLAYMODE and WINED3DSCANLINEORDERING in my first patch, as that required the minimum set of changes to the current code in d3d8/d3d9/wined3d. I'll give it another try
http://bugs.winehq.org/show_bug.cgi?id=18640
Louis Lenders xerox_xerox2000@yahoo.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #29770|0 |1 is obsolete| |
http://bugs.winehq.org/show_bug.cgi?id=18640
Louis Lenders xerox_xerox2000@yahoo.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #29773|0 |1 is obsolete| |
http://bugs.winehq.org/show_bug.cgi?id=18640
--- Comment #25 from Louis Lenders xerox_xerox2000@yahoo.co.uk 2010-07-23 12:53:36 --- Created an attachment (id=29789) --> (http://bugs.winehq.org/attachment.cgi?id=29789) reworked patch 1
new patch, patch 2+3 still apply. Will also attach reworked patch 4
http://bugs.winehq.org/show_bug.cgi?id=18640
--- Comment #26 from Louis Lenders xerox_xerox2000@yahoo.co.uk 2010-07-23 12:54:08 --- Created an attachment (id=29790) --> (http://bugs.winehq.org/attachment.cgi?id=29790) reworked patch 4
http://bugs.winehq.org/show_bug.cgi?id=18640
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |dotnet
--- Comment #27 from Anastasius Focht focht@gmx.net 2010-08-05 15:37:58 --- Hello,
revisiting, adding 'dotnet' keyword. Keep up the work! ;-)
Regards
http://bugs.winehq.org/show_bug.cgi?id=18640
--- Comment #28 from Andrew V. Anisimov anisimov@appsys.net 2011-03-03 15:40:20 CST --- Created an attachment (id=33521) --> (http://bugs.winehq.org/attachment.cgi?id=33521) Autodesk Inventor 2011 crash log
http://bugs.winehq.org/show_bug.cgi?id=18640
Juan Lang juan_lang@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #33521|application/octet-stream |text/plain mime type| |
http://bugs.winehq.org/show_bug.cgi?id=18640
NSLW lukasz.wojnilowicz@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |lukasz.wojnilowicz@gmail.co | |m
--- Comment #29 from NSLW lukasz.wojnilowicz@gmail.com 2011-06-11 02:51:49 CDT --- Free app affected by this bug http://stuff.hamstersoft.com/software/hamsterfreeburningstudio.exe
http://bugs.winehq.org/show_bug.cgi?id=18640
--- Comment #30 from Louis Lenders xerox_xerox2000@yahoo.co.uk 2011-07-20 15:51:46 CDT --- This also seems to affect all .Net 4.0 apps that use WPF.
I installed .Net 4.0 on a fresh wine using the hack from bug 10601: http://bugs.winehq.org/show_bug.cgi?id=10601#c15 (also delete registrykey HKLM\Software\MicroSoft\Net Framework\NDP\v4, otherwise it says .Net 4.0 is already installed and set mscoree to builtin). Installer finishes fine and non-WPF apps seem to run fine (i tested EVEMon and PhotoMagician), so i guess installation is ok.
For the WPF-apps i tested i also had to return RPC_S_NOT_LISTENING for RpcMgmtIsServerListening in rpcrt4/rpc_server.c, then i get the same crash as in this bug:
fixme:d3d9:IDirect3D9ExImpl_GetAdapterDisplayModeEx iface 0x16f520, adapter 0, mode 0x16fa04, rotation 0x16fa1c stub! err:ntdll:vDbgPrintExWithPrefix 63: MIL FAILURE: Unexpected HRESULT 0x80004001 in caller: The render thread failed unexpectedly.
However, disabling d3d9 doesn't work, and using patch in this bug for IDirect3D9ExImpl_GetAdapterDisplayModeEx doesn't change anything either: I always get the same crash:
fixme:driver:GdiEntry13 stub fixme:win:EnumDisplayDevicesW ((null),0,0x4e2e5b0,0x00000000), stub! fixme:win:EnumDisplayDevicesW ((null),1,0x4e2e5b0,0x00000000), stub! wine: Unhandled exception 0x40000015 at address 0x790ef33a (thread 0028), starting debugger... fixme:advapi:UnregisterTraceGuids 0: stub Process of pid=0008 has terminated No process loaded, cannot execute 'echo Modules:' Cannot get info on module while no process is loaded No process loaded, cannot execute 'echo Threads:' louis@qaqaqaqaqaqaqa:~/Desktop/troep/WPFProject/bin/Debug$ process tid prio (all id:s are in hex) 0000000e services.exe 0000002e 0 0000002d 0 00000024 0 0000001e 0 00000018 0
According to google exception 0x40000015 is STATUS_FATAL_APP_EXIT. Maybe yet another bug is playing a role here?
Notee: Minimal WPF app for .Net 4.0 for example http://www.codeproject.com/KB/WF/wcf-wpf-wf-hello-world/wpfwcfwf.zip
http://bugs.winehq.org/show_bug.cgi?id=18640
lionel.hry@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |lionel.hry@gmail.com
--- Comment #31 from lionel.hry@gmail.com 2011-08-29 09:04:22 CDT --- This bug also affects the software IBM Amos 19.
http://bugs.winehq.org/show_bug.cgi?id=18640
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks| |28924
http://bugs.winehq.org/show_bug.cgi?id=18640
Lucas Fialho Zawacki lfzawacki@yahoo.com.br changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |lfzawacki@yahoo.com.br
http://bugs.winehq.org/show_bug.cgi?id=18640
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|.NET 3.0 WPF MILCore (Media |.NET Framework 3.x/4.x WPF |Integration Layer) requires |Media Integration Layer |IDirect3D9Ex for HW |requires |accelerated support |IDirect3D9ExImpl_EnumAdapte | |rModesEx implementation
--- Comment #32 from Anastasius Focht focht@gmx.net 2012-05-03 06:53:34 CDT --- Hello,
still a major issue for all WPF based apps. Refining summary to better target the stub.
An implementation of IDirect3D9ExImpl_EnumAdapterModesEx certainly helps. Sadly Louis seems no longer active .. if someone wants to continue.
It will later run into the SetPixelFormat -> SendMessage deadlock reported in my comment #6 which should be a separate bug:
--- snip --- Wine-dbg>bt 0x30 Backtrace: =>0 0xf772d42e __kernel_vsyscall+0xe() in [vdso].so (0x0303d2b0)
1 0xf759485b __libc_read+0x4a() in libpthread.so.0 (0x0303d2b0)
2 0x7bc7d889 wait_reply+0x33(cookie=0x303d494) [/home/focht/projects/wine/wine-git/dlls/ntdll/sync.c:807] in ntdll (0x0303d2b0)
3 0x7bc7e91d NTDLL_wait_for_multiple_objects+0x1e5(count=0x1, handles=0x303d558, flags=0x4, timeout=(nil), signal_object=0x0(nil)) [/home/focht/projects/wine/wine-git/dlls/ntdll/sync.c:1122] in ntdll (0x0303d4d0)
4 0x7bc7ea01 NtWaitForMultipleObjects+0x67(count=0x1, handles=0x303d558, wait_all=0, alertable=0, timeout=(nil)) [/home/focht/projects/wine/wine-git/dlls/ntdll/sync.c:1160] in ntdll (0x0303d520)
5 0x7b871ccc WaitForMultipleObjectsEx+0x137(count=0x1, handles=0x303d788, wait_all=0, timeout=0xffffffff, alertable=0) [/home/focht/projects/wine/wine-git/dlls/kernel32/sync.c:188] in kernel32 (0x0303d670)
6 0x7ea0f7ea X11DRV_MsgWaitForMultipleObjectsEx+0xed(count=0x1, handles=0x303d788, timeout=0xffffffff, mask=0x40, flags=0) [/home/focht/projects/wine/wine-git/dlls/winex11.drv/event.c:472] in winex11 (0x0303d6b0)
7 0x7ec316da wait_message+0x41(count=0x1, handles=0x303d788, timeout=0xffffffff, mask=0x40, flags=0) [/home/focht/projects/wine/wine-git/dlls/user32/winproc.c:1126] in user32 (0x0303d6f0)
8 0x7ebf1869 wait_message_reply+0xf9(flags=0) [/home/focht/projects/wine/wine-git/dlls/user32/message.c:2897] in user32 (0x0303d7b0)
9 0x7ebf1f7e send_inter_thread_message+0xf2(info=0x303d888, res_ptr=0x303d844) [/home/focht/projects/wine/wine-git/dlls/user32/message.c:3038] in user32 (0x0303d810)
10 0x7ebf222d send_message+0x249(info=0x303d888, res_ptr=0x303d8b4, unicode=0x1) [/home/focht/projects/wine/wine-git/dlls/user32/message.c:3101] in user32 (0x0303d870)
11 0x7ebf271d SendMessageW+0x53(hwnd=0x2005c, msg=0x80001001, wparam=0x75, lparam=0) [/home/focht/projects/wine/wine-git/dlls/user32/message.c:3278] in user32 (0x0303d8c0)
12 0x7ea2f384 internal_SetPixelFormat+0x1df(physDev=0x1b0868, iPixelFormat=0x1, ppfd=(nil)) [/home/focht/projects/wine/wine-git/dlls/winex11.drv/opengl.c:1661] in winex11 (0x0303d960)
13 0x7ea2f857 X11DRV_SetPixelFormat+0xc7(dev=0x1b0868, iPixelFormat=0x1, ppfd=(nil)) [/home/focht/projects/wine/wine-git/dlls/winex11.drv/opengl.c:1721] in winex11 (0x0303d9a0)
14 0x7eb1b635 SetPixelFormat+0xcf(hdc=0x3a8, iPixelFormat=0x1, ppfd=(nil)) [/home/focht/projects/wine/wine-git/dlls/gdi32/painting.c:542] in gdi32 (0x0303d9f0)
15 0x7ddcc6e6 context_set_pixel_format+0x59(gl_info=0x1c16a8, dc=0x3a8, format=0x1) [/home/focht/projects/wine/wine-git/dlls/wined3d/context.c:725] in wined3d (0x0303da40)
16 0x7ddcf1a9 context_create+0x57c(swapchain=0x1fa968, target=0x1fb000, ds_format=0x1cfe78) [/home/focht/projects/wine/wine-git/dlls/wined3d/context.c:1373] in wined3d (0x0303dc80)
17 0x7de984ac swapchain_init+0x76f(swapchain=0x1fa968, surface_type=WINED3D_SURFACE_TYPE_OPENGL, device=0x1e4990, desc=0x303df70, parent=0x1e43e8, parent_ops=0x7e0d3508) [/home/focht/projects/wine/wine-git/dlls/wined3d/swapchain.c:1011] in wined3d (0x0303ded0)
18 0x7de98da4 wined3d_swapchain_create+0x133(device=0x1e4990, desc=0x303df70, surface_type=WINED3D_SURFACE_TYPE_OPENGL, parent=0x1e43e8, parent_ops=0x7e0d3508, swapchain=0x1e43f0) [/home/focht/projects/wine/wine-git/dlls/wined3d/swapchain.c:1156] in wined3d (0x0303df40)
19 0x7e0bd654 swapchain_init+0x108(swapchain=0x1e43e8, device=0x1e2b20, present_parameters=0x303e058) [/home/focht/projects/wine/wine-git/dlls/d3d9/swapchain.c:283] in d3d9 (0x0303dfc0)
20 0x7e0bd823 d3d9_swapchain_create+0xb2(device=0x1e2b20, present_parameters=0x303e058, swapchain=0x303e054) [/home/focht/projects/wine/wine-git/dlls/d3d9/swapchain.c:327] in d3d9 (0x0303e020)
21 0x7e0b6a81 device_parent_create_swapchain+0x126(device_parent=0x1e2b24, desc=0x1e4378, swapchain=0x303e0e0) [/home/focht/projects/wine/wine-git/dlls/d3d9/device.c:3326] in d3d9 (0x0303e0b0)
22 0x7dddd5f3 wined3d_device_init_3d+0x21f(device=0x1e4990, swapchain_desc=0x1e4378) [/home/focht/projects/wine/wine-git/dlls/wined3d/device.c:1242] in wined3d (0x0303e180)
23 0x7e0b7250 device_init+0x687(device=0x1e2b20, parent=0x1c0da8, wined3d=0x1c1678, adapter=0, device_type=D3DDEVTYPE_HAL, focus_window=0x2005c, flags=0x456, parameters=0x303e68c, mode=(nil)) [/home/focht/projects/wine/wine-git/dlls/d3d9/device.c:3475] in d3d9 (0x0303e390)
24 0x7e0b9538 IDirect3D9ExImpl_CreateDeviceEx+0x16b(iface=0x1c0da8, adapter=0, device_type=D3DDEVTYPE_HAL, focus_window=0x2005c, flags=0x456, parameters=0x303e68c, mode=(nil), device=0x303e544) [/home/focht/projects/wine/wine-git/dlls/d3d9/directx.c:544] in d3d9 (0x0303e410)
25 0x532413be in milcore (+0xb13bd) (0x0303e54c) ... --- snip ---
$ wine --version wine-1.5.3-101-g9c19ba6
Regards
http://bugs.winehq.org/show_bug.cgi?id=18640
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|.NET Framework 3.x/4.x WPF |.NET Framework 3.x/4.x WPF |Media Integration Layer |Media Integration Layer |requires |requires |IDirect3D9ExImpl_EnumAdapte |IDirect3D9ExImpl_GetAdapter |rModesEx implementation |DisplayModeEx | |implementation
--- Comment #33 from Anastasius Focht focht@gmx.net 2012-05-03 06:57:50 CDT --- Hello,
sorry summary typo, I read the wrong line from git diff it's actually IDirect3D9ExImpl_GetAdapterDisplayModeEx that is needed here.
Regards
http://bugs.winehq.org/show_bug.cgi?id=18640
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |2c8834dffdc5325e7e5be72e7ba | |750a8c014664e Status|NEW |RESOLVED Resolution| |FIXED
--- Comment #34 from Anastasius Focht focht@gmx.net 2012-06-28 06:42:51 CDT --- Hello,
this is fixed by commit http://source.winehq.org/git/wine.git/commitdiff/2c8834dffdc5325e7e5be72e7ba...
Thanks Henri
It now runs into SetPixelFormat/SendMessage deadlock described in comment #6
Regards
http://bugs.winehq.org/show_bug.cgi?id=18640
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #35 from Alexandre Julliard julliard@winehq.org 2012-07-03 14:15:47 CDT --- Closing bugs fixed in 1.5.8.
https://bugs.winehq.org/show_bug.cgi?id=18640
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- URL|http://www.brothersoft.com/ |https://web.archive.org/web |games/valil.chess.html |/20081112055516/http://www. | |valil.com/winfx/RTM/Chess/A | |PP/Valil.Chess.WinFX.bin.zi | |p
-
wine-bugs＠winehq.org -
WineHQ Bugzilla