[Bug 30185] SuperPower 2 demo crashes on launch

wine-bugs at winehq.org wine-bugs at winehq.org
Tue Feb 10 10:18:02 CST 2015


https://bugs.winehq.org/show_bug.cgi?id=30185

Anastasius Focht <focht at gmx.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |focht at gmx.net
          Component|-unknown                    |shell32

--- Comment #8 from Anastasius Focht <focht at gmx.net> ---
Hello folks,

confirming.

The app tries to read the icon resource 132 for 'Control Panel' from
shell32.dll via 'ExtractAssociatedIconW' which obviously fails because Wine
doesn't provide it.
Actually, there are multiple problems, the missing icon resource being the less
evil thing.

--- snip ---
$ WINEDEBUG=+tid,+seh,+relay,+resource,+icon wine ./joshua.exe >>log.txt 2>&1
...
0024:Starting thread proc 0x10051350 (arg=0x10092558)
0024:Call shell32.ExtractAssociatedIconW(00000000,10067e1c
L"shell32.dll",0083e9d8) ret=10056386
0024:Call user32.GetSystemMetrics(0000000b) ret=7e0cefb4
0024:Ret  user32.GetSystemMetrics() retval=00000020 ret=7e0cefb4
0024:Call user32.GetSystemMetrics(0000000c) ret=7e0cefc6
0024:Ret  user32.GetSystemMetrics() retval=00000020 ret=7e0cefc6
0024:Call user32.PrivateExtractIconsW(10067e1c
L"shell32.dll",00000089,00000020,00000020,0083e6c8,00000000,00000001,00000000)
ret=7e0cf0d5
0024:trace:icon:PrivateExtractIconsW L"shell32.dll" 137 32x32 0x83e6c8 (nil) 1
0x00000000
0024:trace:icon:ICO_ExtractIconExW L"shell32.dll", 137, 1 (nil) 0x00000000
0024:trace:icon:USER32_GetResourceTable 0x840000 0x83e4d0
0024:warn:icon:ICO_ExtractIconExW nIconIndex 137 is larger than iconDirCount 23
0024:Ret  user32.PrivateExtractIconsW() retval=00000000 ret=7e0cf0d5
0024:Call KERNEL32.GetModuleFileNameW(00000000,10067e1c,00000104) ret=7e0c3648
0024:trace:seh:raise_exception code=c0000005 flags=0 addr=0xf75129d1
ip=f75129d1 tid=0024
0024:trace:seh:raise_exception  info[0]=00000001
0024:trace:seh:raise_exception  info[1]=10067e1c
0024:trace:seh:raise_exception  eax=00115820 ebx=f7543970 ecx=00000054
edx=10067e20 esi=10067e1c edi=00000000
0024:trace:seh:raise_exception  ebp=0083e6c8 esp=0083e650 cs=0023 ds=002b
es=002b fs=0063 gs=006b flags=00010202
0024:trace:seh:call_stack_handlers calling handler at 0x7bc9ecab code=c0000005
flags=0 
--- snip ---

During fallback lookup it tries to update the user-provided buffer for the
module name which is unfortunately living in .rdata section = read-only,
causing the fault.
The app supplies a constant string literal as buffer, hence it never assumes
the buffer is being written to.

Memory map of dll in question:

--- snip ---
Address    Size      Owner              Section  Description
...
10000000   00001000  ginger_s 10000000           PE header
10001000   00066000  ginger_s 10000000  .text    code
10067000   00029000  ginger_s 10000000  .rdata   imports,exports
10090000   00004000  ginger_s 10000000  .data    data
10094000   00001000  ginger_s 10000000  .rsrc    resources
10095000   0000B000  ginger_s 10000000  .reloc   relocations
...
--- snip ---

App code showing hard-coded buffer and instance handle:

--- snip ---
10056360 83EC 7C            SUB ESP,7C
10056363 53                 PUSH EBX
10056364 55                 PUSH EBP
10056365 56                 PUSH ESI
10056366 57                 PUSH EDI
10056367 8D4424 10          LEA EAX,DWORD PTR SS:[ESP+10]
1005636B 50                 PUSH EAX
1005636C 68 1C7E0610        PUSH ginger_s.10067E1C ; const WCHAR* "shell32.dll"
10056371 33ED               XOR EBP,EBP            
10056373 55                 PUSH EBP               ; hInstance = NULL
10056374 894C24 28          MOV DWORD PTR SS:[ESP+28],ECX
10056378 C74424 1C 89000000 MOV DWORD PTR SS:[ESP+1C],89
10056380 FF15 50730610      CALL DWORD PTR
DS:[<&SHELL32.ExtractAssociatedIconW>
...
--- snip ---

Source:
http://source.winehq.org/git/wine.git/blob/e330a128d54613d2f7322cc3da2c8a5fea866992:/dlls/shell32/iconcache.c#l743

(the usual shell32 coding style/indenting inconsistencies aside)

--- snip ---
743 HICON WINAPI ExtractAssociatedIconW(HINSTANCE hInst, LPWSTR lpIconPath,
LPWORD lpiIcon)
744 {
745     HICON hIcon = NULL;
746     WORD wDummyIcon = 0;
747
748     TRACE("%p %s %p\n", hInst, debugstr_w(lpIconPath), lpiIcon);
749
750     if(lpiIcon == NULL)
751        lpiIcon = &wDummyIcon;
752
753     hIcon = ExtractIconW(hInst, lpIconPath, *lpiIcon);
754
755     if( hIcon < (HICON)2 )
756     { if( hIcon == (HICON)1 ) /* no icons found in given file */
...
768       if( hIcon == (HICON)1 )
769         *lpiIcon = 2; /* MSDOS icon - we found .exe but no icons in it */
770       else
771         *lpiIcon = 6; /* generic icon - found nothing */
772
773       if (GetModuleFileNameW(hInst, lpIconPath, MAX_PATH))
774         hIcon = LoadIconW(hInst, MAKEINTRESOURCEW(*lpiIcon));
775     }
776     return hIcon;
777 }
--- snip ---

MSDN:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms648067%28v=vs.85%29.aspx

Maybe on Windows the error path with user-buffer being updated is never hit due
to successful icon resource retrieval or a check is done if the user-buffer is
writeable.
Another explanation could be that the caller provided instance handle is not to
be used as fallback lookup.
It's not explicitly mentioned in remarks section of the function in MSDN where
the lookup sequence is explained.

$ sha1sum SP2Demo.zip 
fd589918790c82f363f9688842b59f0b7eab77b2  SP2Demo.zip

$ du -sh SP2Demo.zip 
165M    SP2Demo.zip

$ wine --version
wine-1.7.36-16-g748788f

Regards

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.



More information about the wine-bugs mailing list