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

[Bug 60415] New: Digitized context cannot be opened
by WineHQ Bugzilla Oct. 21, 2026

Oct. 21, 2026

http://bugs.winehq.org/show_bug.cgi?id=60415 Bug ID: 60415 Summary: Digitized context cannot be opened Product: Wine Version: 11.17 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: wintab32 Assignee: wine-bugs(a)list.winehq.org Reporter: gunay.orbay(a)gmail.com Target Milestone: --- Distribution: --- gpWTInfoA(WTI_DDCTXS,...) call no longer returns a valid context. No tablet input for PaintTool SAI and Wintab supporting apps. Steps to reproduce: https://github.com/Wacom-Developer/wacom-device-kit-windows/tree/master run the ScribbleDemo with '/ctx digitizer' command line argument. -- 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 59823] New: 11.7 regression: Some apps get keys duplicated on single press
by WineHQ Bugzilla Oct. 21, 2026

Oct. 21, 2026

http://bugs.winehq.org/show_bug.cgi?id=59823 Bug ID: 59823 Summary: 11.7 regression: Some apps get keys duplicated on single press Product: Wine Version: 11.7 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winewayland Assignee: wine-bugs(a)list.winehq.org Reporter: bigfoothart(a)gmail.com Distribution: --- Created attachment 81092 --> http://bugs.winehq.org/attachment.cgi?id=81092 keys duplicated on single press Some apps get keys duplicated on single press Bisected to https://gitlab.winehq.org/wine/wine/-/commit/4f8cb7a92da955d3984c3f926701ed… (win32u: Move IME processing to ImeToAsciiEx). 11.10 still reproduced. -- 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 15

[Bug 57993] New: winedevice.exe Hangs After Exiting Games
by WineHQ Bugzilla Oct. 20, 2026

Oct. 20, 2026

https://bugs.winehq.org/show_bug.cgi?id=57993 Bug ID: 57993 Summary: winedevice.exe Hangs After Exiting Games Product: Wine Version: 10.3 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: nekoNexus(a)protonmail.ch Distribution: --- Created attachment 78253 --> https://bugs.winehq.org/attachment.cgi?id=78253 Vanilla Wine version 10.3 Log Distro: Gentoo Linux (x86_64) DXVK Version: 2.6 Gamescope Version: 3.16.2 Desktop Environment: KDE Plasma 6.2.5 (Wayland) CPU: Ryzen 3700X @ 4.98 GHz RAM: 32GBs @ 3600 MHz GPU: AMD RX 7800 XT Mesa Version: 25.0.1 Explanation: ------------- When launching games like Sherlock Holmes: Crimes and Punishments (GOG), exiting the game (even just launching the game and closing via the main menu not long after) causes winedevice.exe to just hang (and this causes a zombie window to remain open) and I'm forced to run "pkill -9 winedevice.exe" (this problem is consistent) It doesn't seem to show up at the end of my log, either, for some reason. I'll still share my log (although, this specific log exhibits a separate issue I'm about to file) for reference, however -- 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 2

[Bug 59946] New: Skyrim (2011): crashes due to "rawinput... unhandled flags 0x230" with >=11.11
by WineHQ Bugzilla Oct. 20, 2026

Oct. 20, 2026

http://bugs.winehq.org/show_bug.cgi?id=59946 Bug ID: 59946 Summary: Skyrim (2011): crashes due to "rawinput... unhandled flags 0x230" with >=11.11 Product: Wine Version: 11.11 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: user32 Assignee: wine-bugs(a)list.winehq.org Reporter: red2x4(a)gmail.com Distribution: Gentoo Created attachment 81312 --> http://bugs.winehq.org/attachment.cgi?id=81312 The relevant log snippet. Skyrim (2011) crashes on the main menu with Wine Staging >=11.11. Rolling app-emulation/wine-staging (Gentoo) back to <=11.10 resolves the issue. -- 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 60552] New: RFE: Explicitly define linker segment option to override distro default
by WineHQ Bugzilla Oct. 20, 2026

Oct. 20, 2026

http://bugs.winehq.org/show_bug.cgi?id=60552 Bug ID: 60552 Summary: RFE: Explicitly define linker segment option to override distro default Product: Wine Version: 11.20 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: loader Assignee: wine-bugs(a)list.winehq.org Reporter: mike(a)cchtml.com Target Milestone: --- Distribution: --- Wine has relied on default linker behavior. Starting with Fedora 45 and binutils 2.47 the default linker option "--rosegment" is now set for all binary linking. The previous default linker option was "--no-rosegments" and other distros may or may not follow Fedora. The reasoning behind the option switch is to improve security of the resulting binary layout. May Wine explicitly define "--no-rosegments" to preserve the expected binary output? This should be a no-op for all distros except Fedora 45+ that now override the defaults. I have opened a binutils bug to discuss the change, too. https://sourceware.org/bugzilla/show_bug.cgi?id=34714 -- 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 57890] New: 3DMark11 is not working
by WineHQ Bugzilla Oct. 20, 2026

Oct. 20, 2026

https://bugs.winehq.org/show_bug.cgi?id=57890 Bug ID: 57890 Summary: 3DMark11 is not working Product: Wine Version: 10.0 Hardware: x86-64 OS: MacOS Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: isakov-sl(a)bk.ru Created attachment 78118 --> https://bugs.winehq.org/attachment.cgi?id=78118 Log of the fail Unlike bug 42119 I can't start this DirectX11 benchmark in the same wine. The application started with empty windows. The last line in the log ~~~~ 0024:fixme:dxgi:dxgi_output_GetDisplayModeList iface 0000000001233510, format DXGI_FORMAT_R8G8B8A8_UNORM_SRGB, flags 0x3, mode_count 000000000011FC58, modes 00000000009908F0 partial stub! ~~~~ So the problem is in dxgi? -- 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 60433] New: crypt32: SSL chain policy rejects certificates with an iPAddress subject alternative name
by WineHQ Bugzilla Oct. 20, 2026

Oct. 20, 2026

http://bugs.winehq.org/show_bug.cgi?id=60433 Bug ID: 60433 Summary: crypt32: SSL chain policy rejects certificates with an iPAddress subject alternative name Product: Wine Version: 11.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: crypt32 Assignee: wine-bugs(a)list.winehq.org Reporter: dhane1000(a)yahoo.com Target Milestone: --- Distribution: --- CertVerifyCertificateChainPolicy with CERT_CHAIN_POLICY_SSL fails with CERT_E_CN_NO_MATCH when the server name is an IP address and the certificate lists that address as an iPAddress subject alternative name. Windows accepts these certificates. Public CAs now issue such certificates, for example Let's Encrypt IP address certificates, and public services use them (https://1.1.1.1/) Steps to reproduce: 1. In a .NET Framework 4.8 program, make an HTTPS request to https://1.1.1.1/ (HttpWebRequest, with a ServerCertificateValidationCallback that prints the SslPolicyErrors). 2. Run it in Wine. Result in Wine: SslPolicyErrors = RemoteCertificateNameMismatch Result on Windows: SslPolicyErrors = None The chain itself is valid. A certificate for a DNS name, such as https://letsencrypt.org/, works in the same program. Cause: match_dns_to_subject_alt_name() in dlls/crypt32/chain.c only compares CERT_ALT_NAME_DNS_NAME entries. It skips CERT_ALT_NAME_IP_ADDRESS entries, so an IP address server name never matches. The subject DN fallback does not help, because these certificates have an empty subject. The code is the same in current master (wine-11.19). Expected behaviour: If the server name parses as an IPv4 or IPv6 address, compare its binary form with the iPAddress entries (4 or 16 bytes). Tested with: - wine-11.0 (Staging), Fedora 44 - Proton-CachyOS 11.0, GE-Proton 11, DW-Proton All fail the same way. Real application affected: the RO3 Asia game client logs in to a server by IP address with a Let's Encrypt IP certificate, and the login fails in Wine. -- 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 60273] New: crypt32: signature verification re-sorts PKCS#7 authenticated attributes, breaking valid signatures whose SignedAttrs are not in DER order (FL Studio 26.1.5 fails to start)
by WineHQ Bugzilla Oct. 20, 2026

Oct. 20, 2026

http://bugs.winehq.org/show_bug.cgi?id=60273 Bug ID: 60273 Summary: crypt32: signature verification re-sorts PKCS#7 authenticated attributes, breaking valid signatures whose SignedAttrs are not in DER order (FL Studio 26.1.5 fails to start) Product: Wine Version: 11.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: crypt32 Assignee: wine-bugs(a)list.winehq.org Reporter: mcnster(a)gmail.com Target Milestone: --- Distribution: --- Created attachment 81992 --> http://bugs.winehq.org/attachment.cgi?id=81992 Minimal WinVerifyTrust reproducer, builds with mingw-w64 FL Studio 2026 version 26.1.5.5618 fails to start under Wine. The application displays "The validity of the program could not be verified. Please reinstall it and try again." and exits. Version 26.1.3.5570 of the same application starts and runs normally in the same prefix. The two builds are signed by the same CA with the same algorithms; the only change is a routine renewal of the leaf code-signing certificate. The signature on the 26.1.5 binaries is valid. osslsigncode and OpenSSL verify it successfully, including the PE image hash, the certificate chain to DigiCert Trusted Root G4, and the RFC 3161 timestamp. The binaries also run correctly on Windows. Wine's WinVerifyTrust rejects them. STEPS TO REPRODUCE 1. Install FL Studio 26.1.5.5618 into a clean prefix. The free trial installer is the same binary and requires no license, so this is reproducible without purchasing anything. 2. Run FL64.exe. The validity dialog appears and the program exits. Or, without installing the application, using the attached reproducer (wvt.c, ~30 lines, builds with mingw-w64): x86_64-w64-mingw32-gcc -o wvt.exe wvt.c -lwintrust wine wvt.exe FL64-2615.exe EXPECTED RESULT WinVerifyTrust returns 0, as it does on Windows and as OpenSSL's verification of the same file agrees it should. ACTUAL RESULT WinVerifyTrust: 0x80096004 (TRUST_E_CERT_SIGNATURE) Against the equivalent file from 26.1.3 the same reproducer returns 0x00000000. WHERE IT FAILS WINEDEBUG=+wintrust,+chain,+crypt,+cryptasn,+bcrypt Failing (26.1.5): trace:crypt:new_key alg = "RSA_KEYX", dwKeyLen = 3072 trace:crypt:CryptVerifySignatureW (..., 384, ..., (null), 00000000) trace:crypt:RSAENH_CPVerifySignature (... dwSigLen=384 ...) trace:wintrust:WinVerifyTrust returning 80096004 Working (26.1.3): trace:crypt:new_key alg = "RSA_KEYX", dwKeyLen = 4096 trace:crypt:CryptVerifySignatureW (..., 512, ..., (null), 00000000) trace:crypt:RSAENH_CPVerifySignature (... dwSigLen=512 ...) trace:crypt:new_key alg = "RSA_SIGN", dwKeyLen = 4096 <- chain trace:crypt:new_key alg = "RSA_SIGN", dwKeyLen = 4096 trace:crypt:new_key alg = "RSA_SIGN", dwKeyLen = 4096 trace:wintrust:WinVerifyTrust returning 00000000 The failure occurs inside CryptMsgControl(hMsg, 0, CMSG_CTRL_VERIFY_SIGNATURE, ...) at the first RSA operation, one millisecond into the call. CertGetCertificateChain is never reached; CertFreeCertificateChain receives a NULL handle. This is a SignerInfo signature failure, not a certificate chain failure, despite the returned HRESULT. RULED OUT BY TESTING - Certificate chain. Never built. The intermediate is byte-for-byte identical in both versions (DigiCert Trusted G4 Code Signing RSA4096 SHA384 2021 CA1, serial 08:AD:40:B2...), chaining to DigiCert Trusted Root G4 in both cases. - PE image hash. Computed and accepted before the failure point, and independently confirmed by osslsigncode. - Timestamp. RFC 3161 token at 1.3.6.1.4.1.311.3.3.1 in both versions. Never reached. - Signature algorithms. Both versions: SHA-256 message digest, rsaEncryption, sha256WithRSAEncryption leaf, sha384WithRSAEncryption intermediate. No RSASSA-PSS, no ECDSA. - Dual/nested signing. Neither version has 1.3.6.1.4.1.311.2.4.1. Single signature in both. - RSA key size. The leaf key changed from 4096-bit to 3072-bit (signature 512 to 384 bytes). Tested directly against rsaenh with synthetic keys via CryptImportPublicKeyInfoEx and CryptVerifySignatureW: 2048, 3072 and 4096 all verify correctly. - rsaenh entirely. Feeding the real leaf public key, the real 384-byte enc_digest and the real 126-byte SignedAttrs in stored order through CryptImportPublicKeyInfoEx + CryptVerifySignatureW under Wine returns success. The identical key, signature and octets fail when the same rsaenh code is reached via WinVerifyTrust. The sole difference is that crypt32 hashes re-encoded attributes rather than the original ones. THE ONE STRUCTURAL DIFFERENCE The PKCS#7 authenticated attributes appear in a different order in the two files. Each attribute is a SEQUENCE with a single-byte length, so DER ordering is decided by that length octet: attribute encoding length SPC_SP_OPUS_INFO (2.1.12) 30 10 0x10 contentType (1.2.840.113549.1.9.3) 30 19 0x19 SPC_STATEMENT_TYPE (2.1.11) 30 1C 0x1C messageDigest (1.2.840.113549.1.9.4) 30 2F 0x2F 26.1.3 file order: 0x10, 0x19, 0x1C, 0x2F ascending 26.1.5 file order: 0x1C, 0x10, 0x19, 0x2F NOT ascending X.690 11.6 requires the components of a SET OF to appear in ascending order compared as octet strings. The 26.1.5 SignedAttrs set does not satisfy this. It is nonetheless the encoding the signature was computed over, since OpenSSL verifies the file successfully and OpenSSL hashes the attributes in their decoded order (PKCS7_ATTR_VERIFY is declared with ASN1_TFLG_SET_ORDER, which preserves order rather than sorting). Windows accepts the file as well. CONFIRMATION THAT THE SIGNATURE COVERS THE UNSORTED BYTES The 126-byte SignedAttrs region was extracted from the DER PKCS#7 blob with the implicit [0] tag replaced by SET (0x31), leaving the attribute order exactly as stored in the file. The 384-byte enc_digest and the leaf public key were extracted from the same file. Then: openssl dgst -sha256 -verify leafpub.pem -signature encdigest.bin attrs.bin Verified OK So the signature was computed over the attributes in their stored, non-DER order. Any verifier that re-orders them before hashing will compute a different digest and reject a valid signature. ROOT CAUSE CSignedMsgData_UpdateAuthenticatedAttributes (dlls/crypt32/msg.c:1106) re-encodes the decoded attributes via CryptEncodeObjectEx(PKCS_ATTRIBUTES) and hashes the result, rather than hashing the attribute bytes as they appear in the file. That reaches CRYPT_AsnEncodePKCSAttributes (dlls/crypt32/encode.c:1896), which calls CRYPT_DEREncodeItemsAsSet (encode.c:1239). That function qsort()s the encoded attributes into DER order at encode.c:1294 before concatenating them. (Note there is a second sorting encoder, CRYPT_DEREncodeSet at encode.c:1195, qsort at 1217. It sorts the values within a single attribute, not the attributes themselves. Every attribute here has one value, so it is a no-op in this case.) The sorted 126 bytes therefore differ from the 126 bytes the signer signed, the digest does not match, and the RSA verification fails. This explains why 26.1.3 works and 26.1.5 does not: 26.1.3's attributes are already in ascending DER order, so the sort is a no-op. Note that sorting does not change the total length, which is 126 bytes either way, so length is not a useful diagnostic signal here. Sorting is correct behaviour when producing a signature. It is wrong when verifying one, because it discards the exact octets the signature was computed over. SUGGESTED FIX DIRECTION For signature verification, hash the authenticated attributes in the order they were decoded, rather than round-tripping them through a DER set encoder that sorts. This is what Windows does, and it is why non-canonically-ordered SignedAttrs verify there. A patch implementing this, together with a conformance test, has been written and tested. It adds an order-preserving attribute encoder and uses it on the verify path only. With it applied: - the new test in dlls/crypt32/tests/msg.c passes, and fails without it - crypt32, wintrust and rsaenh tests report 0 failures on both i386 and x86_64 - FL Studio 26.1.5 starts and runs normally A merge request will be linked here. VERSIONS TESTED - wine-11.0 (winehq-stable), Debian 13 trixie, x86-64 -- fails - Community reports indicate wine-11.16 is also affected, so this is not fixed in current development branches. - Affected application builds: 26.1.4.5589 and 26.1.5.5618 fail; 26.1.3.5570 and earlier work. -- 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 22

[Bug 60551] New: combase: LocalService activation fails when CLSID is registered only in the opposite WOW64 registry view
by WineHQ Bugzilla Oct. 20, 2026

Oct. 20, 2026

http://bugs.winehq.org/show_bug.cgi?id=60551 Bug ID: 60551 Summary: combase: LocalService activation fails when CLSID is registered only in the opposite WOW64 registry view Product: Wine Version: 11.20 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ole32 Assignee: wine-bugs(a)list.winehq.org Reporter: hamsteruser(a)gmail.com Target Milestone: --- Distribution: --- Created attachment 82416 --> http://bugs.winehq.org/attachment.cgi?id=82416 Try the opposite registry view for LocalService activation. This bug prevents 64-bit 3DMark 11 from starting unless an AppID value of {1BF1C030-CE12-4A8A-A4E1-EDDCE7176799} is added under HKLM\Software\Classes\CLSID\{F9C82199-B002-41B4-8B00-0F1ECA89425F} in the 64-bit registry view. The patch fixes COM LocalService activation by retrying the CLSID-to-AppID lookup in the opposite WOW64 registry view when the initial lookup fails. A standalone MinGW-w64 reproducer is attached. It tests same-view registration, opposite-view registration, and opposite-view registration with an AppID mapping added in the client's view. The tested reproducer returns 0, 0, 0 on Windows and patched Wine, and 0, 1, 0 on unpatched Wine. -- 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 60437] New: RiSCAN_PRO: OpenGL child window renders black since wine 11.16
by WineHQ Bugzilla Oct. 20, 2026

Oct. 20, 2026

http://bugs.winehq.org/show_bug.cgi?id=60437 Bug ID: 60437 Summary: RiSCAN_PRO: OpenGL child window renders black since wine 11.16 Product: Wine Version: 11.16 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: opengl Assignee: wine-bugs(a)list.winehq.org Reporter: pyro4hell+winehq(a)gmail.com Target Milestone: --- Distribution: --- Created attachment 82250 --> http://bugs.winehq.org/attachment.cgi?id=82250 Patch file with workaround starting with wine-11.16 the pointcloud viewer in RiSCAN PRO (commercial Windows only program https://www.riegl.com/en-usa/products/detail/riscan-pro ) only renders black screen. The viewer is using an OpenGL sub-window With wine-11.15 the view works perfectly. I got a `git bisect` and got the following commit out of it: ``` 5cbad47284b52c69b8f2f30c3786d00ae69823b8 is the first 'bad' commit commit 5cbad47284b52c69b8f2f30c3786d00ae69823b8 (HEAD) Author: Rémi Bernon <rbernon(a)codeweavers.com> Date: Wed Aug 19 16:19:33 2026 +0200 opengl32: Restore read and draw buffers when popping default FBOs. dlls/opengl32/unix_wgl.c | 28 ++++++++++++++++++++++------ include/wine/opengl_driver.h | 1 + 2 files changed, 23 insertions(+), 6 deletions(-) ``` I reverted the commit based on wine-11.16 and the viewer worked again. On wine-11.19 the revert didn't work, but I found a workaround by not drawing the default buffer if its content is 0 (see attached patch file). App: RiSCAN_PRO.exe 2.26 Steps to reproduce: - Open RiSCAN_PRO.exe - load project - open pointcloud - see black viewer instead of pointcloud GPU / driver: NVIDIA GeForce RTX 3060 with proprietary driver 615.71.09 Session: both X11 and Wayland OS: both Kubuntu 24.04 and CachyOS using Plasma Wine build: --enable-archs=i386,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 7