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

[Bug 39773] New: File->Open slowdown caused by desktop.ini checks
by wine-bugs＠winehq.org Sept. 9, 2026

Sept. 9, 2026

https://bugs.winehq.org/show_bug.cgi?id=39773 Bug ID: 39773 Summary: File->Open slowdown caused by desktop.ini checks Product: Wine Version: 1.8-rc2 Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: shell32 Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com Distribution: --- To reproduce this you will need two Linux machines, a Samba server and a Samba client. On the Samba server: * Create a directory with lots of subdirectories and files: mkdir smbdir cd smbdir for i in `seq 1 200`;do mkdir sub$i; done for i in `seq 1 200`;do touch file$i; done * Export smbdir through Samba. (alternatively you could export '/' and use '/usr/lib' as a replacement for smbdir) On the Samba client: * Mount the Samba share. You can either do it by adding a /etc/fstab line like: //MYSERVER/smbdir /mnt/smbdir cifs rw,username=MYLOGIN,password=MYPASSWORD,domain=MYDOMAIN 0 0 Or by starting Nautilus in GNOME, clicking on '+Other Places' -> Windows network... using GVFS. Note that in this case you'll have to work around the colon in the mount point filename (see bug 34868). * Slow down the network connection using a command like this: tc qdisc add dev eth0 root netem delay 10ms * Check the above line is effective by running: ping MYSERVER The rtt should be around 10ms. * cd /mnt/root/ wine notepad * Open the File->Open dialog, navigate to the smbdir folder exported through Samba. * BUG: The initial display will be slow and scrolling through the many subfolders will be very slow. * Change the file mask to '*.*'. * Scroll all the way to the right so only files are visible. As long as only files are visible scrolling should then be very fast! * Finally change the rtt to 0ms on the Samba server and check that the RTT is under 1ms. * Now test again notepad's File->Open dialog and everything should be reasonably fast. The problem is that whenever File->Open displays a folder in the open file dialog it checks whether it contains a desktop.ini file to display the right icon. That's not cached, thus incurring a few file lookups per folder displayed. For local file systems that's fast enough but on network shares with a non-trivial RTT the speed impact is significant. A 10+ ms RTT makes the dialog essentially unusable. Note that when displaying a filename we have everything in the cache so redisplays are lightning fast and track the mouse. Also Microsoft Office has the same problem even though it does not use the standard comdlg32 dialog (though that may depend on the Windows version being emulate). On Windows Microsoft Office suffers no slowdown in this situation. What this means is that the standard common dialog is probably the wrong level for fixing this. Hacking SHELL32_GetCustomFolderAttributeFromPath() in shell32 to just return FALSE speeds things up greatly. The display still lags a bit behind the mouse so that there may be some residual file lookups or other slowdowns but it's still night and day. -- 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 5

[Bug 55029] New: Wishlist: do reflink on CopyFileW for WINEPREFIX size reduction
by WineHQ Bugzilla Sept. 9, 2026

Sept. 9, 2026

https://bugs.winehq.org/show_bug.cgi?id=55029 Bug ID: 55029 Summary: Wishlist: do reflink on CopyFileW for WINEPREFIX size reduction Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: kernel32 Assignee: wine-bugs(a)winehq.org Reporter: arthur200126(a)gmail.com Distribution: --- The current implementation of CopyFileW consists of a simple read-write loop. This of course is completely fine in terms of Windows emulation, but one of the consequences is huge file size inflation when setting up things like a WINEPREFIX: on a wine 7.7-staging 64-bit install, each fresh prefix takes up 1.2 GiB: 619M of that is System32, and Syswow64 520M. Doing reflink on the CopyFileW interface (which is what rundll32 uses to get wine.ini set up) would greatly reduce the disk space burden associated with setting up a fresh prefix. Removal of real disk IO would also make the process a lot faster. Back in GNU land, the `cp` utility has been doing reflink by default since June 2020. -- 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 60196] New: Barrow Hill - Curse of the Ancient Circle: Game window is shifted down in fullscreen when DE has upper panel
by WineHQ Bugzilla Sept. 8, 2026

Sept. 8, 2026

http://bugs.winehq.org/show_bug.cgi?id=60196 Bug ID: 60196 Summary: Barrow Hill - Curse of the Ancient Circle: Game window is shifted down in fullscreen when DE has upper panel Product: Wine Version: 11.15 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: kajitsu22(a)gmail.com Target Milestone: --- Distribution: --- OS: Gentoo Linux DE: MATE Desktop Environment I played Barrow Hill: Curse of the Ancient Circle, and discovered a bug. When the game is running in fullscreen mode, the whole game window is somewhat shifted down, with the lowest part of it ending up beyond the display. It causes some annoying UX on the gameplay, as the player inventory is located at the lower side of the screen, and pictures of all of the items in it are halved, making them hard to recognise. Also, certain in-game equipment is also displayed near the lower side of the screen, and some information on it cannot be seen at all due to also being halved. I noticed then that the upper part of the screen has a weird unused black line, which does nothing. Then I remembered I have two panels in my desktop environment: upper one and lower one. I removed the upper panel, and relaunched the game. The shift was gone; the game window was now displayed in full. Then, I added the upper panel back and launched the game again. The shift returned. My desktop settings should be unrelated to whatever applications/games I run, and they certainly must not affect how an application works or the user/player experience. Thus, I'm reporting this as a bug. Screenshots are attached below: With two panels: https://postimg.cc/18CXqZBq https://postimg.cc/9DFz0fd9 https://postimg.cc/Yvn0WwRh With a single panel: https://postimg.cc/LYdHt41L https://postimg.cc/dkMq2Qy7 https://postimg.cc/cgqsR1nn -- 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 23

[Bug 25723] New: PhysX causes major lag in Mirror's Edge.
by wine-bugs＠winehq.org Sept. 8, 2026

Sept. 8, 2026

http://bugs.winehq.org/show_bug.cgi?id=25723 Summary: PhysX causes major lag in Mirror's Edge. Product: Wine Version: 1.3.11 Platform: x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: H3g3m0n(a)gmail.com When the PhysX option is enabled (setting in the Video Options) in Mirror's Edge. When 'physics' things start to occur the game starts to get some major lag becoming unplayable. Mirror's Edge doesn't make too much use of PhysX (I believe it was on of the first games with support for it), afaik it's mostly used for enabling shattering glass to create shards and maybe some bits of paper on the ground. As such this only seems to happen at specific points in the game. For example Chapter 1 Flight->Check Point D. As you are running across the bridge, the helicopter starts to shoot the glass causing it to shatter. If you continue on to the next area, at some point (when you go underground) it suddenly returns to normal speed (most likely it has unloaded the previous area). With PhysX set to off, there is no lag but no glass shards. -- 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 22

[Bug 60172] New: WPF font fallback does not work: the families named by GlobalUserInterface.CompositeFont do not resolve under Wine
by WineHQ Bugzilla Sept. 7, 2026

Sept. 7, 2026

http://bugs.winehq.org/show_bug.cgi?id=60172 Bug ID: 60172 Summary: WPF font fallback does not work: the families named by GlobalUserInterface.CompositeFont do not resolve under Wine Product: Wine Version: 11.15 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: gdi32 Assignee: wine-bugs(a)list.winehq.org Reporter: wehrwolfmann(a)gmail.com Target Milestone: --- Distribution: --- Created attachment 81815 --> http://bugs.winehq.org/attachment.cgi?id=81815 family resolution and glyph outlines for Latin and Cyrillic WPF (.NET Framework, PresentationCore) does not use DirectWrite layout or the dwrite fallback API -- it carries its own per-character fallback table, the GlobalUserInterface.CompositeFont file installed with the framework. That table is written entirely in terms of Windows system font families. Under Wine essentially none of those families exist, so the table has nowhere to go and WPF emits .notdef for the character instead. Measured on this prefix (Wine 11.15, WINEARCH=win64, reported Windows 10 build 19045, native .NET Framework 4.8, host CachyOS/Arch with the usual Noto, DejaVu and Liberation font packages installed), against the RS5 section of GlobalUserInterface.CompositeFont, which is the section .NET selects when Wine reports Windows 10: families named as fallback targets 44 resolvable through Wine 1 (Tahoma) not resolvable 43 (Segoe UI, Segoe UI Symbol, Ebrima, Nirmala UI, Leelawadee UI, Malgun Gothic, Gulim, Gadugi, Yu Gothic UI, Meiryo UI, Microsoft YaHei UI, Microsoft JhengHei UI, SimSun, MS Gothic, MingLiU, Calibri, Cambria Math, Myanmar Text, MV Boli, Mongolian Baiti, Simplified Arabic, ... ) The single map that matters most is the first one: <FontFamilyMap Unicode = "0000-052F, 0590-05FF, ..." Target = "Segoe UI, Segoe UI Symbol, Ebrima" /> U+0000-U+052F is Latin, Latin Extended, IPA, Greek and Cyrillic; the same map also carries Hebrew. All three targets are missing, so under Wine a WPF application has no fallback at all for those scripts. A plain WPF application does not notice, because its default typeface comes from SystemParametersInfo(SPI_GETNONCLIENTMETRICS) and Wine answers "Tahoma", which covers Latin, Greek and Cyrillic by itself. An application that ships its own branded font does notice, and branded fonts are usually Latin-only. WHAT THIS LOOKS LIKE IN A REAL APPLICATION Razer Central 7.23.0.1220 (the launcher bundled with Razer Axon) draws its tray icon context menu with WPF, in its own font "RazerF5" (SIL OFL, derived from Titillium, embedded in the executable and also shipped as a separate download). RazerF5 has 229 glyphs: Latin and punctuation, no Cyrillic. With the application's language set to Russian, every Latin menu entry renders and every Cyrillic menu entry is a row of empty boxes. On Windows the same build renders the Russian entries, because the fallback lands on Segoe UI. MINIMAL REPRODUCER wpf_fonts.cs (attached). It is a console program; build it with the csc.exe that comes with the framework already installed in the prefix, no SDK needed: wine "C:\windows\Microsoft.NET\Framework64\v4.0.30319\csc.exe" /nologo \ /nowarn:0618 /target:exe /out:C:\wpf_fonts.exe \ "/r:C:\windows\Microsoft.NET\Framework64\v4.0.30319\WPF\PresentationCore.dll" \ "/r:C:\windows\Microsoft.NET\Framework64\v4.0.30319\WPF\PresentationFramework.dll" \ "/r:C:\windows\Microsoft.NET\Framework64\v4.0.30319\WPF\WindowsBase.dll" \ "/r:C:\windows\Microsoft.NET\assembly\GAC_MSIL\System.Xaml\v4.0_4.0.0.0__b77a5c561934e089\System.Xaml.dll" \ C:\wpf_fonts.cs For every family name given on the command line it prints whether the family resolves, whether the resolved face covers Latin and Cyrillic, and the bounding box of the outlines FormattedText.BuildGeometry() actually produced for the Latin string "Settings" and the Cyrillic string "Настройки". An empty bounding box means WPF produced no glyph outline at all -- the tofu case. It also writes wpf_fonts.png so the failure can be seen rather than read. Run it with any font that covers Latin but not Cyrillic; RazerF5 is the one used here (razerf5-light.otf, freely downloadable, SIL OFL): family "RazerF5" resolved=True latin=True cyrillic=False latin width= 55.26 height= 18.66 outline=53.7x14.8 cyrillic width= 33.84 height= 18.66 outline=EMPTY (nothing drawn) family "Tahoma" resolved=True latin=True cyrillic=True latin width= 56.50 height= 19.31 outline=55.9x15.0 cyrillic width= 77.58 height= 19.31 outline=75.6x15.0 family "Segoe UI" resolved=False Tahoma proves the text path itself is fine. RazerF5 shows that once the requested face lacks the character, nothing takes over. THE GDI CONTRAST gdi_cyrillic.c (attached) does the same two strings through plain GDI: CreateFontIndirectA, GetGlyphIndicesW(GGI_MARK_NONEXISTING_GLYPHS), TextOutW into a DIB, counting painted pixels. face "Segoe UI" latin missing_glyphs=0/8 painted_pixels=522 (GetTextFace Liberation Sans) cyrillic missing_glyphs=0/9 painted_pixels=637 (GetTextFace Liberation Sans) face "RazerF5" latin missing_glyphs=0/8 painted_pixels=489 (GetTextFace RazerF5) cyrillic missing_glyphs=9/9 painted_pixels=653 (GetTextFace RazerF5) So Wine already degrades gracefully when a Win32 application asks for a Windows font by name -- "Segoe UI" quietly becomes Liberation Sans and the Cyrillic renders. That graceful degradation happens at font *selection* time and is invisible to any consumer that first asks whether the family exists. WPF asks exactly that question, gets "no", and its whole fallback table dies with it. (GDI's own per-glyph behaviour for RazerF5 -- 9 unmapped glyphs, boxes painted -- matches Windows; GDI TextOutW does not font-link either. The difference is only in the family lookup.) A HARSHER MANIFESTATION If the *requested* family also fails to resolve, WPF does not fall back to a default -- the process dies silently inside text formatting. With the reproducer above: wine wpf_fonts.exe "Segoe UI" family "Segoe UI" resolved=False <process gone, no exception, no message> This looks like the same root cause as bug 50021 (PS Remote Play, assertion in MS.Internal.Shaping.TypefaceMap.MapUnresolvedCharacters, "installing corefonts changes the behaviour"): MapUnresolvedCharacters has nothing left to map to. Related but distinct: bug 59925 is also WPF fallback failing, but there the requested families do resolve and a single character (U+002D) is orphaned into a run of its own. Here the fallback targets do not exist as families at all, so the table has nothing to reach in the first place. SUGGESTED FIX Wine already has the mechanism, it just has no default entries for these names: HKCU\Software\Wine\Fonts\Replacements, honoured by both win32u/font.c (load_gdi_font_replacements) and dwrite/font.c. It enumerates an existing family under an additional name, and it steps aside automatically if a real font of that name is ever installed. REG_MULTI_SZ values are already supported and the first available entry wins, so one value works across distributions: [HKEY_CURRENT_USER\Software\Wine\Fonts\Replacements] "Segoe UI"=hex(7):... Noto Sans, DejaVu Sans, Liberation Sans, Arial, Tahoma "Segoe UI Symbol"=hex(7):... DejaVu Sans, Noto Sans, Liberation Sans, Arial, Tahoma "Ebrima"=hex(7):... Noto Sans, DejaVu Sans, Liberation Sans, Arial, Tahoma Adding just those three restores WPF fallback for Latin Extended, Greek, Cyrillic and Hebrew. Verified on this prefix with the reproducer, with GlobalUserInterface.CompositeFont left untouched: before family "RazerF5" cyrillic outline=EMPTY (nothing drawn) after family "RazerF5" cyrillic outline=80.8x16.0 (Noto Sans metrics) Tahoma as the last entry is a safe floor: Wine ships it, and it covers Latin, Greek and Cyrillic. The same treatment would extend naturally to the CJK and Indic target names for hosts that have suitable fonts. An independent cross-check that the composite font really is the mechanism: appending an existing family to every Target attribute in the prefix's *.CompositeFont files fixes it too, with no registry change at all. The registry route is preferable because it needs no edits to files that belong to the framework. VERSIONS Reproduced on wine-11.15 (Arch/CachyOS package), WINEARCH=win64, native .NET Framework 4.8, reported Windows version 10 (build 19045). Not tested on Wine-Mono; Wine-Mono's WPF carries its own copy of the same composite font files, so the same reasoning should apply. ATTACHMENTS wpf_fonts.cs WPF reproducer described above gdi_cyrillic.c the GDI counterpart used for the contrast wpf_fonts_before.png offscreen render, stock prefix: Cyrillic missing wpf_fonts_after.png the same render once "Segoe UI" resolves -- 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 15

[Bug 60253] New: Incoming (1998) crashes after the intro animation
by WineHQ Bugzilla Sept. 7, 2026

Sept. 7, 2026

http://bugs.winehq.org/show_bug.cgi?id=60253 Bug ID: 60253 Summary: Incoming (1998) crashes after the intro animation Product: Wine Version: 11.3 Hardware: x86-64 URL: https://archive.org/download/incoming_201401/incoming. exe OS: Linux Status: NEW Keywords: download, regression Severity: normal Priority: P2 Component: d3d Assignee: wine-bugs(a)list.winehq.org Reporter: gyebro69(a)gmail.com CC: rbernon(a)codeweavers.com Target Milestone: --- Regression SHA1: 7df175a66faef1804ee84e278feecbd69a30cf37 Distribution: --- Created attachment 81966 --> http://bugs.winehq.org/attachment.cgi?id=81966 terminal output (Incoming demo version) The regression was introduced by commit: 7df175a66faef1804ee84e278feecbd69a30cf37 ddraw: Pass the active device to material_activate. Reverting this commit on current Wine 11.16 fixes the crash completely. The issue is reproducible with the original demo version and the Steam and GOG.versions as well. wine-11.16-156-g2ecc2f84b45 NVIDIA GeForce GTX 1660 SUPER NVIDIA 610.57.04 -- 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 59322] New: Star Trek Bridge Commander: massive graphical glitches under XWayland full-screen mode
by WineHQ Bugzilla Sept. 7, 2026

Sept. 7, 2026

http://bugs.winehq.org/show_bug.cgi?id=59322 Bug ID: 59322 Summary: Star Trek Bridge Commander: massive graphical glitches under XWayland full-screen mode Product: Wine Version: 11.1 Hardware: x86-64 URL: https://archive.org/download/StarTrekBridgeCommanderDE MO/StarTrekBridgeCommanderDEMO.exe OS: Linux Status: NEW Keywords: download Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: gyebro69(a)gmail.com Distribution: ArchLinux Created attachment 80253 --> http://bugs.winehq.org/attachment.cgi?id=80253 terminal output I just recently switched over to KDE Plasma to test my games using XWayland or the native Wayland driver. This bug occurs only with XWayland and in Wine's fullscreen mode: some of my old games (DX6 and DX7 era) shows graphical glitches that look like wrong Z-order issue and textures overlapping or missing entirely. The bug doesn't occur with XWayland in virtual desktop mode, neither under X server or when using the native Wayland driver. Reproduced using the nouveau vulkan driver (NVK over Zink) and Mesa 25.3.4 and with the following Nvidia binary driver versions as well: 570.211.01, 580.126.09, 590.48.01. Star Trek Bridge Commander demo, when starting a new game from the main menu, has this bug. StarTrekBridgeCommanderDEMO.exe sha256: 8fe735f356ac008f6ef5072502b19aefb5be5115fc15adf26ae70655b3b7e62a Another example of the broken rendering is Tachyon: The Fringe on Steam: https://store.steampowered.com/app/32760/Tachyon_The_Fringe/ Tested with wine-11.1-58-gf4626afec7c Arch Linux KDE Plasma 6.5.5 KWin (Wayland) X server version: 1.24.1 NVIDIA binary drivers 590.48.01 -- 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 59383] New: Beyond Divinity (GOG, Steam) doesn't exit cleanly in Wayland when CSMT is enabled
by WineHQ Bugzilla Sept. 7, 2026

Sept. 7, 2026

http://bugs.winehq.org/show_bug.cgi?id=59383 Bug ID: 59383 Summary: Beyond Divinity (GOG, Steam) doesn't exit cleanly in Wayland when CSMT is enabled Product: Wine Version: 11.2 Hardware: x86-64 URL: https://store.steampowered.com/app/219760/Beyond_Divin ity/ OS: Linux Status: NEW Severity: minor Priority: P2 Component: winewayland Assignee: wine-bugs(a)list.winehq.org Reporter: gyebro69(a)gmail.com Distribution: ArchLinux After exiting the game via the menu, the game executable (div.exe) remains in the process list and occupies one CPU core at 100%. I waited for 5 minutes, but the process still didn't exit. The problem happens only when using the native Wayland driver (DISPLAY= wine div.exe), but it is not reproducible under XWayland or when running the game under X11 (XFCE). This was reproduced with NVIDIA driver 580.126.09 and with NVK / Mesa 25.3.4. Running the game under Weston 14.02 also triggers this bug. Both the Steam and GOG.com versions are affected, but the original demo version is not. Disabling CSMT resolves the problem for me. FWIW, it was commit de0fc7fd (from Wine-10.11) that enabled the game to display properly in Wayland, and the issue was already present then. Prior to that commit, the game displayed only a black screen while running; however, navigating blindly to the 'Quit' button in the menu resulted in a clean shutdown. Plain terminal output doesn't reveal anything, let me know if any debug log would help. Arch Linux KDE Plasma 6.5.5 KWin (Wayland) Nvidia 580.126.09 -- 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 1

[Bug 59334] New: Pop-up menu opened behind the parent window in Steam when using XWayland in full-screen mode
by WineHQ Bugzilla Sept. 7, 2026

Sept. 7, 2026

http://bugs.winehq.org/show_bug.cgi?id=59334 Bug ID: 59334 Summary: Pop-up menu opened behind the parent window in Steam when using XWayland in full-screen mode Product: Wine Version: 11.1 Hardware: x86-64 URL: https://cdn.fastly.steamstatic.com/client/installer/St eamSetup.exe OS: Linux Status: NEW Keywords: download Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: gyebro69(a)gmail.com Distribution: ArchLinux Created attachment 80272 --> http://bugs.winehq.org/attachment.cgi?id=80272 plain terminal output In the Steam client, when you right-click a game in your library, a context menu opens that allows you to perform several functions, such as uninstalling, performing a validity check, or viewing properties. This context menu opens behind the main Steam window; therefore, it cannot be interacted with. This happens when running Steam in XWayland and using Wine full-screen mode. In XWayland and virtual desktop mode the menu appears correctly. The problem doesn't occur under X Server and using full-screen (XFCE). I also reproduced the issue in Weston 14.0.2; this rules out the possibility of it being a bug specific to KDE Plasma or KWin as far as I know. I can't check out the native Wayland driver because it has it's own problem: the Steam window is empty/black using Wayland. The same problem with Wine-9.0, 10.0 etc. Wine-Staging has this problem, too. You can reproduce the problem even though you don't have a Steam account. Install the Steam client, let it perform the auto-update and when the login window appears click on <Create a free account> in the lower right corner. There is a drop-down menu under Country of residence, when opened in full-screen mode (XWayland), the list of countries appear behind the main Steam window. In virtual desktop mode the list is visible properly. wine-11.1-102-g93f3d8ae9fa Arch Linux KDE Plasma 6.5.5 KWin (Wayland) Xwayland Version 24.1.9 Nvidia binary drivers 590.48.01 -- 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 58361] New: Genshin Impact: Game cannot start while an internet-connection is available
by WineHQ Bugzilla Sept. 7, 2026

Sept. 7, 2026

http://bugs.winehq.org/show_bug.cgi?id=58361 Bug ID: 58361 Summary: Genshin Impact: Game cannot start while an internet-connection is available Product: Wine Version: 10.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: 9427421240(a)posteo.net Distribution: --- Created attachment 78751 --> http://bugs.winehq.org/attachment.cgi?id=78751 Log - directly starting GenshinImpact.exe with an internet-connection available The game cannot start while an internet-connection is available. The internet-connection can be (re)activated after starting the game, for logging in and playing the game. This issue happens with Wine 10.0 and Wine 10.10. I was able to start the game normally with Wine 10.0 before, so it seems that a recent update to the game caused this 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.

2 9