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

[Bug 45480] New: LOUDPLAY: crashes when I launch application
by wine-bugs＠winehq.org July 19, 2026

July 19, 2026

https://bugs.winehq.org/show_bug.cgi?id=45480 Bug ID: 45480 Summary: LOUDPLAY: crashes when I launch application Product: Wine Version: 3.12 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: mikhail.v.gavrilov(a)gmail.com Distribution: --- Created attachment 61835 --> https://bugs.winehq.org/attachment.cgi?id=61835 console logs $ wine --version wine-3.12 (Staging) -- 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 9

[Bug 59682] New: Windrose server: UDP bind to specific IPv4 behaves like 0.0.0.0%iface, causing wrong source IP and multihoming conflicts
by WineHQ Bugzilla July 19, 2026

July 19, 2026

http://bugs.winehq.org/show_bug.cgi?id=59682 Bug ID: 59682 Summary: Windrose server: UDP bind to specific IPv4 behaves like 0.0.0.0%iface, causing wrong source IP and multihoming conflicts Product: Wine Version: 11.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: wineserver Assignee: wine-bugs(a)list.winehq.org Reporter: koekdendeniz(a)gmail.com Distribution: --- A Windows dedicated server application (WindroseServer-Win64-Shipping.exe) works correctly on native Windows, where binding to a specific IP via -Multihome=<IP> results in UDP sockets bound to that IP:PORT. Under Wine on Linux, the same server appears to bind correctly in Wine debug logs, but the resulting Linux UDP socket shows up as 0.0.0.0%iface:PORT instead of IP:PORT. This causes two problems: 1. Outgoing UDP replies use the wrong source IP (the host's main IP instead of the IP passed to -Multihome). 2. Multiple instances cannot use the same UDP port on different local IPs, because the socket effectively behaves like 0.0.0.0:PORT instead of IP_A:PORT and IP_B:PORT. Tested with: * host networking * multiple public IPv4 addresses assigned on the same host * command line using -Multihome=<IP> Expected result: UDP socket is bound to the specific IPv4 address, replies use that source IP, and multiple instances can bind the same UDP port on different local IPs. Actual result: UDP socket appears as 0.0.0.0%iface:PORT, replies use the wrong source IP, and same-port multi-IP hosting fails. -- 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 33008] New: UDP listening on specific IP address does not work properly
by wine-bugs＠winehq.org July 19, 2026

July 19, 2026

http://bugs.winehq.org/show_bug.cgi?id=33008 Bug #: 33008 Summary: UDP listening on specific IP address does not work properly Product: Wine Version: 1.5.24 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: critical Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: decimusmaximus(a)seznam.cz Classification: Unclassified Wine updated from 1.5.6 to 1.5.24. My app uses UDP listening on specific address (not 0.0.0.0). It is running on machine with NAT, there are two interfaces with IP A.A.A.A (public) and IP B.B.B.B (private) My app is set to listen only on one IP address, IP A.A.A.A It works properly on Wine 1.5.6. Traffic from subnet B.B.B.B is NATed to A.A.A.A interface and application running in wine receives it correctly. After update to 1.5.24 it does not work anymore. Application does not receive data from private subnet B.B.B.B, however it works properly for traffic incoming on A.A.A.A interface. Please see attached schema. results of "netstat --listening" with Wine 1.5.6 it is listening on A.A.A.A address correctly. with Wine 1.5.24 it is listening on 0.0.0.0 (obviously incorrect, socket binding is set to A.A.A.A address in application and although it is saying 0.0.0.0 app does not receive any data from B.B.B.B network) This application has to be listening only on one interface and do not mix public and private addresses. In this case it is not accessible for clients in private network, so it is critical bug. Main strange thing is, that it is listening on all addresses 0.0.0.0 although socket binding in application is set to address A.A.A.A -- 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 35

[Bug 56488] New: TCP socket appears to be in use but it is not
by WineHQ Bugzilla July 19, 2026

July 19, 2026

https://bugs.winehq.org/show_bug.cgi?id=56488 Bug ID: 56488 Summary: TCP socket appears to be in use but it is not Product: Wine Version: 4.0-rc2 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: bugzilla400(a)gmail.com Distribution: --- I have a .net 3.5 application that runs fine on Windows but have a problem when running on Debian. The problem is a socket binding error "address already in use". CODE: System.Net.Sockets.SocketException: Unknown error (0x2740) at System.Net.Sockets.Socket.DoBind(EndPoint endPointSnapshot, SocketAddress socketAddress) at System.Net.Sockets.Socket.Bind(EndPoint localEP) netstat and lsof commands don't show the socket that appears to be in use, so I assume it's not really in use. Furthermore the problem only happens, and it always happen, in the following circumstance. 1. The program A.exe listens successfully on the server socket <anyip>:<port>. 2. Then it start the program B.exe and close itself (closing the socket too). 3. Program B.exe do something and then starts again A.exe. 4. A.exe try to bind the server socket but in that case it fails with the error "address already in use". 5. Restart A.exe, now the binding success. To start the new process I'm using System.Diagnostic.Process. CODE: // This is only a generic example var process = new Process() { StartInfo = new ProcessStartInfo { FileName = "cmd", Arguments = "/c /usr/bin/bash -c \"/usr/bin/sleep 5 && /usr/bin/wine path/of/process/program.exe\"", UseShellExecute = false, WorkingDirectory = "the/working/dir", } } These are the socket states after each steps (netstat): 1. LISTEN 2. not listed due to socket is closed 3. not listed due to socket is closed 4. not listed due to socket is closed <- But I have got the error 5. LISTEN I suppose that the A and B processes close properly because I don't see them in htop anymore. There seems to be something left hanging. I've found that if I don't relaunch A.exe from B, but do it manually, everything works fine. I also noticed this behavior that I wasn't expecting: - if I use socket.Accept the socket is bound to the A.exe process, - if I use socket.BeginAccept the socket is bound to the winserver32 process Clearly if I simply close the A.exe application and restart it all works fine. -- 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 59687] New: 'const' variable modifier causes null return-value in vertex shader
by WineHQ Bugzilla July 19, 2026

July 19, 2026

http://bugs.winehq.org/show_bug.cgi?id=59687 Bug ID: 59687 Summary: 'const' variable modifier causes null return-value in vertex shader Product: Wine Version: 11.6 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: d3d Assignee: wine-bugs(a)list.winehq.org Reporter: bczhc0(a)126.com Distribution: --- Created attachment 80789 --> http://bugs.winehq.org/attachment.cgi?id=80789 trace-ok.log Take this HLSL code which basically is a hello-triangle. ```hlsl struct VsOut { float4 pos : SV_Position; }; static const float2 VERTICES[3] = { float2(0.0, 0.5), float2(-0.5, -0.5), float2(0.5, -0.5) }; static const float4 RED = float4(1.0, 0.0, 0.0, 1.0); VsOut vs_main(uint vid : SV_VertexID) { float2 position = VERTICES[min(vid, 2u)]; VsOut output = { float4(position, 0.0, 1.0) }; return output; } float4 fs_main() : SV_Target { return RED; } ``` I have this wgpu program: https://gist.github.com/bczhc/e8d11db2280ffd20fee43fb1fed7410e to run and render this shader. (Sorry I'm not familiar with hlsl and windows programming so I just now only able to write the wgpu program to demonstrate it and suppose it may not be related to wgpu anyway) To compile and run it, do: ```bash # ensure to put it in a cargo project first cargo build --target x86_64-pc-windows-gnu # run WINEPREFIX=`pwd`/prefix WGPU_BACKEND=dx12 wine target/x86_64-pc-windows-gnu/debug/demo.exe the-hlsl-above.hlsl vs_main ``` It will display a red triangle. However, modify this line `VsOut output = { float4(position, 0.0, 1.0) };` to `const VsOut output = { float4(position, 0.0, 1.0) };`, then compile the Rust program then run it using wine again, the red triangle will not show. Or, if that line is left as is but you add another const variable, like this: ```hlsl VsOut vs_main(uint vid : SV_VertexID) { float2 position = VERTICES[min(vid, 2u)]; VsOut output = { float4(position, 0.0, 1.0) }; const VsOut output1 = output; return output1; } ``` The red triangle is also not able to display. This is originally reported as a wgpu issue here: https://github.com/gfx-rs/wgpu/issues/9056. At that time, only proton has this issue (wine is okay). However now with wine 11.6 I tested it again, wine has this issue either. So I suspect this is an upstream vkd3d hlsl compiler issue then? I haven't done the bisect yet because I haven't managed how to properly compile this project and substitute it for wine. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 11

[Bug 58274] New: Cannot get past Steam age check
by WineHQ Bugzilla July 19, 2026

July 19, 2026

http://bugs.winehq.org/show_bug.cgi?id=58274 Bug ID: 58274 Summary: Cannot get past Steam age check Product: Wine Version: 10.8 Hardware: x86-64 URL: https://store.steampowered.com/app/680420/OUTRIDERS/ OS: Linux Status: NEW Keywords: download Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: imwellcushtymelike(a)gmail.com Distribution: Ubuntu When trying to access a game that contains adult themes you can be annoyed/greeted by an age verification check. It is a very simple check where you select your date of birth from drop-down menus. With Wine, these menus don't work. When clicking on them this is printed in the console: 0150:fixme:uxtheme:AllowDarkModeForWindow 000000000032025C 1: stub 0150:fixme:dwmapi:DwmExtendFrameIntoClientArea (000000000032025C, 00007FFFFE1FD990) stub 0150:fixme:dwmapi:DwmExtendFrameIntoClientArea (000000000032025C, 00007FFFFE1FE610) stub 0150:fixme:manipulation:viewport_ActivateConfiguration 00007A592875B710, 823 0150:fixme:manipulation:viewport_SetViewportOptions 00007A592875B710, 2 0150:fixme:manipulation:viewport_AddEventHandler 00007A592875B710, 000000000031025A, 00002CEC011144A0, 00002CEC01052470 0150:fixme:manipulation:viewport_Stop 00007A592875B710 0150:fixme:manipulation:viewport_RemoveEventHandler 00007A592875B710, 1 0150:fixme:manipulation:viewport_Abandon 00007A592875B710 0150:fixme:manipulation:direct_manip_Deactivate 00007A592875B650, 000000000031025A 0150:fixme:manipulation:viewport_ActivateConfiguration 00007A592875B710, 823 0150:fixme:manipulation:viewport_SetViewportOptions 00007A592875B710, 2 0150:fixme:manipulation:viewport_AddEventHandler 00007A592875B710, 000000000031025A, 00002CEC011144A0, 00002CEC01052470 0150:fixme:manipulation:viewport_Stop 00007A592875B710 0150:fixme:manipulation:viewport_RemoveEventHandler 00007A592875B710, 1 0150:fixme:manipulation:viewport_Abandon 00007A592875B710 0150:fixme:manipulation:direct_manip_Deactivate 00007A592875B650, 000000000031025A 0150:fixme:manipulation:viewport_ActivateConfiguration 00007A592875B710, 823 0150:fixme:manipulation:viewport_SetViewportOptions 00007A592875B710, 2 0150:fixme:manipulation:viewport_AddEventHandler 00007A592875B710, 000000000031025A, 00002CEC00FE8420, 00002CEC00FEAF70 0150:fixme:manipulation:viewport_Stop 00007A592875B710 0150:fixme:manipulation:viewport_RemoveEventHandler 00007A592875B710, 6 0150:fixme:manipulation:viewport_Abandon 00007A592875B710 0150:fixme:manipulation:direct_manip_Deactivate 00007A592875B650, 000000000031025A 01b8:fixme:dwmapi:DwmGetWindowAttribute attribute 14 not implemented. 01b8:fixme:dwmapi:DwmGetWindowAttribute attribute 14 not implemented. 01b8:fixme:win:NtUserGetWindowPlacement not fully supported on other process window 0x30038. 01b8:fixme:dwmapi:DwmGetWindowAttribute attribute 14 not implemented. 01b8:fixme:dwmapi:DwmGetWindowAttribute attribute 14 not implemented. 01b8:fixme:win:NtUserGetWindowPlacement not fully supported on other process window 0x30038. To get this far requires a log in and so "winetricks arial" (Bug 47325), and disabling GPU acceleration for web views helps (Bug 56758). -- 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 3

[Bug 58346] New: Text is not shown in non-full screen Steam windows
by WineHQ Bugzilla July 19, 2026

July 19, 2026

http://bugs.winehq.org/show_bug.cgi?id=58346 Bug ID: 58346 Summary: Text is not shown in non-full screen Steam windows Product: Wine Version: 10.9 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: jonis9898(a)hotmail.com Distribution: --- Created attachment 78723 --> http://bugs.winehq.org/attachment.cgi?id=78723 Installation window for Borderlands 2 in Steam. Any account details have been painted over. When running Steam through Wine at first no text is shown, but is restored it the window is resized. The installation window can not be resized and stays textless. The install buttons are also missing. -- 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 10

[Bug 49822] New: vatSys: crashes on run, unhandled Reflection.TargetInvocationException
by WineHQ Bugzilla July 19, 2026

July 19, 2026

https://bugs.winehq.org/show_bug.cgi?id=49822 Bug ID: 49822 Summary: vatSys: crashes on run, unhandled Reflection.TargetInvocationException Product: Wine Version: 5.16 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: blue(a)blu3wolf.com Distribution: --- Created attachment 68157 --> https://bugs.winehq.org/attachment.cgi?id=68157 console output from running the installed program vatSys installs normally, but crashes on run, throwing a TargetInvocationException. Can be downloaded from https://vatsys.sawbe.com/downloads/vatSysSetup.zip -- 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 59186] New: Starcraft 2 detects wrong graphics card
by WineHQ Bugzilla July 19, 2026

July 19, 2026

http://bugs.winehq.org/show_bug.cgi?id=59186 Bug ID: 59186 Summary: Starcraft 2 detects wrong graphics card Product: WineHQ Gitlab Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: gitlab-unknown Assignee: wine-bugs(a)list.winehq.org Reporter: calmstorm(a)posteo.de Distribution: --- I am using a T480 and it has a HD graphics 820 yet it keeps detecting it as if its the intel HD 4000 series graphics card. It is kind of weird... I wonder why blizzard is detecting the wrong graphics card? Is this a wine issue? I think it is but I could be wrong. -- 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 58

[Bug 57353] New: Steam: the console is spammed with dxgi d3d11 fixmes
by WineHQ Bugzilla July 18, 2026

July 18, 2026

https://bugs.winehq.org/show_bug.cgi?id=57353 Bug ID: 57353 Summary: Steam: the console is spammed with dxgi d3d11 fixmes Product: Wine Version: 9.20 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: m1m1k4tz(a)protonmail.com Distribution: --- Created attachment 77324 --> https://bugs.winehq.org/attachment.cgi?id=77324 dxgi My setup is using the new wow64 mode -- 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