http://bugs.winehq.org/show_bug.cgi?id=49193 Bgungor <baris.gungor.it@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |baris.gungor.it@gmail.com --- Comment #16 from Bgungor <baris.gungor.it@gmail.com> --- Created attachment 82050 --> http://bugs.winehq.org/attachment.cgi?id=82050 Terminal output, wine-11.17, Genshin Impact 7.0.0, clean win64 prefix Still reproducible with Genshin Impact 7.0.0 (Global) on plain upstream wine-11.17, clean win64 prefix. The game registers its own kernel service "HoYoProtect" for HoYoKProtect.sys, then fails to load it because WDFLDR.SYS is not present: err:module:import_dll Library WDFLDR.SYS (which is needed by L"C:\windows\system32\HoYoKProtect.sys") not found err:ntoskrnl:ZwLoadDriver failed to create driver L"...\Services\HoYoProtect": c0000142 The game then aborts via NtRaiseHardError 0x50000018 before creating any window and before writing its own output_log.txt, so there is no in-game log to attach. Exit code is 5. On builds that do ship a wdfldr stub (GE-Proton11-6 / wine-staging 11.0, GE-Proton10-34, proton-cachyos 11.0-20260703, wine-dwproton-wow64 11.0-11) the load gets one step further and fails at the stubbed entry points instead: fixme:wdfldr:WdfVersionBind ... L"...\Services\HoYoProtect" ... stub! fixme:wdfldr:WdfVersionUnbind ... L"...\Services\HoYoProtect" ... stub! err:ntoskrnl:ZwLoadDriver failed to create driver L"...\Services\HoYoProtect": c0000355 The outcome is identical in both cases. Three additional data points that may help triage: 1. Deleting HoYoKProtect.sys from both the game directory and system32 does not help. The driver load is then never attempted, but the game still opens an error dialog (window class #32769) and exits the same way. So the driver load is not the only gate. 2. In that configuration the last meaningful call before the error dialog is NtQuerySystemInformation with SystemCodeIntegrityInformation, which Wine currently reports as a stub: fixme:ntdll:NtQuerySystemInformation SystemCodeIntegrityInformation, size 8, info 0x..., stub! That is information class 103, returning SYSTEM_CODEINTEGRITY_INFORMATION (Length, CodeIntegrityOptions). Unlike the driver itself, this looks like an ordinary unimplemented information class and might be worth handling independently of the wdfldr question. Happy to file it as a separate bug if that is preferred. 3. The service control manager also denies a handle right before the driver load: err:service:validate_context_handle Access denied - handle created with access 34, needed 10000 This may be the same "Access denied" reported in bug 59437, where the reporter supplied a real WDFLDR.SYS, got past the import error, and then hit an access-denied wall. If so, providing wdfldr alone would not be sufficient. I am aware that running Windows kernel-mode drivers is out of scope for Wine and I am not requesting that. This is filed as a data point for the existing report, and because points 2 and 3 look separable from the driver question. System: CachyOS, kernel 7.2.2, Wayland/KDE Plasma, NVIDIA RTX 4070 Laptop (driver 610.57.04) + Intel UHD Raptor Lake-S, Mesa 26.2.2. Terminal output attached. -- 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.