[Bug 6833] AIM Pro fails to load 'apExtCmp.dll' (MSVCRT_ungetc write operation on read-only section/mapping)
http://bugs.winehq.org/show_bug.cgi?id=6833 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |focht(a)gmx.net Component|shdocvw |msvcrt Summary|AIM Pro does not run, |AIM Pro fails to load |instead produces a |'apExtCmp.dll' |backtrace and quits |(MSVCRT_ungetc write | |operation on read-only | |section/mapping) --- Comment #9 from Anastasius Focht <focht(a)gmx.net> --- Hello folks, confirming. --- quote --- Now complains it can't find one if its dll's (apExtCmp.dll), which is in its directory. --- quote --- That's because an exception occurs during dll init/entry hence the dll is forced to unload. It seems the application (or rather a dll) plays some dirty tricks with msvcrt internal FILE structure/_iob. --- snip --- $ pwd /home/focht/.wine/drive_c/Program Files/AIM/AIM Pro $ WINEDEBUG=+tid,+seh,+relay,+msvcrt wine ./aimpro.exe >>log.txt 2>&1 ... 0026:Call KERNEL32.LoadLibraryExA(0153d0fc "apExtCmp.dll",00000000,00000000) ret=015229df 0026:Ret KERNEL32.LoadLibraryExA() retval=01150000 ret=015229df ... 0026:Call KERNEL32.LoadLibraryExA(01601000 "apExtRes.dll",00000000,00000000) ret=01528e36 0026:Ret KERNEL32.LoadLibraryExA() retval=01660000 ret=01528e36 0026:Call KERNEL32.FindResourceA(01660000,0153d4e0 "skin.xml",00000017) ret=01528e6b 0026:Ret KERNEL32.FindResourceA() retval=01666288 ret=01528e6b 0026:Call KERNEL32.SizeofResource(01660000,01666288) ret=01528ea1 0026:Ret KERNEL32.SizeofResource() retval=00008c05 ret=01528ea1 0026:Call KERNEL32.LoadResource(01660000,01666288) ret=01528eab 0026:Ret KERNEL32.LoadResource() retval=017d0f28 ret=01528eab 0026:Call KERNEL32.LockResource(017d0f28) ret=01528eb2 0026:Ret KERNEL32.LockResource() retval=017d0f28 ret=01528eb2 0026:Call msvcrt.??2(a)YAPAXI@Z(000000dc) ret=01528ec6 0026:Call ntdll.RtlAllocateHeap(00110000,00000000,000000dc) ret=7e357294 0026:Ret ntdll.RtlAllocateHeap() retval=01601028 ret=7e357294 0026:trace:msvcrt:MSVCRT_operator_new (220) returning 0x1601028 0026:Ret msvcrt.??2(a)YAPAXI@Z() retval=01601028 ret=01528ec6 ... 0026:Call msvcrt.strncmp(0153d768 "font",017d0faa "font=\"Tahoma:11:b\" fontcolor=\"0x003366\">21</default>\n </caption>\n\n // bmp,left,top,right,bottom \n <borderouter>\n <default img=\"bmp:oborder.bmp:2:2:2:2:1:b\">2,2,2,2</default>\n <archout img=\"clr:0xa8a8a8\">1,1,1,1</archout>\n </borderouter>\n \n <borderinner>\n <default im"...,00000004) ret=01522017 0026:Ret msvcrt.strncmp() retval=00000000 ret=01522017 0026:trace:msvcrt:MSVCRT_vfscanf_l 0x7e3c13a0 ("%[^:,\"><]:%d:%[^,\"><]") ... 0026:trace:seh:raise_exception code=c0000005 flags=0 addr=0x7e356ff9 ip=7e356ff9 tid=0026 0026:trace:seh:raise_exception info[0]=00000001 0026:trace:seh:raise_exception info[1]=017d0fbb 0026:trace:seh:raise_exception eax=017d0fbb ebx=7e3b9000 ecx=0033ee40 edx=00000022 esi=0000000a edi=7e369f59 0026:trace:seh:raise_exception ebp=0033ee58 esp=0033ee40 cs=0023 ds=002b es=002b fs=0063 gs=006b flags=00210206 0026:trace:seh:call_stack_handlers calling handler at 0x1538f24 code=c0000005 flags=0 0026:trace:seh:call_stack_handlers handler at 0x1538f24 returned 1 0026:trace:seh:call_stack_handlers calling handler at 0x1538eeb code=c0000005 flags=0 0026:trace:seh:call_stack_handlers handler at 0x1538eeb returned 1 0026:trace:seh:call_stack_handlers calling handler at 0x7bc9dcec code=c0000005 flags=0 ... 0026:trace:seh:__regs_RtlUnwind handler at 0x1538eeb returned 1 0026:exception in PE entry point (proc=0x119969b,module=0x1150000,reason=PROCESS_ATTACH,res=(nil)) 0026:Ret PE DLL (proc=0x119969b,module=0x1150000 L"apExtCmp.dll",reason=PROCESS_ATTACH,res=(nil)) retval=0 0026:Call PE DLL (proc=0x119969b,module=0x1150000 L"apExtCmp.dll",reason=PROCESS_DETACH,res=(nil)) 0026:Call KERNEL32.FreeLibrary(01660000) ret=01175c3b 0026:Ret KERNEL32.FreeLibrary() retval=00000001 ret=01175c3b --- snip --- Winedbg was rather unhelpful in this case. Most of the time it gets the disas/breakpoints wrong ... hence Ollydbg to the rescue. Stack before 'MSVCRT_fscanf' entry: --- snip --- 0033F028 7E3C13A0 stream = msvcrt.7E3C13A0 0033F02C 0153D794 format = "%[^:,"><]:%d:%[^,"><]" 0033F030 0033F104 0033F034 0033F08C 0033F038 0033F048 0033F03C 0033F124 0033F040 0021E95C 0033F044 0021E950 0033F048 00000000 --- snip --- Dump of MSVCRT_FILE/MSVCRT__iobuf: --- snip --- $+0 7E3C13A0 017D0FB0 ASCII "Tahoma:11:b" ... $+4 7E3C13A4 7FFFFFFF $+8 7E3C13A8 017D0FB0 ASCII "Tahoma:11:b" ... $+C 7E3C13AC 00000041 $+10 7E3C13B0 00000000 $+14 7E3C13B4 00000000 $+18 7E3C13B8 7FFFFFFF $+1C 7E3C13BC 00000000 --- snip --- Definition for reference: --- snip --- struct MSVCRT__iobuf { char* _ptr; int _cnt; // +4 char* _base; // +8 int _flag; // +C int _file; // +10 int _charbuf; // +14 int _bufsiz; // +18 char* _tmpfname; // +1C }; --- snip --- _base = _ptr = 0x017D0FB0 ... check all PE mappings, getting a hit: --- snip --- Address Size Section Contains 01660000 00001000 PE header 01661000 00001000 .text code 01662000 00001000 .rdata imports 01663000 00001000 .data data 01664000 0017F000 .rsrc resources 017E3000 00001000 .reloc relocations --- snip --- The address is located in '.rsrc' section of 'apExtRes.dll' which corresponds with earlier LoadResource() in trace log. After digging further I found the code that initializes the FILE structure/_iob array entry: --- snip --- 01533F90 56 PUSH ESI 01533F91 8B35 98A15301 MOV ESI,DWORD PTR DS:[<&MSVCRT._iob>] 01533F97 8BC1 MOV EAX,ECX 01533F99 57 PUSH EDI 01533F9A B9 08000000 MOV ECX,8 01533F9F 8BF8 MOV EDI,EAX 01533FA1 F3:A5 REP MOVS DWORD PTR ES:[EDI],DWORD PTR DS:[ESI] 01533FA3 8B0D 98A15301 MOV ECX,DWORD PTR DS:[<&MSVCRT._iob>] 01533FA9 5F POP EDI 01533FAA 5E POP ESI 01533FAB C741 0C 41000000 MOV DWORD PTR DS:[ECX+C],41 ; _flag 01533FB2 8B15 98A15301 MOV EDX,DWORD PTR DS:[<&MSVCRT._iob>] 01533FB8 8B4C24 04 MOV ECX,DWORD PTR SS:[ESP+4] 01533FBC 894A 08 MOV DWORD PTR DS:[EDX+8],ECX ; _base 01533FBF 8B15 98A15301 MOV EDX,DWORD PTR DS:[<&MSVCRT._iob>] 01533FC5 890A MOV DWORD PTR DS:[EDX],ECX 01533FC7 8B15 98A15301 MOV EDX,DWORD PTR DS:[<&MSVCRT._iob>] 01533FCD B9 FFFFFF7F MOV ECX,7FFFFFFF 01533FD2 894A 04 MOV DWORD PTR DS:[EDX+4],ECX ; _cnt 01533FD5 8B15 98A15301 MOV EDX,DWORD PTR DS:[<&MSVCRT._iob>] 01533FDB 894A 18 MOV DWORD PTR DS:[EDX+18],ECX ; _bufsiz 01533FDE C2 0400 RETN 4 --- snip --- MSVCRT_fscanf() gets it right with parsing and extracting the integer (including negative char filters from format string). During run-down, it needs to put back character(s) using MSVCRT_ungetc(). This is a write operation which won't work on memory/section mapped as read-only (see fault address 'info[1]=017d0fbb' / PE mappings). --- snip --- int CDECL MSVCRT_ungetc(int c, MSVCRT_FILE * file) { if (c == MSVCRT_EOF) return MSVCRT_EOF; MSVCRT__lock_file(file); if(file->_bufsiz == 0 && msvcrt_alloc_buffer(file)) file->_ptr++; if(file->_ptr>file->_base) { file->_ptr--; *file->_ptr=c; file->_cnt++; MSVCRT_clearerr(file); MSVCRT__unlock_file(file); return c; } MSVCRT__unlock_file(file); return MSVCRT_EOF; } --- snip --- $ sha1sum aimpro.exe 540a8b2a74224df29d32d98eb9741c8477a58d52 aimpro.exe $ du -sh aimpro.exe 13M aimpro.exe $ wine --version wine-1.7.8-220-g0bef543 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.
participants (1)
-
wine-bugs＠winehq.org