February 2024 - Wine-Bugs - list.winehq.org

[Bug 56364] New: Crazy Factory: Hang when starting new game
by WineHQ Bugzilla Feb. 25, 2024

Feb. 25, 2024

https://bugs.winehq.org/show_bug.cgi?id=56364 Bug ID: 56364 Summary: Crazy Factory: Hang when starting new game Product: Wine Version: 9.2 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: user32 Assignee: wine-bugs(a)winehq.org Reporter: winebugzilla(a)tasossah.com Distribution: --- Created attachment 76101 --> https://bugs.winehq.org/attachment.cgi?id=76101 Minimal reproducible example: client Crazy Factory (AppID 13494, also known as Gadget Tycoon) hangs when starting a new game (Main Menu -> Offline game -> Freeplay). This is not a regression, but has last been tested under wine-staging 9.2. The game (client) spawns the server (CrazyFactoryServer.exe), waits for it to finish initialising by calling WaitForSingleObject() and WaitForInputIdle(), and then looks for its HWND so that it can communicate with it using window messages. I have written a standalone test case which reproduces this issue in Wine without requiring access to the original software. To reproduce: 1. Download client.c and server.c 2. Compile them as follows: - i686-w64-mingw32-gcc server.c -l ole32 -mwindows -o server.exe - i686-w64-mingw32-gcc client.c -o client.exe 3. Run client.exe Under Windows XP: client.exe reports "HWND Found" and exits. Under Wine: client.exe hangs on WaitForInputIdle(). The only way in Wine to get WaitForInputIdle() to return is by running everything in a virtual desktop, clicking on the start menu (which makes the server show up in the taskbar), clicking on the server in the taskbar, and then clicking on the server's window decoration and moving it around. Unfortunately, since the game itself runs in fullscreen, one can not click and drag the server window. Instead, to get the game working as-is, one can patch the binary (556b01b1afa97f39d361fe692bc3477a2577a25abf91f4a92e88a561bd5bd561 GadgetTycoon.exe) by setting the byte at offset 0x241ED from 0xFF to 0x01. This sets the dwMilliseconds parameter on WaitForInputIdle() to 0x01 (instead of INFINITE), which makes it time out, thus avoiding the hang and getting the game running. -- 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.

1 5

[Bug 56366] New: Worms Blast characters become grey/untextured
by WineHQ Bugzilla Feb. 24, 2024

Feb. 24, 2024

https://bugs.winehq.org/show_bug.cgi?id=56366 Bug ID: 56366 Summary: Worms Blast characters become grey/untextured Product: Wine Version: 9.3 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: iodreamify(a)gmail.com Distribution: --- Created attachment 76106 --> https://bugs.winehq.org/attachment.cgi?id=76106 wine log If you play a game vs cpu, when 2 characters are on screen, one or both of them will become grey as if they're untextured. Sometimes it's the whole character and sometime only their weapon or boat. It doesn't seem to be tied to any action or event, they'll become grey and then rendered correctly again with color. Tested this with Wine 9.3 inside Wine Steam. Also, in puzzle mode, when there's a single player, it doesn't seem to happen as fast or at all. Steps to reproduce: 1. open game 2. choose game vs cpu 3. select deathmatch 4. swim around in game a bit Kernel Version: 6.7.5-arch1-1 (64-bit) mesa 24.0.1-1 Graphics Platform: X11 Graphics Processor: Mesa Intel® HD Graphics 3000 -- 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.

1 1

[Bug 54346] New: (Multithreaded) Applications sometimes get heap corruption on exit due to ignoring critical sections in Wine
by WineHQ Bugzilla Feb. 24, 2024

Feb. 24, 2024

https://bugs.winehq.org/show_bug.cgi?id=54346 Bug ID: 54346 Summary: (Multithreaded) Applications sometimes get heap corruption on exit due to ignoring critical sections in Wine Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: dmusic Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com Distribution: --- (Multithreaded) Applications sometimes get heap corruption on exit due to ignoring critical sections in Wine. For instance dmloader:loader: 0118:warn:sync:RtlpWaitForCriticalSection process L"Z:\\home\\fgouget\\wine\\wine-gitlab\\dlls\\dmloader\\tests\\i386-windows\\dmloader_test.exe" is shutting down, returning STATUS_SUCCESS ... 0118:warn:sync:RtlpWaitForCriticalSection process L"Z:\\home\\fgouget\\wine\\wine-gitlab\\dlls\\dmloader\\tests\\i386-windows\\dmloader_test.exe" is shutting down, returning STATUS_SUCCESS 0118:err:sync:RtlLeaveCriticalSection section 00140074 "dlls/ntdll/heap.c: main process heap section" is not acquired Normally this does not cause the test to fail. But when running with WINEDEBUG=heap this frequently leads to heap corruption because: * Each call to the heap API triggers a heap validation. * Each heap_validate() call is requires taking the main process heap lock. * More contention makes the "not acquired" events more likely. * Leading to multiple threads manipulating the heap at the same time, thus causing corruption. Also, be aware that when heap corruption is detected due to WINEDEBUG=heap, Wine raises an exception which kills the process. Also note that although dmloader:loader looks like it is not multithreaded (no CreateThread() call), it loads dlls that create their own thread: * winealsa.drv/midi.c -> notify_thread * winealsa.drv/mmdevdrv.c -> alsa_timer_thread * winepulse.drv/mmdevdrv.c -> pulse_mainloop_thread, pulse_timer_cb ...etc. So this issue probably impacts most audio / multimedia applications and Wine tests. The "main process heap section is not acquired" errors most often look like they are caused by the following functions which are all called on DLL_PROCESS_DETACH: * msacm32.MSACM_WriteCache() calling RegSetValueExA() * ucrtbase.msvcrt_free_io() calling DeleteCriticalSection() when WINEDEBUG=heap Ignoring the critical sections during shutdown is intentional and was introduced by the 7def0f200f11 commit to fix bug 42470. See RtlpWaitForCriticalSection(): /* Don't allow blocking on a critical section during process termination */ if (RtlDllShutdownInProgress()) { WARN( "process %s is shutting down, returning STATUS_SUCCESS\n", debugstr_w(NtCurrentTeb()->Peb->ProcessParameters->ImagePathName.Buffer) ); return STATUS_SUCCESS; } However that commit also had to add todo_wine statements to kernel32:loader so it's not clear that is is correct. -- 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.

1 4

[Bug 56340] New: Update to 9.0.0-1.3 wine-mono from 8.1.0-1.2 wipes out Quicken 2011 (which needs .net) in Tumbleweed
by WineHQ Bugzilla Feb. 24, 2024

Feb. 24, 2024

https://bugs.winehq.org/show_bug.cgi?id=56340 Bug ID: 56340 Summary: Update to 9.0.0-1.3 wine-mono from 8.1.0-1.2 wipes out Quicken 2011 (which needs .net) in Tumbleweed Product: Wine Version: 9.1 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: timothyadams(a)ymail.com Distribution: --- A recent openSUSE Tumbleweed (rolling distro) snapshot pulled in a new version of wine-mono: 9.0.0-1.3, replacing 8.1.0-1.2. After I updated my system to this snapshot via "zypper dup," I discovered that I could no longer load Quicken 2011 in wine. The program would start to load, then crash. I have locked wine-mono and restored to an earlier snapshot with wine-mono 8.1.0-1.2. Quicken now loads properly again, with no other packages locked. Still, I thought I should file a bug to let you know. I have installed wine 9.1-1.1, wine-32bit 9.1-1.1, wine-gecko 2.47.4-1.2, and winetricks 20240105-1.2. -- 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.

1 7

[Bug 9221] Force Feedback doesn't work but does after little source modification
by WineHQ Bugzilla Feb. 24, 2024

Feb. 24, 2024

https://bugs.winehq.org/show_bug.cgi?id=9221 --- Comment #59 from groybe(a)gmail.com --- (In reply to Rémi Bernon from comment #51) > Sure, it's okay. I don't have the device so it's going to be hard to fix it > unless someone with it and a bit of technical knowledge can debug it > directly. > > Anyway thanks for the log, but would you mind adding the +hid channel too? > Not that it will make it magically fixable but I can have a look and see if > there's anything obvious. > > For instance something like running > `WINEDEBUG=+pid,+tid,+timestamp,+joycpl,+dinput,+hid wine control joy.cpl` > and then try running a couple of force feedback effects. The patch here fixes force feedback in Richard Burns Rally. https://bugs.winehq.org/show_bug.cgi?id=52714 GP Legends still has no ffb though. -- 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.

1 0

[Bug 55800] New: Fallout 3: on the experimental wow64 mode the terminal gets spammed with d3dx errors
by WineHQ Bugzilla Feb. 23, 2024

Feb. 23, 2024

https://bugs.winehq.org/show_bug.cgi?id=55800 Bug ID: 55800 Summary: Fallout 3: on the experimental wow64 mode the terminal gets spammed with d3dx errors Product: Wine Version: 8.18 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: m1m1k4tz(a)protonmail.com Distribution: --- While playing almost everything works good like the old wow64 mode but the terminal gets spammed with 0234:fixme:d3dx:D3DXLoadSurfaceFromMemory Unhandled filter 0x5. -- 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.

1 4

[Bug 56343] New: A regression since commit de492f9a342f398087f9f635fd5d9b5ae78b45eb (err:virtual:virtual_setup_exception stack overflow)
by WineHQ Bugzilla Feb. 23, 2024

Feb. 23, 2024

https://bugs.winehq.org/show_bug.cgi?id=56343 Bug ID: 56343 Summary: A regression since commit de492f9a342f398087f9f635fd5d9b5ae78b45eb (err:virtual:virtual_setup_exception stack overflow) Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: zefkerrigan(a)gmail.com Distribution: --- Since Wine commit https://gitlab.winehq.org/wine/wine/-/commit/de492f9a342f398087f9f635fd5d9b… my games have completely stopped launching. Wine just hangs at the very beginning anytime I try to run the games. I get this error message every single time: 0100:fixme:file:NtLockFile I/O completion on lock not implemented yet 0108:err:virtual:virtual_setup_exception stack overflow 2368 bytes addr 0x6fffffca7082 stack 0x7fffff6706c0 (0x7fffff670000-0x7fffff671000-0x7fffff770000) 010c:err:virtual:virtual_setup_exception stack overflow 2112 bytes addr 0x6fffffc810d0 stack 0x7401f00f07c0 (0x7401f00f0000-0x7401f00f1000-0x7401f01f0000) 0110:err:virtual:virtual_setup_exception stack overflow 2112 bytes addr 0x6fffffc810d0 stack 0x7401e7ef07c0 (0x7401e7ef0000-0x7401e7ef1000-0x7401e7ff0000) 0100:err:virtual:virtual_setup_exception stack overflow 896 bytes addr 0x6fffffc74c2b stack 0x7ffffe100c80 (0x7ffffe100000-0x7ffffe101000-0x7ffffe200000) This is completely the entire terminal output when running BG3 when this problem is present. I've tried running Baldur's Gate 3 and Mass Effect Legendary Edition, but the result is always the same. Everything launches fine if I use the previous commit https://gitlab.winehq.org/wine/wine/-/commit/165830c317b63999ee7e32b58c7359…. I don't know if you'll find this information useful, but I'm using Arch Linux, Radeon GPU with Mesa drivers. -- 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.

1 4

[Bug 56273] New: [Sway] winewayland.drv: cursor does not work in Dead Island 2
by WineHQ Bugzilla Feb. 23, 2024

Feb. 23, 2024

https://bugs.winehq.org/show_bug.cgi?id=56273 Bug ID: 56273 Summary: [Sway] winewayland.drv: cursor does not work in Dead Island 2 Product: Wine Version: 9.1 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: grabbend(a)hotmail.com Distribution: --- # Overview This cannot be reproduced with XWayland. The mouse works fine for ingame menus (meaning main menu & settings menu) and it even uses the game's custom cursor theme. However, you can't move the cursor while actually playing the game, it's stuck. # What I've tried Versions * WINE 9.1.r0.gc963c4141a0-1 * WINE 9.1-1 * WINE 9.1.r52.ge3431a02-1 Settings * Bottles > Advanced Display Settings > Fullscreen Mouse Capture: ON * Bottles > Advanced Display Settings > Take Focus: ON * Bottles > Advanced Display Settings > Mouse Wrap: ON # Reproduce 1. Make sure Wayland driver is enabled in Registry & DISPLAY= environment variable is empty. 2. Start Dead Island 2 3. Mouse cursor is stuck when you launch your saved game. -- 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.

1 2

[Bug 46263] New: Final Fantasy XI crashes after accepting EULA when using Ashita
by wine-bugs＠winehq.org Feb. 23, 2024

Feb. 23, 2024

https://bugs.winehq.org/show_bug.cgi?id=46263 Bug ID: 46263 Summary: Final Fantasy XI crashes after accepting EULA when using Ashita Product: Wine-staging Version: 3.21 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: winehq(a)foreversmall.com CC: leslie_alistair(a)hotmail.com, z.figura12(a)gmail.com Distribution: --- Created attachment 62965 --> https://bugs.winehq.org/attachment.cgi?id=62965 Terminal Output with backtrace of crash. When using Ashita with FFXI the game crashes shortly after accepting the EULA. I've confirmed this with all the versions of wine starting from version 3.0 stable, all the way up to 3.21 staging. The only way I've been able to get the game to launch is to compile wine myself with the following patch: https://gitlab.com/farmboy0/wine/commit/54aea128e91a6b03bff05e79d9a09bea572… Its very easy to recreate, use all the standard AppDB info to get FFXI setup. Download ashita from the website: https://git.ashitaxi.com/Ashita/Ashitav3-Launcher/raw/master/Ashita.exe >From here you need all the ashita pre-reqs: http://docs.ashitaxi.com/requirements/ Setup a config file with the settings ../Ashita/Config/Boot/ You can launch the game via this command: wine %path_to_Ashita%/injector.exe "%CONFIGFILE%.xml" If it properly loads then once you accept the EULA it will crash. -- 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.

2 17

[Bug 55584] New: Possibly incorrect handling of end_c in ARM64 process_unwind_codes
by WineHQ Bugzilla Feb. 23, 2024

Feb. 23, 2024

https://bugs.winehq.org/show_bug.cgi?id=55584 Bug ID: 55584 Summary: Possibly incorrect handling of end_c in ARM64 process_unwind_codes Product: Wine Version: unspecified Hardware: aarch64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)winehq.org Reporter: wine(a)corsix.org Distribution: --- In signal_arm64.c, unwind code 0xe5 (end_c) is considered in three places: 1. get_sequence_len 2. The while loop at the start of process_unwind_codes which skips codes 3. The main while loop in process_unwind_codes which performs codes Place 1 looks correct. Place 2 also looks fine, though I hope we'd never see end_c there (because we should only skip an amount identified by get_sequence_len). I am less certain about place 3 though; it currently treats end_c like end, whereas I think it should treat end_c like nop. The documentation at https://learn.microsoft.com/en-us/cpp/build/arm64-exception-handling?view=m… isn't great in describing end_c, though the example at "Unwind code for region 2" is a fairly clear example of end_c behaving like a nop for place 3. -- 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.

1 2