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

[Bug 59677] New: Wine crashes when using zink with Vampire: The Masquerade — Redemption
by WineHQ Bugzilla May 23, 2026

May 23, 2026

http://bugs.winehq.org/show_bug.cgi?id=59677 Bug ID: 59677 Summary: Wine crashes when using zink with Vampire: The Masquerade — Redemption Product: Wine Version: 11.7 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: shtetldik(a)gmail.com Distribution: --- It used to work before, but I noticed that now when running Vampire: The Masquerade — Redemption (which is a DX7 game) using zink, it crashes. It does work when using a regular OpenGL driver (radeonsi in my case). It crashes both with Mesa git and Mesa 26.0.4 zink. I was testing it using MESA_LOADER_DRIVER_OVERRIDE='zink' Nothing really stands out in the wine log. Let me know if I should attach it with some specific debug channels. OS: Debian testing GPU: Radeon RX 7900 XTX (crashes with zink→radv, works with radeonsi). -- 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 59212] New: Firefox : msi 64 bit archive doesn't install
by WineHQ Bugzilla May 23, 2026

May 23, 2026

http://bugs.winehq.org/show_bug.cgi?id=59212 Bug ID: 59212 Summary: Firefox : msi 64 bit archive doesn't install Product: Wine Version: 11.0-rc4 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: blocker Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: jerome.bouat(a)laposte.net Distribution: --- Created attachment 80105 --> http://bugs.winehq.org/attachment.cgi?id=80105 configure log ~$ ./tmp/wine/bin/msiexec /i Firefox\ Setup\ 146.0.1.msi 0124:fixme:file:NtLockFile I/O completion on lock not implemented yet 0124:fixme:ntdll:NtQuerySystemInformation info_class SYSTEM_PERFORMANCE_INFORMATION ~$ -- 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 40039] New: Dictation Pro 1.01 access to temp directory denied
by wine-bugs＠winehq.org May 23, 2026

May 23, 2026

https://bugs.winehq.org/show_bug.cgi?id=40039 Bug ID: 40039 Summary: Dictation Pro 1.01 access to temp directory denied Product: Wine Version: 1.9.1 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: lukasz.wojnilowicz(a)gmail.com Distribution: --- Created attachment 53491 --> https://bugs.winehq.org/attachment.cgi?id=53491 Access denied Steps to reproduce: 1) remove ~/.wine 2) sh winetricks dotnet40 3) wine Dictation Pro.exe Behaviour: Access to temp directory denied (see attachment) Expected behaviour: Acces to temp directory shouldn't be denied -- 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 33450] New: .NET 3.5 Framework installation fails (.NET WorkFlow Service Registration Tool "WFServicesReg.exe" crash)
by wine-bugs＠winehq.org May 23, 2026

May 23, 2026

http://bugs.winehq.org/show_bug.cgi?id=33450 Bug #: 33450 Summary: .NET 3.5 Framework installation fails (.NET WorkFlow Service Registration Tool "WFServicesReg.exe" crash) Product: Wine Version: 1.5.28 Platform: x86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: msxml3 AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Classification: Unclassified Hello folks, while investigating some .NET related bugs I found .NET Framework 3.5 doesn't install anymore with current winetricks. There is now a crash in .NET WorkFlow Service Registration Tool (WFServicesReg.exe) which leads to main installer getting stuck. Looks like a Wine msxml regression or new bug. Can be reproduced after first failed install by running the tool manually. Prerequisite: clean WINEPREFIX + 'winetricks -q dotnet35' Console output: --- snip --- $ wine C:\\windows\\Microsoft.NET\\Framework\\v3.5\\WFServicesReg.exe /c /v /m /i fixme:heap:HeapSetInformation (nil) 1 (nil) 0 DDSet_Entry: WFServicesReg.exe DDSet_Status: CFxInstaller::CopyConfigFilesToTemp is64bit=0 DDSet_Status: CFileHelper::CopyConfigFilesToTempLocation DDSet_Status: CFxInstaller::SetupComponents isInstall=1 DDSet_Status: CFxInstaller::SetupComponents Calling SetupExtensions. isInstall=1 DDSet_Status: CFxInstaller::SetupExtensions isInstall=1 is64Bit=0 DDSet_Status: CConfigEntry::Initialize szConfigPath=C:\users\focht\Temp\WSF8f8c.tmp DDSet_Status: CConfigEntry::RefreshConfigFile DDSet_Status: CExtensionElement::SetData szName=persistenceProvider szType=System.ServiceModel.Configuration.PersistenceProviderElement, System.WorkflowServices, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35 szXPath=system.serviceModel/extensions/behaviorExtensions/add DDSet_Status: CFxInstaller::SetupExtensions Adding System.ServiceModel.Configuration.PersistenceProviderElement, System.WorkflowServices, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35. DDSet_Status: CExtensionElement::AddToConfigFile _xPath=system.serviceModel/extensions/behaviorExtensions/add DDSet_Status: CConfigEntry::IsPresent szPath=system.serviceModel/extensions/behaviorExtensions/add[@name='persistenceProvider' and @type='System.ServiceModel.Configuration.PersistenceProviderElement, System.WorkflowServices, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'] DDSet_Status: CConfigEntry::IsPresent szPath=system.serviceModel/extensions/behaviorExtensions/add[@name='persistenceProvider'] DDSet_Status: CConfigEntry::CreateElementInConfigFile szPath=system.serviceModel/extensions/behaviorExtensions/add insertBefore=0 DDSet_Status: CConfigEntry::AppendTextNode DDSet_Status: CConfigEntry::AppendTextNode DDSet_Status: CConfigEntry::AppendTextNode DDSet_Status: CConfigEntry::AppendTextNode DDSet_Status: CConfigEntry::AppendTextNode DDSet_Status: CConfigEntry::AppendTextNode DDSet_Status: CConfigEntry::AppendTextNode wine: Unhandled page fault on read access to 0x00000007 at address 0xf74cc19d (thread 0009), starting debugger... --- snip --- Running it with winedbg: --- snip --- Unhandled exception: page fault on read access to 0x00000007 in 32-bit code (0xf744619d). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:f744619d ESP:0033f970 EBP:0000003c EFLAGS:00010286( R- -- I S - -P- ) EAX:00000006 EBX:f7578ff4 ECX:f75793f8 EDX:ffffffff ESI:f75793e0 EDI:f75793e0 Stack dump: 0x0033f970: 7e879d70 7bcc89d0 0033f998 0033f9a0 0x0033f980: 7bcc89d0 0033fa20 0033fa08 7bc4b26c 0x0033f990: 7bcc89d0 7bcc89d0 0033fa08 7bc4b26c 0x0033f9a0: 00110060 00000001 00000017 ffffffff 0x0033f9b0: 00000006 00000040 00330000 7de87a8a 0x0033f9c0: 00110014 0000003c 0033fa48 7b850bb3 000c: sel=0067 base=00000000 limit=00000000 32-bit r-x Backtrace: =>0 0xf744619d _int_malloc+0x6d() in libc.so.6 (0x0000003c) 1 0xf7448e75 __libc_malloc+0x64() in libc.so.6 (0x0000003c) 2 0x7dd22462 xmlNewText+0x31() in libxml2.so.2 (0x00000000) 3 0x7dd22850 xmlNewDocText+0xf() in libxml2.so.2 (0x0033fb58) 4 0x7de82243 domdoc_createNode+0x3da(iface=0x12b6d4, Type={n1={n2={vt=0x10, wReserved1=0, wReserved2=0x1a78, wReserved3=0x102, n3={cVal=3, uiVal=0xe03, ulVal=0x1020e03, intVal=0x1020e03, uintVal=0x1020e03, bVal=3, iVal=0xe03, lVal=0x1020e03, fltVal=0.000000, dblVal=0.000000, boolVal=0xe03, scode=0x1020e03, date=0.000000, bstrVal="...", pulVal=0x1020e03, pintVal=0x1020e03, puintVal=0x1020e03, pbVal="...", piVal=0x1020e03, plVal=0x1020e03, pfltVal=0x1020e03, pdblVal=0x1020e03, pboolVal=0x1020e03, pscode=0x1020e03, pdate=0x1020e03, pbstrVal=0x1020e03, pvarVal=0x1020e03, byref=0x1020e03, pcyVal=0x1020e03, pdecVal=0x1020e03, ppunkVal=0x1020e03, ppdispVal=0x1020e03, pparray=0x1020e03, pllVal=0x1020e03, pullVal=0x1020e03, brecVal={pvRecord=0x1020e03, pRecInfo=0x1021a78}}}, decVal={wReserved=0x10, u={={scale=0, sign=0}, signscale=0}, Hi32=0x1021a78, u1={={Lo32=0x1020e03, Mid32=0x1021a78}, Lo64=0x1021a7801020e03}}}}, name=0x0(nil), namespaceURI=0x0(nil), node=0x33fba8) [/home/focht/projects/wine/wine-git/dlls/msxml3/domdoc.c:1969] in msxml3 (0x0033fb58) 5 0x7de811fe domdoc_createTextNode+0x12d(iface=<couldn't compute location>, data=<couldn't compute location>, text=<couldn't compute location>) [/home/focht/projects/wine/wine-build32/dlls/msxml3/../../include/msxml6.h:5222] in msxml3 (0x0033fbf8) 6 0x01013735 in wfservicesreg (+0x13734) (0x0033fc38) ... --- snip --- Can be worked around with 'winetricks msxml3'. $ wine --version wine-1.5.28-200-gf3b0a9f 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 26

[Bug 53847] New: NfRemote: mouse input ignored
by WineHQ Bugzilla May 23, 2026

May 23, 2026

https://bugs.winehq.org/show_bug.cgi?id=53847 Bug ID: 53847 Summary: NfRemote: mouse input ignored Product: Wine Version: 7.0 Hardware: x86-64 OS: Mac OS X Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: thelen(a)radiomankato.com https://www.telosalliance.com/uploads/Omnia%20Products/Software/NfRemote.exe Say hello to nfremote. It's a little piece of software used to administer a particular manufacturer's equipment, commonly used at radio and TV stations. I can confirm it has, and does, work fine under Wine 2.21 - just tested today on a MacBookPro8,1 running the official binaries (https://dl.winehq.org/wine-builds/macosx/pool/winehq-staging-2.21.pkg) under OS 10.13.6. Meanwhile, I have a new Mac (MacBookPro16,2 - Intel-based), on which I’ve deployed Wine 7.0 via homebrew under OS 12.6.1. There I can start nfremote just fine... but it ignores my mouse input. If I were to start it with the command-line argument "run", it presents me with a window where both keyboard and mouse input are accepted; there I can type in the text fields, so I know it's responsive. But when I hover the cursor over buttons, they do not 'light up’ to indicate such. And when I click, nothing happens. Even in years past, I found that newer versions of Wine exhibited the issue I describe below, so I simply never updated beyond 2.21. Wonder if this might be a long-undiscovered regression of some sort? -- 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 11

[Bug 59758] New: Wiki: Use of extended regular expressions with grep in the "Debug Channels" page, without the E flag
by WineHQ Bugzilla May 23, 2026

May 23, 2026

http://bugs.winehq.org/show_bug.cgi?id=59758 Bug ID: 59758 Summary: Wiki: Use of extended regular expressions with grep in the "Debug Channels" page, without the E flag Product: WineHQ.org Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: trivial Priority: P2 Component: www-unknown Assignee: wine-bugs(a)list.winehq.org Reporter: barathrk11(a)gmail.com Distribution: --- In the page https://gitlab.winehq.org/wine/wine/-/wikis/Debug-Channels, the following line: $ grep -r --include='*.c' --include='*.h' 'WINE_(DEFAULT|DECLARE)_DEBUG_CHANNEL' dlls/ programs/ only seems to work when the -E flag is specified(grep -rE). The -E flag is specified in the example immediately after this one, however: for modname in $(find dlls/ programs/ -mindepth 1 -type d | sort); do echo $(grep -rE --include='*.[ch]' '^WINE_(DEFAULT|DECLARE)_DEBUG_CHANNEL' $modname \ | awk -F "[()]" '{print $2}' | sort | uniq) \ | awk -v modname=$modname '{if (NF>0) printf("%-*s%s\n", 26, modname": ", $0)}'; done -- 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 59759] New: Crash using bottles 63.2
by WineHQ Bugzilla May 23, 2026

May 23, 2026

http://bugs.winehq.org/show_bug.cgi?id=59759 Bug ID: 59759 Summary: Crash using bottles 63.2 Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: abcd0000(a)poczta.onet.pl Distribution: --- Created attachment 80957 --> http://bugs.winehq.org/attachment.cgi?id=80957 callstack rom debugger Crash happens on both fedora (latest) and ubuntu (24.04.4), when I run fusion 360 ti runs AdskIdentityManager and this application crash. -- 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 52330] New: iZotope software authorization process fails
by WineHQ Bugzilla May 23, 2026

May 23, 2026

https://bugs.winehq.org/show_bug.cgi?id=52330 Bug ID: 52330 Summary: iZotope software authorization process fails Product: Wine-staging Version: 7.0-rc4 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: christian.frech(a)protonmail.com CC: leslie_alistair(a)hotmail.com, z.figura12(a)gmail.com Distribution: --- Created attachment 71492 --> https://bugs.winehq.org/attachment.cgi?id=71492 journalctl log during authorization process Authorizing iZotope software will result in an error. According to the iZotope Support, the attempt is visible, but the local application did not recognize that. Also see attachment. -- 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 22

[Bug 59765] New: wineserver: performance regression in newer Wine versions (apparently related to Winsock/socket polling)
by WineHQ Bugzilla May 23, 2026

May 23, 2026

http://bugs.winehq.org/show_bug.cgi?id=59765 Bug ID: 59765 Summary: wineserver: performance regression in newer Wine versions (apparently related to Winsock/socket polling) Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: wineserver Assignee: wine-bugs(a)list.winehq.org Reporter: csoresz2(a)gmail.com Distribution: --- Created attachment 80967 --> http://bugs.winehq.org/attachment.cgi?id=80967 CPU usage on various Ubuntu versions Hello Wine developers, I would like to report what looks like a significant wineserver performance regression in newer Wine versions, apparently related to Winsock/socket polling. We run a Windows application stack under Wine on Linux. The architecture is roughly: - one main Windows service process running under Wine - many child worker processes launched by that service - each worker process receives RTSP video streams from IP cameras - the RTSP implementation uses live555 internally - the streams mostly use RTSP/RTP over TCP - a typical system runs around 50-60 worker processes under the same Wine prefix The same workload behaves very differently on two otherwise similar machines: Old system: Ubuntu 20.x + Wine 5.x New system: Ubuntu 26.x + Wine 11.8 On the old system, wineserver uses about 25% of one CPU core and the application runs well. On the new system, wineserver frequently reaches 100% of one CPU core and becomes a bottleneck. Basically anything above Ubuntu 20.x and Wine 5.x is using more CPU. Tested on roughly 50 Linux servers with exactly the same Windows application. See the attachment. Wine versions tested: - wine-5.0 (Ubuntu 5.0-3ubuntu1) - wine-9.0 (Ubuntu 9.0~repack-4build3) - wine-9.15 - wine-10.12 - wine-10.16 - wine-10.19 - wine-11.0 - wine-11.8 Ubuntu versions tested: - 20.04 - 22.04 - 24.04 - 25.10 - 26.04 Let's stick to the original lineup: Ubuntu 20.x + Wine 5.x VS Ubuntu 26.x + Wine 11.8 I collected strace -c data from the wineserver process on both systems under comparable load. On the newer Wine/Linux system, the wineserver syscall profile looks approximately like this: ioctl ~280,000 calls read ~250,000 calls write ~132,000 calls epoll_ctl ~142,000 calls getsockopt ~52,000 calls poll ~50,000 calls On the older Wine/Linux system, the same workload looks very different: write ~443,000 calls read ~462,000 calls epoll_wait ~18,000 calls epoll_ctl ~209 calls poll ~95 calls getsockopt ~6 calls The most striking difference is epoll_ctl: roughly 142,000 calls on the new system versus only about 200 on the old system. ioctl, getsockopt, and poll are also much higher on the newer Wine/Linux system. I also installed debug symbols and profiled wineserver with perf. The hot path on the new system is mostly: main_loop_epoll fd_poll_event thread_poll_event read_request call_req_handler req_ioctl poll_socket sock_poll_event sock_reselect sock_get_poll_events There is also time under: req_select select_on end_wait object_sync_satisfied async_satisfied async_set_result async_reselect sock_reselect_async sock_reselect sock_get_poll_events I also traced epoll_ctl calls. Almost all of them are EPOLL_CTL_MOD, not ADD/DEL: EPOLL_CTL_ADD 2 EPOLL_CTL_DEL 2 EPOLL_CTL_MOD 11625 The event masks are constantly being toggled, mostly between no events and readable/priority events: events=0 5842 events=EPOLLIN|EPOLLPRI 3711 events=EPOLLIN 1961 events=EPOLLOUT 100 events=EPOLLPRI 9 events=EPOLLPRI|EPOLLOUT 2 The affected file descriptors are mostly TCP sockets, including RTSP camera connections such as: TCP:[local_ip:port->camera_ip:554] This strongly suggests that the newer Wine version is doing much more wineserver-side socket re-selection / epoll event mask modification for the same Winsock workload. The application uses live555, so the socket behavior is probably based on normal Winsock select() / ioctlsocket() / recv() style logic. I tried several application-side experiments, including increasing the live555 select() timeout and changing scheduler behavior, but these did not produce a useful improvement. This makes me suspect the regression may be in the Wine socket / wineserver handling path rather than in the application logic itself. The main symptom is that the newer Wine version appears to generate a very large amount of: req_ioctl -> poll_socket -> sock_reselect -> sock_get_poll_events -> epoll_ctl(EPOLL_CTL_MOD) activity for many concurrent TCP RTSP streams, while Wine 5 on the older system does not. Could this be a known change or regression in wineserver socket polling, async socket handling, or Winsock select() / ioctlsocket() emulation between Wine 5 and newer Wine versions? If there is anything we can provide to help investigate this, please let us know. Thank you for your work on Wine. 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 9

[Bug 45461] New: OnScreenKeyboard Portable: App displays splash screen but does not start
by wine-bugs＠winehq.org May 23, 2026

May 23, 2026

https://bugs.winehq.org/show_bug.cgi?id=45461 Bug ID: 45461 Summary: OnScreenKeyboard Portable: App displays splash screen but does not start Product: Wine Version: 3.12 Hardware: x86-64 URL: https://portableapps.com/apps/accessibility/on-screen_ keyboard_portable OS: Mac OS X Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: tobbi.bugs(a)googlemail.com Created attachment 61801 --> https://bugs.winehq.org/attachment.cgi?id=61801 log After installing (extracting) OnScreenKeyboard Portable and tryin to run it, it does show the splash screen but does not start the actual program. $ openssl sha256 On-ScreenKeyboardPortable_2.0.paf.exe SHA256(On-ScreenKeyboardPortable_2.0.paf.exe)= 12c4943e1d7a65a12f7c58ac5aac3430b98c5158f18a94c51c26036770af19df -- 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 5