May 2026 - Wine-Bugs - list.winehq.org

[Bug 59729] New: Volumes do not report FILE_SUPPORTS_OPEN_BY_FILE_ID
by WineHQ Bugzilla May 15, 2026

May 15, 2026

http://bugs.winehq.org/show_bug.cgi?id=59729 Bug ID: 59729 Summary: Volumes do not report FILE_SUPPORTS_OPEN_BY_FILE_ID Product: Wine Version: 11.8 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: mountmgr.sys Assignee: wine-bugs(a)list.winehq.org Reporter: joel(a)airwebreathe.org.uk Distribution: --- Created attachment 80883 --> http://bugs.winehq.org/attachment.cgi?id=80883 reproducer.c (AI-assisted report) Wine's `FileFsAttributeInformation` handler does not include the `FILE_SUPPORTS_OPEN_BY_FILE_ID` flag (`0x01000000`) in the filesystem attribute flags for volumes reported as NTFS. On real Windows (NTFS), `GetVolumeInformationW()` / `GetVolumeInformationByHandleW()` returns this flag. It has been present on NTFS since Windows Vista. ## Impact on MSYS2 The MSYS2/Cygwin runtime checks the filesystem flags at mount time to decide whether to enable POSIX rename semantics. The relevant Cygwin code path is: 1. `mount_info::init_usr_pathconv()` queries `FileFsAttributeInformation` for each mount point. 2. The flags are stored in `fs_info::flags_`. 3. When `rename()` is called, Cygwin checks whether to use `FileRenameInformationEx` with `FILE_RENAME_POSIX_SEMANTICS`. 4. The decision requires **all three** conditions: - `wincap.has_posix_rename_semantics()` is true (Windows 10 1709+) - The filesystem type is NTFS - The filesystem flags include `FILE_SUPPORTS_OPEN_BY_FILE_ID` Without `FILE_SUPPORTS_OPEN_BY_FILE_ID`, Cygwin falls back to legacy rename behavior using `FileRenameInformation` (info class 10) with only `FILE_RENAME_REPLACE_IF_EXISTS`. This legacy path returns `STATUS_ACCESS_DENIED` when the destination file is held open by another process, even if the handle was opened with `FILE_SHARE_DELETE`. This directly causes the `pacman-key --populate` failure documented in the `posix-rename-semantics` bug: GnuPG's `rename(pubring.gpg, pubring.gpg~)` fails because `gpg-agent` holds `pubring.gpg~` open from the previous signing operation. **Note:** Even with `FILE_RENAME_POSIX_SEMANTICS` support implemented in the Wine server (see the `posix-rename-semantics` bug), MSYS2 will never use it unless this flag is also reported, because the Cygwin runtime gates the feature on the filesystem attribute check. ## Reproducer ``` x86_64-w64-mingw32-gcc -o reproducer.exe reproducer.c wine reproducer.exe ``` ### Expected output (Windows 10+, NTFS) ``` C:\: fs=NTFS flags=0x03e706ff C:\: FILE_SUPPORTS_OPEN_BY_FILE_ID: YES (PASS) Z:\: fs=NTFS flags=0x03e706ff Z:\: FILE_SUPPORTS_OPEN_BY_FILE_ID: YES (PASS) PASS ``` (Exact flag values vary by Windows version and filesystem features.) ### Actual output (Wine 10.0) ``` C:\: fs=NTFS flags=0x0000000a C:\: FILE_SUPPORTS_OPEN_BY_FILE_ID: NO (FAIL) Z:\: fs=NTFS flags=0x0000000a Z:\: FILE_SUPPORTS_OPEN_BY_FILE_ID: NO (FAIL) FAIL ``` ## Analysis Wine reports NTFS filesystem attributes in two locations: ### `dlls/ntdll/unix/file.c` — `NtQueryVolumeInformationFile` The `FileFsAttributeInformation` handler's default (NTFS) case returns: ```c info->FileSystemAttributes = FILE_CASE_PRESERVED_NAMES | FILE_PERSISTENT_ACLS; ``` This is `0x00000002 | 0x00000008` = `0x0000000a`. ### `dlls/mountmgr.sys/device.c` — `harddisk_query_volume` The `FileFsAttributeInformation` handler's default (NTFS) case returns: ```c info->FileSystemAttributes = FILE_CASE_PRESERVED_NAMES | FILE_PERSISTENT_ACLS | FILE_SUPPORTS_REPARSE_POINTS; ``` This is `0x00000002 | 0x00000008 | 0x00000080` = `0x0000008a`. Neither includes `FILE_SUPPORTS_OPEN_BY_FILE_ID` (`0x01000000`). Real Windows 10 NTFS reports a rich set of flags including at minimum: `FILE_CASE_PRESERVED_NAMES`, `FILE_PERSISTENT_ACLS`, `FILE_SUPPORTS_REPARSE_POINTS`, `FILE_SUPPORTS_OPEN_BY_FILE_ID`, and many others. The minimal fix is to add `FILE_SUPPORTS_OPEN_BY_FILE_ID` to both default NTFS cases. ## Fix The fix is straightforward — add `FILE_SUPPORTS_OPEN_BY_FILE_ID` to the NTFS default filesystem flags in both locations: - `dlls/ntdll/unix/file.c`: `NtQueryVolumeInformationFile`, `FileFsAttributeInformation` default case - `dlls/mountmgr.sys/device.c`: `harddisk_query_volume`, `FileFsAttributeInformation` default case The constant is already defined in `include/winnt.h`. Commit on branch `msys2-hacks-23`: - `578e06f7b57` `ntdll, mountmgr: Report FILE_SUPPORTS_OPEN_BY_FILE_ID for NTFS volumes.` ### After fix ``` C:\: fs=NTFS flags=0x0100008a C:\: FILE_SUPPORTS_OPEN_BY_FILE_ID: YES (PASS) Z:\: fs=NTFS flags=0x0100000a Z:\: FILE_SUPPORTS_OPEN_BY_FILE_ID: YES (PASS) PASS ``` ## Verified against - Wine 10.0 (nixpkgs upstream): **bug present** (`flags=0x0000000a`) - Wine 11.4 (msys2-hacks-23, commit `578e06f7b57`): **fixed** (`flags=0x0100000a`) - Real Windows 10 build 22631: flag present (`flags=0x03e706ff`) ## Environment - Wine: 10.0 (nixpkgs), 11.4 (msys2-hacks-23) - Windows: 10.0.22631 (reference) - MSYS2 runtime: 3.6.9-1 - Host: Linux x86_64 (NixOS) -- 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 54177] New: vbscript fails to compile sub call when argument expression contains multiplication
by WineHQ Bugzilla May 15, 2026

May 15, 2026

https://bugs.winehq.org/show_bug.cgi?id=54177 Bug ID: 54177 Summary: vbscript fails to compile sub call when argument expression contains multiplication Product: Wine Version: 7.21 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: vbscript Assignee: wine-bugs(a)winehq.org Reporter: jsm174(a)gmail.com Distribution: --- While working on the port of Visual Pinball, we found a script with code similar to the following that fails to compile: Public Sub AddTimer(aDelay, aMessage) End Sub Dim ii ii = 1 AddTimer (ii-1)*200, "Message" If the expression is wrapped in parenthesis, it compiles successfully: AddTimer ((ii-1)*200), "Message" -- 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 15

[Bug 59689] New: SEC_WINNT_AUTH_IDENTITY_EX support in AcquireCredentialsHandle
by WineHQ Bugzilla May 15, 2026

May 15, 2026

http://bugs.winehq.org/show_bug.cgi?id=59689 Bug ID: 59689 Summary: SEC_WINNT_AUTH_IDENTITY_EX support in AcquireCredentialsHandle Product: Wine Version: 11.7 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: secur32 Assignee: wine-bugs(a)list.winehq.org Reporter: winandfx(a)gmail.com Distribution: --- Created attachment 80794 --> http://bugs.winehq.org/attachment.cgi?id=80794 python crash log # Context I have a Python application which uses Windows DLLs so I was unable to run it on Linux. Then I've created a minimal Docker image with Wine 11.7 preinstalled https://github.com/Winand/wine-container I've used Kron4ek wine-11.7-staging-tkg-amd64 build but I think particularly for my issue it doesn't matter. My application works surprisingly well in Wine but I send notification emails via a corporate SMTP server and for authentication I use pyspnego library like it is described here https://stackoverflow.com/a/70788458. In Windows 10 there're no issues but in Wine the whole Python interpreter crashes on line: >>> auth = spnego.client(username, password, service="SMTP", protocol="ntlm") I've started to investigate the problem (with the help of Gemini as it is more experienced than me) and noticed that `options=spnego.NegotiateOptions.use_ntlm` fixes the issue (because it doesn't use SSPI). # Problem I've found out that on the Python side the problem is within sspilib, specifically here: https://github.com/jborean93/pyspnego/blob/main/src/spnego/_sspi.py#L76 ``` def _get_sspi_credential( ... auth_data = sspilib.raw.WinNTAuthIdentity( ... return sspilib.raw.acquire_credentials_handle(**credential_kwargs, auth_data=auth_data).credential ``` sspilib.raw.WinNTAuthIdentity returns SEC_WINNT_AUTH_IDENTITY_EXW structure as described here https://learn.microsoft.com/en-us/windows/win32/secauthn/acquirecredentials… https://github.com/jborean93/sspilib/blob/main/src/sspilib/raw/_credential.… But msv1_0.dll ntlm_SpAcquireCredentialsHandle expects SEC_WINNT_AUTH_IDENTITY_W structure https://gitlab.winehq.org/wine/wine/-/blob/master/dlls/msv1_0/main.c?ref_ty… https://gitlab.winehq.org/wine/wine/-/blob/master/dlls/secur32/lsa.c?ref_ty… In the crash log there's a line: >>> Unhandled exception: page fault on read access to 0x0000004800000200 in 64-bit code (0x006ffffff6746c). Gemini says that these are fields Version=0x02, Length=0x48(72 bytes) from SEC_WINNT_AUTH_IDENTITY_EXW. I'm not experienced enough to confirm this statement. So I think the problem is that ntlm_SpAcquireCredentialsHandle doesn't support SEC_WINNT_AUTH_IDENTITY_EXW. The crash can be easily reproduced using just one line of code in my wine-container described at the beginning: $ WINEDEBUG=+secur32,+ntlm,+msv1_0 wine python3.12 -c 'from spnego._sspi import SSPIProxy; sspi = SSPIProxy("test(a)corp.com", "1234", "unspecified", "host")' -- 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 12

[Bug 53317] New: Logos 9, Wine 7.11, Crash When Indexing: Invalid String Format
by WineHQ Bugzilla May 15, 2026

May 15, 2026

https://bugs.winehq.org/show_bug.cgi?id=53317 Bug ID: 53317 Summary: Logos 9, Wine 7.11, Crash When Indexing: Invalid String Format Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: thwright(a)thwright.com Distribution: --- Created attachment 72698 --> https://bugs.winehq.org/attachment.cgi?id=72698 Invalid String Format Bumped into this error today while trying to use Logos. It failed to index and the program is crashing regularly. -- 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 6

[Bug 59708] New: d3d9: missing MSVC vtable byte-pattern
by WineHQ Bugzilla May 15, 2026

May 15, 2026

http://bugs.winehq.org/show_bug.cgi?id=59708 Bug ID: 59708 Summary: d3d9: missing MSVC vtable byte-pattern Product: Wine Version: 11.7 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: d3d Assignee: wine-bugs(a)list.winehq.org Reporter: danielginovker(a)gmail.com Distribution: --- Created attachment 80842 --> http://bugs.winehq.org/attachment.cgi?id=80842 Proposed patch (git format-patch). Adds an 18-byte MSVC-pattern marker after d3d9_device_vtbl in dlls/d3d9/device.c plus a conformance test in dlls/d3d9/tests/device.c. Wine's d3d9.dll is MinGW GCC-built and doesn't contain the MSVC C++ vtable-init byte sequence (c7 06 ?? 89 86 ?? 89 86) that some closed-source overlay/hook libraries scan for to locate the IDirect3DDevice9 vtable. Concrete affected case: bfmeladder.com's BFME Online Arena. Its dinput8.dll proxy fails to install hooks on Wine, so the Arena's 30-second Automated Matchmaking Test times out with "the overlay didn't load in 30 seconds." Repro: install https://bfmeladder.com/download under Wine staging, sign in, pick any game and patch, watch the test fail. Proposed patch attached: 18-byte packed const struct after d3d9_device_vtbl in .rdata, reproducing the pattern with &d3d9_device_vtbl as imm32. Not referenced by any Wine code. Conformance test included. -- 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 8

[Bug 56281] New: String number converted to ascii value instead of parsed value
by WineHQ Bugzilla May 15, 2026

May 15, 2026

https://bugs.winehq.org/show_bug.cgi?id=56281 Bug ID: 56281 Summary: String number converted to ascii value instead of parsed value Product: Wine Version: 9.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: vbscript Assignee: wine-bugs(a)winehq.org Reporter: francisdb(a)gmail.com Distribution: --- > cat test.vbs Dim x x = "0" If IsNumeric(x) Then WScript.Echo "Numeric" Else WScript.Echo "Not Numeric" End If If x > 30 Then WScript.Echo "> 30" Else WScript.Echo "Not > 30" End If > wine cscript test.vbs 0088:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005 0088:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005 0088:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005 0088:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005 Numeric > 30 Windows > cscript test.vbs Microsoft (R) Windows Script Host Version 5.812 Copyright (C) Microsoft Corporation. All rights reserved. Numeric Not > 30 -- 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 6

[Bug 53877] New: vbscript compile_assignment assertion when assigning multidimensional array by indices
by WineHQ Bugzilla May 15, 2026

May 15, 2026

https://bugs.winehq.org/show_bug.cgi?id=53877 Bug ID: 53877 Summary: vbscript compile_assignment assertion when assigning multidimensional array by indices Product: Wine Version: 7.20 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: vbscript Assignee: wine-bugs(a)winehq.org Reporter: jsm174(a)gmail.com Distribution: --- The following works in real vbscript: Dim x Redim x(10) x(1) = Array(5, 6, 7) WScript.echo x(1)(0) WScript.echo x(1)(2) x(1)(0) = x(1)(2) WScript.echo x(1)(0) Output: 5 7 7 When running through Wine vbscript an assertion happens when processing x(1)(0) = x(1)(2) case EXPR_CALL: call_expr = (call_expression_t*)left; assert(call_expr->call_expr->type == EXPR_MEMBER); Stepping through the debugger, call_expr->call_expr->type appears to be EXPR_CALL -- 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 7

[Bug 58925] New: GOM Player: UI elements not responding to mouse clicks
by WineHQ Bugzilla May 15, 2026

May 15, 2026

http://bugs.winehq.org/show_bug.cgi?id=58925 Bug ID: 58925 Summary: GOM Player: UI elements not responding to mouse clicks Product: Wine Version: 10.18 Hardware: x86-64 URL: https://www.gomlab.com/en/gomplayer-media-player OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: tobbi.bugs(a)googlemail.com Distribution: --- I installed GOM Player from the website mentioned. I noticed that the GOM Player is not responding to mouse clicks. Steps to reproduce: 1. Download GOM from https://www.gomlab.com/en/gomplayer-media-player (button Windows Download) 2. Install GOM using the downloaded .exe file. 3. Start GOM from C:/Program Files (x86)/GOM/GOMPlayer/GOMPlayer.exe 4. Notice how the program is not responding to any mouse clicks. % openssl sha256 GOMPLAYERGLOBALSETUP_NEW.EXE SHA2-256(GOMPLAYERGLOBALSETUP_NEW.EXE)= 841694b497b295b9f42d3f669828334cf59f582ff77f7a9e4b80f99ef084c9e7 % wine --version wine-10.18 I also notice that on first start, there's a "Close" button. Clicking that button somehow opens gomapp://close/ in Wine's Internet Explorer. I don't know if this is a separate bug or if the UI elements are unresponsive because of the non-dismissable message. -- 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 3

[Bug 59408] New: Ultimate Custom Night has severe performance issues
by WineHQ Bugzilla May 15, 2026

May 15, 2026

http://bugs.winehq.org/show_bug.cgi?id=59408 Bug ID: 59408 Summary: Ultimate Custom Night has severe performance issues Product: Wine Version: 11.2 Hardware: x86-64 OS: MacOS Status: UNCONFIRMED Severity: normal Priority: P2 Component: d3d Assignee: wine-bugs(a)list.winehq.org Reporter: afifsworld132(a)gmail.com Created attachment 80376 --> http://bugs.winehq.org/attachment.cgi?id=80376 Ultimate Custom Night logs macOS 14.1.1, Wine Staging 11.2 from Homebrew, Game is D3D9, Installed from Steam. The game barely reaches 10fps. Everything else seemingly works fine and game renders. -- 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 59738] New: GetFinalPathNameByHandleW returns unresolved symbolic link path instead of final resolved path
by WineHQ Bugzilla May 15, 2026

May 15, 2026

http://bugs.winehq.org/show_bug.cgi?id=59738 Bug ID: 59738 Summary: GetFinalPathNameByHandleW returns unresolved symbolic link path instead of final resolved path Product: Wine Version: 11.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: --- Created attachment 80903 --> http://bugs.winehq.org/attachment.cgi?id=80903 The archive contains a minimal reproducer and a prebuilt executable demonstrating the issue. According to Microsoft documentation, GetFinalPathNameByHandleW() is expected to return the fully resolved final path for the object referenced by the handle. The documentation explicitly states: “A final path is the path that is returned when a path is fully resolved. For example, for a symbolic link named C:\tmp\mydir that points to D:\yourdir, the final path would be D:\yourdir.” Wine currently returns the original unresolved path containing the symbolic link component instead of the resolved target path. This differs from native Windows behavior and breaks applications relying on canonical filesystem paths. The issue also affects std::filesystem::weakly_canonical, which internally depends on GetFinalPathNameByHandleW. Steps to reproduce ------------------ Create a symbolic link: 1. touch /tmp/real.txt 2. ln -s /tmp/real.txt /tmp/link.txt 3. wine symlink_test.exe /tmp/link.txt. The program opens link.txt and calls GetFinalPathNameByHandleW() on the handle. Expected behavior ------------------ Input path: /tmp/link.txt GetFinalPathNameByHandleW result: \\?\Z:\tmp\real.txt std::filesystem::weakly_canonical result: Z:\tmp\real.txt The returned path is fully resolved and does not contain the symbolic link component. Actual behavior --------------- Input path: /tmp/link.txt GetFinalPathNameByHandleW result: \\?\Z:\tmp\link.txt std::filesystem::weakly_canonical result: Z:\tmp\link.txt Wine returns the unresolved original path used to open the handle. Regression information ---------------------- A git bisect identifies the following commit as the first bad commit: https://gitlab.winehq.org/wine/wine/-/commit/af35741d3681f21222a85900b54d95… Before this commit, GetFinalPathNameByHandleW() returned the resolved canonical path correctly. Tested on Wine 11.0 -- 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