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

[Bug 37355] New: Tages Protection v5.x needs ntoskrnl 'MmMapLockedPagesSpecifyCache' implementation
by wine-bugs＠winehq.org Sept. 3, 2026

Sept. 3, 2026

https://bugs.winehq.org/show_bug.cgi?id=37355 Bug ID: 37355 Summary: Tages Protection v5.x needs ntoskrnl 'MmMapLockedPagesSpecifyCache' implementation Product: Wine Version: 1.7.27 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: ntoskrnl Assignee: wine-bugs(a)winehq.org Reporter: focht(a)gmx.net Hello folks, reported here: https://github.com/compholio/wine-compholio/issues/80 Michael Müller from FDS team: --- quote --- Sadly this is not enough to make the Tages copy protection happy. The issue you are now running into is: fixme:ntoskrnl:MmMapLockedPagesSpecifyCache (0x111988, 0, 1, (nil), 0, 32): stub The MmMapLockedPagesSpecifyCache command is used to map memory of a process into the kernel, so that a kernel driver can write / read it. This is necessary since the kernel does not share the same address space as the process. The problem is that this command is a stub and always returns 0 as mapped address. The Tages protection does not check for NULL pointers and tries to write to the address resulting in: wine: Unhandled page fault on write access to 0x00000000 at address 0x57fe27 (thread 0018), starting debugger... The problem is that there is no way to properly implement this on Linux since there is no way to simply map the memory of a different process if you are not inside the kernel. Since wine is no kernel module it can only use memory of different processes, when they explicitly create it as shared memory block. Sadly you can not declare a memory block as shared after it was allocated, so this does not help implementing this command. Anyway in the case of the Tages protection we have some luck since it seems like the process is paused (I think it was waiting for the response of the DeviceIoControl function) while the memory is changed by the windows kernel driver. This allows us to emulate the mapping of the memory by using ReadProcessMemory and WriteProcessMemory. I wrote some hack to implement this, but this only prevented the crash and made the application to exit silently. I either made a mistake in my hack or there is still something else which prevents it from working. --- quote --- Regards -- 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 57

[Bug 60262] New: winemac.drv: macOS title bar drawn on frameless windows that reclaim the caption via WM_NCCALCSIZE, displacing all mouse input
by WineHQ Bugzilla Sept. 2, 2026

Sept. 2, 2026

http://bugs.winehq.org/show_bug.cgi?id=60262 Bug ID: 60262 Summary: winemac.drv: macOS title bar drawn on frameless windows that reclaim the caption via WM_NCCALCSIZE, displacing all mouse input Product: Wine Version: 11.16 Hardware: x86-64 OS: MacOS Status: UNCONFIRMED Severity: normal Priority: P2 Component: winemac.drv Assignee: wine-bugs(a)list.winehq.org Reporter: winebugs(a)protonmail.ch Target Milestone: --- winemac.drv draws a macOS title bar on a window that reclaimed its caption area via `WM_NCCALCSIZE`, and the resulting geometry displaces all mouse input by the caption height. ## Reproducer 60 lines, no game or third-party app required: https://github.com/macgameport/cities-skylines-2-macos/blob/main/scripts/fr… ## Steps to reproduce 1. Build the attached 60-line reproducer: `x86_64-w64-mingw32-gcc -O2 -o frameless-repro.exe frameless-window-repro.c -lgdi32` 2. `wine frameless-repro.exe` It creates a `WS_OVERLAPPEDWINDOW` and, in `WM_NCCALCSIZE`, reserves a 5px border on the left, right and bottom and **zero** on the top — the frameless-but-resizable pattern used by Electron and CEF apps. `SWP_FRAMECHANGED` is applied after creation so the change takes effect. ## Expected `dx=5 dy=0` (border kept, caption reclaimed) and **no** title bar — the application declined the caption and draws its own chrome there. ## Actual The window reports `dx=5 dy=0` as expected, and winemac draws a macOS title bar with traffic lights anyway. Applications that draw their own title bar therefore show **two**. The knock-on effect is worse than cosmetic: the Cocoa content view ends up ~28pt shorter than the client rect Win32 reports, so `ScreenToClient` subtracts a window origin ~56px above where the NSWindow actually is. **Every control hit-tests below the visible pointer** — you must hold the cursor above a button to activate it. Measured on a real application (the Paradox launcher shipped with Cities: Skylines II): ``` Win32 window rect : 228,346 px = 114,173 pt Cocoa window drawn at : 232,402 px = 116,201 pt -> 56 px = 28 pt apart Cocoa window 1279 x 674 pt Cocoa content view 1279 x 642 pt -> a 32 pt title bar that should not exist Win32 client rect 1279 x 669.5 pt -> widths identical, heights 27.5 pt apart ``` Not a pointer-mapping bug — `GetCursorPos` agrees with macOS `CGEvent` to within truncation (`dx -0.4, dy -0.4 px`, pointer verified stationary by bracketing the reads). ## Analysis Two functions answer "does this window have a title bar" from different inputs, and nothing reconciles them: | caller | function | input | |---|---|---| | `macdrv_GetWindowStyleMasks` — win32u asks how much non-client space the window rect reserves | `get_window_features_for_style()` | **style bits only** | | window creation / style change — the actual Cocoa decoration | `get_cocoa_window_features()` | style bits **+ `data->rects`** | `get_cocoa_window_features()` already carries an evidence-based override — `EqualRect(&data->rects.window, &data->rects.visible)` — so the incompleteness of the style test was clearly known. But it never consults `rects.client`, which is precisely the record of what `WM_NCCALCSIZE` did, and `struct window_rects` carries it already. **That guard is also why this is not more widely noticed.** An application that reclaims the *entire* window rect gets `dx=0 dy=0`, `window == visible` fires, and the window is left undecorated — Steam's own client does exactly this and is unaffected. The bug needs a **border with no caption**, which is the more common Electron shape. ## What does not fix it Suppressing `title_bar` in `get_cocoa_window_features()` when `client.top == window.top` removes the doubled chrome but **not the offset**: `GetWindowStyleMasks` still reports caption masks, win32u keeps reserving the space, and the NSWindow simply moves down by it. Measured content-view vs client: 27.5pt apart before and after. A fix has to make both answers share one source of truth, and the ordering is the hard part — `GetWindowStyleMasks` is called *while* win32u is computing the very rects it would need to consult. ## Disclosure This was investigated with heavy AI assistance. I am filing a bug report rather than a patch, and the reproducer is deliberately small enough to confirm or dismiss in two minutes without taking my analysis on trust. -- 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 30523] New: Jupiter crashes when trying to fill online tax declarations
by wine-bugs＠winehq.org Sept. 2, 2026

Sept. 2, 2026

http://bugs.winehq.org/show_bug.cgi?id=30523 Bug #: 30523 Summary: Jupiter crashes when trying to fill online tax declarations Product: Wine Version: 1.5.2 Platform: x86 URL: http://pity.elfin.pl/pliki/Jupiter/Jupiter2011/std/1.0 .5.6/Jupiter2011_std_1.0.5.exe OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: washuu(a)eastnews.com.pl Classification: Unclassified Created attachment 39930 --> http://bugs.winehq.org/attachment.cgi?id=39930 sample data file with bogus numbers Jupiter is free, downloadable program for calculating taxes in Poland, it's quite popular. I found using it under Wine quite uncomfortable, because of a few bugs. Here is one of them: - install the application. In my case it went without any glitches. - run the application. - open the attached sample data file, using menu "Plik" ("file") and "Otworz" ("open"). - wait a few seconds to open data file, when it is loaded you see some text in the middle, starting with "dziekujemy za skorzystanie z programu". - in the menu, choose "Rozliczenia" ("statements") and "e-deklaracje" ("e-declarations"). The program crashes with error: Unhandled exception: page fault on write access to 0x017c0bce in 32-bit code (0x02358bf5). Backtrace: =>0 0x02358bf5 (0x0033f804) 1 0x7c0af136 in mscoree (+0xf135) (0x0033f874) 2 0x7e71b84a CoCreateInstance+0x369() in ole32 (0x0033f8e4) 3 0x004167e4 in jupiter (+0x167e3) (0x7ea9c9d0) 4 0xb8ec81ec (0x8b55ff8b) 0x02358bf5: addb %al,0x0(%eax). -- 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.

2 10

[Bug 60087] New: GDI+ cannot find a private font family by its reported name
by WineHQ Bugzilla Sept. 1, 2026

Sept. 1, 2026

http://bugs.winehq.org/show_bug.cgi?id=60087 Bug ID: 60087 Summary: GDI+ cannot find a private font family by its reported name Product: Wine Version: 11.14 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: gdiplus Assignee: wine-bugs(a)list.winehq.org Reporter: brandowlucas(a)gmail.com Target Milestone: --- Distribution: ArchLinux Created attachment 81608 --> http://bugs.winehq.org/attachment.cgi?id=81608 +timestamp,+tid,+gdiplus,+font When running Adobe Premiere Pro 2025 25.5 with Wine 11.14-14-g84fe968b936, startup fails with the following message after the Adobe Clean fonts have been installed and registered: unable to load operating system font. GDI Status: FontFamilyNotFound Font: Adobe Clean Style The same behavior can be reproduced without Adobe using the existing long font name resource in the GDI+ font tests. After a private font is loaded, `GdipGetFamilyName()` reports its family name, but passing that name and the same collection to `GdipCreateFontFamilyFromName()` returns `FontFamilyNotFound`. The reduced trace shows: trace:gdiplus:GdipGetFamilyName 0000000000837220, 000000000031F9F0, 0 trace:gdiplus:GdipCreateFontFamilyFromName L"wine_3_this_is_a_very_long_name", 0000000000823FC0 000000000031F9E0 trace:font:font_EnumFonts facename = L"wine_3_this_is_a_very_long_name" charset 1 font.c:124: Test failed: GdipCreateFontFamilyFromName failed: 14 `GdipCreateFontFamilyFromName()` currently asks GDI to enumerate the requested name and compares the resulting `LOGFONTW.lfFaceName` with the family names stored in the private collection: if (!wcsicmp(lf.lfFaceName, collection->FontFamilies[i]->FamilyName)) The name returned by GDI can differ from the name stored and reported by GDI+. This causes a valid family in the supplied private collection to be rejected. Steps to reproduce: 1. Add a font with a long family name to a private GDI+ font collection. 2. Obtain its name with `GdipGetFamilyName()`. 3. Pass that name and the same collection to `GdipCreateFontFamilyFromName()`. 4. Observe that unpatched Wine returns `FontFamilyNotFound` with status 14. The candidate patch first compares the requested name with the family names in the supplied collection. It retains the existing comparison with the name returned by GDI as a fallback. The patch also extends `test_long_name()` to exercise this lookup. The new check fails on unpatched Wine in both 32 bit and 64 bit tests: font.c:124: Test failed: GdipCreateFontFamilyFromName failed: 14 The check passes with the candidate patch in both architectures. The complete local font test still has four unrelated metric failures at `font.c:452`, which occur with both the patched and unpatched builds. Application verification confirms that the patch removes the Adobe Clean `FontFamilyNotFound` startup failure. Native Windows test results have not been 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 3

[Bug 58134] New: GTA San Andreas: A required security module can not be activated.
by WineHQ Bugzilla Sept. 1, 2026

Sept. 1, 2026

http://bugs.winehq.org/show_bug.cgi?id=58134 Bug ID: 58134 Summary: GTA San Andreas: A required security module can not be activated. Product: Wine Version: unspecified Hardware: x86-64 OS: FreeBSD Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: Alexander88207(a)Protonmail.com Hello, when i want to start GTA San Andreas using the original disc copy then i do get the message "A required security module can not be activated. This program can not be executed". The game is using SecuROM. Tested with Wine 10.3 Thanks in advance. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

2 3

[Bug 29372] New: Chrome exit with "fixme:file:ReplaceFileW Ignoring flags 2" while dragging tabs
by wine-bugs＠winehq.org Sept. 1, 2026

Sept. 1, 2026

http://bugs.winehq.org/show_bug.cgi?id=29372 Bug #: 29372 Summary: Chrome exit with "fixme:file:ReplaceFileW Ignoring flags 2" while dragging tabs Product: Wine Version: 1.3.35 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: fracting(a)gmail.com Classification: Unclassified 1. Downlaod and install Google Chrome http://www.google.com/chrome/index.html?platform=win&hl=en&standalone=1 sha1sum : ChromeStandaloneSetup-b6ea56f7a04f9bcee3565687f5aef83695d13b97-2011-12-09.exe 2. disable "Allow the window manager to decorate the windows." in winecfg (Reference: Bug 28467 and Bug 28468) 3. Start chrome $ cd ~/.wine/drive_c/users/fracting/Local\ Settings/Application\ Data/Google/Chrome/Application $ wine chrome.exe 4. make sure there is only one tab, drag the chrome tab away from the origin position, then chrome will exit with following messages: fixme:file:ReplaceFileW Ignoring flags 2 fixme:file:ReplaceFileW Ignoring flags 2 fixme:file:ReplaceFileW Ignoring flags 2 fixme:iphlpapi:CancelIPChangeNotify (overlapped 0xc8ab1c): stub fixme:advapi:UnregisterTraceGuids 0: stub fixme:advapi:UnregisterTraceGuids 0: stub -- 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.

2 14

[Bug 30652] New: Wrong TextOut font substitution under en_US locale
by wine-bugs＠winehq.org Sept. 1, 2026

Sept. 1, 2026

http://bugs.winehq.org/show_bug.cgi?id=30652 Bug #: 30652 Summary: Wrong TextOut font substitution under en_US locale Product: Wine Version: 1.5.4 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: gdi32 AssignedTo: wine-bugs(a)winehq.org ReportedBy: hqm03ster(a)gmail.com Classification: Unclassified Created attachment 40125 --> http://bugs.winehq.org/attachment.cgi?id=40125 The screenshots, test code, and test font The test program "tunihan.c" behaves differently on Windows and Wine (under linux). When a Unicode string containing CJK characters is TextOut-ed using a custom font, Wine font substitution isn't working properly like Windows does. To reproduce: 1. Install the font "nkf11_magicum_texturae.ttf". The font can be downloaded for free at: http://hwm3.gyao.ne.jp/shiroi-niwatori/nkf11_magicum_texturae.zip Windows standard CJK fonts NSimSun, PMingLiu, MS UI Gothic, Tahoma are also required to completely reproduce the attached screenshots. 2. Compile attached tunihan.c using MinGW on Windows with command line: gcc -otunihan.exe tunihan.c -lgdi32 3. Run the generated tunihan.exe under Windows, with global non-Unicode program locale set to English (US). Attached screenshot "enUS-windows.png" should be reproduced. 4. Copy/link all Windows fonts into Wine. 5. Run the generated tunihan.exe under Wine using command line: LANG=en_US.utf8 wine tunihan.exe Attacehed screenshot "enUS-linux.png" should be reproduced. Test environment: Windows: A Chinese Edition of Windows 7 with global non-Unicode program locale set to English (US). Wine: Wine 1.5.4 on Arch Linux 3.3.5, with all windows fonts symlinked into "C:\windows\Fonts" in Wine. Notes: A. The attached font, "nkf11_magicum_texturae.ttf", is an incomplete fictional glyph set for ASCII characters. It is chosen as a test font because it is missing glyphs for a number of ASCII symbols (e.g. '[', ']'), is clearly distinguishable from any potential substitution font, and is clearly not a Windows standard font. B. This behavior can't be reproduced using AppLocale. The Windows machine must have its global non-Unicode program locale set to English (US). C. tunihan.c writes 7 lines of texts to a Window: Line 1: A line of ASCII/CJK characters in a Simplified Chinese font Line 2: A line of ASCII/CJK characters in a Traditional Chinese font Line 3: A line of ASCII/CJK characters in a Japanese font Line 4: A line of ASCII/CJK characters in the test font Line 5: A line of ASCII characters in the test font, using TextOutW Line 6: A line of ASCII characters in the test font, using TextOutA Line 7: A line of ASCII/CJK characters in Tahoma In line 4, Windows is providing font substitution for the test font through a Japanese substitution font (deduced from unified Han character shape), thus displaying all ASCII/CJK characters correctly, despite that there isn't such a rule defined in the registry. Wine failed to do the same. On the other hand, Windows doesn't provide the same font substitution if a completely-ASCII string is TextOut-ed. The CJK characters are chosen to include both unified Han characters with a different shape in each font and non-unified characters for each individual font. Implications: 1. This bug may be related to a few weird CJK script rendering problems. 2. This bug may be related to a few western font rendering problems when CJK fonts are installed. 3. I'm not sure if the issue is even CJK related. Windows could be using similar font substitution for other scripts like Hebrew. -- 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.

2 5

[Bug 60261] New: movavi video editor bug ON STEAM LINUX
by WineHQ Bugzilla Sept. 1, 2026

Sept. 1, 2026

http://bugs.winehq.org/show_bug.cgi?id=60261 Bug ID: 60261 Summary: movavi video editor bug ON STEAM LINUX Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: pocomal112(a)codverts.com Target Milestone: --- Distribution: --- CANT LAUNCH MOVAVI VIDEO EDITOR 2025 AND 2026 STEAM VERSION ON LINUX AND I DONT HAVE BUG FILES. PLEASE FIX IT. MOVAVI VIDEO EDITOR STEAM VERSION NOT LAUNCHING -- 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 60092] New: Spotify Fails to Login
by WineHQ Bugzilla Aug. 31, 2026

Aug. 31, 2026

http://bugs.winehq.org/show_bug.cgi?id=60092 Bug ID: 60092 Summary: Spotify Fails to Login Product: Wine-staging Version: 11.14 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: spamemail392g(a)gmail.com CC: leslie_alistair(a)hotmail.com, z.figura12(a)gmail.com Target Milestone: --- Distribution: --- Created attachment 81624 --> http://bugs.winehq.org/attachment.cgi?id=81624 A zip file of two logs, one being an attempt of logging into Spotify via the browser, and another via the QR code When attempting to login on Spotify via either the Open in Browser method or the Scan QR Code method, the Spotify client will fail to login. When selecting Open in Browser, it does not do such, even when pressing "Try Again". When scanning the QR code, Spotify shows the option to pair, but when doing so, the client will completely freeze, and cannot be closed, unless it is killed. -- 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 49029] New: ABBYY FineReader 12 Professional crashes in trial mode
by WineHQ Bugzilla Aug. 31, 2026

Aug. 31, 2026

https://bugs.winehq.org/show_bug.cgi?id=49029 Bug ID: 49029 Summary: ABBYY FineReader 12 Professional crashes in trial mode Product: Wine Version: 5.7 Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: msxml6 Assignee: wine-bugs(a)winehq.org Reporter: focht(a)gmx.net Distribution: --- Hello folks, continuation from bug 43454 ("Multiple installers and applications crash on unhandled exception 0x000006ba inside NdrAsyncClientCall (ABBYY FineReader 12 Professional)"). Clicking 'Run Program' (= run app in trial mode) causes a crash. --- snip --- $ pwd /home/focht/.wine/drive_c/Program Files (x86)/ABBYY FineReader 12 $ WINEDEBUG=+seh,+relay,+msxml wine ./FineReader.exe >>log.txt 2>&1 ... 0055:Call ole32.CoCreateInstance(2f815e1c,00000000,00000017,2f815e2c,0032d544) ret=2f7ab6e9 ... 0055:Ret msxml3.DllGetClassObject() retval=00000000 ret=00ad5801 ... 0055:trace:msxml:DOMClassFactory_CreateInstance (nil) {00000000-0000-0000-c000-000000000046} 0x32d460 0055:trace:msxml:DOMDocument_create (60, 0x32d41c) ... 0055:trace:msxml:xmldoc_add_refs (0xf76c2d20)->(1) 0055:trace:msxml:get_domdoc_from_xmldoc returning iface 0x28b3f38 0055:trace:msxml:domdoc_QueryInterface (0x28b3f20)->({00000000-0000-0000-c000-000000000046} 0x32d460) 0055:trace:msxml:domdoc_AddRef (0x28b3f20)->(2) 0055:trace:msxml:domdoc_Release (0x28b3f20)->(1) 0055:trace:msxml:DOMClassFactory_Release (0x28d6120) ref = 0 ... 0055:Ret ole32.CoCreateInstance() retval=00000000 ret=2f7ab6e9 ... 0055:trace:msxml:domdoc_createProcessingInstruction (0x28b3f20)->(L"xml" L"version=\"1.0\" encoding=\"UTF-8\"" 0x32d46c) ... 0055:trace:msxml:node_set_content (0x29856e0)->(L"version=\"1.0\" encoding=\"UTF-8\"") ... 0055:trace:msxml:domdoc_createNode (0x28b3f20)->(0x32d3e0 {VT_INT: 1} L"root" L"http://www.abbyy.com/FineReader/BatchOptions/0" 0x32d468) ... 0055:trace:msxml:domdoc_createNode node_type 1 ... 0055:trace:msxml:domdoc_get_documentElement (0x28b3f20)->(0x32d480) 0055:trace:msxml:create_node type 1 ... 0055:trace:msxml:xmldoc_add_refs (0xf76c2d20)->(2) 0055:trace:msxml:domelem_QueryInterface (0x29856e0)->({2933bf80-7b36-11d2-b20e-00c04f983e60} 0x32d42c) 0055:trace:msxml:domelem_AddRef (0x29856e0)->(2) 0055:trace:msxml:domelem_Release (0x29856e0)->(1) 0055:trace:msxml:domelem_QueryInterface (0x29856e0)->({2933bf86-7b36-11d2-b20e-00c04f983e60} 0x32d480) 0055:trace:msxml:domelem_AddRef (0x29856e0)->(2) 0055:trace:msxml:domelem_Release (0x29856e0)->(1) 0055:trace:msxml:domelem_AddRef (0x29856e0)->(2) 0055:trace:msxml:domelem_AddRef (0x29856e0)->(3) 0055:trace:msxml:domelem_Release (0x29856e0)->(2) ... 0055:trace:msxml:domelem_setAttribute (0x29856e0)->(L"type" 0x32d400 {VT_BSTR: L""}) ... 0055:trace:msxml:domelem_setAttribute (0x29856e0)->(L"languages" 0x32d400 {VT_BSTR: L"English"}) 0055:Call KERNEL32.WideCharToMultiByte(0000fde9,00000000,028b8ecc L"English",ffffffff,00000000,00000000,00000000,00000000) ret=f799f4a2 0055:Call ntdll.RtlUnicodeToUTF8N(00000000,00000000,0032d324,028b8ecc,00000010) ret=7b0198f4 0055:Ret ntdll.RtlUnicodeToUTF8N() retval=00000000 ret=7b0198f4 0055:Ret KERNEL32.WideCharToMultiByte() retval=00000008 ret=f799f4a2 0055:Call ntdll.RtlAllocateHeap(00110000,00000000,00000009) ret=f799f4c1 0055:Ret ntdll.RtlAllocateHeap() retval=028d6120 ret=f799f4c1 0055:Call KERNEL32.WideCharToMultiByte(0000fde9,00000000,028b8ecc L"English",ffffffff,028d6120,00000009,00000000,00000000) ret=f799f4ea 0055:Call ntdll.RtlUnicodeToUTF8N(028d6120,00000009,0032d324,028b8ecc,00000010) ret=7b0198f4 0055:Ret ntdll.RtlUnicodeToUTF8N() retval=00000000 ret=7b0198f4 0055:Ret KERNEL32.WideCharToMultiByte() retval=00000008 ret=f799f4ea 0055:Call KERNEL32.WideCharToMultiByte(0000fde9,00000000,028310bc L"languages",ffffffff,00000000,00000000,00000000,00000000) ret=f799f3a3 0055:Call ntdll.RtlUnicodeToUTF8N(00000000,00000000,0032d324,028310bc,00000014) ret=7b0198f4 0055:Ret ntdll.RtlUnicodeToUTF8N() retval=00000000 ret=7b0198f4 0055:Ret KERNEL32.WideCharToMultiByte() retval=0000000a ret=f799f3a3 0055:Call ntdll.RtlAllocateHeap(00110000,00000000,0000000b) ret=f799f3c2 0055:Ret ntdll.RtlAllocateHeap() retval=028b5a50 ret=f799f3c2 0055:Call KERNEL32.WideCharToMultiByte(0000fde9,00000000,028310bc L"languages",ffffffff,028b5a50,0000000b,00000000,00000000) ret=f799f3e3 0055:Call ntdll.RtlUnicodeToUTF8N(028b5a50,0000000b,0032d324,028310bc,00000014) ret=7b0198f4 0055:Ret ntdll.RtlUnicodeToUTF8N() retval=00000000 ret=7b0198f4 0055:Ret KERNEL32.WideCharToMultiByte() retval=0000000a ret=f799f3e3 0055:trace:seh:raise_exception code=c0000005 flags=0 addr=0xf7bd80b2 ip=f7bd80b2 tid=0055 0055:trace:seh:raise_exception info[0]=00000000 0055:trace:seh:raise_exception info[1]=a5317000 0055:trace:seh:raise_exception eax=7d125010 ebx=f7cfb000 ecx=7d12501c edx=a5317000 esi=00000030 edi=0000003f 0055:trace:seh:raise_exception ebp=00000003 esp=0032d370 cs=0023 ds=002b es=002b fs=0063 gs=006b flags=00010283 0055:trace:seh:call_stack_handlers calling handler at 0x2f7bc908 code=c0000005 flags=0 0055:trace:seh:call_stack_handlers handler at 0x2f7bc908 returned 1 ... wine: Unhandled page fault on read access to A5317000 at address F7BD80B2 (thread 0055), starting debugger... --- snip --- Tidbit: The app installer bundles Microsoft MSXML 6.0 x64 redist installer. >From 'AbbyyMsiLog.txt': --- snip -- ... Get prerequisites... Prerequisites: Z:\home\focht\Downloads\FR12_PE\MSXML\msxml6_x64.msi Checking related Product for UpgradeCode: {5BBED1F8-E6F3-4A02-BC97-26D35BE200CA} Prerequisite MaxUpdateVersion is: 6.10.1129.0 No related products for this UpgradeCode [Setup] Run="C:\windows\system32\msiexec.exe" /i "Z:\home\focht\Downloads\FR12_PE\MSXML\msxml6_x64.msi" /passive /Liwrmo!vepacu "C:\users\focht\Temp\msxml6_x64.log" [Setup] RunExitCode=0 ... --- snip --- Due to the presence of Wine's MSXML 6.0 PE builtins, the redist installer does not overwrite them. Only binaries that don't exist in Wine, such as 'msxml6r.dll' get installed in SysWOW64 and System32 respectively. It wouldn't work anyway as Wine always prefers msxml builtins for good reason. 'winetricks -q msxml6' prevents the crash. $ sha1sum ABBYY_FR12_PRO_TRIAL.exe cd209916f9f13486a6d8f6fc6276eeb761b30803 ABBYY_FR12_PRO_TRIAL.exe $ du -sh ABBYY_FR12_PRO_TRIAL.exe 340M ABBYY_FR12_PRO_TRIAL.exe $ wine --version wine-5.7 Regards -- 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