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.
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.
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.
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.
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.
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.
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.
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.
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.