http://bugs.winehq.org/show_bug.cgi?id=10002
--- Comment #9 from Anastasius Focht focht@gmx.net 2008-03-31 16:34:29 --- Created an attachment (id=11771) --> (http://bugs.winehq.org/attachment.cgi?id=11771) better GetWindowModuleFileNameA/W to prevent error handler from crashing
Hello,
another problem is the crash when the error message box is dismissed. This is due to GetWindowModuleFileNameA() being a stub.
The illustrator error handler directly accesses the returned buffer contents without checking return value, leading to crash (and stack overflow).
--- illustrator crash trace --- .. 0009:Call user32.GetWindowModuleFileNameA(00030038,0033dff0,00000400) ret=004177bb 0009:fixme:win:GetWindowModuleFileNameA GetWindowModuleFileNameA(hwnd 0x30038, lpszFileName 0x33dff0, cchFileNameMax 1024) stub! 0009:Ret user32.GetWindowModuleFileNameA() retval=00000000 ret=004177bb 0009:trace:seh:raise_exception code=c0000005 flags=0 addr=0x4177d4 0009:trace:seh:raise_exception info[0]=00000001 0009:trace:seh:raise_exception info[1]=00000000 0009:trace:seh:raise_exception eax=00000000 ebx=603c5708 ecx=00000000 edx=0033dff0 esi=ffffffff edi=00030038 0009:trace:seh:raise_exception ebp=00030038 esp=0033dd7c cs=0073 ds=007b es=007b fs=0033 gs=003b flags=00210246 0009:trace:seh:call_stack_handlers calling handler at 0xbc3a7c code=c0000005 flags=0 0009:trace:seh:call_stack_handlers handler at 0xbc3a7c returned 1 0009:trace:seh:call_stack_handlers calling handler at 0xbf7558 code=c0000005 flags=0 0009:trace:seh:call_stack_handlers handler at 0xbf7558 returned 1 0009:trace:seh:call_stack_handlers calling handler at 0xbf740c code=c0000005 flags=0 0009:trace:seh:call_stack_handlers handler at 0xbf740c returned 1 0009:trace:seh:call_stack_handlers calling handler at 0xc06bad code=c0000005 flags=0 0009:trace:seh:call_stack_handlers handler at 0xc06bad returned 1 0009:trace:seh:call_stack_handlers calling handler at 0xc06b10 code=c0000005 flags=0 --- illustrator crash trace ---
The use of this API seems a bit awkward because it's obsoleted for long time (relict of Win9X) and doesn't work as initially intended for NT based systems. See http://support.microsoft.com/kb/228469 for more information.
I just deferred the work to GetModuleFileNameA/W() which is mentioned in KB article with default app instance handle supplied. This should mimick the behaviour for NT based systems and it keeps the app crash handler happy.
I don't think it makes much sense to emulate 9X behaviour. According to MSDN, GetWindowModuleFileName() will always fail on NT and later unless the window was created by the process that calls it. If you know some apps that break because they expect module names from remote processes, free to file bugs .. I seriously doubt it. To get the info for remote process window handles one could use GetWindowThreadProcessId and translate the pid into process module name by using psapi or other means - but that would be incompatible to NT based systems as described in MSDN.
Attached patch prevents the crash in error handler.
NOTE: This will not solve the cause of error but will allow a clean app exit (after another message box, which was previously not seen due to crash is dismissed). More stuff will follow (needs some time).
Regards