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

[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 56034] New: Borland Turbo CPP 4.5 installer hangs after opening INSTALL.TXT
by WineHQ Bugzilla May 23, 2026

May 23, 2026

https://bugs.winehq.org/show_bug.cgi?id=56034 Bug ID: 56034 Summary: Borland Turbo CPP 4.5 installer hangs after opening INSTALL.TXT Product: Wine Version: 9.0-rc2 Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: alexhenrie24(a)gmail.com Distribution: --- Created attachment 75680 --> https://bugs.winehq.org/attachment.cgi?id=75680 Patch that fixes the first hang Note that the installer is INSTALL.EXE, not SETUP.EXE. If you click Continue, the installer opens INSTALL.TXT in Notepad. When you close Notepad, the installer should continue, but instead it hangs. If you click Skip, the installer works but hangs after installation. The attached patch fixes the problem, mostly. For some reason you have to click the background after closing Notepad, and the installer still hangs at the end. I don't know how close the patch is to a correct solution. $ sha256sum 'Borland Turbo CPP 4.5 for Windows.7z' 8a6f5797f0af880728421426beacf5e5760701e424d89e14cd714a13e625f2ff -- 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 53355] New: Missing functions SystemTimeToTzSpecificLocalTimeEx and TzSpecificLocalTimeToSystemTimeEx
by WineHQ Bugzilla May 23, 2026

May 23, 2026

https://bugs.winehq.org/show_bug.cgi?id=53355 Bug ID: 53355 Summary: Missing functions SystemTimeToTzSpecificLocalTimeEx and TzSpecificLocalTimeToSystemTimeEx Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: kernel32 Assignee: wine-bugs(a)winehq.org Reporter: osmanx(a)problemloesungsmaschine.de Distribution: --- Created attachment 72743 --> https://bugs.winehq.org/attachment.cgi?id=72743 tz.exe Please implement SystemTimeToTzSpecificLocalTimeEx and TzSpecificLocalTimeToSystemTimeEx. The documentation can be found at <https://docs.microsoft.com/en-us/windows/win32/api/timezoneapi/nf-timezonea…> and <https://docs.microsoft.com/en-us/windows/win32/api/timezoneapi/nf-timezonea…>. Note that because these functions currently outright abort, the work-around I implemented requires explicitly detecting Wine and not even trying to call them, which is far from optimal. Even just implementing stubs that always fail gracefully instead of just aborting the whole process would be much appreciated. This came up when improving local timezone handling in OpenMPT. See <https://bugs.openmpt.org/view.php?id=1618> and <https://source.openmpt.org/browse/openmpt?op=comp&compare[]=/trunk/OpenMPT/…>. Simple test case (for SystemTimeToTzSpecificLocalTimeEx): tz.cpp: ``` #include <iostream> #include <stdexcept> #include <windows.h> int main() { try { SYSTEMTIME sys{}; GetSystemTime(&sys); DYNAMIC_TIME_ZONE_INFORMATION dtzi{}; if (GetDynamicTimeZoneInformation(&dtzi) == TIME_ZONE_ID_INVALID) { throw std::runtime_error("GetDynamicTimeZoneInformation() failed."); } SYSTEMTIME sys_local{}; if (SystemTimeToTzSpecificLocalTimeEx(&dtzi, &sys, &sys_local) == FALSE) { throw std::runtime_error("SystemTimeToTzSpecificLocalTimeEx() failed."); } std::cout << "OK" << std::endl; return 0; } catch (const std::exception & e) { std::cout << std::flush; std::cerr << e.what() << std::endl; std::cerr << std::flush; } std::cout << "FAIL" << std::endl; return 1; } ``` built with VS2022 by running `cl /std:c++20 /permissive- /EHsc /O2 /W4 tz.cpp` results in ``` wine: Call from 0x7bc7c990 to unimplemented function KERNEL32.dll.SystemTimeToTzSpecificLocalTimeEx, aborting ``` not even reaching the FAIL output. tz.exe attached. -- 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 59782] New: Diablo (GOG): Menu screen is completely white, though functional.
by WineHQ Bugzilla May 22, 2026

May 22, 2026

http://bugs.winehq.org/show_bug.cgi?id=59782 Bug ID: 59782 Summary: Diablo (GOG): Menu screen is completely white, though functional. Product: Wine Version: 11.0-rc3 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: d3d Assignee: wine-bugs(a)list.winehq.org Reporter: chiitoo(a)gentoo.org Regression SHA1: 98d1f8bb3847b18ca0797cbc58e9a65311a21381 Distribution: Gentoo Created attachment 80990 --> http://bugs.winehq.org/attachment.cgi?id=80990 log at wine-11.9-86-gcf80269f7e9 After 98d1f8bb384 [1] Diablo / Hellfire menu screen is completely white, though functional. This is the GOG-modified version; need to find my CDs to try the original, too... As a side-note, perhaps uninterestingly, the screen is black instead without 18339eb0f50 [2] which is related to bug 59109 [3], and I can see flashes of white in the menu here too. Before it turns all-white that is. There's one difference I can see in regular logging with the whiteness happening, though it's printed only after exiting the game via ESC: fixme:d3d_shader:glsl_blitter_upload_palette P8 texture loaded without a palette. There's also another issue before this, where the menu rendering isn't updated except for when moused over, which looks like painting/erasing away the black from covering the screen, or when moving the menu selection with arrow keys. Could not find a bug for that, so maybe that will happen after this. The game itself seems to work just fine in any case, though have only tried moving around the starting area a little bit so far. Thank you! 1. https://gitlab.winehq.org/wine/wine/-/commit/98d1f8bb3847b18ca0797cbc58e9a6… 2. https://gitlab.winehq.org/wine/wine/-/commit/18339eb0f5048500efb668e6a9b679… 3. https://bugs.winehq.org/show_bug.cgi?id=59109 -- 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 46803] New: Diablo 1 GOG.com crash
by wine-bugs＠winehq.org May 22, 2026

May 22, 2026

https://bugs.winehq.org/show_bug.cgi?id=46803 Bug ID: 46803 Summary: Diablo 1 GOG.com crash Product: Wine Version: 4.3 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: xzgamertag(a)mail.com Distribution: --- Created attachment 63823 --> https://bugs.winehq.org/attachment.cgi?id=63823 Log Diablo crashes immidiately after skipping intro, while using hi-res, latest version. When I try to run Diablo (Classic) version, it requires original CD to proceed. -- 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 59783] New: WordPerfect Office X3 (and Office 12): PerfectScript macros silently no-op; pfbc130.pfc!DllGetClassObject returns CLASS_E_CLASSNOTAVAILABLE
by WineHQ Bugzilla May 22, 2026

May 22, 2026

http://bugs.winehq.org/show_bug.cgi?id=59783 Bug ID: 59783 Summary: WordPerfect Office X3 (and Office 12): PerfectScript macros silently no-op; pfbc130.pfc!DllGetClassObject returns CLASS_E_CLASSNOTAVAILABLE Product: Wine Version: 9.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: em36(a)columbia.edu Distribution: --- Created attachment 80996 --> http://bugs.winehq.org/attachment.cgi?id=80996 Log file from the attempt to run a WP X3 macro. NB: I am running this under Sikuragur, so the Wine version is wine-9.0 (SikarugirCX 24.0.7) -------- Playing any PerfectScript .wcm macro in WordPerfect (the macro engine is ps130.exe in X3, ps120.exe in Office 12) silently no-ops. The macro engine process is spawned and connects to wpwin via DDE successfully, but a single CoCreateInstance call required to dispatch the macro fails, and WordPerfect then abandons the operation without any user-visible message. This has been confirmed on both: - WordPerfect Office X3 (PerfectScript engine v6), macOS via Sikarugir (a Wineskin-based wrapper) - WordPerfect Office 12 (PerfectScript engine v5), vanilla Wine on Linux Trying a newer Wine engine inside Sikarugir did not change the behavior. Reproducer ---------- 1. Install WordPerfect Office X3 (or Office 12) into a Wine prefix. 2. Launch wpwin13.exe (X3) or wpwin12.exe (Office 12). 3. Tools -> Macro -> Play, choose any supplied .wcm (e.g. EXPNDALL.WCM from ...\Languages\EN\Macros\WPWin\), click Open. 4. Expected: the macro runs. 5. Observed: nothing visible happens. The macro engine launches in the background, connects via DDE, but the macro never executes. What the log shows ------------------ With WINEDEBUG=+module,+loaddll,+process,+ole,+dde,+ddeml: (a) ps130.exe launches successfully as a child of wpwin13.exe: trace:process:CreateProcessInternalW app "C:\Program Files (x86)\WordPerfect Office X3\Programs\ps130.exe" cmdline "...\ps130.exe /# /l-EN" trace:process:NtCreateUserProcess ... ps130.exe ... pid 0134 tid 0138 trace:loaddll:build_module Loaded ...\ps130.exe at 00400000: native (b) WordPerfect and PerfectScript establish DDE conversations: trace:ddeml:WDML_MakeHszFromAtom c0ec => L"WPWin13_Macros" trace:ddeml:WDML_MakeHszFromAtom c0ee => L"WPWin" trace:ddeml:WDML_InvokeCallback ... (callbacks fire on both sides) (c) WordPerfect attempts CoCreateInstance on the CLSID required to dispatch the macro: trace:ole:CoCreateInstance {c0e10002-0031-0006-c0e1-c0e1c0e1c0e1}, 00000000, 0x1 (CLSCTX_INPROC_SERVER), IID_IUnknown trace:ole:apartment_getclassobject added new loaded dll "C:\Program Files (x86)\WordPerfect Office X3\Programs\pfbc130.pfc" err:ole:apartment_getclassobject DllGetClassObject returned error 0x80040111 for dll "...\pfbc130.pfc" err:ole:com_get_class_object no class object {c0e10002-0031-0006-c0e1-c0e1c0e1c0e1} could be created for context 0x1 0x80040111 == CLASS_E_CLASSNOTAVAILABLE, returned by pfbc130.pfc's own DllGetClassObject. Wine is not the proximate cause -- it correctly locates and loads the registered server -- but the server's own code refuses to hand back a class factory. (d) Other CoCreateInstance calls in the same session SUCCEED: {c0e10001-0006-0006-c0e1-c0e1c0e1c0e1} -> ok {c0e10001-0009-0006-c0e1-c0e1c0e1c0e1} -> ok {c0e10004-0001-0006-c0e1-c0e1c0e1c0e1} -> ok Only -0031- fails. This is one specific class in the PerfectFit framework, not a generic load problem. (e) Immediately before DllGetClassObject is called, pfbc130.pfc's DllMain(PROCESS_ATTACH) issues two consecutive anti-debug probes: trace:process:NtQueryInformationProcess (0xffffffffffffffff, 0x0c, ...) trace:process:NtQueryInformationProcess (0xffffffffffffffff, 0x0c, ...) ProcessInformationClass 0x0c is ProcessDebugPort. PerfectFit was Corel's anti-tamper / licensing framework. The probe result is plausibly cached as a flag that gates the class factory for protected CLSIDs. This is a hypothesis -- confirming it requires stepping pfbc130.pfc!DllGetClassObject in winedbg. (f) Side note (probably not the root cause, but worth fixing): Wine's DDEML cannot handle Corel's private DDE clipboard format 0xc0ea used by the wpwin <-> ps130 conversation: fixme:ddeml:WDML_Global2DataHandle Unsupported format (ffffc0ea) for data ..., passing raw information fixme:ddeml:WDML_DataHandle2Global Unsupported format (c0ea) for data ..., passing raw information What this is NOT ---------------- Things ruled out by investigation: - COM registration: the registry has full and correct entries for every PerfectFit CLSID, ProgID, Interface/TypeLib, ProxyStubClsid, and PFBC130/PFOB130/PFQS130/PFSE130/PFDT130/PFVM130 component server, written by Corel's installer. - Wrong DLL registered: pfbc130.pfc *does* contain the failing CLSID in its binary (verified by 16-byte struct grep), along with 42 other CLSIDs in the same Corel-tail family. The registry maps the failing CLSID to the right DLL. - DDE broken: DDE conversations between wpwin and ps130 establish correctly and exchange messages. The Corel-private 0xc0ea format fixme is real but is hit during the conversation, not at setup. - Missing dependency: pfbc130.pfc's DllMain(PROCESS_ATTACH) returns 1 (success). All other DLLs in the dependency chain (MSVCRT, KERNEL32, USER32, GDI32, ADVAPI32, SHELL32, COMCTL32, ole32, OLEAUT32, ThemeManager, CRLUTL114, MFC42) load fine. - DllRegisterServer not run: the prefix has the registration; that's not the issue. Attached -------- wp-x3-macro.log.gz -- full WINEDEBUG=+module,+loaddll,+process,+ole,+dde,+ddeml capture of one wpwin13.exe session in which EXPNDALL.WCM was triggered via Tools->Macro->Play. -- 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 59762] New: application crashes when launching lotro store window ingame
by WineHQ Bugzilla May 22, 2026

May 22, 2026

http://bugs.winehq.org/show_bug.cgi?id=59762 Bug ID: 59762 Summary: application crashes when launching lotro store window ingame Product: Wine Version: 11.8 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: blocker Priority: P2 Component: winedbg Assignee: wine-bugs(a)list.winehq.org Reporter: djpat30(a)gmail.com Distribution: --- Created attachment 80961 --> http://bugs.winehq.org/attachment.cgi?id=80961 backtrace Launch the lord of the ring online game, login. At the main screen, launch the lotro store (upper right corner) notice the crash and error -- 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 55710] New: wine-staging fails to run anything in 64-bit prefix
by WineHQ Bugzilla May 21, 2026

May 21, 2026

https://bugs.winehq.org/show_bug.cgi?id=55710 Bug ID: 55710 Summary: wine-staging fails to run anything in 64-bit prefix Product: Wine-staging Version: 8.17 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: dmitry(a)baikal.ru CC: leslie_alistair(a)hotmail.com, z.figura12(a)gmail.com Distribution: --- Even an attemp to create new 64-bit prefix fails: $ WINEPREFIX=~/.wine64 WINEARCH=win64 ~/wine-staging64/wine winver wine: created the configuration directory '/home/dmitry/.wine64' 002c:fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.Windows.Common-Controls" (6.0.0.0) 002c:fixme:winediag:LdrInitializeThunk wine-staging 8.17 is a testing version containing experimental patches. 002c:fixme:winediag:LdrInitializeThunk Please mention your exact version when filing bug reports on winehq.org. 002c:fixme:sync:NtAcceptConnectPort ((nil),832,0x90000002,31,0x7ffffe0ff338,0x7d7d011256a0),stub! *** stack smashing detected ***: <unknown> terminated 002c:err:seh:call_stack_handlers invalid frame 00007FFFFE0FF320 (00007FFFFE102000-00007FFFFE200000) 002c:err:seh:NtRaiseException Exception frame is not in stack limits => unable to dispatch exception. With 32-bit prefix everything seems to work. It looks like this problem started with wine-staging 8.16. -- 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 45