[Bug 33384] New: Basic WPF application fails to handle images

http://bugs.winehq.org/show_bug.cgi?id=33384

Bug #: 33384
           Summary: Basic WPF application fails to handle images
           Product: Wine
           Version: 1.5.25
          Platform: x86
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: major
          Priority: P2
         Component: -unknown
        AssignedTo: [e-mail]
        ReportedBy: [e-mail]
    Classification: Unclassified

I created a simple application that display an image loaded from a file (see
MainWindow.xaml). The file added as a "Resource" to the application project.
Basically, the only thing I added to the base skeleton, is <Image
Source="beta.png"/>.

The application fails at
System.Media.Imaging.BitmapSource.get_DUCECompatibleMILPtr() 
with System.InvalidCastException: Specified case is not valid.

[Bug 33384] Basic WPF application fails to handle images

http://bugs.winehq.org/show_bug.cgi?id=33384

Anastasius Focht  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |dotnet
                 CC|                            |[e-mail]
           Severity|major                       |normal

--- Comment #1 from Anastasius Focht  2013-04-14 10:59:38 CDT ---
Hello,

which WPF version does your application target (WPF 4.0 or WPF 3.5 SPx)?
Make sure you have all required .NET Frameworks and Service Packs installed in
the WINEPREFIX your application is run from (following appdb/winetricks
recipes).

Please attach the application binary and all needed resources (preferable a
simple version).

Regards

[Bug 33384] Basic WPF application fails to handle images

http://bugs.winehq.org/show_bug.cgi?id=33384

--- Comment #2 from leon  2013-04-14 12:59:14 CDT ---
Created attachment 44184
  --> http://bugs.winehq.org/attachment.cgi?id=44184
WPF executable, should show a single picture

[Bug 33384] Basic WPF application fails to handle images

http://bugs.winehq.org/show_bug.cgi?id=33384

--- Comment #3 from leon  2013-04-14 13:02:03 CDT ---
Created attachment 44185
  --> http://bugs.winehq.org/attachment.cgi?id=44185
WPF application sources

The picture file added to the Visual Studio based project and defined as a
resource. After that used in MainWindow.xaml.

[Bug 33384] Basic WPF application fails to handle images

http://bugs.winehq.org/show_bug.cgi?id=33384

--- Comment #4 from leon  2013-04-14 13:04:43 CDT ---
Hello,

The application was developed with Visual Studio 2010, targeting .NET 3.5.
I think all required prerequisites were installed.

Is there any difference between handling .NET 3.5 and 4.0 by Wine? Is there
chance that the same application works when targeting .NET 4.0?

Thanks a lot,
Leon.

[Bug 33384] Basic WPF applications using .NET 3.5 WPF fails to handle images (windowscodecs {7543696a-bc8d-46b0-5f81-8d95728972be} = IMILBitmapSource unsupported)

http://bugs.winehq.org/show_bug.cgi?id=33384

Anastasius Focht  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
          Component|-unknown                    |windowscodecs
            Summary|Basic WPF application fails |Basic WPF applications
                   |to handle images            |using .NET 3.5 WPF fails to
                   |                            |handle images
                   |                            |(windowscodecs
                   |                            |{7543696a-bc8d-46b0-5f81-8d
                   |                            |95728972be} =
                   |                            |IMILBitmapSource
                   |                            |unsupported)
     Ever Confirmed|0                           |1

--- Comment #5 from Anastasius Focht  2013-04-14 14:23:12 CDT ---
Hello,

confirming.

It seems that .NET Framework WPF 3.x queries an internal interface that Wine
builtin windowscodecs doesn't support.

--- snip ---
$ WINEDEBUG=+tid,+seh,+loaddll,+process,+msvcrt,+snoop,+wincodecs wine
./WineTest.exe
...
002b:CALL wpfgfx_v0300.MilResource_SendCommand(0032dd70,00000018,0019a108)
ret=046790e0
002b:RET  wpfgfx_v0300.MilResource_SendCommand() retval=00000000 ret=046790e0
002b:CALL wpfgfx_v0300.MilCompositionEngine_EnterCompositionEngineLock()
ret=042f08c3
002b:RET  wpfgfx_v0300.MilCompositionEngine_EnterCompositionEngineLock()
retval=00000000 ret=042f08c3
002b:CALL
wpfgfx_v0300.MilResource_CreateOrAddRefOnChannel(0019a108,00000031,0032dd3c)
ret=042f0a20
002b:RET  wpfgfx_v0300.MilResource_CreateOrAddRefOnChannel() retval=00000000
ret=042f0a20
002b:CALL wpfgfx_v0300.MilCompositionEngine_EnterCompositionEngineLock()
ret=042f08c3
002b:RET  wpfgfx_v0300.MilCompositionEngine_EnterCompositionEngineLock()
retval=00000000 ret=042f08c3
002b:CALL
wpfgfx_v0300.MilResource_CreateOrAddRefOnChannel(0019a108,00000062,0032dcf8)
ret=042f0a20
002b:RET  wpfgfx_v0300.MilResource_CreateOrAddRefOnChannel() retval=00000000
ret=042f0a20
002b:trace:wincodecs:BitmapImpl_CopyPixels (0x1b6d30,0x32dc44,4,4,0x84ce6c)
002b:CALL wpfgfx_v0300.MILQueryInterface(001b6d30,0032dc34,0032dc9c)
ret=042f123d
002b:trace:wincodecs:BitmapImpl_QueryInterface
(0x1b6d30,{7543696a-bc8d-46b0-5f81-8d95728972be},0x32dc9c)
002b:RET  wpfgfx_v0300.MILQueryInterface() retval=80004002 ret=042f123d 
...
002b:trace:seh:raise_exception code=e0434f4d flags=1 addr=0x7b83aabb
ip=7b83aabb tid=002b
002b:trace:seh:raise_exception  info[0]=80004002
002b:trace:seh:raise_exception  eax=7b826891 ebx=7b8b96b0 ecx=80004002
edx=0032da94 esi=0032db18 edi=00132d10
002b:trace:seh:raise_exception  ebp=0032dad8 esp=0032da74 cs=0023 ds=002b
es=002b fs=0063 gs=006b flags=00000283
002b:trace:seh:call_stack_handlers calling handler at 0x79f908a2 code=e0434f4d
flags=1
002b:trace:seh:_except_handler4_common exception e0434f4d flags=1 at 0x7b83aabb
handler=0x79f908a2 0x32d710 0x32d5dc cookie=a6e038fa scope table=0x79eda938
cookies=-2/0,-72/0
002b:trace:seh:_except_handler4_common level 0 prev -2 filter 0x79eda969
002b:trace:seh:_except_handler4_common filter returned CONTINUE_SEARCH
002b:trace:seh:_except_handler4_common reached -2, returning
ExceptionContinueSearch
002b:trace:seh:call_stack_handlers handler at 0x79f908a2 returned 1
002b:trace:seh:call_stack_handlers calling handler at 0x79fb4869 code=e0434f4d
flags=1 
...
--- snip ---

Managed backtrace:

--- snip ---
System.InvalidCastException: Specified cast is not valid.
   at System.Windows.Media.Imaging.BitmapSource.get_DUCECompatibleMILPtr()
   at
System.Windows.Media.Imaging.BitmapSource.UpdateBitmapSourceResource(Channel
channel, Boolean skipOnChannelCheck)
   at System.Windows.Media.Imaging.BitmapSource.UpdateResource(Channel channel,
Boolean skipOnChannelCheck)
   at System.Windows.Media.Imaging.BitmapSource.AddRefOnChannelCore(Channel
channel)
   at
System.Windows.Media.Imaging.BitmapSource.System.Windows.Media.Composition.DUCE.IResource.AddRefOnChannel(Channel
channel)
   at
System.Windows.Media.RenderData.System.Windows.Media.Composition.DUCE.IResource.AddRefOnChannel(Channel
channel)
   at System.Windows.UIElement.RenderContent(RenderContext ctx, Boolean
isOnChannel)
   at System.Windows.Media.Visual.UpdateContent(RenderContext ctx,
VisualProxyFlags flags, Boolean isOnChannel)
   at System.Windows.Media.Visual.RenderRecursive(RenderContext ctx)
   at System.Windows.Media.Visual.UpdateChildren(RenderContext ctx,
ResourceHandle handle)
...
   at System.Windows.Media.Visual.RenderRecursive(RenderContext ctx)
   at System.Windows.Media.Visual.Render(RenderContext ctx, UInt32 childIndex)
   at System.Windows.Media.CompositionTarget.Compile(Channel channel)
   at
System.Windows.Media.CompositionTarget.System.Windows.Media.ICompositionTarget.Render(Boolean
inResize, Channel channel)
   at System.Windows.Media.MediaContext.Render(ICompositionTarget
resizedCompositionTarget)
   at System.Windows.Media.MediaContext.RenderMessageHandlerCore(Object
resizedCompositionTarget)
   at System.Windows.Media.MediaContext.RenderMessageHandler(Object
resizedCompositionTarget)
   at System.Windows.Media.MediaContext.Resize(ICompositionTarget
resizedCompositionTarget)
   at System.Windows.Interop.HwndTarget.OnResize()
--- snip ---

Google suggests that "7543696A-BC8D-46b0-5F81-8D95728972BE" is
"IMILBitmapSource".

It's also mentioned in United States Patent 7511718 "Media integration layer":
http://www.freepatentsonline.com/7511718.html

The interface has the same members/signatures as IWICBitmapSource except for
CopyPalette() -> GetPalette().

You can work around installing native 'windowscodecs' using 'winetricks
windowscodecs' recipe.
Be aware the installer seems very unstable = needs several tries, most likely
regressed over long time.

With native windowscodecs override your application properly loads and displays
the picture on my system.

--- quote ---
Is there any difference between handling .NET 3.5 and 4.0 by Wine? Is there
chance that the same application works when targeting .NET 4.0?
--- quote ---

Not by Wine (as long it's not an underlying win32 API insufficiency) but there
are of course major WPF versions (3.0, 3.5, 3.5sp1, 4.0, 4.5) that have whole
rendering engines underneath rewritten, interfaces obsoleted/added and the
like.
This is outside of Wine's scope, I suggest to read on MSDN.

Regarding .NET Framework 4.0 (containing WPF 4.0) ... you can try by
rebuilding/deploying your app.
Be sure to set the application target framework to ".NET Framework 4 Client
Profile" in build settings.
For testing I suggest a separate WINEPREFIX, created with 'winetricks -q
dotnet40'.

Regards

[Bug 33384] Basic WPF applications using .NET 3.5 WPF fails to handle images (windowscodecs {7543696a-bc8d-46b0-5f81-8d95728972be} = IMILBitmapSource unsupported)

http://bugs.winehq.org/show_bug.cgi?id=33384

Vincent Povirk  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #6 from Vincent Povirk  2013-04-14 16:23:38 CDT ---
Argh.

What's the signature on GetPalette? Are you getting this information from the
WPF .NET metadata (seems like the most obvious way to do it, but it's also code
I can't personally look at)? Did you verify the method order?

[Bug 33384] Basic WPF applications using .NET 3.5 WPF fails to handle images (windowscodecs {7543696a-bc8d-46b0-5f81-8d95728972be} = IMILBitmapSource unsupported)

http://bugs.winehq.org/show_bug.cgi?id=33384

--- Comment #7 from Anastasius Focht  2013-04-14 17:11:06 CDT ---
Hello Vincent,

the method signatures and order are exactly the same so I'm wondering why this
second interface exist (solely for performance reasons?).

The definition for Wine's "wincodec.idl" would be as follows (I replaced the
GUID and CopyPalette method name):

--- snip ---
[
    object,
    uuid(7543696a-bc8d-46b0-5f81-8d95728972be)
]
interface IMILBitmapSource : IUnknown
{
    HRESULT GetSize(
        [out] UINT *puiWidth,
        [out] UINT *puiHeight);

HRESULT GetPixelFormat(
        [out] WICPixelFormatGUID *pPixelFormat);

HRESULT GetResolution(
        [out] double *pDpiX,
        [out] double *pDpiY);

HRESULT GetPalette(
        [in] IWICPalette *pIPalette);

HRESULT CopyPixels(
        [in] const WICRect *prc,
        [in] UINT cbStride,
        [in] UINT cbBufferSize,
        [out, size_is(cbBufferSize)] BYTE *pbBuffer);
}
--- snip ---

So technically if the vtable layout and method signatures are exactly the same,
we could get away by just using our BitmapImpl?

Regards

[Bug 33384] Basic WPF applications using .NET 3.5 WPF fails to handle images (windowscodecs {7543696a-bc8d-46b0-5f81-8d95728972be} = IMILBitmapSource unsupported)

http://bugs.winehq.org/show_bug.cgi?id=33384

--- Comment #8 from Anastasius Focht  2013-04-14 18:13:26 CDT ---
Hello folks,

well it seems I was wrong on "exact" the same parameters.
It seems there is at least another deviation in the interface.

For testing I added IMILBitmapSource to .idl file and allowed
BitmapImpl_QueryInterface to return BitmapImpl for IID_IMILBitmapSource.

This gets the app a little farther only to run into:

--- snip ---
...
002b:CALL wpfgfx_v0300.MilResource_SendCommandBitmapSource(<unknown, check
return>) ret=044123d7
002b:trace:wincodecs:BitmapImpl_GetPixelFormat (0x1b2de8,0x32dbc4)
002b:trace:wincodecs:BitmapImpl_AddRef (0x1b2de8) refcount=5
002b:trace:wincodecs:BitmapImpl_GetSize (0x1b2de8,0x32dbb4,0x32dbb0)
002b:trace:wincodecs:BitmapImpl_GetResolution (0x1b2de8,0x32dc40,0x32dc38)
002b:fixme:wer:WerRegisterMemoryBlock (0x5418ebf0 6144) stub
002b:fixme:wer:WerRegisterMemoryBlock (0x5418ebe8 4) stub
002b:trace:wincodecs:BitmapImpl_Release (0x1b2de8) refcount=4
002b:RET 
wpfgfx_v0300.MilResource_SendCommandBitmapSource(00000010,001b2de8,00000001,00000001,0018b1d0)
retval=80070216 ret=044123d7 
...
002b:trace:seh:raise_exception code=e0434f4d flags=1 addr=0x7b83aabb
ip=7b83aabb tid=002b
002b:trace:seh:raise_exception  info[0]=80131516
002b:trace:seh:raise_exception  eax=7b826891 ebx=7b8b96b0 ecx=80131516
edx=0032db38 esi=0032dbc0 edi=00133148
002b:trace:seh:raise_exception  ebp=0032db78 esp=0032db14 cs=0023 ds=002b
es=002b fs=0063 gs=006b flags=00000283
002b:trace:seh:call_stack_handlers calling handler at 0x79f908a2 code=e0434f4d
flags=1 
...
0033:err:eventlog:ReportEventW L"clr20r3"
0033:err:eventlog:ReportEventW L"winetest.exe"
0033:err:eventlog:ReportEventW L"1.0.0.0"
0033:err:eventlog:ReportEventW L"5168fd72"
0033:err:eventlog:ReportEventW L"presentationcore"
0033:err:eventlog:ReportEventW L"3.0.0.0"
0033:err:eventlog:ReportEventW L"488f140b"
0033:err:eventlog:ReportEventW L"480"
0033:err:eventlog:ReportEventW L"29"
0033:err:eventlog:ReportEventW L"system.overflowexception"
0033:err:eventlog:ReportEventW L"NIL"
--- snip ---

Managed backtrace:

--- snip ---
System.OverflowException: The image data generated an overflow during
processing. ---> System.ArithmeticException: Overflow or underflow in the
arithmetic operation.
   --- End of inner exception stack trace ---
   at
System.Windows.Media.Composition.DUCE.Channel.SendCommandBitmapSource(ResourceHandle
imageHandle, BitmapSourceSafeMILHandle pBitmapSource, Boolean shareBitmap,
Boolean systemMemoryBitmap)
   at
System.Windows.Media.Imaging.BitmapSource.UpdateBitmapSourceResource(Channel
channel, Boolean skipOnChannelCheck)
   at System.Windows.Media.Imaging.BitmapSource.UpdateResource(Channel channel,
Boolean skipOnChannelCheck)
   at System.Windows.Media.Imaging.BitmapSource.AddRefOnChannelCore(Channel
channel)
   at
System.Windows.Media.Imaging.BitmapSource.System.Windows.Media.Composition.DUCE.IResource.AddRefOnChannel(Channel
channel)
   at
System.Windows.Media.RenderData.System.Windows.Media.Composition.DUCE.IResource.AddRefOnChannel(Channel
channel)
   at System.Windows.UIElement.RenderContent(RenderContext ctx, Boolean
isOnChannel)
   at System.Windows.Media.Visual.UpdateContent(RenderContext ctx,
VisualProxyFlags flags, Boolean isOnChannel)
   at System.Windows.Media.Visual.RenderRecursive(RenderContext ctx)
   at System.Windows.Media.Visual.UpdateChildren(RenderContext ctx,
ResourceHandle handle)
   at System.Windows.Media.Visual.RenderRecursive(RenderContext ctx)
   at System.Windows.Media.Visual.UpdateChildren(RenderContext ctx,
ResourceHandle handle)
   at System.Windows.Media.Visual.RenderRecursive(RenderContext ctx)
   at System.Windows.Media.Visual.UpdateChildren(RenderContext ctx,
ResourceHandle handle)
   at System.Windows.Media.Visual.RenderRecursive(RenderContext ctx)
   at System.Windows.Media.Visual.UpdateChildren(RenderContext ctx,
ResourceHandle handle)
   at System.Windows.Media.Visual.RenderRecursive(RenderContext ctx)
   at System.Windows.Media.Visual.UpdateChildren(RenderContext ctx,
ResourceHandle handle)
   at System.Windows.Media.Visual.RenderRecursive(RenderContext ctx)
   at System.Windows.Media.Visual.Render(RenderContext ctx, UInt32 childIndex)
   at System.Windows.Media.CompositionTarget.Compile(Channel channel)
   at
System.Windows.Media.CompositionTarget.System.Windows.Media.ICompositionTarget.Render(Boolean
inResize, Channel channel)
   at System.Windows.Media.MediaContext.Render(ICompositionTarget
resizedCompositionTarget)
   at System.Windows.Media.MediaContext.RenderMessageHandlerCore(Object
resizedCompositionTarget)
   at System.Windows.Media.MediaContext.RenderMessageHandler(Object
resizedCompositionTarget)
   at System.Windows.Media.MediaContext.Resize(ICompositionTarget
resizedCompositionTarget)
   at System.Windows.Interop.HwndTarget.OnResize() 
--- snip ---

After a bit of debugging it seems the pixel format is not correct.
The overflow happens when .NET MIL looks at BitmapImpl_GetPixelFormat() data.
It seems IMILBitmapSource::GetPixelFormat is expected as integer value (enum?),
not a GUID.
The code verifies the parameter value range to 0..0x2c and throws the overflow
error > 0x2c.

I don't have the WIC SDK but maybe there exist an enumerator for pixel formats
(which maps to GUIDs and vise versa).

So we need a separate impl to cope with different GetPixelFormat() at least.
Still BitmapImpl code could be reused.

Regards

[Bug 33384] Basic WPF applications using .NET 3.5 WPF fails to handle images (windowscodecs {7543696a-bc8d-46b0-5f81-8d95728972be} = IMILBitmapSource unsupported)

http://bugs.winehq.org/show_bug.cgi?id=33384

--- Comment #9 from Vincent Povirk  2013-04-14 18:33:38 CDT ---
There isn't any such enum, but most of the pixel formats that were there
originally differ only by the last byte, which happens to be within the needed
range: http://source.winehq.org/source/include/wincodec.idl#L177

Or if not, it shouldn't be hard to write tests to find the values.

[Bug 33384] Basic WPF applications using .NET 3.5 WPF fails to handle images (windowscodecs {7543696a-bc8d-46b0-5f81-8d95728972be} = IMILBitmapSource unsupported)

http://bugs.winehq.org/show_bug.cgi?id=33384

--- Comment #10 from Anastasius Focht  2013-04-15 16:45:08 CDT ---
Hello Vincent,

--- quote ---
There isn't any such enum, but most of the pixel formats that were there
originally differ only by the last byte, which happens to be within the needed
range: http://source.winehq.org/source/include/wincodec.idl#L177
--- quote ---

the last byte of the format GUID seems indeed to map to enum int value.

--- snip ---
Indexed1 = 1, 
Indexed2 = 2,
Indexed4 = 3,
Indexed8 = 4,
BlackWhite = 5,
Gray2 = 6,
Gray4 = 7,
Gray8 = 8,
...
--- snip ---

To avoid duplicating BitmapImpl/iface code I quickly hacked
BitmapImpl_QueryInterface() to set a hint in BitmapImpl struct when
IID_IMILBitmapSource is requested.
With that hint I was able to distinguish the out parameter type for
BitmapImpl_GetPixelFormat() -> WICPixelFormatGUID* vs. int* (enum).
I used a GUID to enum translator similar to what converter.c/FormatConverter
does (pixelformat).
That worked but the whole thing crashed later...

There is a vtable access/call after CopyPixels method offset which happens to
be "BitmapImpl_Lock" in Wine (4 params).
Unfortunately the stack got imbalanced by 8 bytes after the method call (only 2
params get pushed).
This hints at a different BitmapImpl vtable layout for MIL.

+0x00: QueryInterface
+0x04: AddRef
+0x08: Release
+0x0C: GetSize
+0x10: GetPixelFormat
+0x14: GetResolution
+0x18: CopyPalette/GetPalette
+0x1C: CopyPixels
+0x20: ???

--- snip ---
...
0024:CALL wpfgfx_v0300.MILQueryInterface(001babb0,0032dc34,0032dc9c)
ret=042f123d
0024:trace:wincodecs:BitmapImpl_QueryInterface
(0x1babb0,{7543696a-bc8d-46b0-5f81-8d95728972be},0x32dc9c)
0024:trace:wincodecs:BitmapImpl_AddRef (0x1babb0) refcount=4
0024:RET  wpfgfx_v0300.MILQueryInterface() retval=00000000 ret=042f123d
0024:CALL wpfgfx_v0300.MilResource_SendCommandBitmapSource(<unknown, check
return>) ret=042f23d7
0024:trace:wincodecs:BitmapImpl_GetPixelFormat (0x1babb0,0x32dbc4)
0024:trace:wincodecs:BitmapImpl_AddRef (0x1babb0) refcount=5
0024:trace:wincodecs:BitmapImpl_GetSize (0x1babb0,0x32dbb4,0x32dbb0)
0024:trace:wincodecs:BitmapImpl_GetResolution (0x1babb0,0x32dc40,0x32dc38)
0024:trace:wincodecs:BitmapImpl_Lock (0x1babb0,0x32db90,32dc38,0x180)
0024:trace:wincodecs:BitmapImpl_GetSize (0x1babb0,0x49907a8,0x49907ac)
0024:trace:wincodecs:BitmapImpl_GetPixelFormat (0x1babb0,0x49907b8)
0024:trace:wincodecs:BitmapImpl_GetResolution (0x1babb0,0x32db54,0x32db4c)
0024:trace:wincodecs:BitmapImpl_QueryInterface
(0x1babb0,{b1784d3f-8115-4763-13aa-32eddb68294a},0x49907ec)
0024:trace:wincodecs:BitmapImpl_AddRef (0x1babb0) refcount=6
0024:trace:seh:raise_exception code=c0000005 flags=0 addr=0x32dc39 ip=0032dc39
tid=0024
0024:trace:seh:raise_exception  info[0]=00000001
0024:trace:seh:raise_exception  info[1]=00000000
0024:trace:seh:raise_exception  eax=00000000 ebx=5403fd31 ecx=54008b30
edx=0499076d esi=0032dc48 edi=00000000
0024:trace:seh:raise_exception  ebp=04990768 esp=0032db9c cs=0023 ds=002b
es=002b fs=0063 gs=006b flags=00010202 
...
--- snip ---

Managed backtrace:

--- snip ---
System.AccessViolationException: Attempted to read or write protected memory.
This is often an indication that other memory is corrupt.
   at
System.Windows.Media.Composition.DUCE.UnsafeNativeMethods.MilResource_SendCommandBitmapSource(ResourceHandle
handle, BitmapSourceSafeMILHandle pBitmapSource, Boolean shareBitmap, Boolean
systemMemoryBitmap, IntPtr pChannel)
   at
System.Windows.Media.Composition.DUCE.Channel.SendCommandBitmapSource(ResourceHandle
imageHandle, BitmapSourceSafeMILHandle pBitmapSource, Boolean shareBitmap,
Boolean systemMemoryBitmap)
   at
System.Windows.Media.Imaging.BitmapSource.UpdateBitmapSourceResource(Channel
channel, Boolean skipOnChannelCheck)
   at System.Windows.Media.Imaging.BitmapSource.UpdateResource(Channel channel,
Boolean skipOnChannelCheck)
   at System.Windows.Media.Imaging.BitmapSource.AddRefOnChannelCore(Channel
channel)
   at
System.Windows.Media.Imaging.BitmapSource.System.Windows.Media.Composition.DUCE.IResource.AddRefOnChannel(Channel
channel)
   at
System.Windows.Media.RenderData.System.Windows.Media.Composition.DUCE.IResource.AddRefOnChannel(Channel
channel)
   at System.Windows.UIElement.RenderContent(RenderContext ctx, Boolean
isOnChannel)
   at System.Windows.Media.Visual.UpdateContent(RenderContext ctx,
VisualProxyFlags flags, Boolean isOnChannel)
   at System.Windows.Media.Visual.RenderRecursive(RenderContext ctx)
--- snip ---

I'm a bit out of ideas now ... even if IMILBitmapSource seems pretty similar to
IWICBitmapSource, some internal representation seems different.

Regards

[Bug 33384] Basic WPF applications using .NET 3.5 WPF fails to handle images (windowscodecs {7543696a-bc8d-46b0-5f81-8d95728972be} = IMILBitmapSource unsupported)

http://bugs.winehq.org/show_bug.cgi?id=33384

--- Comment #11 from Dmitry Timoshkov  2013-04-15 23:59:23 CDT ---
Created attachment 44194
  --> http://bugs.winehq.org/attachment.cgi?id=44194
IMILBitmapSource forwarding implementation

Attached IMILBitmapSource forwarding implementation seems to work, but the app
now crashes with:

Unhandled Exception: System.OverflowException: The image data generated an
overflow during processing. ---> System.ArithmeticException: Overflow or
underflow in the arithmetic operation.
   --- End of inner exception stack trace ---
   at MS.Internal.HRESULT.Check(Int32 hr)
   at
System.Windows.Media.Composition.DUCE.Channel.SendCommandBitmapSource(ResourceHandle
imageHandle, BitmapSourceSafeMILHandle pBitmapSource, Boolean shareBitmap,
Boolean systemMemoryBitmap)
...

[Bug 33384] Basic WPF applications using .NET 3.5 WPF fails to handle images (windowscodecs {7543696a-bc8d-46b0-5f81-8d95728972be} = IMILBitmapSource unsupported)

http://bugs.winehq.org/show_bug.cgi?id=33384

--- Comment #12 from Anastasius Focht  2013-04-16 02:01:06 CDT ---
Hello Dmitry,

your patch is obviously better to work with, thanks ;-)

--- quote ---
Unhandled Exception: System.OverflowException: The image data generated an
overflow during processing. ---> System.ArithmeticException: Overflow or
underflow in the arithmetic operation.
--- quote ---

The exception is thrown when no suitable pixelformat has been found in
IMILBitmapImpl_GetPixelFormat().
MIL substracts 1 from the returned pixelformat enum value and checks against
[0..max-1] pixelformat enum range.
If the default value "don't care" (=0) is returned it becomes negative.
This seems reasonable as it needs a specific format for further operations.

--- snip ---
if (IsEqualIID(&pixel_fmt_map[i].WIC_format, &This->pixelformat))
--- snip ---

Both params are REFGUID.
This works for me and the correct pixelformat 15 (GUID_WICPixelFormat32bppBGRA)
is returned:

--- snip ---
if (IsEqualGUID(pixel_fmt_map[i].WIC_format, &This->pixelformat))
...
--- snip ---

Anyway it ends at the same place where I currently stay.

Regards

[Bug 33384] Basic WPF applications using .NET 3.5 WPF fails to handle images (windowscodecs {7543696a-bc8d-46b0-5f81-8d95728972be} = IMILBitmapSource unsupported)

http://bugs.winehq.org/show_bug.cgi?id=33384

--- Comment #13 from Vincent Povirk  2013-04-18 16:34:27 CDT ---
Created attachment 44212
  --> http://bugs.winehq.org/attachment.cgi?id=44212
a test to figure out the iface signatures

The interface appears to have two more methods than IWICBitmapSource, one
taking a single argument and one taking 3 arguments, as determined by this
excessively terrible python script.

Between observing the behavior of the calling code with stub methods and black
box testing of the interface, we should be able to figure this out. Unless your
current crash isn't caused by this interface at all. (I'm not in a position to
run the code that's hitting this, but I may write some tests later.)

[Bug 33384] Basic WPF applications using .NET 3.5 WPF fails to handle images (windowscodecs {7543696a-bc8d-46b0-5f81-8d95728972be} = IMILBitmapSource unsupported)

http://bugs.winehq.org/show_bug.cgi?id=33384

--- Comment #14 from Anastasius Focht  2013-04-19 05:22:18 CDT ---
Hello folks,

--- quote ---
The interface appears to have two more methods than IWICBitmapSource, one
taking a single argument and one taking 3 arguments, as determined by this
excessively terrible python script.
--- quote ---

The missing method where it currently crashes has indeed one argument.
It looks like an out pointer as this memory is later accessed by WPF.

Creating a stub method and returning infamous 0xdeadbeef results in another
crash:

--- snip ---
$ WINEDEBUG=+tid,+seh,+snoop,+wincodecs wine ./WineTest.exe
...
0024:trace:wincodecs:BitmapImpl_CopyPixels (0x1ce114,0x32dc44,4,4,0x84ce6c)
0024:CALL wpfgfx_v0300.MILQueryInterface(001ce114,0032dc34,0032dc9c)
ret=042f123d
0024:trace:wincodecs:BitmapImpl_QueryInterface
(0x1ce114,{7543696a-bc8d-46b0-5f81-8d95728972be},0x32dc9c)
0024:trace:wincodecs:BitmapImpl_AddRef (0x1ce114) refcount=4
0024:RET  wpfgfx_v0300.MILQueryInterface() retval=00000000 ret=042f123d
0024:CALL wpfgfx_v0300.MilResource_SendCommandBitmapSource(<unknown, check
return>) ret=042f23d7
0024:trace:wincodecs:IMILBitmapImpl_GetPixelFormat (0x1ce110,0x32dbc4)
0024:trace:wincodecs:BitmapImpl_AddRef (0x1ce114) refcount=5
0024:trace:wincodecs:BitmapImpl_GetSize (0x1ce114,0x32dbb4,0x32dbb0)
0024:trace:wincodecs:BitmapImpl_GetResolution (0x1ce114,0x32dc40,0x32dc38)
0024:trace:wincodecs:IMILBitmapImpl_UnknownMethod1 (0x1ce110,0x32db90)
0024:trace:seh:raise_exception code=c0000005 flags=0 addr=0x5403f9dc
ip=5403f9dc tid=0024
0024:trace:seh:raise_exception  info[0]=00000000
0024:trace:seh:raise_exception  info[1]=deadbeef
0024:trace:seh:raise_exception  eax=deadbeef ebx=001ce110 ecx=00000000
edx=7bce4108 esi=00000000 edi=00000000
0024:trace:seh:raise_exception  ebp=0032db88 esp=0032db7c cs=0023 ds=002b
es=002b fs=0063 gs=006b flags=00010246
0024:trace:seh:call_stack_handlers calling handler at 0x7a00a2e7 code=c0000005
flags=0
0024:trace:seh:call_stack_handlers handler at 0x7a00a2e7 returned 1
0024:trace:seh:call_stack_handlers calling handler at 0x79edc3bc code=c0000005
flags=0
0024:trace:seh:call_stack_handlers handler at 0x79edc3bc returned 1
0024:trace:seh:call_stack_handlers calling handler at 0x79f908a2 code=c0000005
flags=0 
--- snip ---

The caller code (eax -> 0xdeadbeef returned from iface "unknown" method):

--- snip ---
Wine-dbg>disas
0x5403f9d9: movl    0x8(%ebp),%eax
0x5403f9dc: movl    0x0(%eax),%ecx
0x5403f9de: pushl    %eax
0x5403f9df: call    *0x4(%ecx)
0x5403f9e2: movl    0x8(%ebp),%eax
0x5403f9e5: movl    0x0(%eax),%ecx
0x5403f9e7: pushl    %eax
0x5403f9e8: call    *0x4(%ecx)
0x5403f9eb: movl    0xc(%ebp),%eax
0x5403f9ee: movl    0x8(%ebp),%ecx
--- snip ---

Looks pretty much like another interface/vtable, second method being called.

So I went forward and created another simple IUnknown based interface without
any additional methods and returned that.
Yay, it went much further ... but still crashed at some point :|

Interestingly only AddRef() and Release() are called (pairwise) which seems
reinforce the assumption that this might be indeed IUnknown based.
But strangely no QueryInterface() call?

--- snip ---
$ WINEDEBUG=+tid,+seh,+snoop,+wincodecs wine ./WineTest.exe
...
0024:CALL wpfgfx_v0300.MILQueryInterface(001ce468,0032dc34,0032dc9c)
ret=042f123d
0024:trace:wincodecs:BitmapImpl_QueryInterface
(0x1ce468,{7543696a-bc8d-46b0-5f81-8d95728972be},0x32dc9c)
0024:trace:wincodecs:BitmapImpl_AddRef (0x1ce468) refcount=4
0024:RET  wpfgfx_v0300.MILQueryInterface() retval=00000000 ret=042f123d
0024:CALL wpfgfx_v0300.MilResource_SendCommandBitmapSource(<unknown, check
return>) ret=042f23d7
0024:trace:wincodecs:IMILBitmapImpl_GetPixelFormat (0x1ce460,0x32dbc4)
0024:trace:wincodecs:BitmapImpl_AddRef (0x1ce468) refcount=5
0024:trace:wincodecs:BitmapImpl_GetSize (0x1ce468,0x32dbb4,0x32dbb0)
0024:trace:wincodecs:BitmapImpl_GetResolution (0x1ce468,0x32dc40,0x32dc38)
0024:trace:wincodecs:IMILBitmapImpl_UnknownMethod1 (0x1ce460,0x32db90)
0024:trace:wincodecs:IMILUnknown1Impl_AddRef (0x1ce464)
0024:trace:wincodecs:BitmapImpl_AddRef (0x1ce468) refcount=6
0024:trace:wincodecs:IMILUnknown1Impl_AddRef (0x1ce464)
0024:trace:wincodecs:BitmapImpl_AddRef (0x1ce468) refcount=7
0024:trace:wincodecs:IMILUnknown1Impl_Release (0x1ce464)
0024:trace:wincodecs:BitmapImpl_Release (0x1ce468) refcount=6
0024:trace:wincodecs:BitmapImpl_Release (0x1ce468) refcount=5
0024:RET 
wpfgfx_v0300.MilResource_SendCommandBitmapSource(00000010,001ce460,00000001,00000001,001a7858)
retval=00000000 ret=042f23d7
0024:CALL wpfgfx_v0300.MilCompositionEngine_ExitCompositionEngineLock()
ret=042f08c3
0024:RET  wpfgfx_v0300.MilCompositionEngine_ExitCompositionEngineLock()
retval=00000000 ret=042f08c3
0024:CALL
wpfgfx_v0300.MilChannel_BeginCommand(001a7858,0032da6c,0000000c,00000030)
ret=04dce89e
0024:RET  wpfgfx_v0300.MilChannel_BeginCommand() retval=00000000 ret=04dce89e
0024:CALL wpfgfx_v0300.MilChannel_AppendCommandData(001a7858,0083f888,00000008)
ret=04dcea12
0024:RET  wpfgfx_v0300.MilChannel_AppendCommandData() retval=00000000
ret=04dcea12
0024:CALL wpfgfx_v0300.MilCompositionEngine_EnterCompositionEngineLock()
ret=042f08c3 
...
0024:CALL wpfgfx_v0300.MilResource_SendCommand(0032deb4,00000010,001a7858)
ret=046790e0
0024:RET  wpfgfx_v0300.MilResource_SendCommand() retval=00000000 ret=046790e0
0024:CALL wpfgfx_v0300.MilResource_SendCommand(0032df20,00000010,001a7858)
ret=046790e0
0024:RET  wpfgfx_v0300.MilResource_SendCommand() retval=00000000 ret=046790e0
0024:CALL wpfgfx_v0300.MilResource_SendCommand(0032df8c,00000010,001a7858)
ret=046790e0
0024:RET  wpfgfx_v0300.MilResource_SendCommand() retval=00000000 ret=046790e0
0024:CALL wpfgfx_v0300.MilResource_SendCommand(0032dff8,00000010,001a7858)
ret=046790e0
0024:RET  wpfgfx_v0300.MilResource_SendCommand() retval=00000000 ret=046790e0
0024:CALL wpfgfx_v0300.MilChannel_CommitChannel(001a7858) ret=0467924c
0024:RET  wpfgfx_v0300.MilChannel_CommitChannel() retval=00000000 ret=0467924c
0024:CALL wpfgfx_v0300.MilComposition_SyncFlush(001a7858) ret=0467945c
0027:trace:seh:raise_exception code=c0000005 flags=0 addr=0x5404056b
ip=5404056b tid=0027
0027:trace:seh:raise_exception  info[0]=00000000
0027:trace:seh:raise_exception  info[1]=00000009
0027:trace:seh:raise_exception  eax=00000005 ebx=00000000 ecx=0497cc48
edx=54009440 esi=001ce46c edi=048de5bc
0027:trace:seh:raise_exception  ebp=048de590 esp=048de588 cs=0023 ds=002b
es=002b fs=0063 gs=006b flags=00010206
0027:trace:seh:call_stack_handlers calling handler at 0x7bc982ed code=c0000005
flags=0 
...
Unhandled exception: page fault on read access to 0x00000009 in 32-bit code
(0x5404056b).
Register dump:
 CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b
 EIP:5404056b ESP:048de588 EBP:048de590 EFLAGS:00010206(  R- --  I   - -P- )
 EAX:00000005 EBX:00000000 ECX:0497cc48 EDX:54009440
 ESI:001ce46c EDI:048de5bc
Stack dump:
0x048de588:  001ce46c 0497cc48 048de5a4 540405a8
0x048de598:  048de5bc 00000000 0497ac00 048de604
0x048de5a8:  54040140 048de5d0 0497ac00 00000000
0x048de5b8:  0497e500 00000000 00000000 00000000
0x048de5c8:  43a18000 43a18000 7f7fffff 7f7fffff
0x048de5d8:  048de610 00000005 00000000 00000000
000c: sel=0067 base=00000000 limit=00000000 32-bit r-x
Backtrace:
=>0 0x5404056b in wpfgfx_v0300 (+0x4056b) (0x048de590)
  1 0x540405a8 in wpfgfx_v0300 (+0x405a7) (0x048de5a4)
  2 0x54040140 in wpfgfx_v0300 (+0x4013f) (0x048de604)
  3 0x540400bb in wpfgfx_v0300 (+0x400ba) (0x048de6a8)
  4 0x54015944 in wpfgfx_v0300 (+0x15943) (0x048de6d8)
--- snip ---

Regards

[Bug 33384] Basic WPF applications using .NET 3.5 WPF fails to handle images (windowscodecs {7543696a-bc8d-46b0-5f81-8d95728972be} = IMILBitmapSource unsupported)

http://bugs.winehq.org/show_bug.cgi?id=33384

--- Comment #15 from Anastasius Focht  2013-04-19 05:31:24 CDT ---
Created attachment 44216
  --> http://bugs.winehq.org/attachment.cgi?id=44216
Enhanced version based on Dmitry's patch with unknown method/interface added

I attached an enhanced version based on Dmitry's patch with unknown
method/interface added, also including pixel format GUID comparison fix.

Still lots of uncertainty but at least it goes a bit further.

[Bug 33384] Basic WPF applications using .NET 3.5 WPF fails to handle images (windowscodecs {7543696a-bc8d-46b0-5f81-8d95728972be} = IMILBitmapSource unsupported)

http://bugs.winehq.org/show_bug.cgi?id=33384

--- Comment #16 from Anastasius Focht  2013-04-19 06:03:51 CDT ---
Hello folks,

a bit more info...

The caller code of current crash (with v2 patch):

--- snip ---
Wine-dbg>disas 0x54040560 
0x54040560: pushl    %esi
0x54040561: movl    0x2c(%ecx),%esi
0x54040564: testl    %esi,%esi
0x54040566: jz    0x5404056e
0x54040568: movl    0x0(%esi),%eax
0x5404056a: pushl    %esi
0x5404056b: call    *0x4(%eax)
0x5404056e: movl    0x8(%ebp),%eax
0x54040571: movl    %esi,0x0(%eax)
0x54040573: xorl    %eax,%eax

Wine-dbg>info reg
Register dump:
 CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b
 EIP:5404056b ESP:0495e588 EBP:0495e590 EFLAGS:00010202(  R- --  I   - - - )
 EAX:00000005 EBX:00000000 ECX:04a08048 EDX:54009440
 ESI:00200c4c EDI:0495e5bc
--- snip ---

Looks like interface/vtable method calling code again.
"eax" has a strange value which is read from "[esi]".

Dumping the memory around "esi" shows an interesting thing:

--- snip ---
Wine-dbg>x/10x $esi-20
0x00200c38:  00000068 00455355 7cbf61c0 7cbf61e4
0x00200c48:  7cbf6180 00000005 00000000 00000000
0x00200c58:  00000000 049a8038
--- snip ---

"00455355" looks familar? Yes, heap magic.
Resolving all other values shows this is indeed our BitmapImpl.

--- snip ---
00200c38   00000068  ; block size
00200c3c   00455355  ; "USE" heap magic
00200c40   7cc2b1c0  ; windowscodecs.IMILBitmapImpl_Vtbl
00200c44   7cc2b1e4  ; windowscodecs.IMILUnknown1Impl_Vtbl
00200c48   7cc2b180  ; windowscodecs.BitmapImpl_Vtbl
00200c4c   00000005  ; ref (refcount)
00200c50   00000000
--- snip ---

It seems the WPF code has knowledge of the underlying WIC/MIL bitmap object
implementation and tries to directly access the member(s).
Because Wine's BitmapImpl has a different layout, the "refcount" is mistaken as
interface/vtable pointer.

Regards

[Bug 33384] Basic WPF applications using .NET 3.5 WPF fails to handle images (windowscodecs {7543696a-bc8d-46b0-5f81-8d95728972be} = IMILBitmapSource unsupported)

http://bugs.winehq.org/show_bug.cgi?id=33384

Dmitry Timoshkov  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #44194|0                           |1
        is obsolete|                            |

--- Comment #17 from Dmitry Timoshkov  2013-04-22 02:10:56 CDT ---
Created attachment 44249
  --> http://bugs.winehq.org/attachment.cgi?id=44249
IMILBitmapSource forwarding implementation (try3)

This version of the implementation includes a test to play with, also it
simplifies a bit COM interface definitions by using standard macros.

Now the app goes even further.

[Bug 33384] Basic WPF applications using .NET 3.5 WPF fails to handle images (windowscodecs {7543696a-bc8d-46b0-5f81-8d95728972be} = IMILBitmapSource unsupported)

http://bugs.winehq.org/show_bug.cgi?id=33384

--- Comment #18 from Dmitry Timoshkov  2013-04-22 02:17:14 CDT ---
Also MIL pixel format enums seem to be documented here:
http://msdn.microsoft.com/en-us/library/dd341790.aspx

Although there is no mention of where they are actually used, or what MIL
abbreviation stands for.

[Bug 33384] Basic WPF applications using .NET 3.5 WPF fails to handle images (windowscodecs {7543696a-bc8d-46b0-5f81-8d95728972be} = IMILBitmapSource unsupported)

http://bugs.winehq.org/show_bug.cgi?id=33384

--- Comment #19 from Anastasius Focht  2013-04-22 18:33:38 CDT ---
Hello Dmitry,

thanks for the new patch v3.

--- quote ---
Now the app goes even further.
--- quote ---

Hmm... it still crashes here at the same place as my v2 patch in my previous
comment (caused by different BitmapImpl layout).

--- quote ---
...
0028:CALL wpfgfx_v0300.MilComposition_SyncFlush(001b62f8) ret=0467945c
002b:trace:seh:raise_exception code=c0000005 flags=0 addr=0x5404056b
ip=5404056b tid=002b
002b:trace:seh:raise_exception  info[0]=00000000
002b:trace:seh:raise_exception  info[1]=dea10004
002b:trace:seh:raise_exception  eax=dea10000 ebx=00000000 ecx=0495f7f0
edx=54009440 esi=001d290c edi=048de5bc
002b:trace:seh:raise_exception  ebp=048de590 esp=048de588 cs=0023 ds=002b
es=002b fs=0063 gs=006b flags=00010206
--- quote ---

So I added another IUnknown based interface, named "IMILUnknown2" at that
offset.
It crashed a bit further:

--- quote ---
0024:CALL wpfgfx_v0300.MilComposition_SyncFlush(001a70e8) ret=0467945c
0027:trace:wincodecs:IMILUnknown2Impl_AddRef (0x1d2f6c)
0027:trace:wincodecs:BitmapImpl_AddRef (0x1d2f68) refcount=6
0027:trace:seh:raise_exception code=c0000005 flags=0 addr=(nil) ip=00000000
tid=0027
0027:trace:seh:raise_exception  info[0]=00000000
0027:trace:seh:raise_exception  info[1]=00000000
0027:trace:seh:raise_exception  eax=001d2f6c ebx=00000000 ecx=7cbf6bd0
edx=048de57c esi=048de5d0 edi=048de5bc
0027:trace:seh:raise_exception  ebp=048de580 esp=048de564 cs=0023 ds=002b
es=002b fs=0063 gs=006b flags=00010206
0027:trace:seh:call_stack_handlers calling handler at 0x7bc98301 code=c0000005
flags=0
...
Backtrace:
=>0 0x00000000 (0x048de580)
  1 0x540405fb in wpfgfx_v0300 (+0x405fa) (0x048de58c)
  2 0x540405c7 in wpfgfx_v0300 (+0x405c6) (0x048de5a4)
  3 0x54040140 in wpfgfx_v0300 (+0x4013f) (0x048de604) 
--- quote ---

Caller code:

--- snip ---
5403039B    MOV ECX,DWORD PTR DS:[EAX] ; windowscodecs.IMILUnknown2Impl_Vtbl
...
5403039E    LEA EDX,[EBP-8]
540303A1    PUSH EDX
540303A2    LEA EDX,[EBP-4]
540303A5    PUSH EDX
540303A6    PUSH EAX
540303A7    CALL DWORD PTR DS:[ECX+0C] ; ??
540303AA    MOV EDI,EAX
540303AC    TEST EDI,EDI
540303AE    JL 5408C08B
540303B4    FLDZ 
--- snip ---

That new unknown method at offset 0x0C has 2 parameters which are of "out"
semantics again (the caller expects values written to supplied stack
addresses).
What if one of the already known interfaces/vtables are actually expected at
that offset BitmapImpl+0x0C (it's just a member order/layout issue)?

IWICBitmap and IMILBitmapSource have similar interfaces, except for 0x20+
offsets.

--- snip ---
+0x00: QueryInterface
+0x04: AddRef
+0x08: Release
+0x0C: GetSize
+0x10: GetPixelFormat
+0x14: GetResolution
+0x18: CopyPalette/GetPalette
+0x1C: CopyPixels
--- snip ---

IWICBitmap::GetSize() which lives at method offset 0x0C matches the signature
of the caller.
I moved the "dummy1" member in between to have IWICBitmap located at
BitmapImpl+0x0C

--- snip ---
typedef struct BitmapImpl {
    IMILBitmapSource IMILBitmapSource_iface;    // +0x00
    IMILUnknown1 IMILUnknown1_iface;            // +0x04
    void *dummy1;                               // +0x08
    IWICBitmap IWICBitmap_iface;                // +0x0C
    void *dummy2;
    void *dummy3;
--- snip ---

This crashes again with following trace:

--- snip ---
0028:CALL wpfgfx_v0300.MilComposition_SyncFlush(001ae5f8) ret=0467945c
002b:trace:wincodecs:BitmapImpl_AddRef (0x1d3024) refcount=6
002b:trace:wincodecs:BitmapImpl_GetSize (0x1d3024,0x48de57c,0x48de578)
002b:trace:wincodecs:BitmapImpl_QueryInterface
(0x1d3024,{0ccd7824-dc16-4d09-bca8-6b09c4ef5535},0x48de2e8)
002b:trace:wincodecs:BitmapImpl_Release (0x1d3024) refcount=5
002b:fixme:d3d9:Direct3DShaderValidatorCreate9 stub
002b:err:d3d:wined3d_buffer_map >>>>>>>>>>>>>>>>> GL_INVALID_VALUE (0x501) from
glMapBufferRange @ /home/focht/projects/wine/wine-git/dlls/wined3d/buffer.c /
1028
002b:err:d3d:wined3d_buffer_unmap >>>>>>>>>>>>>>>>> GL_INVALID_OPERATION
(0x502) from glFlushMappedBufferRange @
/home/focht/projects/wine/wine-git/dlls/wined3d/buffer.c / 1140
002b:fixme:wer:WerRegisterMemoryBlock (0x5418ebf0 6144) stub
002b:fixme:wer:WerRegisterMemoryBlock (0x5418ebe8 4) stub
002b:fixme:d3d:resource_check_usage Unhandled usage flags 0x8.
002b:trace:wincodecs:BitmapImpl_AddRef (0x1d3024) refcount=6
002b:trace:wincodecs:BitmapImpl_GetSize (0x1d3024,0x48de40c,0x48de408)
002b:trace:wincodecs:BitmapImpl_QueryInterface
(0x1d3024,{0ccd7824-dc16-4d09-bca8-6b09c4ef5535},0x48de178)
002b:trace:wincodecs:BitmapImpl_Lock (0x1d3024,0x48ddad0,48ddbd8,0x4968498)
002b:trace:wincodecs:BitmapImpl_QueryInterface
(0x1d3024,{181fa62c-0133-43d4-8d5c-639c3487783f},0x48dd994)
002b:trace:seh:raise_exception code=c0000005 flags=0 addr=(nil) ip=00000000
tid=002b
002b:trace:seh:raise_exception  info[0]=00000000
002b:trace:seh:raise_exception  info[1]=00000000
002b:trace:seh:raise_exception  eax=00000000 ebx=540395a9 ecx=00000000
edx=54024bb8 esi=048ddadc edi=048ddae8
002b:trace:seh:raise_exception  ebp=0494a468 esp=048dd9a0 cs=0023 ds=002b
es=002b fs=0063 gs=006b flags=00010282 
--- snip ---

Tidbit: these GL_INVALID_xxx messages seem to have been surfaced with recent
Wine commits (last days), I've not seen them before in that context.
Maybe this is related bug 33426 ?

Anyway, that looked better but I got stuck again - something was still wrong.
All members except for offset 0x04 were accessed in vtable manner.
So I moved the "dummy1" to offset 0x04 and settled with the following layout
(could be still very wrong but it produced best results):

--- snip ---
typedef struct BitmapImpl {
    IMILUnknown1 IMILUnknown1_iface;                // +0x00
    void *dummy1;                                   // +0x04
    IMILBitmapSource IMILBitmapSource_iface;        // +0x08
    IWICBitmap IWICBitmap_iface;                    // +0x0C
    void *dummy2;
    void *dummy3;
...
--- snip ---

I now hit the "deadxxxx" method stub from your patch.

--- snip ---
0024:CALL wpfgfx_v0300.MilComposition_SyncFlush(001a7f10) ret=0467945c
0027:trace:wincodecs:BitmapImpl_AddRef (0x1d2fac) refcount=6
0027:trace:wincodecs:BitmapImpl_GetSize (0x1d2fac,0x48de57c,0x48de578)
0027:trace:wincodecs:IMILBitmapImpl_QueryInterface
(0x1d2fa8,{0ccd7824-dc16-4d09-bca8-6b09c4ef5535},0x48de2e8)
0027:trace:wincodecs:BitmapImpl_Release (0x1d2fac) refcount=5
0027:fixme:d3d9:Direct3DShaderValidatorCreate9 stub
0027:err:d3d:wined3d_buffer_map >>>>>>>>>>>>>>>>> GL_INVALID_VALUE (0x501) from
glMapBufferRange @ /home/focht/projects/wine/wine-git/dlls/wined3d/buffer.c /
1028
0027:err:d3d:wined3d_buffer_unmap >>>>>>>>>>>>>>>>> GL_INVALID_OPERATION
(0x502) from glFlushMappedBufferRange @
/home/focht/projects/wine/wine-git/dlls/wined3d/buffer.c / 1140
0027:fixme:wer:WerRegisterMemoryBlock (0x5418ebf0 6144) stub
0027:fixme:wer:WerRegisterMemoryBlock (0x5418ebe8 4) stub
0027:fixme:d3d:resource_check_usage Unhandled usage flags 0x8.
0027:trace:wincodecs:BitmapImpl_AddRef (0x1d2fac) refcount=6
0027:trace:wincodecs:BitmapImpl_GetSize (0x1d2fac,0x48de40c,0x48de408)
0027:trace:wincodecs:IMILBitmapImpl_QueryInterface
(0x1d2fa8,{0ccd7824-dc16-4d09-bca8-6b09c4ef5535},0x48de178)
0027:trace:wincodecs:IMILBitmapImpl_UnknownMethod1 (0x1d2fa8,0x48ddad0)
0027:err:wincodecs:dead0004 0x1d2fb0
0027:trace:seh:raise_exception code=c0000005 flags=0 addr=0x4966ce0 ip=04966ce0
tid=0027
0027:trace:seh:raise_exception  info[0]=00000000
0027:trace:seh:raise_exception  info[1]=bd5a005c
0027:trace:seh:raise_exception  eax=dead0004 ebx=048dd990 ecx=001d2fb0
edx=048def48 esi=00000001 edi=048ddae8
0027:trace:seh:raise_exception  ebp=048ddbd8 esp=048dd990 cs=0023 ds=002b
es=002b fs=0063 gs=006b flags=00010206 
--- snip ---

There is still a strange QueryInterface with
"{0ccd7824-dc16-4d09-bca8-6b09c4ef5535}" in between (IID not documented?).

The caller code, leading to crash:

--- snip ---
54039229    MOV DWORD PTR SS:[EBP+8],ESI
5403922C    MOV EDX,DWORD PTR DS:[ECX] ; OFFSET windowscodecs.dea20000
5403922E    LEA ESI,[EBP+8]
54039231    PUSH ESI
54039232    PUSH EAX
54039233    PUSH ECX
54039234    CALL DWORD PTR DS:[EDX+0C] ; windowscodecs.dead0004
--- snip ---

Stack values:

--- snip ---
0495D974  002069E8 ; This 002069E8 -> 7CB83674 ; windowscodecs.dea20000
0495D978  00000001 ; arg1 ?
0495D97C  0495D990 ; arg2 -> stack "out" parameter?
...
0495D990  00000000
--- snip ---

Looks like another IUnknown based interface at BitmapImpl+0x10 + a stub method,
taking 2 params?

Your "stub" dea20000 interface pretty much matches the first 3 method
signatures of IUnknown:

--- snip ---
static HRESULT WINAPI dead0001(void *iface, REFIID iid, void **ppv)
{
    ERR("(%p,%s,%p)\n", iface, debugstr_guid(iid), ppv);
    *ppv = (void *)0xdead1234;
    return S_OK;
}
static HRESULT WINAPI dead0002(void *arg1)
{
    ERR("(%p)\n", arg1);
    return 0xdead0002;
}
static HRESULT WINAPI dead0003(void *arg1)
{
    ERR("(%p)\n", arg1);
    return 0xdead0003;
} 
--- snip ---

Changing your "dead0004" stub to:

--- snip ---
static HRESULT WINAPI dead0004(void *iface, void *arg1, void *arg2)
{
    ERR("(%p,%p,%p)\n", iface, arg1, arg2);
    return 0xdead0004;
}
--- snip ---

yields better results:

--- snip ---
003a:CALL wpfgfx_v0300.MilComposition_SyncFlush(001a7f10) ret=0467945c
003d:trace:wincodecs:BitmapImpl_AddRef (0x1ce3c4) refcount=6
003d:trace:wincodecs:BitmapImpl_GetSize (0x1ce3c4,0x48de57c,0x48de578)
003d:trace:wincodecs:IMILBitmapImpl_QueryInterface
(0x1ce3c0,{0ccd7824-dc16-4d09-bca8-6b09c4ef5535},0x48de2e8)
003d:trace:wincodecs:BitmapImpl_Release (0x1ce3c4) refcount=5
003d:fixme:d3d9:Direct3DShaderValidatorCreate9 stub
003d:err:d3d:wined3d_buffer_map >>>>>>>>>>>>>>>>> GL_INVALID_VALUE (0x501) from
glMapBufferRange @ /home/focht/projects/wine/wine-git/dlls/wined3d/buffer.c /
1028
003d:err:d3d:wined3d_buffer_unmap >>>>>>>>>>>>>>>>> GL_INVALID_OPERATION
(0x502) from glFlushMappedBufferRange @
/home/focht/projects/wine/wine-git/dlls/wined3d/buffer.c / 1140
003d:fixme:wer:WerRegisterMemoryBlock (0x5418ebf0 6144) stub
003d:fixme:wer:WerRegisterMemoryBlock (0x5418ebe8 4) stub
003d:fixme:d3d:resource_check_usage Unhandled usage flags 0x8.
003d:trace:wincodecs:BitmapImpl_AddRef (0x1ce3c4) refcount=6
003d:trace:wincodecs:BitmapImpl_GetSize (0x1ce3c4,0x48de40c,0x48de408)
003d:trace:wincodecs:IMILBitmapImpl_QueryInterface
(0x1ce3c0,{0ccd7824-dc16-4d09-bca8-6b09c4ef5535},0x48de178)
003d:trace:wincodecs:IMILBitmapImpl_UnknownMethod1 (0x1ce3c0,0x48ddad0)
003d:err:wincodecs:dead0004 (0x1ce3c8,0x1,0x48dd990)
003d:trace:wincodecs:IMILBitmapImpl_UnknownMethod1 (0x1ce3c0,0x48dd96c)
003d:err:wincodecs:dead0004 (0x1ce3c8,0x1,0x48dd8e8)
003d:trace:wincodecs:IMILBitmapImpl_GetPixelFormat (0x1ce3c0,0x48dd8b8)
003d:trace:wincodecs:BitmapImpl_GetSize (0x1ce3c4,0x48dd940,0x48dd944)
003d:err:wincodecs:dead0004 (0x1ce3c8,0x1,0x48dd8b4)
003d:trace:seh:raise_exception code=c0000005 flags=0 addr=(nil) ip=00000000
tid=003d
003d:trace:seh:raise_exception  info[0]=00000000
003d:trace:seh:raise_exception  info[1]=00000000
003d:trace:seh:raise_exception  eax=7cb7a7c4 ebx=04962cc8 ecx=001ce3b8
edx=00000000 esi=04962d70 edi=048dd900
003d:trace:seh:raise_exception  ebp=048dd8c4 esp=048dd8b4 cs=0023 ds=002b
es=002b fs=0063 gs=006b flags=00010206 
--- snip ---

That's progress ... but I'm not sure if we're on the right track here and how
much work is still left until we see the picture.

Regards

[Bug 33384] Basic WPF applications using .NET 3.5 WPF fails to handle images (windowscodecs {7543696a-bc8d-46b0-5f81-8d95728972be} = IMILBitmapSource unsupported)

http://bugs.winehq.org/show_bug.cgi?id=33384

--- Comment #20 from Dmitry Timoshkov  2013-04-23 01:03:48 CDT ---
(In reply to comment #19)
> Hmm... it still crashes here at the same place as my v2 patch in my previous
> comment (caused by different BitmapImpl layout).

Looks like the differences observed are caused by the fact that we use
different
versions of .NET. I used 'winetricks dotnet35', while it seems that your
version
is 3.0. Also your backtraces indicate a crash in wpfgfx_v0300, while I have
crashes in milcore.dll.

[Bug 33384] Basic WPF applications using .NET 3.5 WPF fails to handle images (windowscodecs {7543696a-bc8d-46b0-5f81-8d95728972be} = IMILBitmapSource unsupported)

http://bugs.winehq.org/show_bug.cgi?id=33384

Anastasius Focht  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #44216|0                           |1
        is obsolete|                            |

--- Comment #21 from Anastasius Focht  2013-04-23 15:51:33 CDT ---
Created attachment 44273
  --> http://bugs.winehq.org/attachment.cgi?id=44273
Patch "v4" based on Dmitry's "try3" with additional unknown interface/method
stub added and BitmapImpl layout tweak

Hello Dmitry,

--- quote ---
Looks like the differences observed are caused by the fact that we use
different versions of .NET. I used 'winetricks dotnet35', while it seems that
your version
is 3.0. Also your backtraces indicate a crash in wpfgfx_v0300, while I have
crashes in milcore.dll.
--- quote ---

Actually I was working with a .NET Framework 3.5 SP1 WINEPREFIX (even if the
crash backtraces suggest something with "3.0").

I created more prefixes for testing:

.NET 3.0
.NET 3.0 SP1
.NET 3.5 (winetricks install currently broken, recent msxml3 regression/new
bug? Needs native msmlx3 now)
.NET 3.5 SP1 (same as .NET 3.5, recreating didn't work anymore with plain
winetricks recipe)

To my surprise your patch combined with my findings _already_ worked in a .NET
3.0 prefix.
The WPF test application shows the "beta" picture. Yay!

It's .NET 3.5 SP1 MIL that seems to behave differently and needs further
investigation (different engine/usage?).

I attached a new version "v4" patch based on your "try3" with my findings.
The method stub "IMILUnknown2Impl_UnknownMethod1" has to return something
different than S_OK, otherwise it crashes in all 3.x prefixes.

Can you test it with your installation?
At least we've got something with surprisingly little implementation effort.

Regards

[Bug 33384] Basic WPF applications using .NET 3.5 WPF fails to handle images (windowscodecs {7543696a-bc8d-46b0-5f81-8d95728972be} = IMILBitmapSource unsupported)

http://bugs.winehq.org/show_bug.cgi?id=33384

--- Comment #22 from Dmitry Timoshkov  2013-04-23 20:08:06 CDT ---
(In reply to comment #21)
> To my surprise your patch combined with my findings _already_ worked in a .NET
> 3.0 prefix.
> The WPF test application shows the "beta" picture. Yay!
>
> It's .NET 3.5 SP1 MIL that seems to behave differently and needs further
> investigation (different engine/usage?).
>
> I attached a new version "v4" patch based on your "try3" with my findings.
> The method stub "IMILUnknown2Impl_UnknownMethod1" has to return something
> different than S_OK, otherwise it crashes in all 3.x prefixes.
>
> Can you test it with your installation?
> At least we've got something with surprisingly little implementation effort.

Heh, it also works here showing the "Beta" image! Impressive work as always
Anastasius :)

I suppose v4 patch is still not ready to be sent for inclusion yet, since
3.5 SP1 needs more work.

[Bug 33384] Basic WPF applications using .NET 3.5 WPF fails to handle images (windowscodecs {7543696a-bc8d-46b0-5f81-8d95728972be} = IMILBitmapSource unsupported)

http://bugs.winehq.org/show_bug.cgi?id=33384

--- Comment #23 from Dmitry Timoshkov  2013-04-24 02:54:11 CDT ---
(In reply to comment #21)
> Created attachment 44273 [details]
> Patch "v4" based on Dmitry's "try3" with additional unknown interface/method
> stub added and BitmapImpl layout tweak
> typedef struct BitmapImpl {
> - IMILUnknown1 IMILUnknown1_iface;
> - void *dummy1;
> - IMILBitmapSource IMILBitmapSource_iface;
> IWICBitmap IWICBitmap_iface;
> - IMILUnknown2 IMILUnknown2_iface;
> LONG ref;
> IWICPalette *palette;
> int palette_set;

Testing shows that dummy1 is really a refcount, and all 4 interfaces
respond to QI with IID_IUnknown, IID_IWICBitmap, IID_IWICBitmapSource,
IID_IMILBitmap and IID_IMILBitmapSource, returning the same iface pointers.
They do not respond to other IID_IMIL* ids (that could be found in PSDK's
uuid.lib): IID_IMILBitmapLock, IID_IMILBitmapScaler, IID_IMILBitmapConverter
and IID_IMILPalette.

[Bug 33384] Basic WPF applications using .NET 3.5 WPF fails to handle images (windowscodecs {7543696a-bc8d-46b0-5f81-8d95728972be} = IMILBitmapSource unsupported)

http://bugs.winehq.org/show_bug.cgi?id=33384

Dan Kegel  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #24 from Dan Kegel  2013-04-25 21:54:01 CDT ---
*** Bug 32906 has been marked as a duplicate of this bug. ***

[Bug 33384] Basic WPF applications using .NET 3.5 WPF fails to handle images (windowscodecs {7543696a-bc8d-46b0-5f81-8d95728972be} = IMILBitmapSource unsupported)

http://bugs.winehq.org/show_bug.cgi?id=33384

--- Comment #25 from leon  2013-05-08 07:40:45 CDT ---
Impressive work !!

Can you please update what is the status of this bug?
Is it fixed for .NET 3.5 or .NET 4.0 ?
Is the fix going to be included in Wine 1.6 or some earlier version?

[Bug 33384] Basic WPF applications using .NET 3.5 WPF fails to handle images (windowscodecs {7543696a-bc8d-46b0-5f81-8d95728972be} = IMILBitmapSource unsupported)

http://bugs.winehq.org/show_bug.cgi?id=33384

--- Comment #26 from Austin English  2013-05-08 12:37:55 CDT ---
(In reply to comment #25)
> Impressive work !!
>
> Can you please update what is the status of this bug?
> Is it fixed for .NET 3.5 or .NET 4.0 ?
> Is the fix going to be included in Wine 1.6 or some earlier version?

It's not yet fixed.

[Bug 33384] Basic WPF applications using .NET 3.5 WPF fails to handle images (windowscodecs {7543696a-bc8d-46b0-5f81-8d95728972be} = IMILBitmapSource unsupported)

http://bugs.winehq.org/show_bug.cgi?id=33384

--- Comment #27 from Anastasius Focht  2013-05-09 12:50:46 CDT ---
Hello folks,

maybe Dmitry can attach a cleaned up version, incorporating his additional
findings (comment #23) which should work for WPF 3.0 and 3.5
Though 3.5 SP1 behaviour still needs to be investigated ...

WPF 4.x doesn't seem have any problems connected to this bug (windowscodecs
interfaces), most likely due to different engines/code rewrite.

Regards

[Bug 33384] Basic WPF applications using .NET 3.5 WPF fails to handle images (windowscodecs {7543696a-bc8d-46b0-5f81-8d95728972be} = IMILBitmapSource unsupported)

http://bugs.winehq.org/show_bug.cgi?id=33384

--- Comment #28 from Dmitry Timoshkov  2013-05-10 22:51:02 CDT ---
(In reply to comment #27)
> maybe Dmitry can attach a cleaned up version, incorporating his additional
> findings (comment #23) which should work for WPF 3.0 and 3.5

The only change I did is replacing 'dummy1' by 'ref'. Probably your v4 variant
with this change could be sent to wine-patches + some other minor clean ups.

[Bug 33384] Basic WPF applications using .NET 3.5 WPF fails to handle images (windowscodecs {7543696a-bc8d-46b0-5f81-8d95728972be} = IMILBitmapSource unsupported)

http://bugs.winehq.org/show_bug.cgi?id=33384

Egor  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #29 from Egor  2013-07-02 06:17:01 CDT ---
Hi, all.
Perhaps I have same problem with my application using dynamic array via RPC.
I suppose the core of the problem is in corruption of internal Wine's data
during memory freeing.
I created topic in the forum -
http://forum.winehq.org/viewtopic.php?f=8&t=19251
I hope my info help developers to fix the bug faster.
Excuse me, if I mistake.

[Bug 33384] Basic WPF applications using .NET 3.5 WPF fails to handle images (windowscodecs {7543696a-bc8d-46b0-5f81-8d95728972be} = IMILBitmapSource unsupported)

http://bugs.winehq.org/show_bug.cgi?id=33384

[e-mail] changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

[Bug 33384] Basic WPF applications using .NET 3.5 WPF fails to handle images (windowscodecs {7543696a-bc8d-46b0-5f81-8d95728972be} = IMILBitmapSource unsupported)

http://bugs.winehq.org/show_bug.cgi?id=33384

--- Comment #30 from Dmitry Timoshkov  2013-10-18 21:36:12 CDT ---
5e78e0b695c91041d2f034b8cc9409bf4bd37144 could be considered a first draft
that has been committed.

[Bug 33384] Basic WPF applications using .NET 3.5 WPF fails to handle images (windowscodecs {7543696a-bc8d-46b0-5f81-8d95728972be} = IMILBitmapSource unsupported)

http://bugs.winehq.org/show_bug.cgi?id=33384

Anastasius Focht  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
      Fixed by SHA1|                            |5e78e0b695c91041d2f034b8cc9
                   |                            |409bf4bd37144
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #31 from Anastasius Focht  2013-10-19 04:54:38 CDT ---
Hello folks,

I think the initial goal to get the example app work with Wine builtin
windowscodecs has been met.
The example works for .NET Framework 3.0 and 3.5

Different behaviour for .NET Framework 3.5 SP1 MIL deserves its own bug.

Fixed by commit
http://source.winehq.org/git/wine.git/commitdiff/5e78e0b695c91041d2f034b8cc9...

Thanks Dmitry.

Regards

[Bug 33384] Basic WPF applications using .NET 3.5 WPF fails to handle images (windowscodecs {7543696a-bc8d-46b0-5f81-8d95728972be} = IMILBitmapSource unsupported)

http://bugs.winehq.org/show_bug.cgi?id=33384

--- Comment #32 from Anastasius Focht  2013-10-19 05:17:20 CDT ---
Hello folks,

created bug 34764 for crash in .NET Framework 3.5 SP1

Regards

[Bug 33384] Basic WPF applications using .NET 3.5 WPF fails to handle images (windowscodecs {7543696a-bc8d-46b0-5f81-8d95728972be} = IMILBitmapSource unsupported)

http://bugs.winehq.org/show_bug.cgi?id=33384

Alexandre Julliard  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #33 from Alexandre Julliard  2013-10-25 12:54:28 CDT ---
Closing bugs fixed in 1.7.5.

[Bug 33384] Basic WPF applications using .NET 3.5 WPF fails to handle images (windowscodecs {7543696a-bc8d-46b0-5f81-8d95728972be} = IMILBitmapSource unsupported)

http://bugs.winehq.org/show_bug.cgi?id=33384

Anastasius Focht  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #34 from Anastasius Focht  2013-11-17 15:14:34 CST ---
*** Bug 34937 has been marked as a duplicate of this bug. ***