http://bugs.winehq.org/show_bug.cgi?id=14604
Summary: Fire Fight: Unhandled page fault crash upon startup Product: Wine Version: 1.1.1 Platform: PC URL: http://files.filefront.com/ffsw10exe/;6981503;/fileinfo. html OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: drakh@spamcop.net
Fire Fight shareware version 1.0 crashes with an unhandled page fault upon running the game's setup/launcher application "LOADER.EXE". The application's runtime log ends with the error "unable to hook keyboard [Kbd::init]".
http://bugs.winehq.org/show_bug.cgi?id=14604
drakh drakh@spamcop.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download
http://bugs.winehq.org/show_bug.cgi?id=14604
--- Comment #1 from drakh drakh@spamcop.net 2008-07-22 11:08:09 --- Created an attachment (id=14983) --> (http://bugs.winehq.org/attachment.cgi?id=14983) Backtrace of crash
http://bugs.winehq.org/show_bug.cgi?id=14604
--- Comment #2 from drakh drakh@spamcop.net 2008-07-22 11:11:34 --- Created an attachment (id=14984) --> (http://bugs.winehq.org/attachment.cgi?id=14984) Loader.exe runtime log
Generated automatically when the application is launched. Found in "\windows\temp".
http://bugs.winehq.org/show_bug.cgi?id=14604
drakh drakh@spamcop.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #14984|application/octet-stream |text/plain mime type| |
http://bugs.winehq.org/show_bug.cgi?id=14604
--- Comment #3 from Vitaliy Margolen vitaliy@kievinfo.com 2008-07-22 22:32:12 --- (In reply to comment #1)
Backtrace of crash
Is that all the messages from Wine? Nothing else is printed? If that's it, can you get the +hook,+dinput,+tid log please?
http://bugs.winehq.org/show_bug.cgi?id=14604
--- Comment #4 from drakh drakh@spamcop.net 2008-07-23 07:05:12 --- Created an attachment (id=15002) --> (http://bugs.winehq.org/attachment.cgi?id=15002) +hook,+dinput,+tid log
As with the backtrace, this is the complete console output piped to a file. +hook appeared to be the only one to generate any additional messages, +tid and +dinput did not seem to add anything beyond the basic backtrace even when tried separately.
http://bugs.winehq.org/show_bug.cgi?id=14604
Nicolas Le Cam niko.lecam@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |niko.lecam@gmail.com
--- Comment #5 from Nicolas Le Cam niko.lecam@gmail.com 2008-07-24 12:42:05 --- Tested with latest wine GIT, it doesn't crash.
It now works exactly as on Win2k where it doesn't start and produce the same FIREFGHT.LOG file containing an error about a [Text] label not contained in the cwe.ini file.
http://bugs.winehq.org/show_bug.cgi?id=14604
--- Comment #6 from drakh drakh@spamcop.net 2008-07-24 14:57:07 --- Nicolas, I think you're running "FIREFGHT.EXE" directly, without having first having set up the game with "LOADER.EXE". As far as I can tell, the bug is still there in the latest GIT.
As for running it on Windows, Fire Fight did not support Win2k until version 1.2, but I've been unable to locate a working copy of the shareware edition for download. In 1.0, it seems that the loader simply refuses to run unless Windows version is set to 9x.
http://bugs.winehq.org/show_bug.cgi?id=14604
--- Comment #7 from Nicolas Le Cam niko.lecam@gmail.com 2008-07-24 17:05:30 --- (In reply to comment #6)
Nicolas, I think you're running "FIREFGHT.EXE" directly, without having first having set up the game with "LOADER.EXE". As far as I can tell, the bug is still there in the latest GIT.
I did test both. No crash with LOADER.EXE nor FIREFGHT.EXE with a git from yesterday and a clean .wine directory.
After your comment I did a new test after a ./winetricks win98 and I can now reproduce the crash. It produces the same crash trying to access the exactly same address of memory (0x7983c362).
I will investigate.
http://bugs.winehq.org/show_bug.cgi?id=14604
--- Comment #8 from Nicolas Le Cam niko.lecam@gmail.com 2008-09-06 10:07:11 --- I did investigate a little bit. I don't think the crash is related to wine. It crashes on a CView:PostNcDestroy() call which object seems to already have been destroyed. The real problem seems to be that it isn't able to set a hook (SetWindowsHookExA) on WH_KEYBOARD (see subroutine at 0x0041F590)
I haven't been able to go further. winedbg is new to me and I haven't been able to get traces that help me much.
Hope someone with more skills than me will find out the problem and explain how he has been able to point & fix it.
http://bugs.winehq.org/show_bug.cgi?id=14604
--- Comment #9 from Nicolas Le Cam niko.lecam@gmail.com 2008-09-06 10:12:48 --- (In reply to comment #8)
I did investigate a little bit. I don't think the crash is related to wine. It crashes on a CView:PostNcDestroy() call which object seems to already have been destroyed. The real problem seems to be that it isn't able to set a hook (SetWindowsHookExA) on WH_KEYBOARD (see subroutine at 0x0041F590)
Sorry I didn't finished my sentence. IMHO, the crash in CView:PostNcDestroy() is a consequence of the inability of setting this hook added to a bad error handling in LOADER.EXE.
http://bugs.winehq.org/show_bug.cgi?id=14604
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |vitaliy@kievinfo.com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1
--- Comment #10 from Vitaliy Margolen vitaliy@kievinfo.com 2008-09-06 12:24:17 --- Confirming. This game does something that's not exactly allowed, according to msdn. Will have to write some tests to see how it should work. Program calls SetWindowsHookEx(WH_KEYBOARD, ptr, NULL, 0).
http://bugs.winehq.org/show_bug.cgi?id=14604
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |user32
http://bugs.winehq.org/show_bug.cgi?id=14604
--- Comment #11 from Vitaliy Margolen vitaliy@kievinfo.com 2008-09-06 17:06:06 --- What Wine is doing is correct for winnt+ I think this one will be a wontfix unless we really care about win9x compatibility.
http://bugs.winehq.org/show_bug.cgi?id=14604
--- Comment #12 from Nicolas Le Cam niko.lecam@gmail.com 2008-09-07 07:47:38 --- (In reply to comment #10)
Confirming. This game does something that's not exactly allowed, according to msdn. Will have to write some tests to see how it should work. Program calls SetWindowsHookEx(WH_KEYBOARD, ptr, NULL, 0).
I did see that too in the +relay traces but according to disassembly it can't be true. ThreadID can't be 0, as it calls SetWindowsHookEx with the exactly same global variable as other calls to it. I will try to debug it once more.
http://bugs.winehq.org/show_bug.cgi?id=14604
--- Comment #13 from Vitaliy Margolen vitaliy@kievinfo.com 2008-09-07 12:46:12 --- (In reply to comment #12)
Then something sets it to 0. If you really sure that all other calls to SetWindowsHookEx() really came from the game and not Wine.
http://bugs.winehq.org/show_bug.cgi?id=14604
--- Comment #14 from Nicolas Le Cam niko.lecam@gmail.com 2008-09-07 13:03:35 --- (In reply to comment #13) At least this other one 0009:Call user32.SetWindowsHookExA(00000005,0042e486,00000000,00000009) ret=0042e5cd comes from the game.
I will track this down (if I can).
http://bugs.winehq.org/show_bug.cgi?id=14604
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |focht@gmx.net
--- Comment #15 from Anastasius Focht focht@gmx.net 2008-09-07 14:17:57 --- Hello,
that custom loader is something that only works in Win9X or when compatibility mode is enabled in Win2K/XP. Some this FAQ: http://robyrt.coolserver.net/firefight.txt which mentions to enable the app compat mode for Win2K/XP.
When you run executables in compatibility mode, special application shims are loaded at runtime which adjust/fix various win32 API behaviour for brain damaged .. err legacy applications. That mess is something that Wine doesn't want to replicate in it's whole "glory".
That zero thread ID when SetWindowsHookEx() is called is intended (default init) because a system global hook is requested and the code ought to run in Win9X only.
According to MSDN:
http://msdn.microsoft.com/en-us/library/ms644990.aspx
--- quote --- hMod
[in] Handle to the DLL containing the hook procedure pointed to by the lpfn parameter. The hMod parameter must be set to NULL if the dwThreadId parameter specifies a thread created by the current process and if the hook procedure is within the code associated with the current process.
dwThreadId
[in] Specifies the identifier of the thread with which the hook procedure is to be associated. If this parameter is zero, the hook procedure is associated with all existing threads running in the same desktop as the calling thread. --- quote ---
The corresponding Wine code:
--- snip dll/user32/hook.c --- static HHOOK set_windows_hook( INT id, HOOKPROC proc, HINSTANCE inst, DWORD tid, BOOL unicode ) { ... if (!proc) { SetLastError( ERROR_INVALID_FILTER_PROC ); return 0; }
if (tid) /* thread-local hook */ { if (id == WH_JOURNALRECORD || id == WH_JOURNALPLAYBACK || id == WH_KEYBOARD_LL || id == WH_MOUSE_LL || id == WH_SYSMSGFILTER) { /* these can only be global */ SetLastError( ERROR_INVALID_PARAMETER ); return 0; } } else /* system-global hook */ { if (id == WH_KEYBOARD_LL || id == WH_MOUSE_LL) inst = 0; else if (!inst) { SetLastError( ERROR_HOOK_NEEDS_HMOD ); return 0; } } ... --- snip dll/user32/hook.c ---
Write a simple conformance test which calls SetWindowsHookEx(WH_KEYBOARD, ptr, NULL, 0). On Windows XP you should get the error as specified by MSDN. If you run the same test in Win9X or Win9X compat mode of Win2K/XP you should get a valid handle back otherwise the code wouldn't make any sense.
When you look at Wine code you see that a valid module handle is required for retrieving the module filename when a system global hook is requested (tid = 0). The logical choice would be to use the main module handle in place (when passed hMod == NULL). This is probably what happens in Win9X/compat mode.
Regards
http://bugs.winehq.org/show_bug.cgi?id=14604
--- Comment #16 from Anastasius Focht focht@gmx.net 2008-09-07 14:42:43 --- Hello,
just verified with a quick proof-of-concept patch, it seems to work that way. The loader starts (gui shows) and one can launch the game.
When the system global hook is requested (tid = 0) and you encounter NULL hMod, use the app module handle, e.g. GetModuleHandleW( NULL). A clean solution would be to do this only in Win9X mode (is_win9x()) and return error otherwise (as of now). I'm actually feeling uneasy when the number of such win9X compat tweaks rises. Such apps/games deserve to die ;-)
Regards
http://bugs.winehq.org/show_bug.cgi?id=14604
--- Comment #17 from Vitaliy Margolen vitaliy@kievinfo.com 2008-09-07 15:08:55 --- Yeah I've done that yesterday indeed it started and worked. And there are few tests like that already under if(0) with comment that they don't work on win9x.
http://bugs.winehq.org/show_bug.cgi?id=14604
--- Comment #18 from Nicolas Le Cam niko.lecam@gmail.com 2008-09-07 16:15:01 --- (In reply to comment #15) Thanks Anastasius for explanations. I already know that but I did think it wasn't the right direction to search. I explain here why I was fooled by disassembly, see :
First I saw that. Here is the call to SetWindowsHookExA. 0x0041f5a1: movl 0x00450ed8,%eax 0x0041f5a6: pushl %eax 0x0041f5a7: pushl $0x0 0x0041f5a9: pushl $0x41f510 0x0041f5ae: pushl $0x2 0x0041f5b0: call *0x46eae8 -> 0x7ebbdbe0 SetWindowsHookExA [/home/nlecam/Development/Wine/Sources/wine/dlls/user32/hook.c:477] in user32 0x0041f5b6: movl %eax,0x00452364
tid is retrieved from memory (0x00450ed8).
So I searched for 0x00450ed8 references. I found a first one here : 0x00418a3b: call *0x46e7ec -> 0x7ee8c2e0 GetCurrentThreadId in kernel32 0x00418a41: movl %eax,0x00450ed8
And a second one here : 0x004203e5: movl 0x00450ed8,%eax 0x004203ea: pushl %eax 0x004203eb: pushl $0x0 0x004203ed: pushl $0x4202c0 0x004203f2: pushl $0x7 0x004203f4: call *0x46eae8 -> 0x7ebbdbe0 SetWindowsHookExA [/home/nlecam/Development/Wine/Sources/wine/dlls/user32/hook.c:477] in user32 0x004203fa: movl %eax,0x004526cc
No other references to that global variable. So I thought it shouldn't be possible for tid to be nil. Except for some write bound overrun that was crushing it before it was used. I did search for such write operations on this area. I didn't find anything. So I decided to look at the execution flow just after your comments and here what I have found :
0x004189ee: call 0x0041f590 (Set keyboard hook, use 0x00450ed8 as tid) 0x004189f3: call 0x004203c0 (Set mouse hook, use 0x00450ed8 as tid) 0x004189f8: cmpl $0,0xc(%ebp) 0x004189fc: jz 0x00418a0a 0x004189fe: movl 0x20(%ebp),%eax 0x00418a01: pushl %eax 0x00418a02: call 0x004178b0 0x00418a07: addl $4,%esp 0x00418a0a: call 0x00420930 0x00418a0f: pushl $0x20000 Wine-dbg> 0x00418a14: call 0x004210a0 0x00418a19: addl $4,%esp 0x00418a1c: pushl $0x20000 0x00418a21: call 0x00421510 0x00418a26: addl $4,%esp 0x00418a29: movl $0x0,0x00450ef8 0x00418a33: movl 0x8(%ebp),%eax 0x00418a36: movl %eax,0x00450ee4 0x00418a3b: call *0x46e7ec -> 0x7ee8c2e0 GetCurrentThreadId in kernel32 0x00418a41: movl %eax,0x00450ed8
So this programs calls two times SetWindowsHookExA using a global variable as the tid value. Then set this global variable using GetCurrentThreadId. As you said, "such apps/games deserve to die ;-)".
If a patch seems useful, I can provide one that add win9x compat mode to SetWindowsHookExA. But as Anastasius, I'm not comfortable with win9x compatibility tweaks.
http://bugs.winehq.org/show_bug.cgi?id=14604
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- URL|http://files.filefront.com/ |http://download.cnet.com/Fi |ffsw10exe/;6981503;/fileinf |re-Fight-demo/3000-7563_4-1 |o.html |0000951.html
--- Comment #19 from Austin English austinenglish@gmail.com 2010-06-03 23:23:16 --- Still present.
http://bugs.winehq.org/show_bug.cgi?id=14604
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|vitaliy@kievinfo.com |
http://bugs.winehq.org/show_bug.cgi?id=14604
Rafal Stanilewicz washuu@eastnews.com.pl changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |washuu@eastnews.com.pl
--- Comment #20 from Rafal Stanilewicz washuu@eastnews.com.pl 2012-04-12 02:08:04 CDT --- in wine 1.5.1 the game run from Loader.exe (not from firefght.exe) is completely playable.
I downloaded the plain version from http://www.classicdosgames.com/game/Fire_Fight.html, because cnet.com's installer is adware packed.
Please someone retest this.
http://bugs.winehq.org/show_bug.cgi?id=14604
--- Comment #21 from Rafal Stanilewicz washuu@eastnews.com.pl 2012-04-12 02:13:45 CDT --- in wine 1.5.1 the game run from Loader.exe (not from firefght.exe) is completely playable.
I downloaded the plain version from http://www.classicdosgames.com/game/Fire_Fight.html, because cnet.com's installer is adware packed.
Please someone retest this.
http://bugs.winehq.org/show_bug.cgi?id=14604
--- Comment #22 from Austin English austinenglish@gmail.com 2012-04-12 06:08:57 CDT --- (In reply to comment #21)
in wine 1.5.1 the game run from Loader.exe (not from firefght.exe) is completely playable.
I downloaded the plain version from http://www.classicdosgames.com/game/Fire_Fight.html, because cnet.com's installer is adware packed.
Please someone retest this.
Yes, though I see the same in 1.3.0, so either fixed for a while, or this version is different (FIREFGHT.exe also works).
https://bugs.winehq.org/show_bug.cgi?id=14604
Jarkko K jarkko_korpi@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jarkko_korpi@hotmail.com
--- Comment #23 from Jarkko K jarkko_korpi@hotmail.com --- I downloaded from http://www.classicdosgames.com/game/Fire_Fight.html
Fire Fight v1.2 Demo (8,497,240 bytes) 31 July 1997 Win9x
I couldnt see 1.3 version, which is mentioned here.
I got couple of these while installing, but it installed.
err:ntdll:RtlpWaitForCriticalSection section 0x7e7ac780 "syslevel.c: Win16Mutex" wait timed out in thread 0033, blocked by 0035, retrying (60 sec)
Works for me.
Wine 1.7.18
https://bugs.winehq.org/show_bug.cgi?id=14604
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |WORKSFORME
--- Comment #24 from Austin English austinenglish@gmail.com --- WORKSFORME.
https://bugs.winehq.org/show_bug.cgi?id=14604
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #25 from Austin English austinenglish@gmail.com --- Closing.
-
wine-bugs＠winehq.org