- Wine-Bugs - list.winehq.org

[Bug 59058] New: Age of Mythology crashes on startup
by WineHQ Bugzilla June 19, 2026

June 19, 2026

http://bugs.winehq.org/show_bug.cgi?id=59058 Bug ID: 59058 Summary: Age of Mythology crashes on startup Product: Wine Version: 10.20 Hardware: x86-64 URL: https://archive.org/details/rld-agofmyex_202208 OS: MacOS Status: UNCONFIRMED Severity: normal Priority: P2 Component: d3d Assignee: wine-bugs(a)list.winehq.org Reporter: tobbi.bugs(a)googlemail.com Created attachment 79829 --> http://bugs.winehq.org/attachment.cgi?id=79829 backtrace % ./wine --version wine-10.20 % openssl sha256 rld-agofmyex.iso SHA2-256(rld-agofmyex.iso)= 3b094c078f1b6f683db9a795915ff4b8a3a748f2e4ecd41341144533a12bf4d6 I noticed that Age of Mythology crashes on startup for me. Steps to reproduce: 1. Mount downloaded ISO image. 2. Run Setup.exe using Wine 3. Replace files in the C:/Program Files (x86)/Age of Mythology/ directory with the ones contained in the Crack directory. 4. Run C:/Program Files/Age of Mythology/aomx.exe using wine. Expected results: Age of Mythology runs. Actual results: Age of Mythology crashes on startup. -- 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 8

[Bug 59872] New: In version 11.11, clicks appeared in Red Dead Remastered
by WineHQ Bugzilla June 19, 2026

June 19, 2026

http://bugs.winehq.org/show_bug.cgi?id=59872 Bug ID: 59872 Summary: In version 11.11, clicks appeared in Red Dead Remastered Product: Wine Version: 11.11 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: critical Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: jon9097(a)gmail.com Distribution: --- In version 11.11, clicks appeared in Red Dead Remastered. When I press Esc, clicks are heard and clicks also appeared in the game itself, there were no clicks in version 11.10. The logs are still the same and there is nothing suspicious. Sometimes the clicks are so strong that they interfere with playing. -- 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 12

[Bug 33474] New: Microsoft Project 2007 cannot load Turn On Project Guide on View>Turn On Project Guide. Other functionalities also not available.
by wine-bugs＠winehq.org June 18, 2026

June 18, 2026

http://bugs.winehq.org/show_bug.cgi?id=33474 Bug #: 33474 Summary: Microsoft Project 2007 cannot load Turn On Project Guide on View>Turn On Project Guide. Other functionalities also not available. Product: Wine Version: 1.5.29 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: critical Priority: P1 Component: jscript AssignedTo: wine-bugs(a)winehq.org ReportedBy: matahari_random(a)hushmail.com Classification: Unclassified Created attachment 44309 --> http://bugs.winehq.org/attachment.cgi?id=44309 Desktop Screenshot showing the bug. 1. Open Microsoft Project 2007 2. Click on View > Turn On Project Guide 3. Project Guide does not load due to errors in jscript.dll and srchui.dll Currently running WINE 1.5.29 on a 32-bit distribution of Ubuntu 12.04 LTS logged on Unity3d Desktop. Hardware ACER 4755G with 750GiB Hard Disk, 2GiB RAM, Intel Core i5-2430M Processor. This bug also affected previous WINE Versions. -- 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 8

[Bug 59885] New: Sonic Boom (1995 Klik & Play fangame) locks up in new WoW64 build
by WineHQ Bugzilla June 18, 2026

June 18, 2026

http://bugs.winehq.org/show_bug.cgi?id=59885 Bug ID: 59885 Summary: Sonic Boom (1995 Klik & Play fangame) locks up in new WoW64 build Product: Wine Version: 11.11 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: kernel32 Assignee: wine-bugs(a)list.winehq.org Reporter: gerbilsoft(a)gerbilsoft.com Distribution: --- The fix for bug 59871 allowed the game to get a bit further in starting up. On wine and wine-staging with the "old" WoW64 setup, the game works (with a 32-bit prefix). With the "new" WoW64 setup, it hangs, and the following message prints in the console every 60 seconds: 01bc:err:sync:RtlpWaitForCriticalSection section 7BA07A00 "dlls/krnl386.exe16/syslevel.c: Win16Mutex" wait timed out in thread 01bc, blocked by 01a0, retrying (60 sec) Using standard wine 11.1 and wine-staging 11.11, both with new WoW64 enabled. (Tested the non-WoW64 build as well, as indicated in bug 59871.) OS: Gentoo Linux Kernel: Linux 7.0.10 Desktop: KDE Plasma 6.7 Beta 2 -- 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 59883] New: They Are Billions (GOG) refuses to launch
by WineHQ Bugzilla June 18, 2026

June 18, 2026

http://bugs.winehq.org/show_bug.cgi?id=59883 Bug ID: 59883 Summary: They Are Billions (GOG) refuses to launch Product: Wine Version: 11.11 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: d3d-util Assignee: wine-bugs(a)list.winehq.org Reporter: lingm+winebz(a)posteo.org Distribution: --- Created attachment 81201 --> http://bugs.winehq.org/attachment.cgi?id=81201 they_are_billions_launch_log It shows a generic error message claiming "There is a problem starting They Are Billions [...]". Setting both d3dcompiler_43 AND d3dx9_43 to (native, builtin) via winecfg works around the issue. The relevant lines from the log are: > 0024:fixme:d3dx:d3dx9_effect_compiler_init ID3DXEffectCompiler implementation is only a stub. > 0024:fixme:d3dx:ID3DXEffectCompilerImpl_GetFunctionByName iface 00007F1F0170FD60, name "VShader" stub! > 0024:fixme:d3dx:ID3DXEffectCompilerImpl_CompileShader iface 00007F1F0170FD60, function 0000000000000000, target "vs.3.0", flags 0, shader 00007FFFFE20C820, error_msgs 00007FFFFE20C830, constant_table 0000000000000000 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.

1 4

[Bug 59813] New: Recent LINE messenger don't start with "NO SIGNATURE".
by WineHQ Bugzilla June 18, 2026

June 18, 2026

http://bugs.winehq.org/show_bug.cgi?id=59813 Bug ID: 59813 Summary: Recent LINE messenger don't start with "NO SIGNATURE". Product: Wine Version: 11.10 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: whatisthis.sowhat(a)gmail.com Distribution: --- After updating LINE (Messenger by LINE Corp.) to version 26.1.x (or 26.2.x), LINE makes error with below message dialog: > File: C:\windows\system32\CRYPT32.dll > Reason: NO_SIGNATURE So, after LINE 26.1.x can't use.(26.0.0.3823 and previouses can use). For two months, I reported this issue of v26.1.x to LINE corp. and waited for update with fixes, but recent releases v26.2.x, both v26.2.0.3889 and v26.0.3894 still not fix this issue. See below APPDB for details. https://appdb.winehq.org/objectManager.php?sClass=version&iId=43225&iTestin… Additional information: This issue was discussed at facebook on April of 2026, another software (Sandboxie Plus & Classic) made workarounds for this issue. -Sandboxie Plus & Classic: https://github.com/sandboxie-plus/Sandboxie/ See below discussion (@Facebook) and issue report for Sandboxie. -Discussion at Facebook, April of 2026: https://www.facebook.com/IvonHuan/posts/pfbid0zTZRVhJjyJUsBDJBNM9bPW8wsxB5q… -Issue report and workarounds for recent LINE: https://github.com/sandboxie-plus/Sandboxie/issues/5306 BEST REGARDS, Ohta. -- 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 3

[Bug 55818] New: 32-bit game Dark Age of Camelot slow memory leak leads to crash since WINE 7.4
by WineHQ Bugzilla June 18, 2026

June 18, 2026

https://bugs.winehq.org/show_bug.cgi?id=55818 Bug ID: 55818 Summary: 32-bit game Dark Age of Camelot slow memory leak leads to crash since WINE 7.4 Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: d3d Assignee: wine-bugs(a)winehq.org Reporter: tmwine(a)pertho.net Distribution: --- I've bisected a bug relating to a possible memory leak in wined3d. I've been playing an old game (Dark Age of Camelot) for years now on free servers, but I noticed there is a slow memory leak as it runs. I ran 'top' and watched the RES memory creep up to 1.0 GB and then hit about 1.2-1.3 GB before the game crashes. On WINE 8 this issue seems to persist as well. So I went back and bisected the bug and it occurs between WINE 7.3 and 7.4. In 7.3, I don't get the memory leak and the game plays for hours, but in 7.4 I get the memory leak. I've narrowed it down to this commit: https://gitlab.winehq.org/wine/wine/-/commit/ee12556960e30fc22f276d2de2833e… It might have to do with the code change in the function wined3d_context_gl_destroy_bo that introduced this. Happy to try any patches to test with against latest WINE 8.x tree. Thanks, Tom -- 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 50

[Bug 59857] New: ntdll: process heap grows without bound under sustained allocation load; subheaps are never returned to the OS
by WineHQ Bugzilla June 18, 2026

June 18, 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 17

[Bug 59870] New: [bcrypt] VRChat ProtonEncryptorPlugin.dll crash
by WineHQ Bugzilla June 18, 2026

June 18, 2026

http://bugs.winehq.org/show_bug.cgi?id=59870 Bug ID: 59870 Summary: [bcrypt] VRChat ProtonEncryptorPlugin.dll crash Product: Wine Version: 11.11 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: bcrypt Assignee: wine-bugs(a)list.winehq.org Reporter: teardown(a)inbox.ru Distribution: --- Created attachment 81177 --> http://bugs.winehq.org/attachment.cgi?id=81177 cdb backtrace After bcrypt/ncrypt changed the implementation from tomcrypt to symcrypt, VRChat started crashing on startup. -- 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 9

[Bug 55324] New: AllDup doesn't start in win10 mode: "OS not supported"
by WineHQ Bugzilla June 17, 2026

June 17, 2026

https://bugs.winehq.org/show_bug.cgi?id=55324 Bug ID: 55324 Summary: AllDup doesn't start in win10 mode: "OS not supported" Product: Wine Version: 8.13 Hardware: x86-64 URL: https://www.alldup.info/download/AllDupSetup.zip OS: Linux Status: NEW Keywords: download, patch Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: xerox.xerox2000x(a)gmail.com Distribution: Debian Created attachment 74920 --> https://bugs.winehq.org/attachment.cgi?id=74920 patch for IsOS This program was tried out by someone on the forum. In default windows 10 mode it pops up a messagbox "OS not supported" and exits. The attached patch is enough to fix this bug. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

2 6