wine-bugs August 2025

wine-bugs@winehq.org

1 participants
109 discussions

[Bug 58504] New: 10.12 regression: MS Office 2007 semitransparent menus
by WineHQ Bugzilla 11 Aug '25

11 Aug '25

http://bugs.winehq.org/show_bug.cgi?id=58504 Bug ID: 58504 Summary: 10.12 regression: MS Office 2007 semitransparent menus Product: Wine Version: 10.12 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winewayland Assignee: wine-bugs(a)winehq.org Reporter: bigfoothart(a)gmail.com Distribution: --- Created attachment 78965 --> http://bugs.winehq.org/attachment.cgi?id=78965 office2007-1 10.12 regression: MS Office 2007 semitransparent menus. See attachments -- 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 58505] New: Odd windows management behaviour in later dev versions
by WineHQ Bugzilla 11 Aug '25

11 Aug '25

http://bugs.winehq.org/show_bug.cgi?id=58505 Bug ID: 58505 Summary: Odd windows management behaviour in later dev versions 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: kg.hammarlund(a)gmail.com Distribution: --- I run a geneaology database program written for windows under wine. It runs fine on v10.0 (stable) and on dev versions up to 10.4. From v10.5 and upwards, including v1012, I'm encountering an odd issue. When opening a search window, this window opens in the background instead of on top of the main window. I then have to move or resize the main window in order to highilght the search window and fill in the search data. But this only happens the first time I open the search window. Next time it opens in the foreground. If I untick the box "Allow the window manager to control the windows" in winecfg > graphics, the search window opens expected. But this solution has its drawbacks. -- 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 54157] New: dir command of cmd fails on Z: on Ubuntu under WSL
by WineHQ Bugzilla 11 Aug '25

11 Aug '25

https://bugs.winehq.org/show_bug.cgi?id=54157 Bug ID: 54157 Summary: dir command of cmd fails on Z: on Ubuntu under WSL Product: Wine Version: 8.0-rc1 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: mterrisse(a)free.fr Distribution: --- Wine 8.0 rc1, Ubuntu 22.10 under WSL (Windows SubSystem for Linux, Windows 11 22H2) Hello, You will probably think it is a weird idea running Wine in Ubuntu under WSL. I tried it to avoid copying many files with my program to test it under Wine. I noticed this: wine64 cmd.exe dir This works fine on C: But if I do Z: dir I receive Invalid function. I tried this WINEDEBUG=warn+file wine64 cmd.exe Z: dir and there is something more explicit 0108:warn:file:get_mountmgr_fs_info failed to retrieve filesystem type from mountmgr, status 0xc000000e Invalid function. Do you know what is wrong? Regards, Michel Terrisse -- 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 17

[Bug 58537] New: wine explorer opens full screen above 1920x1080
by WineHQ Bugzilla 11 Aug '25

11 Aug '25

http://bugs.winehq.org/show_bug.cgi?id=58537 Bug ID: 58537 Summary: wine explorer opens full screen above 1920x1080 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: ToddAndMargo(a)zoho.com Distribution: --- Fedora 41 Wine-Devel 10.12 screen resultion 3840x2160 $ wine explorer /desktop=1920x1080,1920x1080 opens correctly $ wine explorer /desktop=1920x1440,1920x1440 opens full screen. You have to use <ctrl><alt><f2> to kill it. -- 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 58584] New: msvcp140: Multiple modern applications using C++ Concurrency crash in CONCRT140.dll on startup
by WineHQ Bugzilla 10 Aug '25

10 Aug '25

http://bugs.winehq.org/show_bug.cgi?id=58584 Bug ID: 58584 Summary: msvcp140: Multiple modern applications using C++ Concurrency crash in CONCRT140.dll on startup Product: Wine Version: 10.12 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: blocker Priority: P2 Component: msvcp Assignee: wine-bugs(a)winehq.org Reporter: waser(a)waser.tech Distribution: --- This report details a consistent, immediate startup crash in `CONCRT140.dll` affecting modern S.T.A.L.K.E.R. engine forks. These engines are based on the open-source **Open X-Ray 1.6**, which itself works flawlessly under Wine. The crash only appears in these newer, more advanced forks which leverage the MSVC concurrency runtime for performance. This strongly indicates the issue lies within Wine's implementation of these APIs, not a bug in the engines themselves. This is effectively a regression, as the baseline engine works while the newer, concurrency-enabled versions do not. **Existing Related Bugs:** This issue appears to be a new, highly reproducible test case for known problems in Wine's concurrency support. We are filing this as a new report due to the unique test case and the specific failure point (constructor vs. destructor), but it is likely caused by the same underlying issues as: - **Bug 52899:** Notes that `CONCRT140.dll` requires `CreateEventExW` from `kernel32`. This is the most likely root cause. - **Bug 41749:** Shows a crash in the destructor for `Concurrency::details::_TaskCollection`. Our crash occurs in the *constructor* of this same object, demonstrating a different failing code path. Our report provides two clear methods to reproduce this crash, including one that is fully free and requires no commercial software. --- ### **Primary Reproduction Steps (IX-Ray on S.T.A.L.K.E.R.: Call of Pripyat)** *(Steps 1-5 as in previous draft)* 6. **Run the Game with Debug Logging:** Launch the game using its main executable with full debug channels enabled. ```bash WINEDEBUG=+all wine Stalker-COP.exe &> stalker_cop_crash_all.log WINEDEBUG=+seh,+loaddll wine Stalker-COP.exe &> stalker_cop_crash_seh.log ``` 7. **Result:** The process will crash immediately. The game's own crash log (in `_appdata_ixray_/logs`) and the attached Wine debug logs will show a fatal error in `CONCRT140.dll`. --- ### **Alternative Reproduction Steps (AOEngine on S.T.A.L.K.E.R. Anomaly)** This method is fully free and requires no commercial game assets. 1. **Download S.T.A.L.K.E.R. Anomaly:** Download the standalone game from its [ModDB page](https://www.moddb.com/mods/stalker-anomaly/downloads). 2. **Download AOEngine:** Download the latest AOEngine release from its [ModDB addons page](https://www.moddb.com/mods/stalker-anomaly/addons/aoengine). 3. **Install AOEngine:** Extract the contents into the Anomaly game's `bin` directory, overwriting `AnomalyDX11.exe`. 4. **Create a Clean Wine Prefix:** ```bash export WINEPREFIX=~/.wine_anomaly rm -rf $WINEPREFIX && wineboot -u ``` 5. **Install Runtimes:** ```bash winetricks -q vcrun2022 d3dcompiler_47 ``` 6. **Run the Game with Debug Logging:** Launch the game using the Anomaly launcher. ```bash WINEDEBUG=+all wine AnomalyLauncher.exe &> anomaly_crash_all.log WINEDEBUG=++seh,+loaddll wine AnomalyLauncher.exe &> anomaly_crash_seh.log ``` (Within the launcher, disable AVX, select DX11, disable the shader cache, and click Play). 7. **Result:** The exact same crash behavior as the IX-Ray method will be observed. The game's crash log will be in `_appdata_/logs` and the full Wine log will be `anomaly_crash_*.log`. --- **Expected Behavior:** The game launcher should appear, and the game should launch to the main menu successfully, as it does on Windows and as the baseline Open X-Ray 1.6 engine does under Wine. **Logs:** Three files will be attached for the primary reproduction case: 1. `stalker_cop_crash_seh.log`: A small log with `+seh,+loaddll` for quick initial review. 2. `stalker_cop_crash_all.log.bz2`: The complete `+all` debug log, compressed with bzip2 due to its large size. 3. `ixray-2025.08.10-02.37.21-waser.log`: The game's own crash log from its `_appdata_ixray_/logs` directory. **References:** - **IX-Ray GitHub (Open Source Engine):** https://github.com/ixray-team/ixray-1.6-stcop - **GE-Proton Issue #197 (Full History):** https://github.com/GloriousEggroll/proton-ge-custom/issues/197 -- 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 16

[Bug 58575] New: Low performance in an old Directx8 Sonic fangame in wined3d
by WineHQ Bugzilla 10 Aug '25

10 Aug '25

http://bugs.winehq.org/show_bug.cgi?id=58575 Bug ID: 58575 Summary: Low performance in an old Directx8 Sonic fangame in wined3d Product: Wine Version: 10.11 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: d3d Assignee: wine-bugs(a)winehq.org Reporter: user.pecheniok(a)gmail.com Distribution: --- This game has a built-in fps counter. After launching it, I was surprised to find that it ran at only 30 fps in the hub area, while on windows it runs at 60. It is seemingly ok in the gameplay, but fps is often several values short of 60, and there are also rarer drops to 30 for several seconds. There are no warnings in the console other than related to directsound. DXVK works at a locked 60 fps, so that means that it's a problem with wined3d. Here is the link to the game: https://gamejolt.com/games/sonic3d/28626 -- 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 58578] New: Hygeia Pharmacy: complains that Microsoft ReportViewer is not installed (unimplemented MsiProvideAssemblyW() ?)
by WineHQ Bugzilla 10 Aug '25

10 Aug '25

http://bugs.winehq.org/show_bug.cgi?id=58578 Bug ID: 58578 Summary: Hygeia Pharmacy: complains that Microsoft ReportViewer is not installed (unimplemented MsiProvideAssemblyW() ?) 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: peathot(a)hotmail.com Distribution: --- Created attachment 79093 --> http://bugs.winehq.org/attachment.cgi?id=79093 Terminal output of Hygeia Pharmacy running under Wine Hygeia Pharmacy is a .NET 4 application for pharmacy retail. When the application starts up, it will check for various shared components, ending up complaining that Microsoft Report Viewer has to be installed despite already installed. Attached is the screenshot of the error. It says, "It's necessary to install an additional programed named Microsoft Report Viewer" ("มีความจำเป็นต้องติดตั้งโปรแกรมเสริมที่ชื่อว่า Microsoft Report Viewer"). Terminal output reveals 2 interesting FIXME's: ``` 0174:fixme:msi:MsiProvideAssemblyW L"Microsoft.ReportViewer.Common, Version=10.0 .0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MS IL", L"C:\\Program Files\\HygeiaPharmacy\\HygeiaPharmacy.exe.config", 0, 0, 10D7 A618, 10D7A614 0174:fixme:msi:MsiProvideAssemblyW L"Microsoft.ReportViewer.Common, Version=10.0 .0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MS IL", (null), 0, 0, 10D7A618, 10D7A614 ``` This leads me to believe that the application chokes up because it does not receive the correct path to this .NET assembly, part of MS ReportViewer 2010. --- Looking into multiple documents and into Wine itself, I _think_ it would be relatively simple to implement MsiProvideAssembly[A|W]() using facilities already implemented in Wine. Bug 58577 plays an important role on this. I actually would love to get my hands dirty, if not for 2 problems: 1. I don't actually have much time myself. 2. Many years ago, I disassembled a different component of Windows (related to MDM/management policy) in order to debug my graduating project. I forgot everything by now, and it's IMHO not related, but combined with 1. I think it's probably better to stay safe. (Can I explain some high-level idea? Will I run afoul of 2.?) A number of MSDN documents that might be useful: https://learn.microsoft.com/en-us/windows/win32/api/msi/nf-msi-msiprovideas… https://learn.microsoft.com/en-us/windows/win32/msi/assembly-registry-keys-… Also helpful is a small test program I write myself to exercise MsiProvideAssemblyW() in the same way as the application (and in a slightly different way). On Windows 11, this outputs as follow: ``` MsiProvideAssemblyW("Microsoft.ReportViewer.Common, ..." (qualified)) returns 0 Returned path (119): C:\WINDOWS\assembly\GAC_MSIL\Microsoft.ReportViewer.Common\10.0.0.0__b03f5f7f11d50a3a\Microsoft.ReportViewer.Common.dll MsiProvideAssemblyW("Microsoft.ReportViewer.Common" (unqualified)) returns 0 Returned path (119): C:\WINDOWS\assembly\GAC_MSIL\Microsoft.ReportViewer.Common\10.0.0.0__b03f5f7f11d50a3a\Microsoft.ReportViewer.Common.dll ``` On Wine, it outputs (excluding Wine's output itself): ``` MsiProvideAssemblyW("Microsoft.ReportViewer.Common, ..." (qualified)) returns 120 MsiProvideAssemblyW("Microsoft.ReportViewer.Common" (unqualified)) returns 120 ``` --- Following is the way I run Hygeia Pharmacy. Hygeia Pharmacy is a relatively complex application and requires the full .NET installation (Mono is not enough). The following commands recreate the environment from scratch: ``` export WINEARCH=win32 export WINEPREFIX=/a/new/prefix winetricks dotnet48 jet40 mdac28 wine ReportViewer.exe # sha256sum: e8ff182e202b321ac2b9245ee20c4eb659008ffb2a34cdbd3486f9da3d4c3e06 wine hygeia_trial_install.2.6.28.1.exe # sha256sum: 380085defb0af240f144d603da70d09a76c940a27a65953a9fbe3668c321b4e2 wine "C:\\\\users\\\\Public\\\\Desktop\\\\Hygeia Pharmacy.lnk" &>hygeia_pharmacy_wine_output.txt ``` --- The (trial) version can be obtained from https://www.hygeia-pharmacy.com/trial/. However, it requires a (free) registration, and the website is entirely in Thai with no English version. In order to (try to) help you with the registration, the registration page at https://www.hygeia-pharmacy.com/register/ requires the followed: 1. A chosen username ("Hygeia ID") 2. A chosen password. 3. Your full name 4. Your email. 5. A math captcha (input the equation's answer). I can't remember if there's an email verification after that step or not, because it's been a long time since I registered myself. Once logged in, https://www.hygeia-pharmacy.com/trial/ will show a big blue button for downloading the trial version. The same page will also be a smaller link for "MS Report Viewer" which is hosted by Hygeia Pharmacy themselves (if you prefer an MS link, see the end of bug 58577). -- 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 56347] New: The Sinking City exits after Click any key to continue
by WineHQ Bugzilla 10 Aug '25

10 Aug '25

https://bugs.winehq.org/show_bug.cgi?id=56347 Bug ID: 56347 Summary: The Sinking City exits after Click any key to continue Product: vkd3d Version: 1.10 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: vkd3d Assignee: wine-bugs(a)winehq.org Reporter: andrey.goosev(a)gmail.com Distribution: --- After starting new game and loading the game shows 'Click any key to continue' which results in 0880:err:msvcrt:_wassert (L"1 <= count && count <= VKD3D_VEC4_SIZE",L"../vkd3d/libs/vkd3d-shader/vkd3d_shader_private.h",1613) vkd3d-1.10-492-gd9c68ee4 -- 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 58515] New: Street Chaves only displays a black screen (regression)
by WineHQ Bugzilla 10 Aug '25

10 Aug '25

http://bugs.winehq.org/show_bug.cgi?id=58515 Bug ID: 58515 Summary: Street Chaves only displays a black screen (regression) Product: Wine Version: 10.11 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: denilsonsa(a)gmail.com Distribution: --- Wine versions up to 9.7 were able to render the game graphics correctly. Now I tested again on Wine version 10.11 and all I get is a black screen. The game seems to be working, because I can blindly press "Z" to confirm, then "5" to insert credits (and hear the sound effect), and "1" to start, an "Z" a couple of times to select my character and advance to the actual fight… After all of this, I can hear the in-game music and the in-game sound effects of the fight. I just can't see any of it due to being pure black. How to reproduce? 1. Get the game archive from https://archive.org/details/street-chaves-1.5-a 2. Unpack it anywhere, and run `wine Chaves.exe` 3. After a few moments, a black window without any decoration will show up. Having no decorations is normal expected behavior. Having it completely black is a bug/regression. Tests? The game works fine under "Proton Experimental" on the Steam Deck, but I don't know exactly what is the Wine version. It also works fine under "Proton 10.0-1 (beta)". It does NOT work (black screen) under Wine 10.11 on Manjaro Linux. It does NOT work (black screen) under wine-ge-8-26-x86_64, which is the default Wine runner for Lutris, installed from Flatpak. https://lutris.net/games/street-chaves/ Other Wine versions are untested. If you are testing other versions, please be aware that older versions had a problem with keyboard input. You could see graphics on the screen, but you couldn't progress any further. This has been solved in bug 52738. -- 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 18

[Bug 58588] New: Tokens Acquired from WTSQueryUserToken do not set the session id for the token correctly
by WineHQ Bugzilla 10 Aug '25

10 Aug '25

http://bugs.winehq.org/show_bug.cgi?id=58588 Bug ID: 58588 Summary: Tokens Acquired from WTSQueryUserToken do not set the session id for the token correctly Product: Wine Version: 10.12 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: wtsapi32 Assignee: wine-bugs(a)winehq.org Reporter: katharina(a)hacked.xyz Distribution: --- A service running under NTAUTHORITY\SYSTEM may use the Windows Terminal Server API to resolve user sessions. This is also works on non-terminalservers, that is, normal computers where only one simoultaneous session is allowed. My best guess is that Windows internally treats all sessions as terminal service sessions, so this API becomes canon. If a service wants to then spawn a process attached to this user's session, so that the spawned process is able to open a window showing in the user's session, it may use CreateProcessAsUserW to do this, and supply a token to a users's Windows session. The general principle is for example documented in this stackoverflow question: https://stackoverflow.com/questions/3128017/launching-a-process-in-user-s-s… A real-world user of this mechanism is the Dassault 3DEXPERIENCE Launcher, which is unfortunately not available without purchase. The actual source of the token is not terribly important; the code I debugged uses WTSEnumerateSessions in conjunction with WTSQueryUserToken. The latter should return a token that has it's session ID set to the current users session ID; most likely 1. A reproducer for this bug is available here: https://gitlab.winehq.org/hackathi/wtsqueryusertoken-bug -- 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

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 August 2025