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

[Bug 59356] New: Imperium Great Battles of Rome doesn't reproduce music and audio
by WineHQ Bugzilla Oct. 16, 2026

Oct. 16, 2026

http://bugs.winehq.org/show_bug.cgi?id=59356 Bug ID: 59356 Summary: Imperium Great Battles of Rome doesn't reproduce music and audio Product: Wine Version: 11.1 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: dmusic Assignee: wine-bugs(a)list.winehq.org Reporter: lorenzofer(a)live.it Distribution: --- Created attachment 80291 --> http://bugs.winehq.org/attachment.cgi?id=80291 log Hi, Imperium GBR, Great Battles of Rome, doesn't reproduce music and general audio of the game, unless native directmusic is installed and dmusic,dmime, dswave, dmsynth and dsound are setted on native (native dmime is a bit infectious by asking private undocumented interface on other components). Imperium use Wave audio, and it's supposed to be implemented. And in fact audio fully worked on wine-staging 8.10 (first checked) until 8.15 (last working version available on the arch repo, these version doesn't seems to be compilable, maybe require an older version of some toolchain component), while the sucessive version available on the arch repo, 8.18 doesn't work anymore, and this match with the disabling of dmime-load-wave from staging, as it's supposed to be included into upstream. However it seems the current upstream is quite differently from the patchset, using wavetracks instead of putting the wave inside a segment. Resulting log shows multiple object interoperating, and dmime have a lot of functions that while having an implementation are still marked like "fixme stub",making it confusing to debug without being familiar. Attaching a +dmime,+dswave,+dmsynth,+dmusic log -- 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 11

[Bug 20777] New: Unigine Heaven benchmark crashes on load.
by wine-bugs＠winehq.org Oct. 16, 2026

Oct. 16, 2026

http://bugs.winehq.org/show_bug.cgi?id=20777 Summary: Unigine Heaven benchmark crashes on load. Product: Wine Version: 1.1.33 Platform: PC URL: http://unigine.com/download/#heaven OS/Version: Linux Status: NEW Keywords: dotnet, download Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: jeffz(a)jeffz.name Created an attachment (id=24871) --> (http://bugs.winehq.org/attachment.cgi?id=24871) terminal output sh winetricks dotnet20 wine msiexec /i Unigine_Heaven-1.0.msi -- 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 17

[Bug 60424] New: Office 2013 Click-to-Run installer fails with builtin msxml6 when DOMDocument::save() uses "unicode" encoding
by WineHQ Bugzilla Oct. 16, 2026

Oct. 16, 2026

http://bugs.winehq.org/show_bug.cgi?id=60424 Bug ID: 60424 Summary: Office 2013 Click-to-Run installer fails with builtin msxml6 when DOMDocument::save() uses "unicode" encoding Product: Wine Version: 11.19 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: msxml6 Assignee: wine-bugs(a)list.winehq.org Reporter: pocketpower(a)gmail.com Target Milestone: --- Distribution: --- Created attachment 82233 --> http://bugs.winehq.org/attachment.cgi?id=82233 setup logs with WINEDEBUG=+loaddll,+msxml,+ole,+seh Command to execute: $ WINEDEBUG=+loaddll,+msxml,+ole,+seh WINEPREFIX="$HOME/wine11_19-office2013" wine Downloads/Setup.X64.en-us_HomeBusinessRetail_0ee6c9d8-19c5-410d-9fc0-8e9b4cac755f_TX_DB_.exe &> office-msxml-test.log Setup reaches to 58% and then dislays error code -2147467259-4 msxml6 is builtin not native. Relevant lines from the logs: domdoc_save ... appxpolicy.xml node_save Using L"unicode" encoding. fixme:msxml:node_save Unrecognized output encoding L"unicode". XMLDocument save failed Native 64-bit msxml6 fails early with COM loading failure. Builtin reaches much much further. -- 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 60384] New: Unable to log in to Medicalc4
by WineHQ Bugzilla Oct. 16, 2026

Oct. 16, 2026

http://bugs.winehq.org/show_bug.cgi?id=60384 Bug ID: 60384 Summary: Unable to log in to Medicalc4 Product: Wine Version: 11.17 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: tadeas.janosek(a)mapogroup.cz Target Milestone: --- Distribution: --- Created attachment 82178 --> http://bugs.winehq.org/attachment.cgi?id=82178 Archive with relevant logs Attempts to log in into the application always fails with invalid user name or password. Info about the application: - Medicalc4.exe is 32bit binary. - user is authentificated against Active Directory Environment variables I used - LDAPREFERRALS=off - LDAPSASL_NOCANON=on Testing was done on domain joined Archlinux. On wine version 11.15 when ran without LDAPSASL_NOCANON=on (wine-11.15.log) the application works but from the logs it seems it uses NTLM instead of kerberos. Howerver on version 11.17 and later it no longer falls back to NTLM. By setting LDAPSASL_NOCANON=on the app successfully obtains kerberos ticket, but login still fails. (Verified by setting KRB5_TRACE, wine-11.17-krb5.log) After entering credentials and pressing login button the program recieves SIGSEGV at __wine_unix_call_dispatcher (gdb.txt). ChatGPT suggested to try initializing the Kerberos unixlib in kerberos_SpInstanceInit in dlls/kerberos/krb5_ap.c with following change: ``` static NTSTATUS NTAPI kerberos_SpInstanceInit(ULONG version, SECPKG_DLL_FUNCTIONS *dll_function_table, void **user_functions) { NTSTATUS status; TRACE("%#lx, %p, %p\n", version, dll_function_table, user_functions); TRACE("before unix init: __wine_unixlib_handle=%p\n", __wine_unixlib_handle); if (!__wine_unixlib_handle) { status = __wine_init_unix_call(); TRACE("__wine_init_unix_call returned %#lx, handle=%p\n", status, __wine_unixlib_handle); if (status) return status; status = KRB5_CALL(process_attach, NULL); TRACE("process_attach returned %#lx\n", status); if (status) return status; } return STATUS_SUCCESS; } ``` After compiling wine with this change I can confirm that I am able to log in but I am not sure this is correct way to fix this. -- 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 46568] New: 64-bit msxml6.dll from Microsoft Core XML Services 6.0 redist package fails to load (Wine doesn't respect 44-bit user-mode VA limitation from Windows < 8.1)
by wine-bugs＠winehq.org Oct. 16, 2026

Oct. 16, 2026

https://bugs.winehq.org/show_bug.cgi?id=46568 Bug ID: 46568 Summary: 64-bit msxml6.dll from Microsoft Core XML Services 6.0 redist package fails to load (Wine doesn't respect 44-bit user-mode VA limitation from Windows < 8.1) Product: Wine Version: 4.0 Hardware: x86-64 URL: https://download.microsoft.com/download/2/e/0/2e01308a -e17f-4bf9-bf48-161356cf9c81/msxml6_x64.msi OS: Linux Status: NEW Keywords: download, win64 Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)winehq.org Reporter: focht(a)gmx.net Distribution: --- Hello folks, reported by Louis in https://bugs.winehq.org/show_bug.cgi?id=46107#c2 --- quote --- I tried winetricks msxml3 and msxml6, but somehow it didn`t work out in 64-bit wineprefix; i get errors that msxml is not registered etc, Does anyone know a workaround to use native msxml on 64-bit prefix? --- quote --- Relevant part of trace log: --- snip --- $ pwd /home/focht/.wine/drive_c/Program Files/Altium/AD18 $ WINEDEBUG=+seh,+relay,+loaddll,+virtual wine64 ./X2.EXE >>log.txt 2>&1 ... 002a:Call KERNEL32.LoadLibraryExW(0053f2b0 L"C:\\windows\\system32\\msxml6.dll",00000000,00000008) ret=7fbe435d7558 ... 002a:trace:loaddll:load_native_dll Loaded L"C:\\windows\\system32\\msxml6.dll" at 0x7ff79e00000: native 002a:Call PE DLL (proc=0x7ff79e0101c,module=0x7ff79e00000 L"msxml6.dll",reason=PROCESS_ATTACH,res=(nil)) ... 002a:Call KERNEL32.HeapCreate(00000001,00000000,00000000) ret=7ff79e18411 002a:trace:virtual:NtAllocateVirtualMemory 0xffffffffffffffff (nil) 00110000 2000 00000004 002a:trace:virtual:map_view got mem with anon mmap 0x7fbe39819000-0x7fbe39929000 002a:trace:virtual:VIRTUAL_DumpView View: 0x7fbe39820000 - 0x7fbe3992ffff (valloc) 002a:trace:virtual:VIRTUAL_DumpView 0x7fbe39820000 - 0x7fbe3992ffff --rw- 002a:trace:virtual:NtAllocateVirtualMemory 0xffffffffffffffff 0x7fbe39820000 00010000 1000 00000004 002a:trace:virtual:mprotect_exec forcing exec permission on 0x7fbe39820000-0x7fbe3982ffff 002a:trace:virtual:VIRTUAL_DumpView View: 0x7fbe39820000 - 0x7fbe3992ffff (valloc) 002a:trace:virtual:VIRTUAL_DumpView 0x7fbe39820000 - 0x7fbe3982ffff c-rw- 002a:trace:virtual:VIRTUAL_DumpView 0x7fbe39830000 - 0x7fbe3992ffff --rw- 002a:Ret KERNEL32.HeapCreate() retval=7fbe39820000 ret=7ff79e18411 ... 002a:Call ntdll.RtlAllocateHeap(7fbe39820000,00000000,00000060) ret=7ff79e03c10 002a:Ret ntdll.RtlAllocateHeap() retval=7fbe39822730 ret=7ff79e03c10 002a:Call msvcrt.memset(7fbe39822740,00000000,00000042) ret=7ff79e03a5a 002a:Ret msvcrt.memset() retval=7fbe39822740 ret=7ff79e03a5a 002a:trace:seh:NtRaiseException code=c0000005 flags=0 addr=0x7ff79e03efe ip=7ff79e03efe tid=002a 002a:trace:seh:NtRaiseException info[0]=0000000000000000 002a:trace:seh:NtRaiseException info[1]=ffffffffffffffff 002a:trace:seh:NtRaiseException rax=000000000011b2d0 rbx=6c61567274736270 rcx=0000000000000008 rdx=0000000000000000 002a:trace:seh:NtRaiseException rsi=0000000000007fbe rdi=0000000000000730 rbp=00000ff7c73044e8 rsp=000000000053ea70 002a:trace:seh:NtRaiseException r8=00007fbe39822740 r9=0000000000000000 r10=0000000000000000 r11=0000000000000000 002a:trace:seh:NtRaiseException r12=00007fbe39822740 r13=000007ff79f8dc80 r14=00007fbe436c6160 r15=000000000053f708 ... 002a:exception c0000005 in PE entry point (proc=0x7ff79e0101c,module=0x7ff79e00000,reason=PROCESS_ATTACH,res=(nil)) 002a:Ret PE DLL (proc=0x7ff79e0101c,module=0x7ff79e00000 L"msxml6.dll",reason=PROCESS_ATTACH,res=(nil)) retval=0 002a:Call PE DLL (proc=0x7ff79e0101c,module=0x7ff79e00000 L"msxml6.dll",reason=PROCESS_DETACH,res=(nil)) 002a:Ret PE DLL (proc=0x7ff79e0101c,module=0x7ff79e00000 L"msxml6.dll",reason=PROCESS_DETACH,res=(nil)) retval=1 002a:trace:loaddll:free_modref Unloaded module L"C:\\windows\\system32\\msxml6.dll" : native 002a:Ret KERNEL32.LoadLibraryExW() retval=00000000 ret=7fbe435d7558 002a:err:ole:COMPOBJ_DllList_Add couldn't load in-process dll L"C:\\windows\\system32\\msxml6.dll" --- snip --- It seems that certain older 64-bit components such as Microsoft XML libs make assumptions about the 64-bit user-mode virtual address space layout. This is different from the usual broken apps a la "I failed at porting my 32-bit app to 64-bit" (pointer truncation). In this case, pointers from certain allocations are broken into multiple parts and used as indices into multi-level lookup tables. Pitfall: there is a 44-bit user-mode VA limitation (8TB) for 64-bit Windows which was lifted starting with Windows 8.1+. Wine doesn't respect the 44-bit pre-Windows 8.1 virtual address space limits, allowing process heaps to be placed in 0000'7Fxx'0000'0000 range (128 TB) which causes out-of-bounds access to lookup tables when indices overflow (derived from pointer bits). The exception occurs in entry point, causing 'msxml6.dll' to be unloaded. One workaround is to move Wine's top-down allocations/heaps into 8 TB VA range (Wine preloader) and impose same user-mode address space bits limits as with all 64-bit Windows versions < 8.1 to stay "compatible". I've tested it and it works for native here. Not sure if it's worth to change though. I don't know if a separate 64-bit MSXML6 re-distributable package exists that has been fixed wrt Windows 8.1+ address space limits. MSXML6 is part of Windows OS for newer versions and automatically kept up-to-date. $ sha1sum msxml6_x64.msi 1eb84eeae7729ea5db7fe79779f4e216114261ba msxml6_x64.msi $ du -sh msxml6_x64.msi 2.6M msxml6_x64.msi $ wine --version wine-4.0-276-g84459ba94b 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.

3 19

[Bug 60484] New: wine 11.19 dnsapi parsing a large /etc/hosts stalls fresh prefix initialization
by WineHQ Bugzilla Oct. 16, 2026

Oct. 16, 2026

http://bugs.winehq.org/show_bug.cgi?id=60484 Bug ID: 60484 Summary: wine 11.19 dnsapi parsing a large /etc/hosts stalls fresh prefix initialization Product: Wine Version: 11.19 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: dnsapi Assignee: wine-bugs(a)list.winehq.org Reporter: xash(a)riseup.net Target Milestone: --- Distribution: --- Created attachment 82331 --> http://bugs.winehq.org/attachment.cgi?id=82331 bash script to repro the issue Steps to reproduce: 1. Run the attached repro-wine-hosts.sh script. It generates two synthetic hosts files, one with two lines and one with 434,612 lines, then starts wineboot -i with a fresh prefix for each. bubblewrap bind-mounts each file as /etc/hosts only for Wine. 2. Compare the two prefixes and the script output after the 30-second timeout. Actual results on my machine: - Both wineboot commands hit the 30-second timeout (exit 124). - With the two-line hosts file, the prefix reaches a 2,226,829-byte system.reg and has a .update-timestamp file before the timeout. - With the 434,612-line hosts file (13,038,334 bytes), the prefix only reaches a 1,212-byte system.reg and has no .update-timestamp file before the timeout. - A separate WINEDEBUG=trace+dnsapi capture using my real 434,612-line hosts file shows wineboot calling DnsQuery_UTF8 for the local computer name, followed by thousands of get_next_host_entry "parsing line" messages. The 20-second capture timed out while those messages were still being emitted. Expected result: The size of /etc/hosts should not prevent a fresh Wine prefix from initializing. The application executable is not needed to reproduce this. Workaround: Starting Wine with a minimal /etc/hosts bind-mounted via bubblewrap lets the prefix initialize. My real hosts file is 12,476,010 bytes and has 434,612 lines. Related source: The 11.19 dnsapi implementation parses /etc/hosts during DNS queries: https://github.com/wine-mirror/wine/blob/wine-11.19/dlls/dnsapi/query.c The raw WINEDEBUG log contains the contents of my actual /etc/hosts and was not attached. Output of the script: ``` wine-11.19 (Staging) Linux 7.2.9-arch1-1 2 34 /tmp/wine-hosts-repro.bikl8L/hosts-small 434612 13038334 /tmp/wine-hosts-repro.bikl8L/hosts-large 434614 13038368 total small: wineboot exit=124 elapsed=30s large: wineboot exit=124 elapsed=30s ``` -- 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 60466] New: Battlefield 1942 cannot copy secdrv.sys into c:\windows\syswow64\drivers because directory does not exist.
by WineHQ Bugzilla Oct. 16, 2026

Oct. 16, 2026

http://bugs.winehq.org/show_bug.cgi?id=60466 Bug ID: 60466 Summary: Battlefield 1942 cannot copy secdrv.sys into c:\windows\syswow64\drivers because directory does not exist. Product: Wine Version: 11.19 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: bernhardu(a)mailbox.org Target Milestone: --- Distribution: --- Inspired by bug 60439 but lacking those install disks, I tried to check if Battlefield 1942 would work and found it fails in a new regular wineprefix. I noticed, inside my 64-bit prefix, the first start of bf1942.exe installs the secdrv.sys service inside HKLM\System\CurrentControlSet\Services\SecDrv, but fails to copy the file into the syswow64\drivers directory. A WINEDEBUG +file shows a: 0134:warn:file:copy_file Unable to open dest L"C:\\windows\\system32\\drivers\\\\SECDRV.SYS" The last version that created the syswow64\drivers was wine-6.4, wine-6.5 started to omit 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 4

[Bug 60410] New: MusicBee: System.OutOfMemoryException when trying to load MusicBee on WINE 11.16, 11.17 in WoW64 mode
by WineHQ Bugzilla Oct. 16, 2026

Oct. 16, 2026

http://bugs.winehq.org/show_bug.cgi?id=60410 Bug ID: 60410 Summary: MusicBee: System.OutOfMemoryException when trying to load MusicBee on WINE 11.16, 11.17 in WoW64 mode Product: Wine Version: 11.17 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: critical Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: bugzilla(a)flaky.blue Target Milestone: --- Distribution: --- Reporting on behalf of users of mb_MPRISBee. Reporting for WINE as a whole rather than just staging, as staging is only used for the plugin and I don't think staging patches affect this. This happens without the plugin installed too, according to their reports. On WINE versions 11.16 and 11.17, MusicBee will refuse to load, spawning a .NET OutOfMemoryException. The user who reported it to the plugin maintainer showed their system monitor not showing they are actually out of memory. The plugin maintainer tested with 11.16 and 11.17 (and I will test 11.18 in a virtual machine later) One user claims that commits a436d114..548a639e broke .NET's memory checks when running in WoW64 mode, and that using legacy 32-bit mode fixes this. Since some distros are packaging WINE without 32-bit support (such as Arch, where WINE with 32-bit capabilities has been relegated to the AUR) and this is a bug that breaks the ability to load MusicBee I bumped it to critical. Relevant issue: https://github.com/UrbanCMC/mb_MPRISBee/issues/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 5

[Bug 58418] New: InternetQueryOptionW(proxy_username) crashes with NULL buffer but valid size pointer.
by WineHQ Bugzilla Oct. 16, 2026

Oct. 16, 2026

http://bugs.winehq.org/show_bug.cgi?id=58418 Bug ID: 58418 Summary: InternetQueryOptionW(proxy_username) crashes with NULL buffer but valid size pointer. Product: Wine Version: 10.0 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: wininet Assignee: wine-bugs(a)winehq.org Reporter: bernhardu(a)mailbox.org Distribution: --- InternetQueryOptionW(INTERNET_OPTION_PROXY_USERNAME) crashes with NULL buffer but valid size pointer. Is reproducible with latest git. >From the forum: https://forum.winehq.org/viewtopic.php?t=41123 md5sum: 48d300a85a00a948f5833bdf266226b3 KubiosHRVScientific_4.2.0_setup.exe -- 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 60405] New: ssbs-probe (2026-09-29 source snapshot, ARM64): SSBS cleared after RtlRestoreContext
by WineHQ Bugzilla Oct. 16, 2026

Oct. 16, 2026

http://bugs.winehq.org/show_bug.cgi?id=60405 Bug ID: 60405 Summary: ssbs-probe (2026-09-29 source snapshot, ARM64): SSBS cleared after RtlRestoreContext Product: Wine Version: 11.18 Hardware: arm OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)list.winehq.org Reporter: thomasabbott916(a)hotmail.com Target Milestone: --- Distribution: --- Created attachment 82206 --> http://bugs.winehq.org/attachment.cgi?id=82206 All the evidence logs Summary: ssbs-probe (2026-09-29 source snapshot, ARM64): SSBS cleared after RtlRestoreContext Product: Wine Component: ntdll Version: 11.18 (exact development commit below) Severity: Normal Comments: The attached ssbs-probe.c (September 29, 2026 source snapshot; SHA256 8490049b715e78716f31367343e0cea2c4c391c25dfcf9ab3ad65187b7e7276c) is a native Windows ARM64 console reproducer. It sets PSTATE.SSBS to 1, calls RtlCaptureContext followed by RtlRestoreContext, and observes SSBS=0 afterward. The zero-state control remains zero. This reproduces with unmodified upstream development Wine in a fresh default prefix, without Proton, FEX, DXVK, Windows DLLs, or DLL overrides. Environment: - Wine reports wine-11.18, built from official WineHQ git commit 6880117619afdf62b4ccc40a8c6268c86613131f. This was the repository HEAD at both checkout and final verification on September 29, 2026. - Build: ../wine/configure --disable-tests; make -j8. No source patches; clean git diff. The option skips building Wine's own test suite, not runtime functionality. - CPU/device: Qualcomm Oryon, AYN Odin 3, aarch64; SSBS and DIT instructions are exposed by Linux. - OS: Fedora 44 userspace in a rootless Podman container on Armada 20260927.42a9d14, Linux 7.2.6. The container executes directly on the ARM64 hardware; Wine was launched directly from its build tree. - GCC 16.2.1, Clang 22.1.8, glibc 2.43. Xvfb supplied the display during prefix initialization. Reproduction: 1. On an ARM64 system exposing SSBS read/write instructions, compile attached ssbs-probe.c using LLVM-MinGW: aarch64-w64-mingw32-clang -march=armv8.5-a -O0 ssbs-probe.c -o ssbs-probe.exe 2. Launch it with native ARM64 Wine in a new prefix, leaving DLL overrides and Wine configuration at their defaults. Exact build-tree invocation and environment are attached. 3. Compare the printed before/after SSBS values for requested=1 and requested=0. The raw register value 4096 means SSBS=1; zero means SSBS=0. Actual: requesting 1 produces before=4096 and after=0. Requesting 0 produces before=0 and after=0. Both first-run and repeat invocations exit successfully and reproduce the same result. Expected/proposed behavior: restoring Windows CPU context should not unintentionally discard the host thread's speculative-store-bypass state when the supplied context only contains arithmetic flags. A native Linux control on the same hardware preserves both SSBS values across ordinary signal delivery/return. I do not have native Windows ARM64 hardware, so I have NOT verified Windows behavior or which non-NZCV Cpsr bits Windows permits applications to change; please confirm the intended compatibility semantics. Analysis: In dlls/ntdll/unix/signal_arm64.c, restore_context assigns context->Cpsr to the whole signal-frame PSTATE, and usr2_handler does the same with frame->cpsr. RtlCaptureContext and the syscall dispatcher can supply NZCV without SSBS. Earlier observation of the Proton-shipped handler directly recorded PSTATE changing from 0x60001000 to 0x60000000. The upstream reproduction above does not use that observer or any modified binary. The attachment includes an extended suspend/GetThreadContext/SetThreadContext/resume diagnostic. Supplying the opposite SSBS bit in Cpsr changes the worker's SSBS in either direction. This demonstrates the second write path; it is not presented as proof of the native Windows filtering contract. Attachments: One archive contains both small source reproducers, native Linux control, complete first-run and repeat terminal output, exact build/environment information, source/binary checksums, duplicate-search notes, and a narrowly scoped SSBS-only candidate patch. The candidate was previously validated as equivalent binary edits in Proton Wine; it has NOT been source-built/tested against this upstream build and is offered for review only. It passes git apply --check against the tested source. It preserves incoming SSBS=0 as well as 1 and does not force speculation on. Searches: Bugzilla ALL SSBS and ALL "RtlRestoreContext" ARM64 returned no matches. Known Issues and FF13's AppDB linked bug list were also checked. Details and links are attached. Limitations: native Windows ARM64 comparison, other CPUs, and macOS are untested. Fresh-prefix logs retain all initialization diagnostics, including Mono helper-architecture, Xvfb/DRI3 and container Bluetooth messages. Repeat runs reproduce the state loss after initialization without the Mono helper messages. The probes are native console programs and do not use .NET, graphics acceleration or Bluetooth. -- 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