- Wine-Bugs - list.winehq.org

[Bug 59875] New: Tagscanner: 64-bit version of the program won't open, application error.
by WineHQ Bugzilla June 16, 2026

June 16, 2026

http://bugs.winehq.org/show_bug.cgi?id=59875 Bug ID: 59875 Summary: Tagscanner: 64-bit version of the program won't open, application error. Product: Wine Version: 11.11 Hardware: x86-64 URL: https://web.archive.org/web/20260615231958/https://www .xdlab.ru/files/tagscan-6.1.21_x64-setup.exe OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: draviezz(a)proton.me Distribution: --- Created attachment 81181 --> http://bugs.winehq.org/attachment.cgi?id=81181 Window_wine_x64_default Instructions for reproduction/testing: 1. Create and use a clean, default WINEPREFIX (~/.wine). 2. Install the program normally. 3. Open the program normally. The 64-bit version of the program won't open, application 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 2

[Bug 59839] New: Battle.net crashes immediately after launch on Wine 11.8
by WineHQ Bugzilla June 15, 2026

June 15, 2026

http://bugs.winehq.org/show_bug.cgi?id=59839 Bug ID: 59839 Summary: Battle.net crashes immediately after launch on Wine 11.8 Product: Wine Version: 11.8 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: nileshkumbhar1604(a)gmail.com Distribution: --- Created attachment 81128 --> http://bugs.winehq.org/attachment.cgi?id=81128 Crash log generated while reproducing the issue Battle.net crashes immediately after launch on Wine 11.8. System: - OS: Linux - Hardware: x86_64 - Wine version: 11.8 Steps to reproduce: 1. Install Battle.net. 2. Launch Battle.net using Wine. 3. Battle.net crashes immediately. Expected result: Battle.net should start normally. Actual result: Battle.net crashes and exits. Crash log and terminal output are 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.

1 6

[Bug 59833] New: RT Systems FT-2980 Programmer not working
by WineHQ Bugzilla June 15, 2026

June 15, 2026

http://bugs.winehq.org/show_bug.cgi?id=59833 Bug ID: 59833 Summary: RT Systems FT-2980 Programmer not working Product: Wine Version: 11.10 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winelib Assignee: wine-bugs(a)list.winehq.org Reporter: worcester12345(a)yahoo.com Distribution: --- Created attachment 81109 --> http://bugs.winehq.org/attachment.cgi?id=81109 on screen error 1 Some details I left out earlier: Ubuntu 26.04 LTS 64-bit Gnome 50 Wayland Linux 7.0.0-22-generic Intel® Core™ i7-10700 × 16 32.0 GiB RAM WINE 11.10 The nature of the software is it allows the manipulation of data about ham radio stations. It is basically a simple spreadsheet with different values. The other half of it is it communicates through a USB to RJ45 cable to send the config to program the radio. There is another program, called Chirp, which does work through the WINE software, so it is not particular to the type of software use. The trouble is this particular model of Yaesu radio does not work with Chirp, but this RT Systems software is necessary for this particular radio model. I am very suspicious it has something to do with 32 vs. 64 bit. Thank you. https://forum.winehq.org/viewtopic.php?t=42881 -- 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 38

[Bug 59874] New: winmm: infinite playback on waveOutWrite with WHDR_BEGINLOOP|WHDR_ENDLOOP and dwLoops=0
by WineHQ Bugzilla June 15, 2026

June 15, 2026

http://bugs.winehq.org/show_bug.cgi?id=59874 Bug ID: 59874 Summary: winmm: infinite playback on waveOutWrite with WHDR_BEGINLOOP|WHDR_ENDLOOP and dwLoops=0 Product: Wine Version: 11.11 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winmm&mci Assignee: wine-bugs(a)list.winehq.org Reporter: nedsociety(a)gmail.com Distribution: ArchLinux Created attachment 81179 --> http://bugs.winehq.org/attachment.cgi?id=81179 MRE In wine/dlls/winmm/waveform.c, the audio fill callback handles the combined-flag case with two sequential if statements (not if/else if), so both branches execute in the same pass when a buffer carries both flags: ```c if(queue->dwFlags & WHDR_BEGINLOOP){ device->loop_start = device->playing; device->playing = queue->lpNext; device->loop_counter = queue->dwLoops; /* set to 0 */ } if(queue->dwFlags & WHDR_ENDLOOP){ --device->loop_counter; /* underflows 0xFFFFFFFF */ if(device->loop_counter) /* loops back */ device->playing = device->loop_start; else device->loop_start = device->playing = queue->lpNext; } ``` Under `WHDR_BEGINLOOP | WHDR_ENDLOOP && dwLoops=0` the loop counter underflows as noted above, producing infinite playback. Attached MRE (audioloop-mre.c, generated with AI, reviewed myself) generates a do-re-mi tone (C4 -> D4 -> E4, 0.5 s each running once) and submits it via waveOutWrite with the reproducing flags. - build: `winegcc audioloop-mre.c -o audioloop-mre -lwinmm -lm` - expected: prints "WOM_DONE received" after ~1.5 s. - actual: do-re-mi loops continuously, times out after 10 s. A short disclaimer; on MSDN I couldn't find the proper behavior, since it doesn't even define what `dwLoops = 0` means at all. Though I'm certain that it should work as expected based on my prior experience with some concrete apps with which I'm having this trouble. -- 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 59873] New: Build fails with: undefined reference to `gst_video_format_info_component'
by WineHQ Bugzilla June 15, 2026

June 15, 2026

http://bugs.winehq.org/show_bug.cgi?id=59873 Bug ID: 59873 Summary: Build fails with: undefined reference to `gst_video_format_info_component' Product: Wine Version: 11.10 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winegstreamer Assignee: wine-bugs(a)list.winehq.org Reporter: pmenzel+bugs.winehq.org(a)molgen.mpg.de Distribution: --- Wine 11.10, and GStreamer 1.16.1. The build fails with: ``` $ ./configure --prefix=/dev/shm/pmenzel/local/wine-11.11-0 --with-x --with-gnutls --with-opengl --without-vulkan --with-wayland --enable-win64 --enable-archs=x86_64 --disable-tests […] $ make -j100 […] /usr/lib/gcc/x86_64-pc-linux-gnu/12.5.0/../../../../x86_64-pc-linux-gnu/bin/ld: dlls/winegstreamer/wg_transform.o: in function `align_video_info_planes': /pkg/wine-11.10-0/build/wine-11.10/dlls/winegstreamer/wg_transform.c:133:(.text+0xa15): undefined reference to `gst_video_format_info_component' collect2: error: ld returned 1 exit status make: *** [Makefile:163833: dlls/winegstreamer/winegstreamer.so] Error 1 make: *** Waiting for unfinished jobs.... ``` Wine 11.0 builds fine. The versions between were not tested. -- 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 59860] New: When attempting to find symbol "ResolveAddress" from version.dll, code errors out.
by WineHQ Bugzilla June 15, 2026

June 15, 2026

http://bugs.winehq.org/show_bug.cgi?id=59860 Bug ID: 59860 Summary: When attempting to find symbol "ResolveAddress" from version.dll, code errors out. Product: Wine Version: 11.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)list.winehq.org Reporter: netradeepakc(a)gmail.com Distribution: --- Created attachment 81168 --> http://bugs.winehq.org/attachment.cgi?id=81168 A zip file containing both the dll in question and the inspection results of said dll I have attached the version.dll file in question. When code is attempting to read a function int this dll, it thows the following error: ``` Failed to get 'ResolveAddress' address. Process will now close. Last error: 127 ``` The code in question is this, https://github.com/maximegmd/CyberEngineTweaks/blob/master/src/reverse/Relo… line 44 ``` resolveFunc = reinterpret_cast<functionType>(GetProcAddress(handle, functionName)); ``` I have inspected the version.dll file and it does have that function. And this code has been tested on a windows native setup. PFA the version.dll inspection results -- 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 13

[Bug 59824] New: Studio One (versions 6 and 7, Windows x64 builds) crashes immediately when attempting to drag any element on the arrangement timeline.
by WineHQ Bugzilla June 15, 2026

June 15, 2026

http://bugs.winehq.org/show_bug.cgi?id=59824 Bug ID: 59824 Summary: Studio One (versions 6 and 7, Windows x64 builds) crashes immediately when attempting to drag any element on the arrangement timeline. Product: Wine Version: 11.10 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: dwmapi Assignee: wine-bugs(a)list.winehq.org Reporter: ilian.imc(a)gmail.com Distribution: --- Created attachment 81094 --> http://bugs.winehq.org/attachment.cgi?id=81094 minidump from crash Studio One (versions 6 and 7, Windows x64 builds) crashes immediately when attempting to drag any element on the arrangement timeline. The crash is caused by Wine's `dcomp.dll` `device_CreateSurface` stub returning a null/invalid surface, which `cclgui.dll` dereferences during drag visual rendering, resulting in an access violation. ## Application Details - **Application:** PreSonus Studio One (versions 6 and 7) - **Executable:** `Studio One.exe` - **Architecture:** 64-bit (Win x64) --- ## Environment - **Wine version:** wine-staging 11.10 - **Distribution:** Debian GNU/Linux 13 (Trixie) - **Kernel:** 7.0.10+deb13-rt-amd64 (RT kernel) - **Desktop:** KDE Plasma 6, Wayland (XWayland) - **GPU:** AMD Radeon Graphics (RADV RENOIR, APU) - **Mesa/RADV:** 25.0.7 - **DXVK:** v2.3.1 --- ## Steps to Reproduce 1. Install Studio One 7 (Windows build) under Wine 2. Copy `UIAnimation.dll` from a Windows installation into the Wine prefix (`drive_c/windows/system32/`) and set as native, builtin. Without it the app displays "This application requires Windows 10 or later" and refuses to start. This is consistent with `cclgui.dll` using WAM COM class presence as a Windows 10 feature detection check at startup. 3. Launch `Studio One.exe` 4. Open any project containing at least one audio clip on the timeline 5. Click and attempt to drag any clip/element on the arrangement timeline **Result:** GUI freezes immediately, access violation occurs, application crashes and writes a minidump. **Expected:** Element moves with the mouse cursor as on Windows. --- ## Root Cause Analysis (Claude was used) ### Crash address and call chain The crash is an **access violation at `0x100000012d`** (unmapped memory). This address is not inside any loaded module. The call chain reconstructed from the minidump stack (thread `0x208`) is entirely within `cclgui.dll`: ``` kernelbase.dll+0x71e6d (UnhandledExceptionFilter) dbghelp.dll+0x4993 (MiniDumpWriteDump) cclgui.dll+0xc4a10 ← top of actual call chain cclgui.dll+0x4a1d48 cclgui.dll+0x523238 cclgui.dll+0x523190 cclgui.dll+0x523170 cclgui.dll+0x5231f8 cclgui.dll+0x5231c8 ← deepest frame user32.dll+0xc0000 (message dispatch — drag event) ``` ### Register state at crash ``` RIP = ntdll.dll+0xec64 (already in exception handler) RDX = 0x0 ← NULL pointer (2nd function argument) RBP = 0x0 ← NULL pointer RDI = 0xffffffffffffffff RSP = 0x1097a8 (Wine signal stack — very low address) ``` `RDX = NULL` at crash time indicates `cclgui.dll` received a null surface pointer as the second argument to a render call, then attempted to call a virtual method through it, jumping to `0x100000000 + vtable_offset_0x12d` — unmapped memory. ### DirectComposition is the root cause The WINEDEBUG log immediately before the crash shows: ``` 0208:fixme:dcomp:device_CreateSurface iface 0x339EF90, width 1, height 816, format 0x57, alpha_mode 0x1, surface 0x10F668 stub! 0208:fixme:dcomp:visual_SetContent iface 0x3230AE20, content 0000000000000000 semi-stub! ← NULL content 0208:fixme:dcomp:visual_SetClip ... stub! 0208:fixme:dcomp:visual_SetEffect ... stub! 0208:fixme:dcomp:device_Commit ... semi-stub! [crash follows] ``` When a drag begins, Studio One calls `IDCompositionDevice::CreateSurface` to create a drag ghost/shadow visual. Because this is a stub that does not return a real surface object, `IDCompositionVisual::SetContent` is subsequently called with `content = NULL`. `cclgui.dll` then passes this null content pointer into its D2D rendering loop, which dereferences it and access-violations. ### Hard import dependency confirmed Attempting to disable dcomp via DllOverrides produces: ``` 020c:err:module:import_dll Library dcomp.dll (which is needed by cclgui.dll) not found 020c:err:module:import_dll Library cclgui.dll (which is needed by Studio One.exe) not found 020c:err:module:loader_init Importing dlls for Studio One.exe failed, status c0000135 ``` `cclgui.dll` has a **hard static import** on `dcomp.dll`. There is no fallback path. ### Additional context - The `DragSourceHelper2_InitializeFromBitmap` stub fires simultaneously, confirming the drag visual creation path - 1609 `d2d_text_renderer_DrawGlyphRun Ignoring options 0x2` messages flood the log during drag, before and after the crash — the D2D text renderer continues to be called even after the exception is caught, until the second fault (`0x80000003`) terminates the app - `AvSetMmThreadCharacteristicsW("Pro Audio")` is also stubbed (always returns `0x12345678`) but this appears to be a timing coincidence — the MMCSS calls occur at startup and on every thread creation, not exclusively on drag - Tested with VST support completely disabled — no change - Tested with `WINEDLLOVERRIDES="d2d1=b"`, `"dwrite=b"`, virtual desktop mode — no change - The bug affects both Studio One 6 and Studio One 7 — not a regression in 7.2.1 - `UIAnimation.dll` (Windows Animation Manager / WAM) and `dcomp.dll` are used together as an integrated animation pipeline — WAM generates animation curves consumed directly by DirectComposition. The two missing implementations are not independent; fixing dcomp in isolation may not be sufficient if WAM animation primitives are also fed into the dcomp visual tree during drag --- ## Relevant Wine debug output ### Captured with `WINEDEBUG=fixme+dcomp,err+seh` ``` 0208:fixme:dcomp:device_CreateSurface iface 000000000339EF90, width 1, height 816, format 0x57, alpha_mode 0x1, surface 000000000010F668 stub! 0208:fixme:dcomp:visual_SetContent iface 000000003230AE20, content 0000000000000000 semi-stub! 0208:fixme:dcomp:visual_SetClip iface 000000003230AE20, rect 000000000010F670 stub! 0208:fixme:dcomp:visual_SetOffsetY iface 000000003230AE20, offset_y 0.000000 stub! 0208:fixme:dcomp:device_CreateEffectGroup iface 000000000339EF90, effect_group 000000003358F3F0 stub! 0208:fixme:dcomp:visual_SetEffect iface 000000003230AE20, effect 0000000000000000 stub! 0208:fixme:dcomp:device_Commit iface 000000000339EF90 semi-stub! 0208:err:seh:user_callback_handler ignoring exception c0000005 0208:err:seh:user_callback_handler ignoring exception 80000003 ``` --- ## Minidump analysis summary - **Exception code:** `0xc0000005` (ACCESS_VIOLATION) - **Exception address:** `0x100000012d` (not in any loaded module) - **Faulting thread:** `0x208` (GUI/render thread) - **Modules loaded:** 155 total, including `cclgui.dll`, `dcomp.dll`, `d2d1.dll`, `dxgi.dll` (DXVK 2.3.1), `winevulkan.dll`, `wineasio64.dll` - **dcomp.dll** is present and loads successfully — the crash is not a missing DLL but a stub returning null --- ## Related - Similar dcomp stub crash in Dorico (resolved by returning fake S_OK from SetContent/SetRoot/Commit): https://gitlab.winehq.org/wine/wine/-/merge_requests/9839 --- ## Attachments - `Studio One_7_2_1_106594_Win x64_20260605_102312691.dmp` — minidump from crash (246KB) --- *Note: `UIAnimation.dll` used in testing is the native Windows 11 24H2 build copied from a Windows installation.* -- 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 40

[Bug 59862] New: WineHQ Forum says it's the Crossover Forum
by WineHQ Bugzilla June 15, 2026

June 15, 2026

http://bugs.winehq.org/show_bug.cgi?id=59862 Bug ID: 59862 Summary: WineHQ Forum says it's the Crossover Forum Product: WineHQ.org Version: unspecified Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: www-unknown Assignee: wine-bugs(a)list.winehq.org Reporter: dimesio(a)earthlink.net Distribution: --- Created attachment 81174 --> http://bugs.winehq.org/attachment.cgi?id=81174 Screenshot of the forum showing "Crossover" See attached screenshot. Trying to view posts results in a 500 internal 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 4

[Bug 57287] New: Wayland issues
by WineHQ Bugzilla June 15, 2026

June 15, 2026

https://bugs.winehq.org/show_bug.cgi?id=57287 Bug ID: 57287 Summary: Wayland issues Product: Wine Version: 9.19 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winewayland Assignee: wine-bugs(a)winehq.org Reporter: mike(a)fireburn.co.uk Distribution: --- I'm not sure if these issues are in wine or kwin (tested with 6.1.5 & 6.2.0) Apps don't use system toolbars, this can be seen with winecfg or regedit Battle.net doesn't render anything to the screen The systray isn't integrated Launching WoW works, identifies that there are 3 screens but you can't control which is primary correctly, the default screen doesn't have the correct resolutions available, maxes out at 1920x1080 Switching to windowed mode stops any further mouse input to the game screen - keyboard entries are fine This is the first version that things have launched without crashing Everything works fine under x11, is there anything I can do to pinpoint if these are kwin bugs or not? -- 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 58316] New: Wine Wayland window only opens on "monitor 1" and cannot be moved
by WineHQ Bugzilla June 15, 2026

June 15, 2026

http://bugs.winehq.org/show_bug.cgi?id=58316 Bug ID: 58316 Summary: Wine Wayland window only opens on "monitor 1" and cannot be moved Product: Wine Version: 10.4 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winewayland Assignee: wine-bugs(a)winehq.org Reporter: dakky198(a)gmail.com Distribution: --- I've tested this both on Mutter and KWin. When launching a fullscreen game using Wine's Wayland drivers (by utilizing `env -u DISPLAY game.exe` the game launches on my secondary monitor no matter what you try doing. I've determined this is because my graphics drivers have that monitor set as "monitor 1". If I try to move the window to my other monitor, the window snaps back immediately to it's original position. Windowed applications also spawn only on "monitor 1" but allow themselves to be moved to another monitor. However, they retain the resolution/scaling/etc from their original position and do not update to match the new monitor. In my case, they spawn on a 1080p monitor and when moving them to 1440p the window scales to be quite small. -- 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