http://bugs.winehq.org/show_bug.cgi?id=20466
Summary: Brothers In Arms Hell's Highway fails to start Product: Wine Version: 1.1.32 Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: xvachon@gmail.com
Created an attachment (id=24346) --> (http://bugs.winehq.org/attachment.cgi?id=24346) log
The issue I experienced when attempting to load the game is described here : http://www.whatwasithinking.co.uk/2008/10/08/brothers-in-arms-hells-highway-... .
In this how-to, they suggest to update/reinstall the graphics drivers and the PhysX module. My graphics driver is already updated to the latest (nvidia 190.42), and I fetched the latest bundle for the PhysX software. DirectX is automatically installed by the game, I therefore used winetricks to make sure I had the latest DX9 bundle. Despite that, I still get the same error message.
I browsed furthermore and have been refered to this : http://gbxforums.gearboxsoftware.com/showthread.php?p=1379618#post1379618 . This seems quite unusual to me, therefore before I test this, I would like to have some feedback on the solution proposed.
I have uploaded my console output, if it can help.
http://bugs.winehq.org/show_bug.cgi?id=20466
John Haywards normandy@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |normandy@web.de
--- Comment #1 from John Haywards normandy@web.de 2009-10-25 13:23:00 --- Can confirm this, same for me.
http://bugs.winehq.org/show_bug.cgi?id=20466
Ken Sharp kennybobs@o2.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kennybobs@o2.co.uk
--- Comment #2 from Ken Sharp kennybobs@o2.co.uk 2009-10-25 15:31:33 --- Is the application 32- or 64-bit?
http://bugs.winehq.org/show_bug.cgi?id=20466
--- Comment #3 from Xavier Vachon xvachon@gmail.com 2009-10-25 15:53:08 --- (In reply to comment #2)
Is the application 32- or 64-bit?
32-bit
http://bugs.winehq.org/show_bug.cgi?id=20466
--- Comment #4 from Jeff Zaroyko jeffz@jeffz.name 2009-10-25 16:58:18 --- It's not clear what the problem is from the log or the external links, can you compile from source and attach a backtrace please? http://wiki.winehq.org/Backtraces
http://bugs.winehq.org/show_bug.cgi?id=20466
Ken Sharp kennybobs@o2.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|kennybobs@o2.co.uk |
http://bugs.winehq.org/show_bug.cgi?id=20466
--- Comment #5 from Xavier Vachon xvachon@gmail.com 2009-10-27 17:08:16 --- I followed the howto on the page you referred me, however there must be something wrong because there is no backtrace coming out of it. Can you tell me what's wrong? Thanks!
xavier@xavier-pc /wine/biahh/drive_c/jeu/Binaries $ winedbg Wine-dbg>info process pid threads parent executable (all id:s are in hex) 0000000e 4 0000000a 'services.exe' 00000011 3 0000000e 'winedevice.exe' 00000017 6 00000000 'biahh.exe' 0000001c 1 00000017 'explorer.exe' Wine-dbg>attach 0x17 0xf77c342e: jmp 0xf77c3423 Wine-dbg>set $BreakOnFirstChance=0 Wine-dbg>cont Process of pid=0017 has terminated
http://bugs.winehq.org/show_bug.cgi?id=20466
--- Comment #6 from Vincent Povirk madewokherd@gmail.com 2009-10-30 15:25:40 --- It looks to me like you did that right.
You have to attach to the process before the crash dialog appears. If the dialog appears immediately when you start the program, you'll have to do this another way.
It could also be that some other (newly-created) process is crashing, or that the error isn't really a crash at all.
http://bugs.winehq.org/show_bug.cgi?id=20466
Vincent Povirk madewokherd@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |madewokherd@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=20466
--- Comment #7 from Xavier Vachon xvachon@gmail.com 2009-10-30 15:35:29 --- (In reply to comment #6)
It looks to me like you did that right.
You have to attach to the process before the crash dialog appears. If the dialog appears immediately when you start the program, you'll have to do this another way.
It could also be that some other (newly-created) process is crashing, or that the error isn't really a crash at all.
The crash dialog appears about 5 seconds after I launch the program. If there is a way to "pause" the execution of the program, I would have time to attach the process to winedbg and get a better backtrace
http://bugs.winehq.org/show_bug.cgi?id=20466
--- Comment #8 from Vincent Povirk madewokherd@gmail.com 2009-10-30 16:03:30 --- Instead of attaching, you can start the program using winedbg. Just run "winedbg biahh.exe" instead of "wine biahh.exe", and winedbg will create the process with itself attached.
The instructions don't say to do this because it's usually easier to run the program in the normal way.
http://bugs.winehq.org/show_bug.cgi?id=20466
--- Comment #9 from Xavier Vachon xvachon@gmail.com 2009-10-30 16:22:38 --- Created an attachment (id=24454) --> (http://bugs.winehq.org/attachment.cgi?id=24454) Backtrace
I did as you told, and I got this. Hope that it is more useful.
http://bugs.winehq.org/show_bug.cgi?id=20466
--- Comment #10 from Vincent Povirk madewokherd@gmail.com 2010-06-05 12:29:44 --- The backtrace is unhelpful (crash is in program code, not Wine code). Could you get a +seh,+tid,+relay log?
http://bugs.winehq.org/show_bug.cgi?id=20466
Xavier Vachon xvachon@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #24346|0 |1 is obsolete| | Attachment #24454|0 |1 is obsolete| |
--- Comment #11 from Xavier Vachon xvachon@gmail.com 2010-06-11 23:59:57 --- Created an attachment (id=28755) --> (http://bugs.winehq.org/attachment.cgi?id=28755) Log +seh,+tid,+relay
(In reply to comment #10)
The backtrace is unhelpful (crash is in program code, not Wine code). Could you get a +seh,+tid,+relay log?
Done. Tell me if you need anything else.
http://bugs.winehq.org/show_bug.cgi?id=20466
--- Comment #12 from Vincent Povirk madewokherd@gmail.com 2010-06-12 17:15:53 --- It seems like the important part of the log is garbled because another thread was writing at the same time.
You should be able to prevent that by appending to a file rather than redirecting normally, like this:
WINEDEBUG=+seh,+tid,+relay wine program.exe >> relay-log.txt 2>&1
Somehow I don't have much hope that it would show anything interesting, but I can't be sure.
http://bugs.winehq.org/show_bug.cgi?id=20466
Xavier Vachon xvachon@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #28755|0 |1 is obsolete| |
--- Comment #13 from Xavier Vachon xvachon@gmail.com 2010-06-13 10:54:05 --- Created an attachment (id=28802) --> (http://bugs.winehq.org/attachment.cgi?id=28802) Log +seh,+tid,+relay
(In reply to comment #12)
It seems like the important part of the log is garbled because another thread was writing at the same time.
You should be able to prevent that by appending to a file rather than redirecting normally, like this:
WINEDEBUG=+seh,+tid,+relay wine program.exe >> relay-log.txt 2>&1
Somehow I don't have much hope that it would show anything interesting, but I can't be sure.
Tell me if this log helps you.
http://bugs.winehq.org/show_bug.cgi?id=20466
--- Comment #14 from Vincent Povirk madewokherd@gmail.com 2010-06-13 11:04:29 --- Nope, no new information. Sorry. :(
http://bugs.winehq.org/show_bug.cgi?id=20466
--- Comment #15 from Xavier Vachon xvachon@gmail.com 2010-11-21 15:33:14 CST --- Still a bug in current git (1.3.7)
http://bugs.winehq.org/show_bug.cgi?id=20466
--- Comment #16 from Xavier Vachon xvachon@gmail.com 2010-11-22 22:21:01 CST --- I just tested in Windows 7, and the game works. Hence this is a Wine bug.
http://bugs.winehq.org/show_bug.cgi?id=20466
--- Comment #17 from John Haywards normandy@web.de 2011-01-13 09:43:56 CST --- Created an attachment (id=32835) --> (http://bugs.winehq.org/attachment.cgi?id=32835) +sehtidrelay, 1.3.11, with winetricks vcrun2005/physx
Wine 1.3.11, program still crashes. After winetricks vcrun2005 physx, the error dialog does not appear anymore, but program enters some endless loop. => see log (WITH winetricks)
http://bugs.winehq.org/show_bug.cgi?id=20466
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dank@kegel.com
--- Comment #18 from Dan Kegel dank@kegel.com 2011-01-13 10:46:21 CST --- I bet that game is protected by securom 7, so maybe this is now a dup of bug 7065
http://bugs.winehq.org/show_bug.cgi?id=20466
--- Comment #19 from John Haywards normandy@web.de 2011-01-13 11:14:47 CST --- Tried some no-disc-patch, same result. May be possible though...
http://bugs.winehq.org/show_bug.cgi?id=20466
GyB gyebro69@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gyebro69@gmail.com
--- Comment #20 from GyB gyebro69@gmail.com 2011-05-31 10:49:27 CDT --- (In reply to comment #18)
I bet that game is protected by securom 7, so maybe this is now a dup of bug 7065
The Steam version of BiA:HH behaves in the same way as the retail version: sometimes the game just hangs after starting. Occasionally I'm getting an error message about General Protection Fault just as described in comment #0. The Steam version of the game doesn't have any other DRM than Steam.
Wine-1.3.21 Physx, d3dx9, vcrun2005 were installed.
http://bugs.winehq.org/show_bug.cgi?id=20466
--- Comment #21 from Antonio López amlopezalonso@gmail.com 2011-06-11 11:16:40 CDT --- Created an attachment (id=35103) --> (http://bugs.winehq.org/attachment.cgi?id=35103) BIA - Hell's Highway crash popup
http://bugs.winehq.org/show_bug.cgi?id=20466
Antonio López amlopezalonso@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |amlopezalonso@gmail.com
--- Comment #22 from Antonio López amlopezalonso@gmail.com 2011-06-11 11:17:27 CDT --- Still in 1.3.22. Trying to start the game issues the attached popup, and the following console lines:
fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.VC80.CRT" (8.0.50727.762) fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.VC80.CRT" (8.0.50727.762) fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.VC80.CRT" (8.0.50727.762) fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.VC80.CRT" (8.0.50727.762) fixme:gameux:GameExplorerImpl_VerifyAccess (0x176c08, L"C:\Program Files\Ubisoft\Gearbox Software\Brothers in Arms - Hell's Highway\Binaries\biahh.exe", 0x1fdf378) fixme:win:EnumDisplayDevicesW ((null),0,0x1fddf98,0x00000000), stub! fixme:win:EnumDisplayDevicesW ((null),0,0x1fddea4,0x00000000), stub! fixme:win:EnumDisplayDevicesW ((null),0,0x1fdf30c,0x00000000), stub! fixme:dbghelp:elf_search_auxv can't find symbol in module fixme:dbghelp:validate_addr64 Unsupported address fffffffff7490000 fixme:faultrep:ReportFault 0x1fdf3ec 0x0 stub fixme:system:SystemParametersInfoW Unimplemented action: 59 (SPI_SETSTICKYKEYS) fixme:system:SystemParametersInfoW Unimplemented action: 53 (SPI_SETTOGGLEKEYS) fixme:system:SystemParametersInfoW Unimplemented action: 51 (SPI_SETFILTERKEYS) fixme:msvcr90:__clean_type_info_names_internal (0x2588e98) stub fixme:msvcr90:__clean_type_info_names_internal (0x37afb8) stub fixme:msvcr90:__clean_type_info_names_internal (0x346018) stub fixme:msvcr90:__clean_type_info_names_internal (0x20cc158) stub fixme:msvcr90:__clean_type_info_names_internal (0x31b168) stub fixme:msvcr90:__clean_type_info_names_internal (0x336018) stub fixme:msvcr90:__clean_type_info_names_internal (0x1039d190) stub
http://bugs.winehq.org/show_bug.cgi?id=20466
--- Comment #23 from Antonio López amlopezalonso@gmail.com 2011-06-11 14:03:55 CDT --- ProtectionID reports no protection system at all.
http://bugs.winehq.org/show_bug.cgi?id=20466
--- Comment #24 from Austin English austinenglish@gmail.com 2013-11-13 16:51:46 CST --- This is your friendly reminder that there has been no bug activity for 2 years. Is this still an issue in current (1.7.6 or newer) wine? If so, please attach the terminal output in 1.7.6 (see http://wiki.winehq.org/FAQ#get_log).
http://bugs.winehq.org/show_bug.cgi?id=20466
Andrey Gusev andrey.goosev@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |andrey.goosev@gmail.com
--- Comment #25 from Andrey Gusev andrey.goosev@gmail.com 2013-12-03 07:51:08 CST --- Confirming. Also have the same issue in 1.7.7
http://bugs.winehq.org/show_bug.cgi?id=20466
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |obfuscation Status|UNCONFIRMED |NEW CC| |focht@gmx.net Component|-unknown |ntdll Summary|Brothers In Arms Hell's |Brothers in Arms: Hell's |Highway fails to start |Highway crashes on startup | |(TLS slot index allocation | |must start at non-zero | |indexes) Ever confirmed|0 |1
--- Comment #26 from Anastasius Focht focht@gmx.net --- Hello folks,
confirming, I bought the game for a few bucks and had a look at it :)
First, it seems there exist at least two variants of this game - one with SecuROM protection (the 'gore' variant) and one without DRM scheme (the 'non-gore' variant).
'PC_Release_Ship':
--- snip --- -=[ ProtectionID v0.6.5.5 OCTOBER]=- (c) 2003-2013 CDKiLLER & TippeX Build 31/10/13-21:09:09 Ready... Scanning -> Z:\home\focht.wine\drive_c\Program Files\Ubisoft\Gearbox Software\Brothers in Arms - Hell's Highway\Binaries\biahh.exe File Type : 32-Bit Exe (Subsystem : Win GUI / 2), Size : 30102144 (01CB5280h) Byte(s) -> File Appears to be Digitally Signed @ Offset 01CB4000h, size : 01280h / 04736 byte(s) [File Heuristics] -> Flag : 00000100000000000000000000000101 (0x04000005) [Entrypoint Section Entropy] : 6.65 [Debug Info] Characteristics : 0x0 | TimeDateStamp : 0x48D5096D | MajorVer : 0 / MinorVer : 0 -> (0.0) Type : 2 -> CodeView | Size : 0x6F (111) AddressOfRawData : 0x213201C | PointerToRawData : 0x1B3E01C CvSig : 0x53445352 | SigGuid A8D678DE-5D6F-4786-BD2F11415E52AE0D Age : 0xA | Pdb : r:\gbxbuilder\Build268\Incremental\Binaries\Lib\PC_Release_Ship\PCLaunch-SumacGame.pdb
[!] SecuROM Detected - Version 07.38.0006 [!] Possible CD/DVD-Key or Serial Check -> cdkey [CompilerDetect] -> Visual C++ 8.0 (Visual Studio 2005) - Scan Took : 1.417 Second(s) [00000062Fh tick(s)] [533 scan(s) done]
--- snip ---
'PC_Release_Ship_LowGore' (german):
--- snip --- -=[ ProtectionID v0.6.5.5 OCTOBER]=- (c) 2003-2013 CDKiLLER & TippeX Build 31/10/13-21:09:09 Ready...
Scanning -> Z:\home\focht.wine\drive_c\Program Files\Ubisoft\Gearbox Software\Brothers in Arms - Hell's Highway\Binaries\biahh.exe File Type : 32-Bit Exe (Subsystem : Win GUI / 2), Size : 25448448 (01845000h) Byte(s) [File Heuristics] -> Flag : 00000100000000000000000000000000 (0x04000000) [Entrypoint Section Entropy] : 6.55 [Debug Info] Characteristics : 0x0 | TimeDateStamp : 0x48E26A2C | MajorVer : 0 / MinorVer : 0 -> (0.0) Type : 2 -> CodeView | Size : 0x79 (121) AddressOfRawData : 0x150B6B8 | PointerToRawData : 0x150B6B8 CvSig : 0x53445352 | SigGuid 1C8247A3-5444-42E8-B870DCBAED28AF99 Age : 0x1 | Pdb : c:\Workspace\sumac_releases_final_pc\Binaries\Lib\PC_Release_Ship_LowGore\PCLaunch-SumacGame.pdb
[!] Possible CD/DVD-Key or Serial Check -> cdkey [CompilerDetect] -> Visual C++ 8.0 (Visual Studio 2005) [!] File appears to have no protection or is using an unknown protection - Scan Took : 1.321 Second(s) [00000068Fh tick(s)] [533 scan(s) done] --- snip ---
Both versions exhibit the same problem (crash/backtrace).
Short version: I came to conclusion this is actually a bug in the game engine itself which just works due to the way Windows allocates/manages TLS indexes.
The crash happens shortly after the PhysX SDK got initialized. TLS slots are used in many places in the engine. At one point of the crash, data from one TLS slot accessed and the returned data is interpreted (casted) to member data. Unfortunately the data (pointer) from this slot doesn't belong to the game engine but Wine itself because it reserved the slot and data early before main entry point.
TLS slot data retrieval:
--- snip --- ... 004042C0 55 PUSH EBP 004042C1 8BEC MOV EBP,ESP 004042C3 6A FF PUSH -1 004042C5 68 58895101 PUSH biahh.01518958 004042CA 64:A1 00000000 MOV EAX,DWORD PTR FS:[0] 004042D0 50 PUSH EAX 004042D1 83EC 0C SUB ESP,0C 004042D4 53 PUSH EBX 004042D5 56 PUSH ESI 004042D6 57 PUSH EDI 004042D7 A1 C0E0A501 MOV EAX,DWORD PTR DS:[1A5E0C0] 004042DC 33C5 XOR EAX,EBP 004042DE 50 PUSH EAX 004042DF 8D45 F4 LEA EAX,DWORD PTR SS:[EBP-C] 004042E2 64:A3 00000000 MOV DWORD PTR FS:[0],EAX 004042E8 8BF9 MOV EDI,ECX 004042EA A1 1048A901 MOV EAX,DWORD PTR DS:[1A94810] ; *bad* TLS index 0 004042EF 50 PUSH EAX 004042F0 FF15 44F16701 CALL DWORD PTR DS:[<&KERNEL32.TlsGetValue>] 004042F6 85C0 TEST EAX,EAX ; not zero -> problem! 004042F8 75 78 JNZ SHORT biahh.00404372 --- snip ---
The problem is the slot index stored/referenced at 0x1A94810 After searching the whole process address space for all instructions referencing this address I found two code chunks:
Code that ought to allocate and zero-init the slot:
--- snip --- 0063605E CC INT3 0063605F CC INT3 00636060 FF15 D8F16701 CALL DWORD PTR DS:[<&KERNEL32.TlsAlloc>] 00636066 6A 00 PUSH 0 00636068 50 PUSH EAX 00636069 A3 1048A901 MOV DWORD PTR DS:[1A94810],EAX 0063606E FF15 40F16701 CALL DWORD PTR DS:[<&KERNEL32.TlsSetValue>] 00636074 C3 RETN 00636075 CC INT3 00636076 CC INT3 --- snip ---
Code that sets the TLS slot value:
--- snip --- 00401F10 55 PUSH EBP 00401F11 8BEC MOV EBP,ESP 00401F13 8B45 08 MOV EAX,DWORD PTR SS:[EBP+8] 00401F16 8B0D 1048A901 MOV ECX,DWORD PTR DS:[1A94810] 00401F1C 50 PUSH EAX 00401F1D 51 PUSH ECX 00401F1E FF15 40F16701 CALL DWORD PTR DS:[<&KERNEL32.TlsSetValue>] 00401F24 5D POP EBP 00401F25 C2 0400 RETN 4 --- snip ---
Looks good? In theory yes. In practice there are no references to these chunks to be found. It's dead code.
There are many similar code chunks for other TLS slots/indexes which can be either found by looking at +relay log (return addresses) or searching for referencing callers in disassembly. The only code that actually references the 'magic' slot is the function at 0x004042C0.
The initial value of 0x1A94810 is zero = TLS index zero. As already said earlier, Wine builtins allocate TLS indexes in their dll main/startup phase, hence index zero is taken and initialized to non-zero value. Due to the bug in the game, slot 0 data is read and misinterpreted, leading to later crash.
Fortunately the Win32 API specification itself says there is no guarantee that application code can grab TLS index zero.
MSDN: http://msdn.microsoft.com/en-us/library/windows/desktop/ms686801%28v=vs.85%2...
--- snip --- The threads of the process can use the TLS index in subsequent calls to the TlsFree, TlsSetValue, or TlsGetValue functions. The value of the TLS index should be treated as an opaque value; do not assume that it is an index into a zero-based array. --- snip ---
Either slot indexes that are allocated/exposed by TlsXXX API must start at non-zero values -> ntdll change, keeping index zero 'reserved' (with zero init value!).
A quick hack that also seems to be sufficient for the game is to 'steal' index zero for any further public allocation during process startup -> kernel32 ('singleton' TlsAlloc in process attach) before any higher level Wine builtins can grab it.
Both approaches allow to run the game flawlessly, no more crashes.
Regards
http://bugs.winehq.org/show_bug.cgi?id=20466
--- Comment #27 from Anastasius Focht focht@gmx.net --- Hello folks,
some addendum, I shorted the relevant disassembly snippet a bit too much in my first comment:
--- snip --- ... 004042EA A1 1048A901 MOV EAX,DWORD PTR DS:[1A94810] ; 0 -> TLS index zero 004042EF 50 PUSH EAX 004042F0 FF15 44F16701 CALL DWORD PTR DS:[<&KERNEL32.TlsGetValue>] 004042F6 85C0 TEST EAX,EAX 004042F8 75 78 JNZ SHORT biahh.00404372 ; current TLS slot data 004042FA 8B47 1C MOV EAX,DWORD PTR DS:[EDI+1C] 004042FD 8D70 04 LEA ESI,DWORD PTR DS:[EAX+4] ... <allocate some data structures off heap and initialize> ... 00404363 A1 1048A901 MOV EAX,DWORD PTR DS:[1A94810] 00404368 56 PUSH ESI ; new data 00404369 50 PUSH EAX ; TLS index zero 0040436A FF15 40F16701 CALL DWORD PTR DS:[<&KERNEL32.TlsSetValue>] 00404370 8BC6 MOV EAX,ESI ; return new data 00404372 8B4D F4 MOV ECX,DWORD PTR SS:[EBP-C] 00404375 64:890D 00000000 MOV DWORD PTR FS:[0],ECX 0040437C 59 POP ECX 0040437D 5F POP EDI 0040437E 5E POP ESI 0040437F 5B POP EBX 00404380 8BE5 MOV ESP,EBP 00404382 5D POP EBP 00404383 C3 RETN --- snip ---
ntdll/thread: initialize 'peb->TlsBitmap' with bit 0 already set ('reserved')
TlsGetValue() and TlsSetValue() should still work with index zero marked 'reserved' (no change required).
Regards
http://bugs.winehq.org/show_bug.cgi?id=20466
Andrew Emery aemery777@icloud.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |aemery777@icloud.com
--- Comment #28 from Andrew Emery aemery777@icloud.com ---
Either slot indexes that are allocated/exposed by TlsXXX API must start at non-zero values -> ntdll change, keeping index zero 'reserved' (with zero init value!).
A quick hack that also seems to be sufficient for the game is to 'steal' index zero for any further public allocation during process startup -> kernel32 ('singleton' TlsAlloc in process attach) before any higher level Wine builtins can grab it.
Hi Anastasius. Thanks for taking the time to figure this out. This is all new to me and I have never even heard of TLS. After reading the post 3 or 4 times my understanding is I need to "free up" the TLS index slot zero. Right? How do you change a TLS index value? Or how do you steal the zero index?
http://bugs.winehq.org/show_bug.cgi?id=20466
--- Comment #29 from Anastasius Focht focht@gmx.net --- Hello Andrew,
you need to reserve TLS slot 0 right from the beginning to avoid any TLS alloc stealing it (Wine builtins do that) before the game accesses it.
If you want to try it on your own there are some options. For a one-liner hack, have a look here:
http://source.winehq.org/git/wine.git/blob/HEAD:/dlls/ntdll/thread.c#l205
--- snip --- 212 HANDLE thread_init(void) 213 { ... 255 RtlInitializeBitMap( &tls_bitmap, peb->TlsBitmapBits, sizeof(peb->TlsBitmapBits) * 8 ); 256 RtlInitializeBitMap( &tls_expansion_bitmap, peb->TlsExpansionBitmapBits, ... 331 return exe_file; 332 } --- snip ---
Insert the following code _after_ line 255 to reserve slot 0 internally:
--- snip --- RtlSetBits( peb->TlsBitmap, 0, 1); --- snip ---
Recompile Wine and check with the game.
Regards
http://bugs.winehq.org/show_bug.cgi?id=20466
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks| |35837
http://bugs.winehq.org/show_bug.cgi?id=20466
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sitinh@gmail.com
--- Comment #30 from Anastasius Focht focht@gmx.net --- *** Bug 35877 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=20466
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Brothers in Arms: Hell's |Multiple broken apps and |Highway crashes on startup |games with incorrect TLS |(TLS slot index allocation |usage crash on startup (TLS |must start at non-zero |slot index allocation must |indexes) |start at non-zero indexes | |(Brothers in Arms: Hell's | |Highway, ProShow Gold 5)
--- Comment #31 from Anastasius Focht focht@gmx.net --- Hello folks,
refining summary as the list of affected apps and games grows.
$ wine --version wine-1.7.15-87-g5b55563
Regards
http://bugs.winehq.org/show_bug.cgi?id=20466
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download URL| |http://files.photodex.com/r | |elease/psgold_60_3410.exe Summary|Multiple broken apps and |Multiple broken apps and |games with incorrect TLS |games with incorrect TLS |usage crash on startup (TLS |usage crash on startup (TLS |slot index allocation must |slot index allocation must |start at non-zero indexes |start at non-zero indexes |(Brothers in Arms: Hell's |(Brothers in Arms: Hell's |Highway, ProShow Gold 5) |Highway, ProShow Gold 5/6)
--- Comment #32 from Anastasius Focht focht@gmx.net --- Hello folks,
it seems the successor, ProShow Gold 6 is broken in the same way.
Download: http://files.photodex.com/release/psgold_60_3410.exe
$ sha1sum psgold_60_3410.exe 66cbeeb2112bcb5408d6c67fe17c1dde452bc5b5 psgold_60_3410.exe
$ du -sh psgold_60_3410.exe 45M psgold_60_3410.exe
$ wine --version wine-1.7.15-107-gf3488d0
Regards
http://bugs.winehq.org/show_bug.cgi?id=20466
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |93920c3893709d0e8f9b96eaf05 | |e9333df89a7e7 Status|NEW |RESOLVED Resolution|--- |FIXED
--- Comment #33 from Anastasius Focht focht@gmx.net --- Hello folks,
this is fixed by commit http://source.winehq.org/git/wine.git/commitdiff/93920c3893709d0e8f9b96eaf05...
Thanks Jacek
Alexandre fixed the FLS part (same problem domain) with commit http://source.winehq.org/git/wine.git/commitdiff/598c5816d92d84e579b7554c4ce...
Regards
http://bugs.winehq.org/show_bug.cgi?id=20466
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks|35837 | CC| |zbw14159@126.com
--- Comment #34 from Anastasius Focht focht@gmx.net --- *** Bug 35837 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=20466
zbw14159@126.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|zbw14159@126.com |
http://bugs.winehq.org/show_bug.cgi?id=20466
zbw14159@126.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |zbw14159@126.com
https://bugs.winehq.org/show_bug.cgi?id=20466
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #35 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 1.7.16.
-
wine-bugs＠winehq.org