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

[Bug 56738] New: ODBC stopped working in Wine 9.9, it works fine in 9.8
by WineHQ Bugzilla June 25, 2026

June 25, 2026

https://bugs.winehq.org/show_bug.cgi?id=56738 Bug ID: 56738 Summary: ODBC stopped working in Wine 9.9, it works fine in 9.8 Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: odbc Assignee: wine-bugs(a)winehq.org Reporter: claudius+wine(a)hausnetz.lettenbach.com Distribution: --- Created attachment 76517 --> https://bugs.winehq.org/attachment.cgi?id=76517 WINEDEBUG logs After updating my Arch linux install from wine 9.8-2 to wine 9.9-2 my 32bit applications using multilib unixodbc stopped working. I tried WINEDEBUG=+odbc but could get much relevant output. Most interesting is probabaly this: trace:odbc:SQLAllocEnv Returning 309, EnvironmentHandle 00000000 WINEDLLOVERRIDES="odbc32=b" or "odbc=b" didn't change anything as far as I can tell. If I downgrade the package it immediately starts connecting again. The driver I use is the proprietary SQL Anywhere 17 odbc driver. It works fine using unixodbc with both linux x86_64 and linux 32 bit applications. Is there any way I can provide more relevant information? Attached is a trace of +odbc when it works, and when it doesn't. -- 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 3037] LTspice, Progman: broken internal windows resizing
by WineHQ Bugzilla June 25, 2026

June 25, 2026

http://bugs.winehq.org/show_bug.cgi?id=3037 Alex Henrie <alexhenrie24(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |alexhenrie24(a)gmail.com Resolution|--- |FIXED --- Comment #72 from Alex Henrie <alexhenrie24(a)gmail.com> --- Resolving as fixed based on Edgars's last comment. -- 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 59857] New: ntdll: process heap grows without bound under sustained allocation load; subheaps are never returned to the OS
by WineHQ Bugzilla June 25, 2026

June 25, 2026

http://bugs.winehq.org/show_bug.cgi?id=59857 Bug ID: 59857 Summary: ntdll: process heap grows without bound under sustained allocation load; subheaps are never returned to the OS Product: Wine Version: 11.10 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)list.winehq.org Reporter: nen24t(a)gmail.com Distribution: --- ## Summary A process running an application that issues a high, sustained rate of small/medium heap allocations with mixed lifetimes (e.g. a Direct2D GUI redrawing continuously) shows **unbounded RSS growth that never plateaus and is never returned to the OS**, even though the live working set is stable. Growth stops the instant the redraw load stops, but RSS does not shrink. Observed up to **3.9 GB RSS without crashing**. The growth is **fully attributable to the ntdll heap's `allocate_region()` path** creating subheaps and large blocks that are never decommitted. ## Reproduction - **Wine**: 11.0 (stable), unmodified / vanilla build. Reproduces equally without any third-party D3D layer (builtin wined3d/d3d11/d2d1, OpenGL backend). - **Also reproduces on 11.10 (devel)**: the same unbounded growth is observed. Note that `dlls/ntdll/heap.c` is **functionally identical between 11.0 and 11.10** — the only diff is the removal of one unrelated `#define WIN32_NO_STATUS`; `allocate_region()`, `create_subheap()`, `subheap_decommit()` and the subheap/LFH logic are byte-for-byte unchanged. The mechanism is therefore the same across both releases. - **Workload**: A DAW (REAPER) hosting a Direct2D-based VST plugin GUI (Serum 2) with a continuously animating waveform display (steady ~tens-of-thousands of D2D draw calls per second). Any application doing continuous `ID2D1RenderTarget` drawing with per-frame transient geometry should reproduce; the plugin is just a convenient high-rate driver. - **Observe**: `ps -o rss= -p <pid>` (or `/proc/<pid>/status` `VmRSS`) over a few minutes of active GUI. RSS climbs at a roughly constant rate and does not recover. ## Observed behaviour (measured) - RSS growth rate under active load: **~1.2–1.6 MB/s**, linear, unbounded. - Growth is **100% in anonymous mappings**. Categorising `/proc/<pid>/smaps` over a 2-minute window: `ANON` grows +~190 MB while **every other category is flat** — NVIDIA GL driver mappings flat (~340 MB), glibc `[heap]` flat (~12 MB), file-backed/PE/SO flat. - Per-VMA diff shows the growth concentrated in a **small number of large, growing anonymous regions** (e.g. one region growing to >120 MB), **not** VMA churn (the mapping count is stable). This is the signature of one or a few heaps/arenas committing incrementally. ## Analysis — attribution to the ntdll heap Layered attribution (each step ruled out a candidate): 1. **Not the LFH frontend.** Walking all LFH groups and classifying by live-block count: committed LFH memory **plateaus** (empty-group caching is bounded by the per-bin group cache). Sparse LFH groups dominate over empty ones (~1:9–11 by wasted bytes), but the LFH total does not grow unbounded. LFH-level decommit/pruning has no effect (consistent with the heap immediately reusing freed interior blocks). 2. **Not Win32 `VirtualAlloc`.** Sampling all `VirtualAllocEx`/`MEM_COMMIT` calls: effectively zero committed bytes via this path even at multi-GB RSS. The large allocations bypass it. 3. **Heap-committed breakdown.** Summing committed bytes per heap (all subheaps + large blocks): the **process heap reaches ~770 MiB** (≈597 MiB across ~42 subheaps, max 15 MiB each, plus ~172 MiB across ~66 large blocks) and keeps growing. All other ntdll heaps stay < 4 MiB. 4. **Direct `NtAllocateVirtualMemory` caller.** Attributing each large committed `NtAllocateVirtualMemory` call to its PE return address (read from the syscall frame, resolved offline via `/proc/<pid>/maps` + `nm`/`addr2line`): the dominant driver is **`allocate_region()` in `dlls/ntdll/heap.c`** — ~201 MiB across ~87 calls in a 2-minute window. `allocate_region()` is called from `create_subheap()` and `heap_allocate_large()`. ## Root cause (as understood) The growth is **process-heap fragmentation that is never returned to the OS**, in the **non-LFH range** (mid-size blocks → subheaps) and large blocks: - A subheap holds blocks of mixed size-classes and mixed lifetimes. `subheap_decommit()` only releases trailing free space at the end of a subheap; a subheap that retains even a single long-lived ("residue") block stays fully committed. - Under a workload that allocates many short-lived blocks per frame plus occasional long-lived ones (geometry/shader/glyph objects), subheaps accumulate in a sparse state: low live occupancy, but pinned by residue blocks and therefore never freed. The result is monotonic committed growth with a stable live set. The allocations filling the heap (from caller sampling) are ordinary builtin-DLL allocations: wined3d shader objects (`pixel_shader_init`/`shader_set_function`, ~17–23 KB), d2d1 transient geometry, dwrite glyph/layout structs, d3d11 — nothing unusual; the issue is the heap's retention behaviour, not the callers. This is not D2D1-specific in principle — D2D1/wined3d is just an intense, mixed-lifetime driver that exposes it quickly. ## Context: Windows behaviour On Windows 10+, the Segment Heap (used by default for many processes, and selectable via `HEAP_CREATE_SEGMENT_HEAP` / image-file-execution-options `FrontEndHeapType`) groups allocations into size-class-homogeneous segments and returns empty segments to the OS, so this mixed-lifetime workload does not accumulate the same way. Wine's heap is the classic NT heap (no Segment Heap; `HEAP_CREATE_SEGMENT_HEAP` is not implemented), which never returns interior subheap pages once a subheap is pinned. This is noted only as behavioural context — not as a fix proposal. ## How the data was gathered (for independent reproduction) All instrumentation was diagnostic-only (counters + periodic `ERR()` dumps), removed afterwards: - VMA categorisation and per-VMA growth diff from `/proc/<pid>/smaps`. - Per-heap committed totals (sum over `subheap_list` of `commit_end - base`, plus `large_list`). - `NtAllocateVirtualMemory` caller attribution: aggregate committed bytes by the PE return IP taken from the syscall frame (`rsp`-saved return address, not the syscall stub IP), resolved against the loaded PE modules. Raw per-window measurement tables can be attached on request. ## Related bugs - **Bug 55818** — earlier report of related Direct2D-driven RSS growth. This report adds precise attribution (driven by `allocate_region()` / subheap retention in the *process heap*, not the LFH) plus a vanilla and cross-version confirmation (heap code identical 11.0 ↔ 11.10). - **Bug 57289** — concerns the LFH frontend (`group_release`). The data here indicates the **LFH is NOT the source** of the unbounded growth: LFH committed memory plateaus; the accumulation is one level up, in non-LFH subheaps and large blocks that `allocate_region()` creates and never decommits. Cross-referenced to help refocus the investigation. (Adjust/verify the bug numbers and titles before submitting; also add them to the "See Also" field of the new bug.) ## Severity / impact Long-running sessions of Direct2D-heavy applications (DAWs with plugin GUIs, etc.) hit out-of-memory after a few hours despite a small, stable live working set. Closing the GUI stops growth but does not reclaim; only process exit (which `HeapDestroy`s everything at once) recovers the memory. -- 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 18

[Bug 58325] New: wined3d swapchain use-after-free
by WineHQ Bugzilla June 25, 2026

June 25, 2026

http://bugs.winehq.org/show_bug.cgi?id=58325 Bug ID: 58325 Summary: wined3d swapchain use-after-free Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: d3d Assignee: wine-bugs(a)winehq.org Reporter: yshuiv7(a)gmail.com Distribution: --- Releasing the swapchain brings us to wined3d_swapchain_cleanup, which destroys the front/back buffer textures. Texture destruction is async, happening on the device's command stream. This means these textures can be destroyed way after the swapchain itself. But we did set `texture->swapchain` to `NULL` before queuing their destruction, so that bit is fine. The problem is in texture_resource_unload. Here we try to acquire the context, which goes adapter_gl_acquire_context -> wined3d_context_gl_acquire -> wined3d_context_gl_activate -> wined3d_context_gl_update_window. And here we try to access `context_gl->c.swapchain->win_handle`, which unfortunately points to the swapchain that was just freed. I am unsure what's the fix for this. Do we hold a refcount of the swapchain in the context? Do we clear `context->swapchain` when a swapchain is being freed? Should we release the front/back buffer synchronously? Or something else? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

2 6

[Bug 54695] New: Adobe Premiere Pro CS6: Fails to load msxml3
by WineHQ Bugzilla June 25, 2026

June 25, 2026

https://bugs.winehq.org/show_bug.cgi?id=54695 Bug ID: 54695 Summary: Adobe Premiere Pro CS6: Fails to load msxml3 Product: Wine Version: 8.3 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: msxml3 Assignee: wine-bugs(a)winehq.org Reporter: ericxiang456(a)gmail.com Distribution: --- Created attachment 74204 --> https://bugs.winehq.org/attachment.cgi?id=74204 Terminal output when running Adobe Premiere CS6 When running Adobe Premiere CS6 in Wine with the msxml3 library override to "Native" (installed via Winetricks), Premiere will fail to run because the msxml3 library fails to load (terminal output attached below). When overriding the msxml3 library to "Builtin then native", Premiere will launch, however the user interface will be displayed incorrectly (UI elements in black will appear as white). -- 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 14

[Bug 43493] New: Flight Simulator 2000 duplicated textfield strings: fixme :edit:EDIT_EM_FmtLines soft break enabled, not implemented
by wine-bugs＠winehq.org June 24, 2026

June 24, 2026

https://bugs.winehq.org/show_bug.cgi?id=43493 Bug ID: 43493 Summary: Flight Simulator 2000 duplicated textfield strings: fixme:edit:EDIT_EM_FmtLines soft break enabled, not implemented Product: Wine Version: unspecified Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: an0n1m0(a)hotmail.it Distribution: --- Created attachment 58872 --> https://bugs.winehq.org/attachment.cgi?id=58872 All the scrollable textfields repeat only the first line This bug occurs on all scrollable textfields (maybe the appropriate name is different) in the game. In the terminal, when a menu with the previous textfield is opened, the following appears: fixme:edit:EDIT_EM_FmtLines soft break enabled, not implemented This happens on wine 1.6, wine stable (2.0.2) and wine-devel (2.16). -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

2 2

[Bug 59194] New: CLion 2025.3.1
by WineHQ Bugzilla June 24, 2026

June 24, 2026

http://bugs.winehq.org/show_bug.cgi?id=59194 Bug ID: 59194 Summary: CLion 2025.3.1 Product: Wine Version: 10.20 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: lars_martin4(a)hotmail.com Distribution: --- Internal error java.lang.NullPointerException: Cannot read the array length because "bytes" is null at java.base/java.lang.String.<init>(String.java:1425) at java.base/sun.nio.ch.UnixDomainSockets.localAddress(UnixDomainSockets.java:82) at java.base/sun.nio.ch.SocketChannelImpl.endConnect(SocketChannelImpl.java:824) at java.base/sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:894) at java.base/java.nio.channels.SocketChannel.open(SocketChannel.java:285) at java.base/sun.nio.ch.PipeImpl$Initializer$LoopbackConnector.run(PipeImpl.java:132) at java.base/sun.nio.ch.PipeImpl$Initializer.run(PipeImpl.java:85) at java.base/sun.nio.ch.PipeImpl$Initializer.run(PipeImpl.java:67) at java.base/java.security.AccessController.doPrivileged(AccessController.java:571) at java.base/sun.nio.ch.PipeImpl.<init>(PipeImpl.java:197) at java.base/sun.nio.ch.WEPollSelectorImpl.<init>(WEPollSelectorImpl.java:79) at java.base/sun.nio.ch.WEPollSelectorProvider.openSelector(WEPollSelectorProvider.java:33) at java.base/java.nio.channels.Selector.open(Selector.java:295) at com.intellij.platform.ide.bootstrap.DirectoryLock.tryConnect(DirectoryLock.java:298) at com.intellij.platform.ide.bootstrap.DirectoryLock.lockOrActivate(DirectoryLock.java:164) at com.intellij.platform.ide.bootstrap.StartupUtil.lockSystemDirs(startup.kt:522) at com.intellij.platform.ide.bootstrap.StartupUtil.access$lockSystemDirs(startup.kt:1) at com.intellij.platform.ide.bootstrap.StartupUtil$startApplication$lockSystemDirsJob$1$1.invokeSuspend(startup.kt:122) at com.intellij.platform.ide.bootstrap.StartupUtil$startApplication$lockSystemDirsJob$1$1.invoke(startup.kt) at com.intellij.platform.ide.bootstrap.StartupUtil$startApplication$lockSystemDirsJob$1$1.invoke(startup.kt) at kotlinx.coroutines.intrinsics.UndispatchedKt.startUndispatchedOrReturn(Undispatched.kt:44) at kotlinx.coroutines.BuildersKt__Builders_commonKt.withContext(Builders.common.kt:166) at kotlinx.coroutines.BuildersKt.withContext(Unknown Source) at com.intellij.platform.diagnostic.telemetry.impl.TracerKt.span(tracer.kt:56) at com.intellij.platform.diagnostic.telemetry.impl.TracerKt.span$default(tracer.kt:49) at com.intellij.platform.ide.bootstrap.StartupUtil$startApplication$lockSystemDirsJob$1.invokeSuspend(startup.kt:121) at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:34) at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:100) at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:610) at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runDefaultDispatcherTask(CoroutineScheduler.kt:1194) at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler.kt:906) at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.kt:775) at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:762) ----- JRE: 21.0.9+1-b1163.86 amd64 (JetBrains s.r.o.) C:\Program Files\JetBrains\CLion 2025.3.1\jbr -- 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 57097] New: Keyboard inputs for special characters on non-english keyboards are switched in winewayland
by WineHQ Bugzilla June 24, 2026

June 24, 2026

https://bugs.winehq.org/show_bug.cgi?id=57097 Bug ID: 57097 Summary: Keyboard inputs for special characters on non-english keyboards are switched in winewayland Product: Wine Version: 9.16 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winewayland Assignee: wine-bugs(a)winehq.org Reporter: sutupud(a)yahoo.com Distribution: --- I noticed that if I use a german keyboard layout, the key mapping seems to be off. I'm using kwin_wayland (but also tested on sway, same result). The regular lower keys are ok, but example, ö produces ü, # produces ä, etc. Looking at dlls/winewayland.drv/wayland_keyboard.c, I saw that there are different lookup tables for different languages (scan2vk_qwerty, scan2vk_azerty. scan2vk_qwertz, ...), so my first quess was that something might be switched there. But that doesn't really seem the case, changing it to always use `scan2vk_qwertz ` regardless of `lang` makes it work. I don't really have a very good understanding of how this is supposed to work, but does the appliaction really need to do such a translation? Isn't that already handled by the layout being passed in? At least that would explain why it works when doing no such lookup at all. -- 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 14

[Bug 40548] New: AfterEffects CS6 requires msxml3 to complete
by wine-bugs＠winehq.org June 24, 2026

June 24, 2026

https://bugs.winehq.org/show_bug.cgi?id=40548 Bug ID: 40548 Summary: AfterEffects CS6 requires msxml3 to complete Product: Wine Version: 1.9.7 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: msxml3 Assignee: wine-bugs(a)winehq.org Reporter: robert.munteanu(a)gmail.com Distribution: --- Created attachment 54379 --> https://bugs.winehq.org/attachment.cgi?id=54379 screenshot of installation failure wine 1.9.7, fresh 64-bit prefix, Windows 7 AE CS6 downloaded from https://helpx.adobe.com/x-productkb/policy-pricing/cs6-product-downloads.ht… Installer starts to extract the files, then starts initialising itself. At about 70% it stops with the following message: 'Your installation encountered errors. Installer failed to initialize. This could be due to a missing file'. Wiping the installation and running `winetricks msxml3` before the installer allow the installer to initialise. The terminal output without msxml3: fixme:thread:GetThreadPreferredUILanguages 52, 0x33dfa4, 0x33e014 0x33dfac fixme:console:AttachConsole stub ffffffff fixme:wuapi:update_installer_get_IsBusy fixme:wuapi:update_installer_get_RebootRequiredBeforeInstallation fixme:shell:InitNetworkAddressControl stub fixme:ntdll:NtLockFile I/O completion on lock not implemented yet fixme:heap:RtlSetHeapInformation (nil) 1 (nil) 0 stub fixme:ntdll:NtLockFile I/O completion on lock not implemented yet fixme:nls:GetUserPreferredUILanguages stub: 8 0x33d310 (nil) 0x33d314 err:winsock:WSAIoctl -> _WSAIO(IOC_WS2, 23) request failed with status 0x2733 err:winsock:WSAIoctl -> _WSAIO(IOC_WS2, 23) request failed with status 0x2733 fixme:imm:ImmReleaseContext (0x90084, 0x1f8ef18): stub The terminal output with msxml3 ( until the installed is initialised ): fixme:thread:GetThreadPreferredUILanguages 52, 0x33dfa4, 0x33e014 0x33dfac fixme:console:AttachConsole stub ffffffff fixme:wuapi:update_installer_get_IsBusy fixme:wuapi:update_installer_get_RebootRequiredBeforeInstallation fixme:ntdll:NtLockFile I/O completion on lock not implemented yet fixme:heap:RtlSetHeapInformation (nil) 1 (nil) 0 stub fixme:ntdll:NtLockFile I/O completion on lock not implemented yet fixme:nls:GetUserPreferredUILanguages stub: 8 0x33d310 (nil) 0x33d314 err:winsock:WSAIoctl -> _WSAIO(IOC_WS2, 23) request failed with status 0x2733 err:winsock:WSAIoctl -> _WSAIO(IOC_WS2, 23) request failed with status 0x2733 fixme:heap:RtlSetHeapInformation 0x240000 0 0x23fcc0 4 stub err:ole:COMPOBJ_DllList_Add couldn't load in-process dll L"C:\\windows\\system32\\msxml3.dll" err:ole:create_server class {f5078f32-c551-11d3-89b9-0000f81fe221} not registered fixme:ole:CoGetClassObject CLSCTX_REMOTE_SERVER not supported err:ole:CoGetClassObject no class object {f5078f32-c551-11d3-89b9-0000f81fe221} could be created for context 0x17 err:ole:CoInitializeEx Attempt to change threading model of this apartment from apartment threaded to multi-threaded fixme:ole:CoInitializeSecurity ((nil),-1,(nil),(nil),0,3,(nil),0,(nil)) - stub! fixme:wbemprox:client_security_SetBlanket 0x7c5037a0, 0x30d0fd0, 10, 0, (null), 3, 3, (nil), 0x00000000 fixme:wbemprox:client_security_Release 0x7c5037a0 err:ole:CoInitializeEx Attempt to change threading model of this apartment from apartment threaded to multi-threaded fixme:ole:CoInitializeSecurity ((nil),-1,(nil),(nil),0,3,(nil),0,(nil)) - stub! fixme:wbemprox:client_security_SetBlanket 0x7c5037a0, 0x30812b8, 10, 0, (null), 3, 3, (nil), 0x00000000 fixme:wbemprox:client_security_Release 0x7c5037a0 fixme:imm:ImmReleaseContext (0x90084, 0x4f9e250): stub -- 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 11

[Bug 51155] New: Unable to add security certificates
by WineHQ Bugzilla June 24, 2026

June 24, 2026

https://bugs.winehq.org/show_bug.cgi?id=51155 Bug ID: 51155 Summary: Unable to add security certificates Product: Wine Version: 6.8 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: crypt32 Assignee: wine-bugs(a)winehq.org Reporter: jwbecher(a)gmail.com Distribution: --- Created attachment 70022 --> https://bugs.winehq.org/attachment.cgi?id=70022 output of wine --version and wine control commands Steps to reproduce: 1: `wine control` 2: Internet settings 3: content -> certificates 4: Import 5: Pick your certificate (doesn't matter which one) 6: On the second import screen, try to select which store to save into. You will receive the error `0118:fixme:crypt:CryptFindLocalizedName No name for: L"Trust" - stub` and the selection will stay on "Determined by program" In addition to not being able to select the store, the cert will fail to be added, even though you receive a success message. os: DISTRIB_ID=ManjaroLinux DISTRIB_RELEASE=21.0.4 DISTRIB_CODENAME=Ornara DISTRIB_DESCRIPTION="Manjaro Linux" Wine version: wine-6.7 (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 1