October 2025 - Wine-Bugs - list.winehq.org

[Bug 58749] New: Delayed startup of wine processes in Wine-10.16
by WineHQ Bugzilla Oct. 31, 2025

Oct. 31, 2025

http://bugs.winehq.org/show_bug.cgi?id=58749 Bug ID: 58749 Summary: Delayed startup of wine processes in Wine-10.16 Product: Wine Version: 10.16 Hardware: x86-64 OS: Linux Status: NEW Keywords: regression, source Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)winehq.org Reporter: gyebro69(a)gmail.com CC: z.figura12(a)gmail.com Regression SHA1: 7bb835b3482de5e66515b5a0bd8dce8dc9844c93 Distribution: ArchLinux There is a noticeable delay (8-10s) when starting any applications in Wine-10.16, e.g. wine regedit. No disk activity or high cpu usage from wineserver can be seen with htop, there is just a delay before the actual program appears on the screen. Reproduced with 32bit-only, shared WOW and the new WOW64 prefixes alike. Started happening after commit 7bb835b3482de5e66515b5a0bd8dce8dc9844c93 ntdll: Use in-process synchronization objects. The issue doesn't exist with the previous commit or when the ntsync kernel module is not loaded. I'm using Arch Linux and tested with both the current official kernel on Arch (6.16.10-zen1-1-zen) and with kernel-6.17-cachyos-bore. -- 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 6

[Bug 58852] New: Minimised applications are restored with -4 vertical pixels (redux).
by WineHQ Bugzilla Oct. 31, 2025

Oct. 31, 2025

http://bugs.winehq.org/show_bug.cgi?id=58852 Bug ID: 58852 Summary: Minimised applications are restored with -4 vertical pixels (redux). Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: win32u Assignee: wine-bugs(a)winehq.org Reporter: chiitoo(a)gentoo.org Regression SHA1: be60f77909fc9ce2c9b6f1abd005e3b4aabaafec Distribution: Gentoo It seems be60f77909f [1] is the return of the bug 57577, with anything so far I have tried, including the Wine notepad, reducing in vertical size by 4 pixels when restored. Only tested with KWin-X11 so far. Thank you! 1. https://gitlab.winehq.org/wine/wine/-/commit/be60f77909fc9ce2c9b6f1abd005e3… 2. https://bugs.winehq.org/show_bug.cgi?id=57577 -- 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 58795] New: The Witcher 2 crashes on start
by WineHQ Bugzilla Oct. 31, 2025

Oct. 31, 2025

http://bugs.winehq.org/show_bug.cgi?id=58795 Bug ID: 58795 Summary: The Witcher 2 crashes on start Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: NEW Keywords: regression Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)winehq.org Reporter: gyebro69(a)gmail.com CC: julliard(a)winehq.org Regression SHA1: ad9dfe8bcc0ad048dc044694969e13235caadf46 Distribution: ArchLinux Created attachment 79440 --> http://bugs.winehq.org/attachment.cgi?id=79440 terminal output Starting The Witcher 2 (GOG) using current git HEAD (wine-10.16-212-g6124fea1dde) results in an immediate crash. Couldn't get a backtrace. Present in 32bit-only, shared WOW and WOW64 prefixes alike. The game starts properly in Wine-10.16, the crash occurs since commit ad9dfe8bcc0ad048dc044694969e13235caadf46 ntdll: Use the export name if any to find the corresponding builtin. There is no demo version available. Let me know if you need debug logs. wine-10.16-212-g6124fea1dde -- 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 3

[Bug 58752] New: assembly:Z:\usr\share\wine\mono\wine-mono-10.2.0\lib\mono\4.5\mscorlib.dll type:DllNotFoundException
by WineHQ Bugzilla Oct. 31, 2025

Oct. 31, 2025

http://bugs.winehq.org/show_bug.cgi?id=58752 Bug ID: 58752 Summary: assembly:Z:\usr\share\wine\mono\wine-mono-10.2.0\lib\m ono\4.5\mscorlib.dll type:DllNotFoundException Product: Framework Mono Version: 6.12.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: mono Assignee: wine-bugs(a)winehq.org Reporter: schusr(a)gmail.com CC: madewokherd(a)gmail.com Distribution: --- Installed a 64 bit application that uses System.Media.SoundPlayer. When starting the application fails with DllNotFoundException but the file is present on the system. dir Z:\usr\share\wine\mono\wine-mono-10.2.0\lib\mono\4.5\mscorlib.dll Volume in drive Z is fedora Volume Serial Number is 4979-a18d Directory of Z:\usr\share\wine\mono\wine-mono-10.2.0\lib\mono\4.5 08/28/2025 07:00 PM 4,677,632 mscorlib.dll 1 file 4,677,632 bytes 0 directories 486,067,679,232 bytes free Running wine from Fedora 42 002c:fixme:winediag:loader_init wine-staging 10.15 is a testing version containing experimental patches. 002c:fixme:winediag:loader_init Please mention your exact version when filing bug reports on winehq.org. rpm -qa | grep mono-core mono-core-6.12.0-19.fc42.x86_64 -- 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 24

[Bug 57376] New: Permission denied vs No such file or directory when opening folders with trailing backslash
by WineHQ Bugzilla Oct. 31, 2025

Oct. 31, 2025

https://bugs.winehq.org/show_bug.cgi?id=57376 Bug ID: 57376 Summary: Permission denied vs No such file or directory when opening folders with trailing backslash Product: Wine Version: 9.20 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: alex+winehq(a)cogarr.net Distribution: --- Created attachment 77346 --> https://bugs.winehq.org/attachment.cgi?id=77346 A zip file containing a minimal example.c, and log files wine.txt and win.txt There's a subtle difference when calling fopen(3) between Wine configured for win10, and real Windows 10. When attempting to open a folder (e.g. AppData), wine correctly sets errno to 13 (Permission denied), but when opening a folder with a trailing backslash(e.g. AppData\), Windows sets errno to 2 (No such file or directory) while Wine sets it to 13 (Permission denied). The attached example.c shows this behavior. I compile it with mingw32-x86_64-gcc and run it through cmd.exe with my current directory set to C:\users\user on Wine and get wine.txt, then run it on Windows 10, and get win.txt (COPY a.exe C:\users\user && C: && cd users\user && a.exe > win[e].txt) This behavior exists on current Wine 9.20 and has existed since at least Wine 9.0 . I have tried the winecfg versions: win10, win11, win8.1, vista, and all seem to work the same. My actual use case is running the Luarocks package manager(https://github.com/luarocks/luarocks) compiled for Windows on Wine for testing. Luarocks uses this behavior to check if something is a folder (https://github.com/luarocks/luarocks/blob/master/src/luarocks/fs/win32.lua#…) -- 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 58331] New: Wait cursor does not display
by WineHQ Bugzilla Oct. 31, 2025

Oct. 31, 2025

http://bugs.winehq.org/show_bug.cgi?id=58331 Bug ID: 58331 Summary: Wait cursor does not display Product: Wine Version: 9.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: win32u Assignee: wine-bugs(a)winehq.org Reporter: rikul(a)inbox.ru Distribution: --- Created attachment 78705 --> http://bugs.winehq.org/attachment.cgi?id=78705 Example Starting from Wine version 9.0, the waiting cursor no longer appears when attempting to set it to indicate a long-running operation in MFC applications or other programs. The issue appears to have started after the commit on June 13, 2023. Steps to Reproduce: 1. Run the attached simple MFC application. 2. Click the button "Start Long Operation" Expected Result: The waiting cursor should appear for the duration of the 3-second sleep. Actual Result: The waiting cursor does not appear during the Sleep call. The cursor remains the default arrow. Example Application: The example application has been attached. It uses the most basic implementation of the CWaitCursor class, as described in the official Microsoft documentation: https://learn.microsoft.com/en-us/cpp/mfc/reference/cwaitcursor-class?view=… Regression Commit: The issue seems to have started with the commits made on June 13, 2023: https://github.com/wine-mirror/wine/commits/master/dlls?author=rbernon&sinc… Notes: This issue does not occur in Windows, where the waiting cursor appears as expected. Environment: Wine version: 9.0+ (possibly Wine 8.x, but not 8.0) Operating System: RHEL 7.9, RHEL 8.10 -- 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 6

[Bug 48787] New: WineD3D C&C Generals Zero Hour takes a lot time to load or maximize
by WineHQ Bugzilla Oct. 31, 2025

Oct. 31, 2025

https://bugs.winehq.org/show_bug.cgi?id=48787 Bug ID: 48787 Summary: WineD3D C&C Generals Zero Hour takes a lot time to load or maximize Product: vkd3d Version: 1.1 Hardware: x86-64 OS: Windows Status: UNCONFIRMED Severity: normal Priority: P2 Component: vkd3d Assignee: wine-bugs(a)winehq.org Reporter: moceap(a)hotmail.com As you know (C&C Generals Zero Hour) is an old game. And it use DirectX 8.1. These type of games don't stable in current Windows' versions. So WineD3D used to valid run them on Windows. Using: C&C Generals Zero Hour (Last Version 1.04) Windows 10 (1909) WineD3D (From Wine 5.4)https://fdossena.com/?p=wined3d/index.frag Both (Intel and AMD) cards tested Expected Result: Works fine with high speed. Actual Result: Very long time on maximize the game after minimize or switch to another application Long time on loading the game (Not happen on MS DirectX) -- 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 58839] New: kernel32.timeGetTime error when enabling speedhack in Cheat Engine
by WineHQ Bugzilla Oct. 31, 2025

Oct. 31, 2025

http://bugs.winehq.org/show_bug.cgi?id=58839 Bug ID: 58839 Summary: kernel32.timeGetTime error when enabling speedhack in Cheat Engine Product: Wine Version: 10.17 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: kernel32 Assignee: wine-bugs(a)winehq.org Reporter: alexhenrie24(a)gmail.com Distribution: --- Steps to reproduce: 1. Compile Wine with https://gitlab.winehq.org/wine/wine/-/merge_requests/9256 to work around Bug 58837 2. Run `wine CheatEngine76.exe` and when prompted to install additional software, click "Skip All" 3. Run `wine 'C:\Program Files\Cheat Engine\Cheat Engine.exe'` 4. Click File, then Open Process, then double-click Cheat Engine 5. On the right side of the window, click the "Enable Speedhack" checkbox An error dialog appears that says "Failure hooking kernel32.gettickcount64:Error in line 77 (kernel32.timeGetTime:) :This address specifier is not valid" $ sha256sum CheatEngine76.exe 7f57ab6697f2d27604be2d63d03768612e6022a1c3b708507af8fb23d461428a -- 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 58804] New: Incorrect ConfigureNotify processing in xfce
by WineHQ Bugzilla Oct. 31, 2025

Oct. 31, 2025

http://bugs.winehq.org/show_bug.cgi?id=58804 Bug ID: 58804 Summary: Incorrect ConfigureNotify processing in xfce Product: Wine Version: 10.16 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winex11.drv Assignee: wine-bugs(a)winehq.org Reporter: valy(a)etersoft.ru CC: rbernon(a)codeweavers.com Regression SHA1: 0f1d999bb878ea54214057d3662c116271ec4812 Distribution: --- When switching from windowed mode to maximized mode in Notepad and back, a situation arises in which the window retains its size as in maximized mode. Example: 1) Launching wine notepad 2) A window opens with dimensions of 800x600 3) I switch to maximized mode and the window changes size to 1024x800 4) I switch to windowed mode, the window becomes 800x600 in size for a split second, and eventually retains the size of 1024x800 (while the mode becomes windowed) The bug is reproduced in xfce, I did not observe this bug in mate. After investigating the problem a bit, I noticed that this behavior is due to incorrect processing of repeated ConfigureNotify requests with the value send_event=True in X11DRV_ConfigureNotify. This is a regression. The bug appears for the first time after the commit https://gitlab.winehq.org/wine/wine/-/commit/0f1d999bb878ea54214057d3662c11… , which added asynchronous event handling. Returning to the synchronous method solves the bug Version: wine-10.16-212-g6124fea1dde -- 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 48027] New: cmd pipe | not triggering ReadFile EOF
by WineHQ Bugzilla Oct. 31, 2025

Oct. 31, 2025

https://bugs.winehq.org/show_bug.cgi?id=48027 Bug ID: 48027 Summary: cmd pipe | not triggering ReadFile EOF Product: Wine Version: 4.18 Hardware: x86 OS: Linux Status: NEW Severity: minor Priority: P2 Component: cmd Assignee: wine-bugs(a)winehq.org Reporter: dark.shadow4(a)web.de Distribution: --- Test program is find.exe as of wine commit ccec532879ec14b2e79da08288152a69221ec4d1. I implemented the program so it waits for ReadFile to return FALSE, that's when the input is supposed to be over: ###### BOOL success = ReadFile(handle, buffer, 4096, &buffer_max, NULL); if (!success) return FALSE; ###### Now that's not right anyways, but it exposes a slight difference in Wine cmd: 1) Following input hangs on Wine, but not on Windows: "echo test | find test" It works on Wine when using "winetricks -q cmd" 2) Following input hangs on both Windows and Wine: "find test < test.txt" Wine's implementation of the pipe | uses the redirect operator < internally. This leads to the pipe working differently on Wine, i.e. blocking ReadFile when it's not supposed to. I'm not aware of a real program being affected by that, just noting. -- 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 6