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

[Bug 59765] Custom application using sockets performs worse on 11.8 vs 5.0

by WineHQ Bugzilla

May 18, 2026

[Bug 59765] wineserver: performance regression in newer Wine versions (apparently related to Winsock/socket polling)

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59765 Zeb Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12(a)gmail.com --- Comment #2 from Zeb Figura <z.figura12(a)gmail.com> --- Usually wineserver per se isn't the bottleneck, only because RPC to wineserver is usually a bigger one. On old versions I believe an immediately satisfied recv() or send() takes only one server call; now two are necessary. Unfortunately avoiding these is hard. The fundamental problem is that I/O on the same socket has to be processed in the order that it's issued, which means we need something to be managing a queue, and since sockets can be cross-process, that needs to be the server. We need one server call to insert ourselves into the queue, and a second to remove ourselves after the I/O is satisfied. (Or, if we're not at the front of the queue, the first server call returns that status and we wait or return EWOULDBLOCK as appropriate.) Note that you can't special case nonblocking sockets, because you can still issue blocking I/O on a nonblocking socket using something like WSARecv(). In older versions of Wine, select() didn't take server RPC, but things have changed so now it's necessary for compatibility reasons. I don't remember the details offhand. I think an immediately satsifiable select takes one server call; one which has to wait takes two? Most applications aren't going to run into the corner cases that mattered, which is why things worked fine on 5.x. Most applications also don't care that much about socket I/O performance, I guess because the actual overhead of socket I/O is usually higher. If it's all loopback, I guess that might matter more. Unfortunately cutting the server out is going to be *very* hard. It'll take some thought. Still, it might be worth doing some more careful performance analysis on this, because the most obvious bottlenecks are also probably the hardest by far to remove. Counting calls can be misleading, so can perf, especially when there are multiple processes. I'd probably instead try to measure the time between cycles, and see how that's increased overall, as well as more fine grained differences e.g. how long select() takes including the sleep, how long send() takes, how long recv() takes... -- 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.

May 18, 2026

[Bug 59680] Path of Exile: font rendering related crash

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59680 --- Comment #33 from Vitor Coimbra <vitorcoliveira91(a)gmail.com> --- Created attachment 80969 --> http://bugs.winehq.org/attachment.cgi?id=80969 Post-bandaid patch "e๋" rendering in Path of Exile. > Looks like you are not at the latest wine commit. First discard all of the > local changes by executing "git restore ." in the wine repo. Then apply the > first two patches again and finally at last apply the "bandaid" patch and > compile the repo. I was applying the patches to the latest NixOS unstable wine package, since running the locally compiled wine turned out to not work. But then I remembered that I can just compile it, grab the resulting DLLs and throw them into Proton's directories. This is ok to do since I won't be running the compiled wine anyway. Anyways, after doing just that, I can confirm the mark _does_ show up now. I've attached a screenshot of what it looks like after this latest bandaid patch. -- 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.

May 18, 2026

[Bug 59679] .NET apps crash on Wine due to invalid ICU locale "bgc"

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59679 minrosa9 <tw0ali(a)tutanota.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Some sections of PKHeX |.NET apps crash on Wine due |crash with Wine 11.5+ |to invalid ICU locale "bgc" -- 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.

May 18, 2026

[Bug 59765] wineserver: performance regression in newer Wine versions (apparently related to Winsock/socket polling)

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59765 --- Comment #1 from mcsordas <csoresz2(a)gmail.com> --- Created attachment 80968 --> http://bugs.winehq.org/attachment.cgi?id=80968 strace output for both systems -- 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.

May 18, 2026

[Bug 59679] Some sections of PKHeX crash with Wine 11.5+

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59679 --- Comment #3 from minrosa9 <tw0ali(a)tutanota.com> --- Just a quick update on this. Using DOTNET_SYSTEM_GLOBALIZATION_USENLS=1 fixes the problem. So, yes, you were right, there's probably something wrong with ICU. -- 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.

May 18, 2026

[Bug 59765] New: wineserver: performance regression in newer Wine versions (apparently related to Winsock/socket polling)

by WineHQ Bugzilla

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.

May 18, 2026

[Bug 59680] Path of Exile: font rendering related crash

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59680 --- Comment #32 from समीरसिंह Sameer Singh <lumarzeli30(a)gmail.com> --- (In reply to Vitor Coimbra from comment #31) > (In reply to समीरसिंह Sameer Singh from comment #30) > > Created attachment 80966 [details] > > bandaid-patch > > > > does the above patch work display the thai marks? This is obviously not a > > clean solution, but I wanted to know if I was in the right direction. > > Left the project compiling with all 3 patches (I assume it has to be this > way?), but was met with the following error (in pastebin, because pasting > directly here makes it unreadable): https://pastebin.com/mgUneNn4 > > Not entirely sure what could be causing it. I chose the > wineWow64Packages.unstableFull package from nixpkgs, which I assume is the > most up to date with the latest commit, but maybe even that is not enough > and some mismatch caused this error? Looks like you are not at the latest wine commit. First discard all of the local changes by executing "git restore ." in the wine repo. Then apply the first two patches again and finally at last apply the "bandaid" patch and compile the repo. -- 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.

May 18, 2026

[Bug 59764] New: Joystick button-numbers are mixed up in a lot of older games since wine 11.8

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59764 Bug ID: 59764 Summary: Joystick button-numbers are mixed up in a lot of older games since wine 11.8 Product: Wine Version: 11.8 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: pe.we.psi(a)gmail.com Distribution: --- Since wine 11.8 the numbers of most joystick buttons recognized by a lot of older games have changed. I am using a VKB Gladiator EVO joystick with 32 buttons and in most games (FS2004 for example) the assignment of game functions to joystick buttons is totally wrong now. It would be a very time-consuming task to reconfigure the mappings for every single game. Is there a way to revert the changes made to the joystick control in wine 10.8 ? -- 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.

May 18, 2026

[Bug 59680] Path of Exile: font rendering related crash

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59680 --- Comment #31 from Vitor Coimbra <vitorcoliveira91(a)gmail.com> --- (In reply to समीरसिंह Sameer Singh from comment #30) > Created attachment 80966 [details] > bandaid-patch > > does the above patch work display the thai marks? This is obviously not a > clean solution, but I wanted to know if I was in the right direction. Left the project compiling with all 3 patches (I assume it has to be this way?), but was met with the following error (in pastebin, because pasting directly here makes it unreadable): https://pastebin.com/mgUneNn4 Not entirely sure what could be causing it. I chose the wineWow64Packages.unstableFull package from nixpkgs, which I assume is the most up to date with the latest commit, but maybe even that is not enough and some mismatch caused this 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.

May 18, 2026

[Bug 59680] Path of Exile: font rendering related crash

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59680 --- Comment #30 from समीरसिंह Sameer Singh <lumarzeli30(a)gmail.com> --- Created attachment 80966 --> http://bugs.winehq.org/attachment.cgi?id=80966 bandaid-patch does the above patch work display the thai marks? This is obviously not a clean solution, but I wanted to know if I was in the right direction. -- 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.

May 18, 2026

[Bug 9404] cannot select TWAIN source in irfanview

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=9404 Bartosz <gang65(a)poczta.onet.pl> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED CC| |gang65(a)poczta.onet.pl Status|NEW |RESOLVED --- Comment #12 from Bartosz <gang65(a)poczta.onet.pl> --- It is working for me. -- 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.

May 18, 2026

[Bug 59732] Custom WinXP/7 app printing garbled from wine 9 onwards

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59732 --- Comment #9 from hascc <hugoac2004(a)gmail.com> --- (In reply to Rafał Mużyło from comment #6) > Well, given that 8.8 had a major wineps.drv rework, that's likely what broke. > I wonder what corner case your app covers, that hasn't been stumbled upon > for all that time elsewhere... > > (8.13 doesn't have anything labeled 'crash fix', but one of the psdrv > commits fixes a potential div by zero, so perhaps...) > > So, a 'psdrv' log from 8.8 and 8.13 each, if you don't mind, given that only > you have access to the app. That would be trying WINEDEBUG="+psdrv" for each version? Will do, thank you. -- 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.

May 18, 2026

[Bug 59631] wine-staging-11.6: flickering images in Battle.net Launcher

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59631 --- Comment #35 from Stian Low <wineryyyyy(a)gmail.com> --- Unclear if MR-10567 patch should be added to staging but it would help me better determine its validity if others besides myself were running tests with 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.

May 18, 2026

[Bug 59631] wine-staging-11.6: flickering images in Battle.net Launcher

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59631 --- Comment #34 from Stian Low <wineryyyyy(a)gmail.com> --- (In reply to Stian Low from comment #33) > Flicker mostly resolves via this 1 line fix To be clear: MR-10567 contains the flicker fix (mostly). The 1 line fix to dcomp actually fixes the white/black screen caused by MR-10567 without this dcomp fix. -- 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.

May 18, 2026

[Bug 59631] wine-staging-11.6: flickering images in Battle.net Launcher

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59631 --- Comment #33 from Stian Low <wineryyyyy(a)gmail.com> --- (In reply to Stian Low from comment #32) > I'll look closer at how dcomp depends on wined3d_swapchain_gl_rotate() > differently than rendering pipeline used for those games otherwise fixed by > removing rotate funcs. Flicker mostly resolves via this 1 line fix to ~/tmp/wine_stianlow/dlls/dcomp/device.c::do_composite() call to IDXGISwapChain1_GetBuffer() to use backbuffer 0 (instead of BufferCount - 1) which is always the front buffer for attached MR-10567 patch that removes wined3d_swapchain_gl_rotate(): /* The front buffer is the last back buffer because the composition swapchain must * be created with DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL */ hr = IDXGISwapChain1_GetBuffer(swapchain, swapchain_desc.BufferCount - 1, &IID_IDXGISurface, (void **)&dxgi_surface); hr = IDXGISwapChain1_GetBuffer(swapchain, 0, &IID_IDXGISurface, (void **)&dxgi_surface); The intial login spinner/icon shows the most obvious remaining flicker/graphical glitch, but once logged in, the main window flickers considerably less in a mostly usable fashion resembling rendering prior to latest dcomp staging patches. Logs indicate fbo_blitter is used for my tests: 02f4:trace:d3d:swapchain_blit swapchain 02ABC3B8, context 0298BD98, src_rect (0,0)-(348,646), dst_rect (0,0)-(348,646). 02f4:trace:d3d:fbo_blitter_blit blitter 0298AA20, op 0, context 0298BD98, src_texture 02A94820, src_sub_resource_idx 0, src_location WINED3D_LOCATION_TEXTURE_RGB, src_rect (0,0)-(348,646), dst_texture 02A94820, dst_sub_resource_idx 0, dst_location WINED3D_LOCATION_DRAWABLE, dst_rect (0,0)-(348,646), colour_key 00000000, filter WINED3D_TEXF_NONE, resolve_format 00000000. Part of my reason for removing wined3d_swapchain_gl_rotate()/wined3d_swapchain_vk_rotate() is because GPU calls may be considered to handle swaps/rotations via wglSwapBuffers() and vkAcquireNextImageKHR(). However, even if those GPU calls may be considered valid for handling swap/rotation, CPU-based renderer may still require wined3d_swapchain_gl_rotate()/wined3d_swapchain_gl_rotate() since GPU-based mechanisms are not available. I will test forcing CPU-based rendering to determine if it that is a use case for keeping wined3d_swapchain_gl_rotate()/wined3d_swapchain_vk_rotate(). In the meantime, GPU-based rendering issues seem mostly resolved and remaining graphical glitches may be caused by additional bugs that need to be fixed within dcomp. -- 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.

May 18, 2026

[Bug 59760] Missing i386-part on latest 11.9 Ubuntu (noble, jammy) packages

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59760 Rosanne DiMesio <dimesio(a)earthlink.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #6 from Rosanne DiMesio <dimesio(a)earthlink.net> --- The i586 build environment for Ubuntu 22.04 and 24.04 on the OBS is currently broken: [ 23s] ### VM INTERACTION END ### [ 23s] No buildstatus set, either the base system is broken (kernel/initrd/udev/glibc/bash/perl) [ 23s] or the build host has a kernel or hardware problem... That's not under our control; it's been reported on the OBS mailing list, waiting for them to fix 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.

May 18, 2026

[Bug 59760] Missing i386-part on latest 11.9 Ubuntu (noble, jammy) packages

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59760 Rosanne DiMesio <dimesio(a)earthlink.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |monsterovich(a)gmail.com --- Comment #5 from Rosanne DiMesio <dimesio(a)earthlink.net> --- *** Bug 59761 has been marked as a duplicate of this bug. *** -- 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.

May 18, 2026

[Bug 59761] The ubuntu packages in wine-11.9 are built incorrectly

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59761 Rosanne DiMesio <dimesio(a)earthlink.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #3 from Rosanne DiMesio <dimesio(a)earthlink.net> --- Marking duplicate. *** This bug has been marked as a duplicate of bug 59760 *** -- 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.

May 18, 2026

[Bug 59760] Missing i386-part on latest 11.9 Ubuntu (noble, jammy) packages

by WineHQ Bugzilla

May 18, 2026

[Bug 59631] wine-staging-11.6: flickering images in Battle.net Launcher

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59631 --- Comment #32 from Stian Low <wineryyyyy(a)gmail.com> --- (In reply to Stian Low from comment #31) > Thanks for confirming all white/black dcomp windows also happen for you when > applying patch atop dcomp wine-staging. > > This is the first case of the patch not working so I'll be modding and doing > more testing for compatibility. Adding back wined3d_swapchain_gl_rotate()/wined3d_swapchain_vk_rotate() removed by patch fixes white/black screens but does not resolve flicker. Those wined3d_swapchain_gl_rotate() were removed because they cause flicker for some games using swap_effect 0x3 after adding support for RenderTargetViews for swapchains with more than 1 for wined3d_render_target_view_gl_cs_init(). I'll look closer at how dcomp depends on wined3d_swapchain_gl_rotate() differently than rendering pipeline used for those games otherwise fixed by removing rotate funcs. -- 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.

May 18, 2026

[Bug 57980] Adobe Creative Cloud requires unimplemented function KERNEL32.dll.SetThreadpoolTimerEx

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=57980 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch CC| |leslie_alistair(a)hotmail.com -- 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.

May 18, 2026

[Bug 59631] wine-staging-11.6: flickering images in Battle.net Launcher

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59631 --- Comment #31 from Stian Low <wineryyyyy(a)gmail.com> --- (In reply to Alistair Leslie-Hughes from comment #30) > Though the patch attached, just give a black (white) windows when used. Thanks for confirming all white/black dcomp windows also happen for you when applying patch atop dcomp wine-staging. This is the first case of the patch not working so I'll be modding and doing more testing for compatibility. -- 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.

May 18, 2026

[Bug 59631] wine-staging-11.6: flickering images in Battle.net Launcher

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59631 --- Comment #30 from Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> --- (In reply to Stian Low from comment #29) > (In reply to Alistair Leslie-Hughes from comment #28) > > I'm still not seeing the flicker issue, with/out acceleration enabled. > > Do any of these logs appear with patch applied? > Found that i was loading the dxgi.dll from dxvk, so once I changed that. The bug was easy to see. Though the patch attached, just give a black (white) windows when used. -- 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.

May 18, 2026

[Bug 59673] Densha De Go! Professional 2 crashes on launch

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59673 --- Comment #7 from Rémi Bernon <rbernon(a)codeweavers.com> --- Thank you! I think this might be caused by some interaction of the blamed commit and wined3d multithreaded command stream that is apparently disabled in your prefix. This is a bug and it should probably work but I'm not sure how to fix it properly yet. You might want to edit the user.reg file in the game prefix, to remove the csmt key (or set it to 1) under Software\\Wine\\AppDefaults\\dgopro2.exe\\Direct3D, and see if it helps. -- 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.

May 18, 2026