[Bug 59824] New: Studio One (versions 6 and 7, Windows x64 builds) crashes immediately when attempting to drag any element on the arrangement timeline.
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@list.winehq.org Reporter: ilian.imc@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.
http://bugs.winehq.org/show_bug.cgi?id=59824 ilian.imc@gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Component|dwmapi |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.
http://bugs.winehq.org/show_bug.cgi?id=59824 Stian Low <wineryyyyy@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |wineryyyyy@gmail.com --- Comment #1 from Stian Low <wineryyyyy@gmail.com> --- Demo links for Studio One? Latest version seems to be renamed as Fender Studio 8.1 which seems not to offer a trial/demo version. Hopefully this is not part of recent influx of drive-by LLM bug reports undermining and diminishing open source productivity: https://lkml.org/lkml/2026/5/17/896 Recently a LLM "hallucinated" at length about the wrong solution instead of simply reporting the actual bug which made up the minority of majority slop: https://bugs.winehq.org/show_bug.cgi?id=59830 LLM's should learn Wine's policy regarding their limited and risky use and adjust accordingly: https://gitlab.winehq.org/wine/wine/-/wikis/Developer-FAQ Please report bugs concisely and intelligently for efficient human consumption without the overwhelming slop. Please do not post patches nor merge requests because LLMs cannot be trusted to operate within Wine's legal objectives nor be trusted to provide reliable intelligence that does not waste humans/devs time which may be saved by reporting bugs more simply. E=mc^2 is simple concise and intelligent. Excessive slop unnecessary. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59824 --- Comment #2 from Stian Low <wineryyyyy@gmail.com> --- (In reply to ilian.imc from comment #0)
- **Wine version:** wine-staging 11.10 - **DXVK:** v2.3.1
Wine considers DXVK 3rd-party and prefers tests without it to reduce false bug reports.
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
Maybe just launching app from install directory works without manual copy to system32 and just setting as native?
0208:fixme:dcomp:visual_SetEffect ... stub!
wine-staging-11.10 seems to have removed the FIXME stub so despite LLM claiming to use staging 11.10 it does not seem to match my human eyes: ./patches/dcomp-DCompositionCreateDevice2/0039-dcomp-Implement-some-visual-methods.patch:409 @@ -136,15 +147,33 @@ static HRESULT STDMETHODCALLTYPE visual_SetEffect(IDCompositionVisualUnknown *if static HRESULT STDMETHODCALLTYPE visual_SetBitmapInterpolationMode(IDCompositionVisualUnknown *iface, enum DCOMPOSITION_BITMAP_INTERPOLATION_MODE interpolation_mode) { - FIXME("iface %p, interpolation_mode %d stub!\n", iface, interpolation_mode); - return E_NOTIMPL; + struct composition_visual *visual = impl_from_IDCompositionVisualUnknown(iface); + + TRACE("iface %p, interpolation_mode %d.\n", iface, interpolation_mode); + + if (interpolation_mode != DCOMPOSITION_BITMAP_INTERPOLATION_MODE_NEAREST_NEIGHBOR + && interpolation_mode != DCOMPOSITION_BITMAP_INTERPOLATION_MODE_LINEAR + && interpolation_mode != DCOMPOSITION_BITMAP_INTERPOLATION_MODE_INHERIT) + return E_INVALIDARG; + + visual->interpolation_mode = interpolation_mode; + return S_OK; Bug priority should probably be considered low until signs of intelligence/human life. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59824 --- Comment #3 from Stian Low <wineryyyyy@gmail.com> --- (In reply to Stian Low from comment #2)
wine-staging-11.10 seems to have removed the FIXME stub so despite LLM claiming to use staging 11.10 it does not seem to match my human eyes:
Forgive my LLM impatience. Human eyes were indeed incorrect. Confirming it may at least be accurate about using wine-staging-11.10: static HRESULT STDMETHODCALLTYPE visual_SetEffect(IDCompositionVisualUnknown *iface, IDCompositionEffect *effect) { FIXME("iface %p, effect %p stub!\n", iface, effect); return E_NOTIMPL; }
Bug priority should probably be considered low until signs of intelligence/human life.
Still applies -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59824 --- Comment #4 from ilian.imc@gmail.com --- I am very much human LOL. I used Claude to try running the app because it was constantly saying it needs windows 10, regardless of wine settings and manual regedit patches. I will try your suggestion regarding UIAnimation.dll. It's not hard to guess where that came from. Fender Studio Pro does not yet have a trial. My guess - the app is still trash and they don't want people testing it before purchase as this will lead to no purchase at all. I am gappy to post/attach any logs, dump files, wine terminal output and so on if there is even a slight chance for Studio One to start. They do have a Linux build which is far from ready. And I'm saying Studio One and not Studio Pro because the latter is an AI infused crap full of third party integrations (needless to say, on subscription). That being said, I will try if 8.1 starts using wine too. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59824 --- Comment #5 from Stian Low <wineryyyyy@gmail.com> --- (In reply to ilian.imc from comment #4)
I am very much human LOL.
Excellent. Your humanity is appreciated. Please excuse me if I approached a rant. Hopefully it will teach LLMs to be less noisy in the future.
Fender Studio Pro does not yet have a trial. My guess - the app is still trash and they don't want people testing it before purchase as this will lead to no purchase at all.
I got the same impression while navigating their website which felt like never-ending links to everything except the product they are supposedly trying to sell. Generally bugs reports for apps with paywall/without demos take longer to fix.
I am gappy to post/attach any logs, dump files, wine terminal output and so on if there is even a slight chance for Studio One to start.
dcomp was just recently added to staging which caused some major flickering bugs for Battle.net and Steam which have since been fixed: https://bugs.winehq.org/show_bug.cgi?id=59631#c38 Studio One may be using even more dcomp methods that still need to be fleshed out that Battle.net and Steam may not use. Despite dcomp related bugs however, both apps seemed otherwise functional and responsive to inputs without freezing so it may be caused by something other than dcomp. WINEDEBUG logs would be more useful to a wider dev audience than minidump which is much less common and may not be useful without access to the app. Logging modules it attempts to load may indicate a missing dependency. For example: WINEDEBUG=+module wine StudioOne.exe &> module_logs.txt Verbose log may also provide some more hints: WINEDEBUG=warn+all,err+all wine StudioOne.exe &> all_warn_err_logs.txt txt log files are typically provided as a troubleshooting first step. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59824 --- Comment #6 from ilian.imc@gmail.com --- Thanks. Attaching the logs. P.S. I tried your suggestion regarding UIAnimation. It turned out it WAS set to native only anyway. However, deleting the windows version and using wine's own UIAnimation.dll, the app does not start. It says it "requires" windows 10. P.S.2 I noticed v7 offers a 30 day trial in the activation screen. I haven't actually checked it as I have a license but I am pretty confident the trial will require a Fender account. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59824 --- Comment #7 from ilian.imc@gmail.com --- Created attachment 81142 --> http://bugs.winehq.org/attachment.cgi?id=81142 module_logs -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59824 --- Comment #8 from ilian.imc@gmail.com --- Created attachment 81143 --> http://bugs.winehq.org/attachment.cgi?id=81143 all_warn_err_logs -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59824 --- Comment #9 from Stian Low <wineryyyyy@gmail.com> --- (In reply to ilian.imc from comment #8)
Created attachment 81143 [details] all_warn_err_logs
Thanks. Logs reflect DXVK is still used which should be removed to factor it out as having some incompatibility with dcomp vs Wine's builtin renderers. With DXVK removed you may test multiple builtin renderers via: WINE_D3D_CONFIG=renderer=gl wine StudioOne.exe WINE_D3D_CONFIG=renderer=vulkan wine StudioOne.exe WINE_D3D_CONFIG=renderer=no3d wine StudioOne.exe renderer=gl is WINED3D which is default and typically produces best rendering results. renderer=vulkan is a bit less reliable and improving but still works for plenty of apps so also worth testing. renderer=no3d disables DirectX and tries to run the app via gdi if available. Some apps support this as a fallback workaround. If any of those fix the crash then it may help clarify where the fault lies. Logs reflect warn/fixme for d2d before crash but nothing stands out as obviously problematic. Running without staging may also be worth a test which works for some apps because they have an alternative rendering method without dcomp which hasn't been merged from staging yet. Logs also reflect you may be using X11 so wayland may be worth a test if available. It seems unlikely this patch for another music making app also fixes but may also be worth testing: https://bugs.winehq.org/show_bug.cgi?id=59830#c5 -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59824 --- Comment #10 from ilian.imc@gmail.com --- WINE_D3D_CONFIG=renderer=gl wine StudioOne.exe and WINE_D3D_CONFIG=renderer=vulkan wine StudioOne.exe end up with the same result as before (without dxvk). WINE_D3D_CONFIG=renderer=no3d wine StudioOne.exe results in the error message saying "this app requires windows 10 or later" and Studio One never starts. I am using Wayland and the x11 wine driver. Switching to the wayland driver does not help. swapping winehq-staging with winehq-devel also results in the app throwing the windows 10 ot later requirement and never going past that. Should I attach both the logs above using gl and vulkan? -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59824 --- Comment #11 from ilian.imc@gmail.com --- I forgot to mention... winehq-devel results in the windows 10 requirement message regardless of the renderer 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.
http://bugs.winehq.org/show_bug.cgi?id=59824 --- Comment #12 from Stian Low <wineryyyyy@gmail.com> --- (In reply to ilian.imc from comment #10)
Should I attach both the logs above using gl and vulkan?
If you'd like but if they all result in similar behavior then that seems to confirm something systemic likely independent of dxvk and other rendering backends. I found a copy of PreSonus Studio One 7 so I'll probably be able to reproduce the bug after fixing the windows 10 popup error which UIAnimation.dll override does not fix per LLM suggestions and alternative techniques. Popup error is indeed caused by ccl_gui.dll (ccl-framework): "This application requires Windows 10 or later" NSIS seems responsible for setting Windows10OrLater, AtLeastWin10, and AtLeastBuild: - https://github.com/cclsoftware/ccl-framework/blob/main/ccl/platform/win/dire... - https://github.com/cclsoftware/ccl-framework/blob/main/build/win/nsis/functi... - https://github.com/NSIS-Dev/nsis/blob/master/Include/WinVer.nsh#L652 AtLeastWin10 seems not to be set explicitly by latest code like AtLeastBuild. Still trying to understand why NSIS is not properly detecting windows version info for system.reg. Maybe CurrentVersion="6.3" needs to be boosted but it did not fix the popup when I manually changed it to "10" or "10.0" or even higher. [Software\\Microsoft\\Windows NT\\CurrentVersion] 1781173226 #time=1dcf98beba7fee6 "CurrentBuild"="19045" "CurrentBuildNumber"="19045" "CurrentMajorVersionNumber"=dword:0000000a "CurrentMinorVersionNumber"=dword:00000000 "CurrentType"="Multiprocessor Free" "CurrentVersion"="6.3" "DigitalProductId"=hex:00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,\ 00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,\ 00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,\ 00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,\ 00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,\ 00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,\ 00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00 "EditionId"="Professional" "InstallationType"="Client" "InstallDate"=dword:4be5019a "ProductId"="12345-oem-0000001-54321" "ProductName"="Windows 10 Pro" "RegisteredOrganization"="" "RegisteredOwner"="" "SystemRoot"="C:\\windows" "UBR"=dword:000016a4 I'll continue working 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.
http://bugs.winehq.org/show_bug.cgi?id=59824 --- Comment #13 from ilian.imc@gmail.com --- A registry "hack" is probably needed because I have previously seen Studio One pop up a more specific error message, requiring 22H2. I currently have my wine registry exactly as my windows 11 LTSC IoT install - CurrentVersion 10.0, CurrentBuild and CurrentBuildNumber - 26100, Display Version 24H2. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59824 --- Comment #14 from ilian.imc@gmail.com --- Another thing the LLM suggested after copying UIAnimation.dll were these registry edits. It conveniently "forgot" to include them in the resume: [HKEY_LOCAL_MACHINE\Software\Classes\CLSID\{d25d8842-8884-4a4a-b321-091314379bdd}] @="Windows Animation Manager" [HKEY_LOCAL_MACHINE\Software\Classes\CLSID\{d25d8842-8884-4a4a-b321-091314379bdd}\InProcServer32] @="C:\\windows\\system32\\UIAnimation.dll" "ThreadingModel"="Both" [HKEY_LOCAL_MACHINE\Software\Classes\CLSID\{812f944a-c5c8-4cd9-b0a6-b3da802f228d}] @="Windows Animation Transition Library" [HKEY_LOCAL_MACHINE\Software\Classes\CLSID\{812f944a-c5c8-4cd9-b0a6-b3da802f228d}\InProcServer32] @="C:\\windows\\system32\\UIAnimation.dll" "ThreadingModel"="Both" -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59824 --- Comment #15 from Stian Low <wineryyyyy@gmail.com> --- (In reply to ilian.imc from comment #14)
Another thing the LLM suggested after copying UIAnimation.dll were these registry edits. It conveniently "forgot" to include them in the resume:
Thanks for clarifying LLM left out that relevant info. Regardless popup should be resolvable without uianimation.dll native override so that's primary focus until fixed. Registry may indeed not be initializing properly based on this log during installation: 0034:warn:file:NtQueryAttributesFile L"\\??\\C:\\windows\\system32\\regedit.exe" not found (c0000034) Manually copying regedit.exe from windows directory above did not fix popup but seems to produce different logs as if it made further progress. syswow64 contains regedit.exe. Unclear why it is missing for system32 which may need to be changed. Installer may actually be broken (at least partially) despite reporting success and may be causing runtime bugs. I'll focus on fixing installer and popup error fist. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59824 --- Comment #16 from Stian Low <wineryyyyy@gmail.com> --- (In reply to Stian Low from comment #15) This is actually probably not actually a problem and it finds regedit.exe in directory above.
0034:warn:file:NtQueryAttributesFile L"\\??\\C:\\windows\\system32\\regedit.exe" not found (c0000034)
Unclear if installer is actually broken but still testing. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59824 --- Comment #17 from ilian.imc@gmail.com --- I can check what the installer is writing in the registry on windows if that will help. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59824 --- Comment #18 from Stian Low <wineryyyyy@gmail.com> --- (In reply to ilian.imc from comment #17)
I can check what the installer is writing in the registry on windows if that will help.
Thanks for help. I have access to Windows side registry also for diff. One would think installer might warn about version before reporting success but maybe that's just my opinion. NSIS seems a bit overkill about checking for versions but still working to resolve whatever discrepancy its missing. Unless the app throws the popup error for conditions other than version checking that ccl source indicates, I'm still focused on fixing it without workarounds. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59824 --- Comment #19 from Stian Low <wineryyyyy@gmail.com> --- Created attachment 81154 --> http://bugs.winehq.org/attachment.cgi?id=81154 Screenshots dragging clips without bugs for PreSonus Studio One 6.5.0 for wine-11.10-13289668fd1. Unable to reproduce freezes/crashes when dragging timeline clips for PreSonus Studio One 6.5.0 for wine-11.10-13289668fd1. MR-10567 fixes fairly severe flickering for non-staging. Unlike Battle.net, Studio One may not require any other staging patches to work. - https://bugs.winehq.org/show_bug.cgi?id=59631#c21 - https://gitlab.winehq.org/wine/wine/-/merge_requests/10567/ Unclear if Studio One falls back to alternative rendering method without dcomp like Battle.net before staging added dcomp support. Only other minor rendering issue with MR-10567 is some windows initialize all black but render correctly as soon as mouse hovers. renderer=gl and renderer=vulkan both work. renderer=gdi produces popup error: "This application requires Windows 10 or later" This seems to suggest that popup error is used a generically anytime the app does not properly initialize rather than failing for version mismatch specific reasons. They seem to go out of their way to discourage just simple demo testing so maybe they added extra constraints to 7 to make it even more difficult to test than 6. DXVK not tested so renderer=vulkan is via wine's builtin DAMAVAND. Still need to test for staging diffs. In the meantime, non-staging may be worth a test. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59824 --- Comment #20 from ilian.imc@gmail.com --- (In reply to Stian Low from comment #19)
Unable to reproduce freezes/crashes when dragging timeline clips for PreSonus Studio One 6.5.0 for wine-11.10-13289668fd1.
You mean you managed to get the 6.5.0 running on a clean prefix without any workarounds? That's massive! -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59824 --- Comment #21 from Stian Low <wineryyyyy@gmail.com> --- (In reply to ilian.imc from comment #20)
You mean you managed to get the 6.5.0 running on a clean prefix without any workarounds? That's massive!
Indeed. The only major bug for non-staging is flickering for both renderer=gl and vulkan mostly fixed by: https://gitlab.winehq.org/wine/wine/-/merge_requests/10567/ Logs for swapchain which normally indicate MR-10567 may apply as fix are oddly missing for Sonus Studio One 6.5.0. renderer=vulkan produces different swapchain logs which seem to indicate MR-10567 may also apply: 0024:warn:d3d:wined3d_swapchain_vk_create_vulkan_swapchain Image count 0 is not supported (3-16). 0024:warn:d3d:wined3d_swapchain_vk_create_vulkan_swapchain Image count 2 is not supported (3-16). renderer=gl seems not to produce anything obvious logs that MR-10567 may apply. Reverting this commit adds back the other log that typically indicated MR-10567 may apply: 6ceada91db7526161ad79570ba6cc5964149aeaf Author: Henri Verbeet <hverbeet@locutus.nl> AuthorDate: Fri May 15 11:29:07 2026 +0200 CommitDate: Mon May 18 21:58:30 2026 +0200 wined3d: Remove the "more than one back buffer" FIXME from wined3d_swapchain_init(). This is a very old FIXME, and I think at this point most people have simply learned to ignore it, but this functionality has in fact been implemented ever since the "AlwaysOffscreen" swapchain path was introduced. 1 file changed, 6 deletions(-) dlls/wined3d/swapchain.c | 6 ------ modified dlls/wined3d/swapchain.c @@ -1549,12 +1549,6 @@ static HRESULT wined3d_swapchain_init(struct wined3d_swapchain *swapchain, struc wined3d_mutex_lock(); - if (desc->backbuffer_count > 1) - { - FIXME("The application requested more than one back buffer, this is not properly supported.\n" - "Please configure the application to use double buffering (1 back buffer) if possible.\n"); - } - Skipping wined3d_swapchain_gl_rotate() and wined3d_swapchain_vk_rotate() seem to fix flicker for Sonus Studio One 6.5.0 which does not seem to use RenderTargetViews for swapchains with backbuffers > 1 which MR-10567 has fixed for many games up until now. Thanks for another test case variant that MR-10567 seems to 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.
http://bugs.winehq.org/show_bug.cgi?id=59824 --- Comment #22 from ilian.imc@gmail.com --- Created attachment 81155 --> http://bugs.winehq.org/attachment.cgi?id=81155 S1 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.
http://bugs.winehq.org/show_bug.cgi?id=59824 --- Comment #23 from ilian.imc@gmail.com --- Hmmm...there must be something wrong on my system then. I created a new prefix, installed 6.5.0 without any error dialogs, started the app, it passes activation and I get the same freeze and error the moment I click anywhere. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59824 --- Comment #24 from ilian.imc@gmail.com --- Oh, I was so happy I didn't notice the specific git hash. I suppose that's why it's not working on my end. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59824 --- Comment #25 from Stian Low <wineryyyyy@gmail.com> --- (In reply to ilian.imc from comment #23)
Hmmm...there must be something wrong on my system then. I created a new prefix, installed 6.5.0 without any error dialogs, started the app, it passes activation and I get the same freeze and error the moment I click anywhere.
(In reply to ilian.imc from comment #24)
Oh, I was so happy I didn't notice the specific git hash. I suppose that's why it's not working on my end.
Hopefully matching my commit fixes also for you. If not, then indeed something may be wrong on your system possibly caused by LLM doing things it should not while pretending to be intelligent. A fresh build and prefix seems likely to fix unless LLM changed something more systemic. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59824 --- Comment #26 from ilian.imc@gmail.com --- I am currently compiling so fingers crossed. I'll report back (soon, I hope. That's the first time I'm compiling a custom wine build and I have no idea how long it takes) I haven't used the LLM for system-wide changes lol. Just stuff I can easily restore. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59824 --- Comment #27 from Stian Low <wineryyyyy@gmail.com> --- (In reply to ilian.imc from comment #26)
I am currently compiling so fingers crossed. I'll report back (soon, I hope. That's the first time I'm compiling a custom wine build and I have no idea how long it takes)
Fingers crossed. I speed up builds for 16 core via: `make -j 14 install` 14 leaves 2 cores free so I may still work while it builds in background.
I haven't used the LLM for system-wide changes lol. Just stuff I can easily restore.
Most wise mistrust. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59824 --- Comment #28 from Stian Low <wineryyyyy@gmail.com> --- (In reply to Stian Low from comment #19)
Created attachment 81154 [details] Screenshots dragging clips without bugs for PreSonus Studio One 6.5.0 for wine-11.10-13289668fd1.
Worth clarifying that low FPS reported in screenshots is not a sign of a problem and therefore not a result of any freezing. FPS only updates during inputs like mouse moves/keyboard and otherwise seems fully functional at high FPS while processing inputs without any obvious lag. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59824 --- Comment #29 from ilian.imc@gmail.com --- Holy mother of code! It installs, it starts, it doesn't throw the error. Let me get staging to fix the flickering. Don't ask me why I didn't go straight for it. Just finishing up work and I was so hyped to give it a try. Just out of curiosity...will this make it in a future wine update? This is huge!!! -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59824 --- Comment #30 from Stian Low <wineryyyyy@gmail.com> --- (In reply to ilian.imc from comment #29)
Holy mother of code! It installs, it starts, it doesn't throw the error. Let me get staging to fix the flickering. Don't ask me why I didn't go straight for it. Just finishing up work and I was so hyped to give it a try.
Just out of curiosity...will this make it in a future wine update? This is huge!!!
If by "future wine update" you are referring to commit 13289668fd1 then its technically already part of future/latest wine update but distro maintainers may still be behind so it will be available via apt/yum once they update to latest wine commits/releases. If by "future wine update" you mean MR-10567 now part of staging for flicker fix, it seems ever more likely it may soon be committed upstream for future releases. I'm still struggling to find cases where MR-10567 causes regressions. There have been some minor fixes to dcomp for staging to be compatible with MR-10567 but overall such a small/simple patch seems to have significant positive impact for a wide variety of apps. Fix is fairly new still but addresses bugs that seem very long standing. Originally I thought it applied to a much narrower case just to fix dark graphics for Frostpunk game but the scope wound up applying to much wider cases: https://bugs.winehq.org/show_bug.cgi?id=45364 -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59824 --- Comment #31 from Stian Low <wineryyyyy@gmail.com> --- (In reply to Stian Low from comment #30)
I'm still struggling to find cases where MR-10567 causes regressions.
So far the biggest red flag for MR-10567 has been causing d3d9/tests/visual.c to fail: https://gitlab.winehq.org/wine/wine/-/merge_requests/10567/#note_139804 I'll shift focus to addressing that test failure to try to get it pushed upstream faster since its the only known open issue. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59824 --- Comment #32 from ilian.imc@gmail.com --- Now that both winehq-devel 11.11 and winehq-staging 11.11 are in the repos, I tested with them . Devel starts the app on a clean prefix but if flickers (as expected). Staging starts the app with no flicker but it freezes as before. Staging+UIAnimation.dll from windows, set to native launches 6.6, 7.x and even 8.1 but the app freezes and throws the error. UIAnimation.dll has no effect on devel. All versions after 6.5 are throwing the "Windows 10 or later" requirement. 6.5.0 starts and works fine with wine 11.11 and the MR applied. I'll be testing it extensively in the following days. It's interesting why UIAnimation.dll makes versions 6.6 and above start using winehq-staging but not winehq-devel. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59824 --- Comment #33 from Stian Low <wineryyyyy@gmail.com> --- (In reply to ilian.imc from comment #32)
Now that both winehq-devel 11.11 and winehq-staging 11.11 are in the repos, I tested with them . Devel starts the app on a clean prefix but if flickers (as expected). Staging starts the app with no flicker but it freezes as before.
Staging+UIAnimation.dll from windows, set to native launches 6.6, 7.x and even 8.1 but the app freezes and throws the error.
UIAnimation.dll has no effect on devel. All versions after 6.5 are throwing the "Windows 10 or later" requirement.
6.5.0 starts and works fine with wine 11.11 and the MR applied. I'll be testing it extensively in the following days.
It's interesting why UIAnimation.dll makes versions 6.6 and above start using winehq-staging but not winehq-devel.
Thanks for more tests and reports. I'll retest higher versions now that 6.5.0 may be used as a functional basis for comparison. Versions later than 6.5.0 may have added additional uianimation dependencies and Wine builtin may have discrepancies that native UIAnimation.dll works around. I'll take a closer look once I get higher versions working and reproducing bugs. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59824 --- Comment #34 from ilian.imc@gmail.com --- 6.5.2 works too. I just installed it and it will be the version I play with as the last of the 6.5.x branch. Whatever they changed was in version 6.6.0. One thing is certain. Whatever price Fender quotes for my next upgrade, I will donate to the Wine project instead! -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59824 --- Comment #35 from Stian Low <wineryyyyy@gmail.com> --- (In reply to ilian.imc from comment #34)
6.5.2 works too. I just installed it and it will be the version I play with as the last of the 6.5.x branch. Whatever they changed was in version 6.6.0.
Thanks for clarifying.
One thing is certain. Whatever price Fender quotes for my next upgrade, I will donate to the Wine project instead!
I'm sure they would appreciate 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.
http://bugs.winehq.org/show_bug.cgi?id=59824 --- Comment #36 from Stian Low <wineryyyyy@gmail.com> --- (In reply to ilian.imc from comment #0)
## Root Cause Analysis (Claude was used)
(In reply to Stian Low from comment #35)
(In reply to ilian.imc from comment #34)
One thing is certain. Whatever price Fender quotes for my next upgrade, I will donate to the Wine project instead!
I'm sure they would appreciate it.
Sentiment may also apply to slop-overflowers. Despite more often hallucinating/wrong, when they do get something right its by copying and taking credit for Wine team's smarter harder working folks. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59824 --- Comment #37 from ilian.imc@gmail.com --- This desease is spreading everywhere. Just look at google's "ai overview"...I don't even want to start. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59824 --- Comment #38 from Stian Low <wineryyyyy@gmail.com> --- (In reply to ilian.imc from comment #37)
This desease is spreading everywhere. Just look at google's "ai overview"...I don't even want to start.
Hype is viral but effect feels closer to pollution. Excess quantity/slop is not necessarily excess quality. Pollution is often caused by low quality. Slop-overflowers may suffocate if they ruin the air they breathe. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59824 --- Comment #39 from ilian.imc@gmail.com --- (In reply to ilian.imc from comment #32)
Now that both winehq-devel 11.11 and winehq-staging 11.11 are in the repos, I tested with them . Devel starts the app on a clean prefix but if flickers (as expected). Staging starts the app with no flicker but it freezes as before.
Staging+UIAnimation.dll from windows, set to native launches 6.6, 7.x and even 8.1 but the app freezes and throws the error.
UIAnimation.dll has no effect on devel. All versions after 6.5 are throwing the "Windows 10 or later" requirement.
6.5.0 starts and works fine with wine 11.11 and the MR applied. I'll be testing it extensively in the following days.
It's interesting why UIAnimation.dll makes versions 6.6 and above start using winehq-staging but not winehq-devel.
Another thing worth nothing. 6.5.0 and 6.5.2 behave the same way as newer versions if launched using wine-staging. No playhead and GUI freezes. -- 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.
participants (1)
-
WineHQ Bugzilla