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

wine-bugs at winehq.org wine-bugs at winehq.org
Mon Apr 22 18:33:38 CDT 2013


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

--- Comment #19 from Anastasius Focht <focht at gmx.net> 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

-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.



More information about the wine-bugs mailing list