December 2024 - Wine-bugs - list.winehq.org

[Bug 50055] New: Epic games update crashes
by WineHQ Bugzilla 07 Feb '25

07 Feb '25

https://bugs.winehq.org/show_bug.cgi?id=50055 Bug ID: 50055 Summary: Epic games update crashes Product: Wine Version: 5.20 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: winetest(a)luukku.com Distribution: --- https://www.epicgames.com/store/en-US/ You may need free account to test this. Download Epic (.msi) installer, let it upgrade itself. It fails to install needed depencies(should open a bug about that too), you can only dismiss the information. relaunch the application, press dismiss button and it crashes. fresh wineprefix. Unhandled exception: inexact float result in 32-bit code (0x7b00fc02). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:7b00fc02 ESP:01ebfd34 EBP:01ebfdf8 EFLAGS:00000297( - -- I S -A-P-C) EAX:01ebfd40 EBX:00000000 ECX:01ebfdd4 EDX:01ebfdd2 ESI:00000040 EDI:00000000 Stack dump: 0x01ebfd34: 001cddd0 000c001f 0008001f c000008f 0x01ebfd44: 00000000 00000000 7b00fc02 00000001 0x01ebfd54: 01ebfdd2 01ebfd88 7e6ae1c1 00001fa7 0x01ebfd64: ffff137f ffff0040 fffff5aa 7e6b1537 0x01ebfd74: 00000000 001c4720 ffff0000 01ebfda0 0x01ebfd84: 00000000 01ebfdf8 7e6b1899 6ed0e4d0 Backtrace: =>0 0x7b00fc02 EntryPoint+0xffffffff() in kernelbase (0x01ebfdf8) 1 0x7e6b15c1 _CIpow+0xda0() in ucrtbase (0x01ebfdf8) 2 0x014b114b EntryPoint+0xffffffff() in epicgameslauncher (0x02db3400) 3 0x02db33c0 (0x0152c868) 4 0x0050b550 EntryPoint+0xffffffff() in epicgameslauncher (0x0050b2c0) 5 0xc86806c7 (0x57f18b56) 0x7b00fc02 EntryPoint+0xffffffff in kernelbase: subl $4,%esp Modules: Module Address Debug info Name (64 modules) PE 220000- 236000 Deferred xinput1_3 PE 250000- 253000 Deferred api-ms-win-crt-utility-l1-1-0 PE 260000- 263000 Deferred api-ms-win-crt-time-l1-1-0 PE 400000- 19e8000 Export epicgameslauncher PE 1ec0000- 2323000 Deferred ole32 PE 9430000- 97c0000 Deferred d3dcompiler_47 PE 10000000-10207000 Deferred d3dcompiler_43 PE 61740000-61820000 Deferred advapi32 PE 61f00000-61f04000 Deferred api-ms-win-crt-convert-l1-1-0 PE 61f80000-61f85000 Deferred api-ms-win-crt-math-l1-1-0 PE 62300000-6236f000 Deferred msvcp140 PE 62d40000-62d43000 Deferred api-ms-win-crt-environment-l1-1-0 PE 62fc0000-631ee000 Deferred rpcrt4 PE 63480000-6349c000 Deferred version PE 63740000-63744000 Deferred api-ms-win-crt-runtime-l1-1-0 PE 63bc0000-63c00000 Deferred shcore PE 64a40000-64b59000 Deferred shlwapi PE 64ec0000-65296000 Deferred oleaut32 PE 65d40000-65d43000 Deferred api-ms-win-crt-filesystem-l1-1-0 PE 66240000-6627d000 Deferred bcrypt PE 66600000-66603000 Deferred api-ms-win-crt-locale-l1-1-0 PE 666c0000-666e7000 Deferred hid PE 676c0000-67731000 Deferred explorerframe PE 67840000-6784e000 Deferred psapi PE 68080000-680c5000 Deferred jsproxy PE 68500000-68646000 Deferred combase PE 686c0000-686fc000 Deferred concrt140 PE 68700000-6878e000 Deferred uxtheme PE 68b00000-68b12000 Deferred normaliz PE 69600000-6970d000 Deferred winhttp PE 6a040000-6a0a2000 Deferred msacm32 PE 6a400000-6a571000 Deferred winmm PE 6aa40000-6ab24000 Deferred usp10 PE 6b7c0000-6b7c4000 Deferred api-ms-win-crt-stdio-l1-1-0 PE 6bc00000-6bc9d000 Deferred sechost PE 6bcc0000-6be8e000 Deferred setupapi PE 6ca00000-6ca03000 Deferred api-ms-win-crt-heap-l1-1-0 PE 6cc40000-6d0bb000 Deferred comctl32 PE 6e940000-6ebc4000 Deferred d3d11 PE 6ec40000-6ec5b000 Deferred dwmapi PE 6ed00000-6f38c000 Deferred user32 PE 6f900000-6fa13000 Deferred msctf PE 6fa80000-6fcc8000 Deferred dbghelp PE 6fe40000-6feda000 Deferred rsaenh PE 6ff00000-6ff04000 Deferred api-ms-win-crt-string-l1-1-0 PE 70240000-70253000 Deferred vcruntime140 PE 70d00000-70f58000 Deferred comdlg32 PE 71200000-71246000 Deferred imm32 PE 7a840000-7a844000 Deferred opengl32 PE 7b000000-7b33a000 Dwarf kernelbase PE 7b600000-7b923000 Deferred kernel32 PE 7bc00000-7bed9000 Deferred ntdll PE 7c6b0000-7c6b4000 Deferred winex11 PE 7c9c0000-7c9c4000 Deferred msvcrt PE 7cac0000-7cac4000 Deferred wined3d PE 7cc30000-7cc34000 Deferred dxgi PE 7d730000-7e007000 Deferred shell32 PE 7e2d0000-7e2eb000 Deferred wldap32 PE 7e360000-7e3a4000 Deferred crypt32 PE 7e450000-7e454000 Deferred iphlpapi PE 7e480000-7e48b000 Deferred winspool PE 7e4e0000-7e4e7000 Deferred gdi32 PE 7e660000-7e783000 Export ucrtbase PE 7e660000-7e783000 Export ws2_32 Threads: process tid prio (all id:s are in hex) 00000038 services.exe 0000003c 0 00000040 0 0000004c 0 00000070 0 00000088 0 00000094 0 000000b4 0 000000d4 0 00000044 winedevice.exe 00000048 0 00000054 0 00000058 0 0000005c 0 00000060 plugplay.exe 00000064 0 00000074 0 00000078 0 0000007c 0 0000009c 0 00000068 explorer.exe 0000006c 0 000000c0 0 000000c4 0 00000080 winedevice.exe 00000084 0 0000008c 0 00000090 0 00000098 0 000000a4 0 000000a8 0 000000ac svchost.exe 000000b0 0 000000b8 0 000000bc 0 000000cc rpcss.exe 000000d0 0 000000dc 0 000000e0 0 000000e4 0 000000e8 0 000000ec 0 000000f4 (D) C:\Program Files (x86)\Epic Games\Launcher\Portal\Binaries\Win32\EpicGamesLauncher.exe 000000f8 1 <== 00000100 -1 00000104 -1 00000108 -1 0000010c -1 00000110 -1 00000114 0 00000118 0 0000011c 0 00000120 0 00000124 0 00000128 -2 0000012c -2 00000130 -1 00000134 2 00000138 2 0000013c 2 00000140 2 00000144 -1 00000148 -1 0000014c -1 00000150 -1 00000154 -1 00000158 1 0000015c 1 00000160 1 00000164 0 00000168 1 00000170 0 00000240 0 System information: Wine build: wine-5.20 Platform: i386 (WOW64) Version: Windows 7 Host system: Linux Host version: 5.4.0-52-generic -- 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 51373] New: Videos from Super Seducer won't work anymore
by WineHQ Bugzilla 07 Feb '25

07 Feb '25

https://bugs.winehq.org/show_bug.cgi?id=51373 Bug ID: 51373 Summary: Videos from Super Seducer won't work anymore Product: Wine Version: 6.0.1 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: chaosstare(a)live.fr Distribution: --- Hi, On Wine 6.0, I could play / see the videos while playing Super Seducer 1 / 2 (didn't try the third episode), it's not longer the case with Wine 6.0.1 or later. Nicolas -- 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 5

[Bug 57144] New: X11: Keyboard is not working in some games in virtual desktop
by WineHQ Bugzilla 07 Feb '25

07 Feb '25

https://bugs.winehq.org/show_bug.cgi?id=57144 Bug ID: 57144 Summary: X11: Keyboard is not working in some games in virtual desktop Product: Wine Version: 9.15 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winex11.drv Assignee: wine-bugs(a)winehq.org Reporter: lojorix20(a)yandex.ru Distribution: --- Games, such as Counter-Strike: Source and Out of Action UE4 demo do not detect any keys pressed when using wine in virtual desktop mode without other window manager. I tried using registry key UseTakeFocus=N from https://bugs.winehq.org/show_bug.cgi?id=48121, but it didn't help in these games. After debugging Counter-Strike: Source v34 with WINEDEBUG=trace+event I didn't find anything different, compared to other games, and also there was no FocusIn or FocusOut events. But I noticed, that if I minimize the running game and change focus to some other program (taskmgr.exe) and then return back to the game, keyboard starts working. I did the same test but with Xfce4 wm without virtual desktop, and the problem is not present there. Starting game in windowed mode does not help aswell. -- 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 52566] New: d3d11:d3d11 fails in test_clip_distance() on cw-gtx560
by WineHQ Bugzilla 07 Feb '25

07 Feb '25

https://bugs.winehq.org/show_bug.cgi?id=52566 Bug ID: 52566 Summary: d3d11:d3d11 fails in test_clip_distance() on cw-gtx560 Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: directx-d3d Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com Distribution: --- d3d11:d3d11 has had failures on cw-gtx560 forever [1] but it recently started exhibiting a few new failures in test_clip_distance() on cw-gtx560: d3d11.c:29488: Test failed: Got 0x00000000, expected 0xff00ff00 at (0, 0, 0), sub-resource 0. d3d11.c:29054: Test failed: Got 0x00000000, expected 0xff00ff00 at (0, 0, 0), sub-resource 0. d3d11.c:29061: Test failed: Got 0x00000000, expected 0xff00ff00 at (0, 0, 0), sub-resource 0. d3d11.c:29077: Test failed: Got 0x00000000, expected 0xff00ff00 at (0, 0, 0), sub-resource 0. d3d11.c:29089: Test failed: Got 0x00000000, expected 0xff00ff00 at (0, 0, 0), sub-resource 0. d3d11.c:29054: Test failed: Got 0x00000000, expected 0xff00ff00 at (0, 0, 0), sub-resource 0. d3d11.c:29061: Test failed: Got 0x00000000, expected 0xff00ff00 at (0, 0, 0), sub-resource 0. d3d11.c:29077: Test failed: Got 0x00000000, expected 0xff00ff00 at (0, 0, 0), sub-resource 0. d3d11.c:29089: Test failed: Got 0x00000000, expected 0xff00ff00 at (0, 0, 0), sub-resource 0. d3d11.c:29519: Test failed: Got 0x00000000, expected 0xff00ff00 at (0, 0, 0), sub-resource 0. d3d11.c:29054: Test failed: Got 0x00000000, expected 0xff00ff00 at (0, 0, 0), sub-resource 0. d3d11.c:29061: Test failed: Got 0x00000000, expected 0xff00ff00 at (0, 0, 0), sub-resource 0. d3d11.c:29077: Test failed: Got 0x00000000, expected 0xff00ff00 at (0, 0, 0), sub-resource 0. d3d11.c:29089: Test failed: Got 0x00000000, expected 0xff00ff00 at (0, 0, 0), sub-resource 0. d3d11.c:29542: Test failed: Got 0x00000000, expected 0xff00ff00 at (0, 0, 0), sub-resource 0. d3d11.c:29557: Test failed: Got 0x00000000, expected 0xff00ff00 at (0, 0, 0), sub-resource 0. d3d11.c:29569: Test failed: Got 0x00000000, expected 0xff00ff00 at (0, 0, 0), sub-resource 0. d3d11.c:29582: Test failed: Got 0x00000000, expected 0xff00ff00 at (0, 0, 0), sub-resource 0. https://test.winehq.org/data/patterns.html#d3d11:d3d11 A bisect shows that these failures started with the same commit that causes failures on cw-rx460 (see bug 52563): commit a13fc3bb7e055562b8b9deae985c64c5c7861424 Author: Henri Verbeet <hverbeet(a)codeweavers.com> Date: Fri Feb 11 19:42:02 2022 -0600 wined3d: Use the chunk allocator for GL vertex buffers. Signed-off-by: Zebediah Figura <zfigura(a)codeweavers.com> Signed-off-by: Henri Verbeet <hverbeet(a)codeweavers.com> Signed-off-by: Alexandre Julliard <julliard(a)winehq.org> [1] To be fair it got a lot better on 2022-02-09 but sadly these new failures appeared on a few days later. It's still better than it used to be. -- 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 7

[Bug 57213] New: Starcraft 2 ram usage problem
by WineHQ Bugzilla 07 Feb '25

07 Feb '25

https://bugs.winehq.org/show_bug.cgi?id=57213 Bug ID: 57213 Summary: Starcraft 2 ram usage problem Product: Wine-staging Version: 9.17 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: calmstorm(a)posteo.de CC: leslie_alistair(a)hotmail.com, z.figura12(a)gmail.com Distribution: --- Basically, I play one game of Starcraft 2 via wine-staging. If its long enough, it will start to lag severely if i play a 2nd game, severe lag. By severe, I mean the players in the game are forced to drop me within minutes if I don't leave. I am not sure how I should save a log of this. all I know is that I start the game, I am using 1.5GB once I start it. After the first game or 40 minutes, I am using 5.6GB! Very annoying it is. Any advice as to how to fix this? PS, using a Debian fork known as Devuan. Its based on debian bookworm btw. -- 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 56807] New: Procedure "DllCanUnloadNow" not found in ole32
by WineHQ Bugzilla 07 Feb '25

07 Feb '25

https://bugs.winehq.org/show_bug.cgi?id=56807 Bug ID: 56807 Summary: Procedure "DllCanUnloadNow" not found in ole32 Product: Wine Version: 9.10 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ole32 Assignee: wine-bugs(a)winehq.org Reporter: mywine(a)schiermeier-it.de Distribution: --- While running and tracing "The Bat!" mailer under wine I got a hint about a missing procedure call to the procedure "DllCanUnloadNow". Please see attachment named: thebat-trace-1.log More info about this procedure see here: https://learn.microsoft.com/de-de/windows/win32/api/combaseapi/nf-combaseap… -- 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 56002] New: Adaptive sync results in transient halved refresh rate with winewayland
by WineHQ Bugzilla 07 Feb '25

07 Feb '25

https://bugs.winehq.org/show_bug.cgi?id=56002 Bug ID: 56002 Summary: Adaptive sync results in transient halved refresh rate with winewayland Product: Wine Version: 9.0-rc1 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: shtetldik(a)gmail.com Distribution: --- Component: winewayland.drv When running Cyberpunk 2077 using winewayland (vkd3d-proton/dxvk's dxgi set up in the prefix with Wine 9.0-rc1 + esync), there is a transient issue when monitor's refresh rate drops to half of the game framerate instead of matching it as adaptive sync should do. DE: KDE Plasma 5.27.9. I measure game framerate with MangoHud and monitor's refresh rate with on-screen OSD. With winex11 they match, with winewayland they match most of the time, but sometimes refresh rate is halved. So for example the game would have 128 fps and OSD will show 64 Hz. Since it only happens with winewayland, there must be something specific going on with it. KWin developers suggested it could have something to do with some additional subsurfaces preventing direct scanout for example. -- 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 49767] New: All resources deleted during update Logos Bible Software
by WineHQ Bugzilla 07 Feb '25

07 Feb '25

https://bugs.winehq.org/show_bug.cgi?id=49767 Bug ID: 49767 Summary: All resources deleted during update Logos Bible Software Product: Wine Version: 5.16 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: johnpgoodman(a)gmail.com Distribution: --- Created attachment 68072 --> https://bugs.winehq.org/attachment.cgi?id=68072 Console output from during update Updates result in data wipe. Logos stores all resources, eg. ebooks, videos etc in a subdir like drive_c/users/$username/Local Settings/Application Data/Logos/Data/$uniqueid/ResourceManager/ When an update to Logos Bible Software becomes available there is a notification in the app. The update will usually install ok however on wine the Resources are all wiped. The user is now stuck with a massive download eg. 40gb+. On Windows the resources are always still there after an update. It's as if the msi somehow overwrites the directory rather than merging with it? I've attached a console log updating from 8.15.0.0004 to 8.16.0.0002 - in this case the update also did not relaunch the newly updated app but simply kept running. At this point I checked and confirmed all resources were wiped. Once quit and reloaded it was clear the update had completed but it began to download everything again. -- 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 25

[Bug 56985] New: how to improve the performance of Wine?
by WineHQ Bugzilla 07 Feb '25

07 Feb '25

https://bugs.winehq.org/show_bug.cgi?id=56985 Bug ID: 56985 Summary: how to improve the performance of Wine? Product: Wine Version: 9.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)winehq.org Reporter: csumushu(a)126.com Distribution: --- Created attachment 76816 --> https://bugs.winehq.org/attachment.cgi?id=76816 demo.c I have found that my program runs much slower when using Wine compared to running it directly on Windows. On Windows, it responds quickly, but when running with Wine, there is a delay of three to four seconds. After analyzing the program code, I discovered a loop within which semaphore operations are performed. The time consumption for a single semaphore operation is 10-4 seconds when using Wine, whereas it only takes 10-6 seconds on Windows. I wrote a demo program to test it and indeed confirmed this. Semaphore operations are just one example; some other Windows APIs are also significantly slower when compared to Windows. Is there any way to optimize this? -- 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 7

[Bug 45151] New: patches: 'git send-email' through Zoho SMTP causes patch queue to go berserk
by wine-bugs＠winehq.org 07 Feb '25

07 Feb '25

https://bugs.winehq.org/show_bug.cgi?id=45151 Bug ID: 45151 Summary: patches: 'git send-email' through Zoho SMTP causes patch queue to go berserk Product: WineHQ.org Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: www-unknown Assignee: wine-bugs(a)winehq.org Reporter: kyle.auble(a)zoho.com Distribution: --- Created attachment 61339 --> https://bugs.winehq.org/attachment.cgi?id=61339 I'm starting to get embarrassed So I'll probably just start using my Gmail account for submissions to Wine anyways, but I've been having problems sending patches through Zoho. I've followed the instructions on https://wiki.winehq.org/Submitting_Patches and when running 'git send-email', there are no issues on my computer. I'm prompted for my SMTP password, git does its thing, and I've received an "OK / 250" return code every time. Small, one-off patches seem to make it through fine, but beyond that, then the wine-devel or the patch-list doesn't get them. Furthermore, Zoho delivers me a message saying that wine-devel can't be reached and that they'll keep retrying the delivery. And they do, which is where I think part of the problem might be coming from. --- In the first case, I tried sending a series of 7 patches. The first patch was a very short text change, the next five were larger batch substitutions on different strings, and the last one was a relatively short binary patch to delete five images. The first patch made it through pretty quickly, but the rest never showed up. To make things more confusing, I received Zoho notices that patches 5-7 couldn't reach the list and would be retried, but nothing about 2-4. Then a few hours later, the mailing list confirmed that patch 7 had made it through fine, but no sign of the middle 5. Since I had no notification from wine-devel or Zoho for patches 2-4, I tried resending patch 2 a couple times. Everything besides patches 1 & 7 seemed to just be falling into a black-hole though... until the next morning, every last patch I had sent (including the repeats of patch 2) was on both wine-devel and the patch-list, showing the original send dates, as if they had been there all along. --- In the second case, I had three large binary patches for deleting old images that have since been moved onto the wiki. I tried sending them one-at-a-time, 'git send-email' gave me an OK / 250, and they never made it to the list. This time Zoho sent me a notice saying that there was a fatal error with wine-devel's address, specifically "ResponseCode 421, Read timed out" The notice said they would keep retrying the delivery for 4 days, but then I didn't hear anything... until all of a sudden, today I see this on the patch queue (screenshot attached). I know I didn't resend either of these patches, much less 17 times. Weirdly enough, the wine-devel mailing list seems to understand what's going on a little better and only shows the message once. --- The one other pattern I have noticed is that it almost seems like the mailing list is clocking out for business hours. The first was on a Wed evening, but it wasn't until the next morning that everything suddenly appeared. The second time, I tried sending in my patches before Friday evening, but there was still no sign of them when I checked yesterday (Sun). Sure enough, they're all there today though. TL/DR: I know very little about how mail protocols work, and it could very well be on my mail service's end, but it almost seems like the mailing-list is actually receiving the emails. It then puts them in quarantine outside of normal work-hours, which doesn't seem like a problem in isolation. Somehow the sender is getting "delivery failed" codes though, and I only seem to get delivery receipts sporadically, despite turning on delivery receipts in my pipermail settings for wine-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.

2 6