January 2026 - Wine-bugs - list.winehq.org

[Bug 59217] New: program crashes when attempting install
by WineHQ Bugzilla 07 Jan '26

07 Jan '26

http://bugs.winehq.org/show_bug.cgi?id=59217 Bug ID: 59217 Summary: program crashes when attempting install Product: Wine Version: 11.0-rc4 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: critical Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: thegamemaster(a)hotmail.com Distribution: --- Created attachment 80114 --> http://bugs.winehq.org/attachment.cgi?id=80114 backtrace of crash When attempting to install AD&D 2nd Edition Core Rules 2.0 CD-ROM, the "setup.exe" crashes in wine - the effected module says "winevdm.exe" code page error. I've attached the backtrace. I tried using Wine-Common, Wine-Staging, and Wine-Devel for Fedora 43 with the same results. Dell Inpiron laptop with core ii duo T9900 cpu and IBM business graphics, 8GB of RAM, SSD drive 1TB. Reading from ISO of CD-ROM from cdemu. -- 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 57639] New: Nine Witches Family Disruption (GOG) cannot launch due to missing .donet hostfxr.dll
by WineHQ Bugzilla 06 Jan '26

06 Jan '26

https://bugs.winehq.org/show_bug.cgi?id=57639 Bug ID: 57639 Summary: Nine Witches Family Disruption (GOG) cannot launch due to missing .donet hostfxr.dll Product: Wine Version: 10.0-rc4 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: titan.costa(a)gmail.com Distribution: --- Console log: 00f0:err:eventlog:ReportEventW L"Description: A .NET Core application failed.\n" 00f0:err:eventlog:ReportEventW L"Application: NineWitches.exe\n" 00f0:err:eventlog:ReportEventW L"Path: C:\\GOG Games\\Nine Witches Family Disruption\\NineWitches.exe\n" 00f0:err:eventlog:ReportEventW L"Message: A fatal error occurred. The required library hostfxr.dll could not be found.\n" 00f0:err:eventlog:ReportEventW L"If this is a self-contained application, that library should exist in [C:\\GOG Games\\Nine Witches Family Disruption\\].\n" 00f0:err:eventlog:ReportEventW L"If this is a framework-dependent application, install the runtime in the global location [C:\\Program Files\\dotnet] or use the DOTNET_ROOT environment variable to specify the runtime location or register the runtime location in [HKLM\\SOFTWARE\\dotnet\\Setup\\InstalledVersions\\x64\\Inst"... 00f0:err:eventlog:ReportEventW L"\n" 00f0:err:eventlog:ReportEventW L"The .NET Core runtime can be found at:\n" 00f0:err:eventlog:ReportEventW L" - https://aka.ms/dotnet-core-applaunch?missing_runtime=true&arch=x64&rid=win1…" 00f0:err:eventlog:ReportEventW L"\n" 00f0:fixme:advapi:DeregisterEventSource (00000000CAFE4242) stub -- 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 4

[Bug 29354] New: Microsoft Virtual PC 2007 SP1 installer fails to get past the "Product Key" dialog
by wine-bugs＠winehq.org 06 Jan '26

06 Jan '26

http://bugs.winehq.org/show_bug.cgi?id=29354 Bug #: 29354 Summary: Microsoft Virtual PC 2007 SP1 installer fails to get past the "Product Key" dialog Product: Wine Version: 1.3.34 Platform: x86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: msi AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Classification: Unclassified Hello, split off bug mentioned in http://bugs.winehq.org/show_bug.cgi?id=17512#c3 to track what is most likely a regression ... --- quote --- Tested in 1.3.19 Didn't crash but I couldn't get past the "Product Key" screen. The "Next" button didn't seem to do anything. --- quote --- The problem in Microsoft Virtual PC 2007 SP1 installer is the "ValidateProductID" standard action. Dump using ORCA: --- snip --- CustomerInformationDialog NextButton NewDialog ReadyToInstallDialog PIDRET = 0 4 CustomerInformationDialog NextButton DoAction CA_ValidatePID NOT ProductID AND PIDKEY AND PIDKEY<>" " 1 CustomerInformationDialog NextButton DoAction CA_InstallForAllUsers NOT VPC2004INSTALLED 2 CustomerInformationDialog NextButton DoAction CA_SetTargetPathOnUpgrade VPC2004INSTALLED 3 --- snip --- First condition, if true -> CA_ValidatePID gets executed. --- snip --- 0023:trace:msi:MSI_EvaluateConditionW L"NOT ProductID AND PIDKEY AND PIDKEY<>\" \"" ... 0023:trace:msi:msi_get_property returning L"PWCVDGDPM7P23VYG6QM4R8Y8T" for property L"ProductID" ... 0023:trace:msi:msi_get_property returning L"PWCVDGDPM7P23VYG6QM4R8Y8T" for property L"PIDKEY" ... 0023:trace:msi:MSI_EvaluateConditionW 0 <- L"NOT ProductID AND PIDKEY AND PIDKEY<>\" \"" --- snip --- (not fulfilled) Another condition to reach "ReadyToInstallDialog" is "PIDRET = 0". --- snip --- 0023:trace:msi:MSI_ProcessMessage (nil) (nil) (nil) 0 10 L"Action start 18:26:06: ValidateProductID." 0023:trace:msi:msi_get_property returning L"74216<````=````=````=````=`````>@@@@@" for property L"PIDTemplate" 0023:fixme:msi:ACTION_ValidateProductID partial stub: template L"74216<````=````=````=````=`````>@@@@@" key L"PWCVDGDPM7P23VYG6QM4R8Y8T" 0023:trace:msi:msi_set_property 0x13ce60 L"ProductID" L"PWCVDGDPM7P23VYG6QM4R8Y8T" 0023:trace:msi:MSI_ProcessMessage (nil) (nil) (nil) 0 10 L"Action ended 18:26:06: ValidateProductID. Return value 0." ... 0023:trace:msi:MSI_EvaluateConditionW L"PIDRET = 0" 0023:trace:msi:msi_get_property property L"PIDRET" not found 0023:trace:msi:MSI_EvaluateConditionW 0 <- L"PIDRET = 0" --- snip --- The "PIDRET" property never exists hence the installation is stuck in "CustomerInformationDialog". If you google for "Adding PIDRET property" you will find many similar looking msi logs, suggesting that this property is added during ValidatePID custom action: --- snip --- MSI (c) (DC:20) [17:55:05:750]: Doing action: ValidatePID MSI (c) (DC:20) [17:55:05:750]: Note: 1: 2205 2: 3: ActionText Action 17:55:05: ValidatePID. Action start 17:55:05: ValidatePID. ... MSI (c) (DC!3C) [17:55:05:875]: PROPERTY CHANGE: Adding PID property. Its value is '58730-000-0000007-05734'. MSI (c) (DC!3C) [17:55:05:875]: PROPERTY CHANGE: Adding ProductID property. Its value is '58730-000-0000007-05734'. ... MSI (c) (DC!3C) [17:55:05:875]: PROPERTY CHANGE: Adding PIDRET property. Its value is '0'. Action ended 17:55:05: ValidatePID. Return value 1. --- snip --- Because ProductID was set earlier during ValidateProductID standard action, CA_ValidatePID is never executed. http://source.winehq.org/git/wine.git/blob/8cc5561fbf9f3250fbd2d986390e4013… If you remove line 6891 the installer executes the custom action which allows to proceed and let the installation finally succeed. You need 'winetricks mfc42' for CA_ValidatePID. Regards -- 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.

3 23

[Bug 59214] New: Keysym translation breaks key bindings in most video games for Dvorak users
by WineHQ Bugzilla 06 Jan '26

06 Jan '26

http://bugs.winehq.org/show_bug.cgi?id=59214 Bug ID: 59214 Summary: Keysym translation breaks key bindings in most video games for Dvorak users Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winex11.drv Assignee: wine-bugs(a)list.winehq.org Reporter: burneddi(a)protonmail.com Distribution: --- Created attachment 80110 --> http://bugs.winehq.org/attachment.cgi?id=80110 workaround for the issue Most video games try to bind keys by positions (virtual keycodes) rather than by keysyms. This means the keybindings will be layout-agnostic as long as the user is using a standard physical keyboard -- so e.g. WASD movement will still happen on where the WASD keys would be on QWERTY even if the user's layout is AZERTY or Dvorak. The way Wine remaps vkeys for Dvorak layouts breaks this, resulting in the default controls in most games being unusable and the user having to rebind every key manually (so e.g. WASD in the settings menu becomes ,AOE). I can't imagine translating vkeys like this is actually correct or desireable behaviour. I don't have a Windows machine or the Windows know-how to test this right now, but I'm pretty sure on Windows a Dvorak layout will still be sending standard QWERTY keycodes, making Wine's behaviour incorrect. I've attached a patch that I use to work around this problem by just disabling the Dvorak-specific vkey layout translation. With this patch keyboard binds in games work as expected, and it doesn't break typing into text fields because input into those uses keysyms rather than keycodes. It's not production-ready (I just commented out the dvorak vkey table) but should help illustrate the problem. -- 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 58290] New: eMule 0.50a: Toolbar icons show with black background when in context menu
by WineHQ Bugzilla 05 Jan '26

05 Jan '26

http://bugs.winehq.org/show_bug.cgi?id=58290 Bug ID: 58290 Summary: eMule 0.50a: Toolbar icons show with black background when in context menu Product: Wine Version: 10.7 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: comctl32 Assignee: wine-bugs(a)winehq.org Reporter: kyle.kcsoftwares(a)gmail.com Distribution: --- Created attachment 78640 --> http://bugs.winehq.org/attachment.cgi?id=78640 Back background eMule 0.50a: Toolbar icons show with black background when in context menu -- 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.

3 7

[Bug 58146] New: HWiNFO 8.24 (latest): doesn't work unless winecfg is set to Windows 7
by WineHQ Bugzilla 05 Jan '26

05 Jan '26

http://bugs.winehq.org/show_bug.cgi?id=58146 Bug ID: 58146 Summary: HWiNFO 8.24 (latest): doesn't work unless winecfg is set to Windows 7 Product: Wine Version: 10.6 Hardware: x86-64 OS: MacOS Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: cemer99797(a)isorax.com Created attachment 78427 --> http://bugs.winehq.org/attachment.cgi?id=78427 Wine-devel 10.6 log using default Windows 10 in winecfg HWiNFO 8.24 (latest version, compatible with Windows 10) doesn't work unless winecfg is set to Windows 7 (instead of the default Windows 10). The intro window will load, but after clicking "Start" the app will crash. The progess bar stops at this stage: Examining system configuration... Initializing Kernel Driver... With this error message: Error Cannot install the HWiNFO driver ! It might be blocked by the system other applications. download link: https://sourceforge.net/projects/hwinfo/files/Windows_Portable/hwi_824.zip/… sha256: 74c71b6a8a3498f5a5254b4e692345c45ec5cf88246bf3516cd7c35faf516ca4 I'm using Gcenx's wine-devel 10.6 build (https://github.com/Gcenx/macOS_Wine_builds/releases/tag/10.6) on macOS 11 -- 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 13

[Bug 3638] pif's with batch files
by WineHQ Bugzilla 05 Jan '26

05 Jan '26

http://bugs.winehq.org/show_bug.cgi?id=3638 --- Comment #22 from imccluney(a)comcast.net --- Created attachment 80113 --> http://bugs.winehq.org/attachment.cgi?id=80113 Patch of winevdm.c To be sure, I do have an account on GitLab, at https://gitlab.winehq.org/BigBlueGnu, but yes, you are right when you say that I need approval to fork the project. I intended to show my changes after getting the go-ahead from the Wine team, but if that's not how it works, I guess I will attach a text file containing only the differences between my version of the /wine/programs/winevdm/winevdm.c file and Wine 10.0's own, from which began the patch. Also included are the author of the changes and when the file was last modified. Anyway, here is the file. -- 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 59215] New: Wine fails to start with SELinux enabled on Rocky Linux 8.10+
by WineHQ Bugzilla 05 Jan '26

05 Jan '26

http://bugs.winehq.org/show_bug.cgi?id=59215 Bug ID: 59215 Summary: Wine fails to start with SELinux enabled on Rocky Linux 8.10+ Product: Wine Version: 10.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: rikul(a)inbox.ru Distribution: --- Wine does not start when SELinux is enabled on Rocky Linux 8.10. Even wineboot fails to run. The issue was reproduced with Wine 9.0, Wine 10.0, and the current master branch. --- Steps to Reproduce --- 1. Enable SELinux (enforcing mode). 2. Run wine or wineboot. --- Actual Result --- Wine fails to start. With WINEDEBUG enabled, the following errors are printed: 14111.628:0020:0024:err:virtual:map_image_into_view failed to set 60000020 protection on L"\\??\\C:\\windows\\system32\\ntdll.dll" section .text, noexec filesystem 14111.613:0028:002c:err:virtual:virtual_setup_exception stack overflow 1344 bytes addr 0x6fffffc2faac stack 0x7ffffe100ac0 (0x7ffffe100000-0x7ffffe101000-0x7ffffe300000) SELinux also reports the following denial: SELinux is preventing /home/*user_path*/wine/bin/wine64-preloader from execmod access on the file /home/*user_path*/wine/lib/wine/x86_64-windows/ntdll.dll. ***** Plugin catchall_boolean (89.3 confidence) suggests ****************** If you want to allow selinuxuser to execmod Then you must tell SELinux about this by enabling the 'selinuxuser_execmod' boolean. Do setsebool -P selinuxuser_execmod 1 ***** Plugin catchall (11.6 confidence) suggests ************************** --- Notes --- Disabling SELinux or switching it to permissive mode allows Wine to start normally. I understand the SELinux-suggested workaround above, however I would like to understand why Wine requires such permissions (execmod on DLL files), as enabling them may introduce potential security risks. -- 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 59216] New: Share-Button of XBox Controller not recognized anymore since being a XInput-device only
by WineHQ Bugzilla 05 Jan '26

05 Jan '26

http://bugs.winehq.org/show_bug.cgi?id=59216 Bug ID: 59216 Summary: Share-Button of XBox Controller not recognized anymore since being a XInput-device only Product: Wine Version: 10.20 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: xinput Assignee: wine-bugs(a)list.winehq.org Reporter: hausladen(a)gmx.net Distribution: --- Hello everyone, I created an environment in Bottles using the Soda 9.0.1 runner (I’m not entirely sure which Wine version it’s based on). Due to some graphical issues, I switched to the official Wine 10.20 release. After doing so, I noticed that the Share button (the one in the center with the arrow up symbol) on my Xbox Wireless Controller (Model 1914) stopped working. Under Soda 9, the button was recognized as Button 15 in the DInput tab when I overrode the controller in Wine’s game controller settings. However, with Wine 10.20, I'm not able to get back buttons up to 19 (as under Soda 9). Now the maximum amount of buttons I am able to achieve is 13 buttons. From my research of few days now, it seems this issue might be related to Wine’s controller backend now using XInput only, which doesn’t support additional “misc” buttons like the Share button. It also appears that DInput support can no longer be re-enabled in same way, allowing acces to those extra buttons. Is there any way of a workaround to get back the support for additional controller-buttons? (Or is there already some kind of feature planned allowing ?) What I've tried: - SDL On/off - HiDraw on/off - Disabling XInput in RegEdit by HKCU/Software/Wine/DirectInput/UseXInput - Disabling XInput dlls in library-configuration separately as well as combinations of them. Additional info: OS: ArchLinux (latest updates installed) Desktop: KDE6 Wayland Best regards -- 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 58643] New: "floating" combobox dropdown area in winecfg
by WineHQ Bugzilla 05 Jan '26

05 Jan '26

http://bugs.winehq.org/show_bug.cgi?id=58643 Bug ID: 58643 Summary: "floating" combobox dropdown area in winecfg Product: Wine Version: 10.13 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: comctl32 Assignee: wine-bugs(a)winehq.org Reporter: kyle.kcsoftwares(a)gmail.com Distribution: --- Open winecfg Dropdown a combobox While dropdown area is visible, move winecfg main window => dropdown area does not follow its combobox anchor and is kept "floating" at its original position. -- 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 5