wine-bugs September 2025

wine-bugs@winehq.org

1 participants
512 discussions

[Bug 58229] New: _SH_SECURE sharing flag is not supported and causing _wfsopen to fail
by WineHQ Bugzilla 31 Oct '25

31 Oct '25

http://bugs.winehq.org/show_bug.cgi?id=58229 Bug ID: 58229 Summary: _SH_SECURE sharing flag is not supported and causing _wfsopen to fail Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: msvcrt Assignee: wine-bugs(a)winehq.org Reporter: bruvzg13(a)proton.me Distribution: --- Calling _wfsopen with _SH_SECURE sharing flag result in failure and "012c:err:msvcrt:_wsopen_dispatch Unhandled shflags 0x80" error in the terminal. 0x80 value correspond to _SH_SECURE Discovered while debugging Godot Engine - https://github.com/godotengine/godot/pull/106392 Seems like the case for this flag is missing: https://gitlab.winehq.org/wine/wine/-/blob/master/dlls/msvcrt/file.c?ref_ty… The flag is documented as "shared read, exclusive write access" (https://learn.microsoft.com/en-us/cpp/c-runtime-library/sharing-constants?v…), and the issue can be worked around by substituting it with "(mode_flags == READ) ? _SH_DENYWR : _SH_DENYRW", which result in the same behavior as on Windows (at least in our use case). -- 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 24466] New: Sid Meier's Pirates! frequent hiccups, temporary lock-ups
by wine-bugs＠winehq.org 31 Oct '25

31 Oct '25

http://bugs.winehq.org/show_bug.cgi?id=24466 Summary: Sid Meier's Pirates! frequent hiccups, temporary lock-ups Product: Wine Version: 1.3.3 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: gyebro69(a)gmail.com Created an attachment (id=30870) --> (http://bugs.winehq.org/attachment.cgi?id=30870) terminal output Sid Meier's Pirates! (patched to the latest 1.0.2 version) performs badly in Wine. This issue is described in several test results on the Appdb page of the game, too. I can observe the following symptoms: - After the intro video played, it takes almost 2 minutes to get into the main menu (without noticeable hdd activity). - When I get into the game and visit any places in the port (Governor, Merchant, Tavern etc.) it usually takes the game 15-20 seconds to display the next screen (although music plays continuously). - While sailing, the game frequently "freezes" for 2-3 seconds without no apparent reasons. When those hiccups occur all animations freeze on the current screen until the next screen is loaded but music plays fluently. Reducing the screen resolution, graphical details or disable audio doesn't help. I remember playing this game several years ago in a native Win XP without this issues. No demo available. Fedora 13 x86 AMD Athlon 64 x2 4200+ 3 GB Ram Kernel 2.6.34.6 Nvidia 7600 GT / driver 256.53 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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 19

[Bug 58611] New: Nightshade crashes: err:seh:NtRaiseException Unhandled exception code c0000409 (native vcruntime140 works around the crash)
by WineHQ Bugzilla 31 Oct '25

31 Oct '25

http://bugs.winehq.org/show_bug.cgi?id=58611 Bug ID: 58611 Summary: Nightshade crashes: err:seh:NtRaiseException Unhandled exception code c0000409 (native vcruntime140 works around the crash) Product: Wine Version: 10.13 Hardware: x86-64 URL: https://mirror.cs.uchicago.edu/fawkes/files/nightshade /Nightshade-1.0-Windows.zip OS: Linux Status: NEW Keywords: download Severity: normal Priority: P2 Component: msvcrt Assignee: wine-bugs(a)winehq.org Reporter: xerox.xerox2000x(a)gmail.com Distribution: Debian Reported at the forum: https://forum.winehq.org/viewtopic.php?t=41488 As titles says, native vruntime140 is enough to prevent the crash; last trace before the crash shows __std_type_info_name is called: 0100:trace:msvcrt:__std_type_info_name (00006FFF0E352A78) returning struct x1272d024::DeprecatedRAIIContextManager::DeprecatedRAIIContextManager (Don't know what's wrong,but with a hack to return something else for that last line (i did ti->mangled) the program starts so this might point to that the problem is really in that last line.) 0100:trace:msvcrt:__unDNameEx (0000000000000000,"?AU?$DeprecatedRAIIContextManager@UEnablePythonDispatcher@?A0x1272d024@@$$V@impl@torch@@",0,00006FFFFFA317D0,00006FFFFFA317C0,0000000000000000,2800) 0100:trace:msvcrt:str_array_push 00000000001F70D8 0> "DeprecatedRAIIContextManager" 0100:trace:msvcrt:str_array_get_ref Returning 00000000001F70D8[0] => "DeprecatedRAIIContextManager" 0100:trace:msvcrt:str_array_push 00000000001F70D8 1> "EnablePythonDispatcher" 0100:trace:msvcrt:str_array_push 00000000001F70D8 0> "DeprecatedRAIIContextManager" 0100:trace:msvcrt:str_array_get_ref Returning 00000000001F70D8[1] => "EnablePythonDispatcher" 0100:trace:msvcrt:str_array_push 00000000001F7108 0> "EnablePythonDispatcher" 0100:trace:msvcrt:str_array_push 00000000001F70D8 1} "EnablePythonDispatcher" 0100:trace:msvcrt:str_array_push 00000000001F70D8 0> "DeprecatedRAIIContextManager" 0100:trace:msvcrt:str_array_push 00000000001F7108 0> "DeprecatedRAIIContextManager" 0100:trace:msvcrt:str_array_get_ref Returning 00000000001F70D8[0] => "DeprecatedRAIIContextManager" 0100:trace:msvcrt:str_array_push 00000000001F7108 1> "DeprecatedRAIIContextManager" 0100:trace:msvcrt:str_array_push 00000000001F7108 0> "DeprecatedRAIIContextManager" 0100:trace:msvcrt:str_array_push 00000000001F70D8 1> "x1272d024" 0100:trace:msvcrt:str_array_push 00000000001F70D8 0> "DeprecatedRAIIContextManager" 0100:trace:msvcrt:str_array_get_ref Returning 00000000001F70D8[1] => "x1272d024" 0100:trace:msvcrt:str_array_push 00000000001F7108 2> "x1272d024" 0100:trace:msvcrt:str_array_push 00000000001F7108 1> "DeprecatedRAIIContextManager" 0100:trace:msvcrt:str_array_push 00000000001F7108 0> "DeprecatedRAIIContextManager" 0100:trace:msvcrt:__std_type_info_name (00006FFF0E352A78) returning struct x1272d024::DeprecatedRAIIContextManager::DeprecatedRAIIContextManager 0100:trace:msvcrt:__std_type_info_name (00006FFF0E352A78) returning struct x1272d024::DeprecatedRAIIContextManager::DeprecatedRAIIContextManager 0100:trace:msvcrt:__std_type_info_name (00006FFF0E354F30) returning struct c10::AnyType 0100:trace:msvcrt:__std_type_info_name (00006FFF0E354F30) returning struct c10::AnyType 0100:trace:msvcrt:__std_type_info_name (00006FFF0E352A78) returning struct x1272d024::DeprecatedRAIIContextManager::DeprecatedRAIIContextManager 0100:trace:msvcrt:__std_type_info_name (00006FFF0E352A78) returning struct x1272d024::DeprecatedRAIIContextManager::DeprecatedRAIIContextManager 0100:trace:msvcrt:__std_type_info_name (00006FFF0E352A08) returning struct x1272d024::DeprecatedRAIIContextManager::DeprecatedRAIIContextManager 0100:trace:msvcrt:__std_type_info_name (00006FFF0E352A08) returning struct x1272d024::DeprecatedRAIIContextManager::DeprecatedRAIIContextManager 0100:trace:msvcrt:__std_type_info_name (00006FFF0E352A78) returning struct x1272d024::DeprecatedRAIIContextManager::DeprecatedRAIIContextManager 0100:err:seh:NtRaiseException Unhandled exception code c0000409 flags 1 addr 0x140019241 -- 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 58697] New: Jolly Rover hangs upon starting with 100% cpu usage
by WineHQ Bugzilla 31 Oct '25

31 Oct '25

http://bugs.winehq.org/show_bug.cgi?id=58697 Bug ID: 58697 Summary: Jolly Rover hangs upon starting with 100% cpu usage Product: Wine Version: 10.15 Hardware: x86-64 URL: http://www.brawsome.com.au/rover_demo/jollyrover_demo. zip OS: Linux Status: NEW Keywords: download, regression Severity: normal Priority: P2 Component: win32u Assignee: wine-bugs(a)winehq.org Reporter: gyebro69(a)gmail.com CC: rbernon(a)codeweavers.com Regression SHA1: 0b7e785da4f45a8da6a977db9b05c729132f8afa Distribution: ArchLinux The game doesn't create a window and hangs with 100% cpu usage right after starting. There is nothing relevant in the terminal output. Doesn't happen when UseEGL=Y. Caused by commit 0b7e785da4f45a8da6a977db9b05c729132f8afa win32u: Keep a separate pointer for unused opengl drawable. Can be reproduced with the non-Steam demo as well (installer needs mfc42.dll) OpenGL renderer string: NVIDIA GeForce GTX 1660 SUPER/PCIe/SSE2 OpenGL core profile version string: 4.6.0 NVIDIA 580.82.09 OpenGL core profile shading language version string: 4.60 NVIDIA Install Jolly Rover Demo.exe md5sum: 71d9f44161a6dce81e1df135d276d312 -- 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 56209] New: winetricks vb5run fails
by WineHQ Bugzilla 31 Oct '25

31 Oct '25

https://bugs.winehq.org/show_bug.cgi?id=56209 Bug ID: 56209 Summary: winetricks vb5run fails Product: Wine Version: 8.10 Hardware: x86-64 OS: Linux Status: NEW Keywords: download, regression Severity: normal Priority: P2 Component: advpack Assignee: wine-bugs(a)winehq.org Reporter: austinenglish(a)gmail.com CC: alexhenrie24(a)gmail.com Regression SHA1: 29d543d12a2085be8513859369291bbcc35694db Distribution: Debian austin@debian:~/wine-rt$ wineserver -k ; rm -rf ~/.wine ; WINE=~/wine-rt/wine WINEDEBUG=advpack winetricks -q vb5run ; echo $? Using winetricks 20240105-next - sha256sum: 7c153235548ab7e2f6f47c3d33c7fa7b27543dd3b603ec97227dc7984647ac32 with wine-8.10-124-g24552295499 and WINEARCH=win32 Executing w_do_call vb5run Executing load_vb5run Executing cd /home/austin/.cache/winetricks/vb5run Executing /home/austin/wine-rt/wine msvbvm50.exe /q 0220:trace:advpack:DoInfInstallW (0031FCDC) ------------------------------------------------------ warning: Note: command /home/austin/wine-rt/wine msvbvm50.exe /q returned status 5. Aborting. ------------------------------------------------------ 1 29d543d12a2085be8513859369291bbcc35694db is the first bad commit commit 29d543d12a2085be8513859369291bbcc35694db Author: Alex Henrie <alexhenrie24(a)gmail.com> Date: Fri Jun 16 21:56:14 2023 -0600 advpack: Check the return value of adv_install in DoInfInstallW (scan-build). dlls/advpack/install.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 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 13

[Bug 58598] New: Realterm_2.0.0.70 / Crashes on start
by WineHQ Bugzilla 31 Oct '25

31 Oct '25

http://bugs.winehq.org/show_bug.cgi?id=58598 Bug ID: 58598 Summary: Realterm_2.0.0.70 / Crashes on start Product: Wine Version: 10.12 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: janne.kekkonen(a)gmail.com Distribution: --- Created attachment 79134 --> http://bugs.winehq.org/attachment.cgi?id=79134 Application error messagebox Tested with Wine 22.04 on Ubuntu 22.04 running on VMware. Created new 32bit prefix. Application seems to install normally. During startup it crashes. Attached screenshot of message box shown with backtrace window. -- 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 10

[Bug 58257] New: CD Manipulator cannot detect the drive model name in experimental wow64 mode.
by WineHQ Bugzilla 31 Oct '25

31 Oct '25

http://bugs.winehq.org/show_bug.cgi?id=58257 Bug ID: 58257 Summary: CD Manipulator cannot detect the drive model name in experimental wow64 mode. Product: Wine Version: 10.8 Hardware: x86-64 URL: http://www.storeroom.info/cdm/cdm270.zip OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: sagawa.aki+winebugs(a)gmail.com Distribution: Ubuntu CD Manipulator is a free and user-friendly tool for ripping and writing CDs, supporting image file creation and duplication. The drive model name should appear in the drop box to select the drive in the main menu that appears after starting the program, but it does not appear in new Wow64 mode. I have not tested the other features yet. Steps to reproduce: 1. Make sure you have a physical or virtual CD/DVD drive ready. 2. Obtain cdm270.zip from http://www.storeroom.info/cdm/ . SHA1(cdm270.zip) = 46f4cea613d199974cf1a22741f4ce92e8fef723 3. Unzip it. 4. Execute CdManipulator.exe with Wine. 5. At the first time, language selection window is shown. Choose English. 6. The main menu appears. Expected result: Drive model name is shown in the drop box, e.g. (D:) VBOX CD-ROM 1.0 Actual result: Drive model name is shown as Unknown in the drop box, e.g. (D:) - Unknown - -- 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 9

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

31 Oct '25

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 31 Oct '25

31 Oct '25

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 31 Oct '25

31 Oct '25

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

← Newer
1
...
14
15
16
17
18
19
20
...
52
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-bugs September 2025