Does not boot on Dell XPS 9570
makedir opened this issue · comments
Have the following issue, that I cant boot this EFI bootloader, when secure boot is on, selecting it will just start the Dell Hardware Scan. When I disable secure boot and select the usb stick, I just get a black screen and a "_" on left top corner and it freezes.
How did you arrange the files in your ESP?
This mod grub shell is intended to be started from the UEFI Shell (not this grub shell), which can be launched by renaming and putting the UEFI Shell file in <ESP ROOT>\EFI\BOOT\BOOTX64.efi.
P.S. On most firmwares, directly start the mod grub shell should be OK. In this situation it's the modGRUBShell.efi file to be renamed and put as <ESP ROOT>\EFI\BOOT\BOOTX64.efi.
Yes, I put the file on usb stick, formated fat32, also tried with RUFUS GPT, created EFI/Boot/ on it and named file bootx64.efi: https://i.imgur.com/1VGyiq3.png
Doesnt work. With secure on, it just skips it and for what ever reason opens the Dell Hardware Scan. With secure boot off, it opens a black screen with _ on top left corner and nothing happens anymore and pc is frozen.
Well, you can try to boot a UEFI shell first, and launch grub shell in UEFI shell. I've also met firmware that cannot start grub shell directly.
How would I do that? You didnt say anything about secure boot, does it need to be disabled for this to work? To make one issue less. In bios gui it shows the correct path of the usb stick to EFI\BOOT\BOOTX64.efi but it doesnt work.
First, as we are working with unsigned efi executables, the secure boot should be disabled.
The UEFI shell can be obtained on Internet, such as here, extract the shell file from it (ShellBinPkg/UefiShell/X64/Shell.efi), and rename the Shell.efi as <ESP ROOT>\EFI\BOOT\BOOTX64.efi. Then you can boot the UEFI shell, modGRUBShell.efi should also be put into ESP, but as we will launch it from UEFI shell, the path does not matter, ESP root is most convenient.
After boot into the UEFI shell, there will be a list of filesystems starting from fs0, just use fsX: to enter it (sometimes the USB ESP is not fs0), use ls to verify the partition contents, and last find and execute the GRUB shell from the UEFI shell. (e.g. .\modGRUBShell.efi when put into ESP root)
This shell works, why isnt yours working? The shell shows that list but when I type in FS0 it says bad command.
These two are totally different shells, the UEFI shell is under active development while this grub shell is only based on an old grub codebase, that's why some firmwares can't boot the grub shell. But the BIOS settings can't be altered in UEFI shell.
About entering fs, it needs a colon after fs0, so you should type fs0: (just like entering drives in Windows cmd, where you should type C: to enter C drive)
Ok, got it ^^ fs0:
Yes that worked and I was on the usb stick, typed in ls, there was the grub.efi I renamed. .\grub.efi enter. And black screen and nothing is happening anymore. Same as if directly booting it named as EFI\BOOT\BOOTX64.efi. This time entire screen black though and no _ at top left corner.
So it seems like a firmware-specific problem. This is unexpected as it is just a normal efi program and works normally on another Dell Z370 platform (XPS 8930). I also didn't see any other platforms failed to run this.
You may try checking if the grub shell file is corrupt. Maybe using a newer grub codebase would solve the problem, but I don't have time to port code and test for now.
Could it be an issue, because I have 4k display? I had in mind before Linux didnt like 4k especially not at boot time and boot loader like higher resolution. If you could maybe upgrade this to latest grub when you have time I would really appreciate it and test if that works.
I used this file https://github.com/datasone/grub-mod-setup_var/releases/download/1.1/modGRUBShell.efi
This is how it looks when it tries to start grub and maybe the same issue https://forums.fogproject.org/topic/12362/dell-xps-15-9570-can-t-boot-to-fog-usb-disk
Ok got it working now, I had to enable "allow legacy EFI ROMs" in bios, now grub worked. I want to change the 0x14 from 1 to 0, this is the output: https://i.imgur.com/97AAROp.jpg
Is it safe to continue, or what are those warnings for?
Erm... I just did this:
setup_var_3 0x14
it said it was set to 0x01
I typed in
setup_var_3 0x14 0x00
it said set to 0x00
I rebooted, saw no effect in Windows, went back into grub, typed in
setup_var_3 0x14
and it was back to 0x01
I am a bit scared now. Why wasnt this saved? Hope it didnt mess something up. Do I need to flip "cfg lock" from 01 too to 00 for config saved?
I wanted to change this value: https://i.imgur.com/ivQFTDo.png
To force S3 sleep. I extracted this from the current bios I also have on it.
The original GUID in the program was the one in a InsydeH2O firmware, so in most firmwares the GUID won't match, that's not a problem.
"CFG Lock" entry is the lock of MSR 0xE2 register (no idea why Aptio took this name😂) so it has nothing to do with other settings.
You could verify if the variable value is touched before reboot, if the value write succeed, it maybe the firmware that changes it back. It may worth attention that Variable 0xFE3 controls the form Sleep Mode, maybe the firmware read this value and changes Sleep Mode back to default. You may search for 0xFE3 in the IFR extracted text to know the details of that variable.
P.S. I've also searched a bit about your laptop, and it seems Dell removed S3 settings support in a BIOS update. While they may just hide the settings item, it is possible that all related code has been removed. Personally I recommend to solve this problem in the OS settings (Windows registry or Linux kernel parameter, forcing S3 sleep) instead of changing BIOS settings.
Here is the IFR extract of latest bios 1.16.2 for the XPS 9570 I made, mayde I did it wrong, but if you could have a look I would really appreciate it:
https://www.dropbox.com/s/vpy7eyzutd7q6e0/Section_PE32_image_Setup_body%20IFR.txt?dl=0
Not sure what 0xFE3 does, but it isnt for sleep, it is kinda everywhwere I think it may be for if a setting is hidden in bios gui? But how would it work for everything then? Maybe you see on the file what its for,
it's countless times in the file always like this:
0x3C626 Grayout If: {19 82}
0x3C628 Variable 0xFE3 equals 0x0 {12 86 E3 0F 00 00}
0x3C655 Grayout If: {19 82}
0x3C657 Variable 0xFE3 equals 0x0 {12 86 E3 0F 00 00}
ect
I am sure 0x14 controls the setting I am after because of this:
0x41A60 Form: Sleep Mode, Form ID: 0x2833 {01 86 33 28 42 1A}
0x41A66 Subtitle: Sleep Mode {02 87 42 1A 00 00 00}
0x41A6D End {29 02}
0x41A6F Subtitle: {02 87 02 00 00 00 00}
0x41A76 End {29 02}
0x41A78 Grayout If: {19 82}
0x41A7A Variable 0xFE3 equals 0x0 {12 06 E3 0F 00 00}
0x41A80 Setting: Sleep Mode, Variable: 0x14 {05 91 42 1A 43 1A 54 01 01 00 14 00 10 10 00 01 00}
0x41A91 Option: OS Automatic Selection, Value: 0x1 (default) {09 07 44 1A 10 00 01}
0x41A98 Option: Force S3, Value: 0x0 {09 07 45 1A 00 00 00}
0x41A9F End of Options {29 02}
and it is also a second time mentioned for the same but other naming:
0x46EA6 Setting: Low Power S0 Idle Capability, Variable: 0x14 {05 91 DD 00 DE 00 EF 01 01 00 14 00 10 10 00 01 00}
0x46EB7 Option: Disabled, Value: 0x0 {09 07 04 00 00 00 00}
0x46EBE Option: Enabled, Value: 0x1 {09 07 03 00 30 00 01}
0x46EC5 End of Options {29 02}
Low Power S0 Idle is modern standby support what I want to disable.
What irritates me a bit is that 0x14 is a 3rd time mentioned like this for some bogus nonsense entry:
0x516E8 Setting: N/A, Variable: 0x14 {05 91 80 16 8C 16 91 05 20 00 14 00 10 10 00 04 00}
0x516F9 Option: Auto, Value: 0x0 {09 07 51 16 30 00 00}
0x51700 Option: Floppy, Value: 0x1 {09 07 87 16 00 00 01}
0x51707 Option: Forced FDD, Value: 0x2 {09 07 88 16 00 00 02}
0x5170E Option: Hard Disk, Value: 0x3 {09 07 89 16 00 00 03}
0x51715 Option: CD-ROM, Value: 0x4 {09 07 8A 16 00 00 04}
I had checked when I did setup_var_3 0x14 0x00, that it was 0 with just setup_var_3 0x14. But after reboot it was suddenly back to 01, after I rebooted went into Windows and back into grub.
At release date this was still shown in bios Sleep Mode OS Automatic or Force S3, and with bios 1.3.0 moron Dell idiots removed it, for whatever reason. They told me eventually in a email back "this laptop does not support S3" which is totally a lie of course, because S3 works fine under Linux. So I am sure, they just hide the bios option, not just remove it. The value needs to be in there still for Windows 10 to recognize, if the laptop is modern standby capable or not to determinate if S3 is used or not.
And this lead me to this entire thing: With the latest Windows 10 may 2020 update version 2004, Ms removed ANY form to revert back to S3 sleep. You cant disable modern standby anymore up from version 2004 and they removed the registry entry CsEnabled, if the EC/EFI tells this laptop is modern standby capable, windows will use it and give no option for S3 to chose anymore. You are now STUCK with shitty modern standby, which is dangerous and melts your laptop durin sleep, and drains you battery in 1-2 hours during a catastrophic sleep, which happens all the time on this laptop. This is MADNESS.
https://www.reddit.com/r/Dell/comments/fai8xd/psa_warning_windows_10_version_20h12004_and/
So changing this bios flag to force S3 might be the only way for using S3 still in Windows.
I have no idea how retarded someone can be at MS to force this and give no option anymore for S3 sleep.
Can you try this IFR-Extractor?
The conflicting var offset may due to stored in different UEFI variable (with the same offset). There isn't info about where the variable is stored in the dump. I'm not sure if it's due to an old version of the extractor but it worth a try.
Well, the new dump solved your concerns, but still leave the problem unsolved.
The Setting: N/A is stored in VarStore: 0x20, which is VarStore: VarStoreId: 0x20 [EC87D643-EBA4-4BB5-A1E5-3F3E36B20DA9], Size: 0x21, Name: UsbSupport. So our changing values in Setup variable will not effect this, that is, we are correctly changing value we want.
I guess that because of the removal of the Sleep Mode setting happens in a BIOS update, Dell decided to check the setting value and change it back on every boot to ensure S0ix when the setting has been modified by user in an early version of BIOS.
Though digging in BIOS firmware is too hard, I recalled a project that may solve this problem. The project adds modern standby support to the MacBooks by altering the FADT table, so by modifying the code and altering the FADT table reversely, the modern standby should be disabled.
I've changed it slightly to make it disable the modern standby, but as said here, this small utility should be loaded on every boot and cannot automatically load Windows, so it may be used in rEFInd as a rEFInd UEFI driver.
For a first time testing, you can enter the UEFI shell, run this AcpiPatcher.efi, and then find and run <ESP ROOT>\EFI\Microsoft\Boot\bootmgfw.efi to boot Windows.
Thank you very much for your time looking into this. So your theory is, the EC overwrites the 0x14 flag everytime back to 01 at boot? And it cant be modified anymore via this hack?
I am not an expert in all of this, but what you mentioned here brought back some memory that I read before about something like altering the ACPI table or something for Windows boot manager, so to trick Windows into the device does not support modern standby. Do you think this might be possible? Does the word SSDT also has to do something with this? I googled about it, and these hacks are all just for Macintosh, for example also disabling the dGPU at boot time ( https://khronokernel-4.gitbook.io/disable-unsupported-gpus/disabling-the-gpu/option-3-patching-with-an-ssdt )
This was actually another wish I had, to somehow disable the Nvidia dGPU pre boot, so it would be disabled under Windows. If you disable the dGPU device in Windows device manager, this would create a drain in modern standby, how could it be different... because the SOC cant power down the dGPU obviously not anymore with no driver loaded, and the entire thing blows up. No dGPU powered down means no SOC powered down means everything not powered down... modern standby is such a FAIL design. I hate it so much. It randomly fails, has hundreds ways to fail, if one driver fails, everything fails... S3 is 100% working and reliable.
What does this AcpiPatcher do? This is way beyond my knowledge. But you have to do this every time manually booting the laptop? Is there no way to modify the boot loader somehow maybe of Windows for this? Or this SSDT thing I mentioned above.
There is also this in the file maybe it would be possible to disable dGPU via bios too:
0x4D7C8 One Of: DGPU Power Enable, VarStoreInfo (VarOffset/VarName): 0x575, VarStore: 0x1, QuestionId: 0x46F, Size: 1, Min: 0x0, Max 0x1, Step: 0x0 {05 91 6D 11 6E 11 6F 04 01 00 75 05 10 10 00 01 00}
0x4D7D9 One Of Option: Enabled, Value (8 bit): 0x1 {09 07 03 00 00 00 01}
0x4D7E0 One Of Option: Disabled, Value (8 bit): 0x0 (default) {09 07 04 00 30 00 00}
0x4D7E7 End One Of {29 02}
Well, this AcpiPatcher I uploaded is a specific program and will only remove S0ix support from BIOS (and is temporarily), you can first test the AcpiPatcher in the UEFI shell like I said, to use it daily you may need to install rEFInd bootloader, and use that to automatically execute the patcher and load windows bootloader like here said.
Injecting custom ACPI tables (usually DSDT and SSDTs) is normal in Hackintosh, and can be done in Linux, but there is no reliable solution to inject into Windows, you may try bootloaders used in Hackintosh (like Clover or OpenCore). It will require some knowledge in ACPI (that is, to write your own ACPI code to turn off the GPU on boot, and correctly handling sleep and wake to turn it off. You've said it as well, without the drivers, no automatically turning off) and extra bootloader configurations as they are not designed to boot Windows.
The guide you provided is for macOS, and as Windows interpret _DSM method result differently from macOS, more research is required. Another way to do this is that calling dGPU's _OFF method on boot to turn it off, call _ON before sleep (here S3) to ensure nothing wrong happens in the sleep period, and then call _OFF after wake to turn off it again. But this requires many modifications to the DSDT/SSDTs.
The "DGPU Power Enable" setting name seems reasonable, though the "Disabled" default value doesn't seems promising, trying to change it won't be wrong😂
I tried your modificated acpipatcher right now.... and it WORKED! Modern standby is now disabled in the current run time of Windows. S3 is back powercfg /a says.
I ran the efi shell, then ran acpipatcher.efi this was the output:
https://i.imgur.com/f7rv4bh.jpg
Is that normal or was that bad? Does it do something permanent, writing anywhere, or is this made in RAM and will be restored/lost when you reboot or power down. What about a hibernate or S3 in Windows, it will still be kept, or may it reset (overwritten again by EC) when you hibernate and wake up?
So a solution to this would be to install this rEFInd boot loader, add your efi file to it as plugin set it up to auto load Windows, and it should work? Is it dangerous to set up rEFInd or like fail proof. anything to keep in mind, does it still work properly on latest Windows 10, or with Nvme SSD ect. Secure boot must be disabled too I guess to make it work? I saw this warning on its setup site:
https://i.imgur.com/0bfCD2b.png
That you need to disable hibernate for security reasons?
Hm... so that DGPU power enable maybe means something else, not that the device is disabled?
You maybe know some other way in Windows, to keep the dGPU off with modern standby still working? I guess this is not possible, as I understand how modern standby works... just deactivating a device in device manager would cause a 100% drain.
This is normal, and the modification is temporary, should keep through this boot (keep between S3 sleep, lost when shutdown/hibernate). That's why rEFInd should be introduced. Though I'm not using rEFInd so I'm actually not so sure, there are many people who used it to boot Windows, so I think there shouldn't be much problems.
As for the warning about hibernation, the corruption only happens when you try to write the Windows filesystem (mostly C drive) in another operating system. So if you only uses Windows, it's safe to ignore the warning.
Finally, you can try to change value of "DGPU Power Enable". But if Optimus works normally, the dGPU should be off if it's not used by any program, so Windows users hardly need to manually turn dGPU off. I'm afraid there is no easy way to do it.
Wait, so this is lost after hibernate? What happens, if this trick is used to boot into Windows, it now thinks modern standby is not supported. You put the laptop to hibernate, wake up. What now? Does Windows still thinks so or will now use modern standby again?
Optimus never worked. It is still bugged. I wrote to Nvidia about this once, to ask them, if they could include a toggle Optimus off setting into their setting GUI, they refused to do so with the moron answer "Optimus decides when and how to use the dGPU by performance". So even if you set the "use intergated" option in the Nvidia GUI, the dGPU STILL will be randomly triggered over Windows 10. The issue with the Dell 9570 is, that moron Dell changed with a bios, that the fans are activated for no reason, everytime the dGPU gets activated (temp sensor ignored, just if dGPU = on fans are triggered), even just for 100ms or so. Guess what happens? dGPU gets randomly polled randomly all the time in Windows 10, and the fans kick in randomly for 10 seconds, and then off again. This also happens when you put the laptop to sleep, wake it up from sleep, shut it down, power it on. Because all those trigger short dGPU polls. This laptop is a nightmare. And Dell doesnt understand those issues nor is interested in fixing them.
Then there is a bug a friend of mine has with his 9570, that his dGPU randomly gets activated during modern standby, and I so far didnt find out whats causing this:
Someone else answered to this post, having the exact same issue.
I tried to log it with the Windows performance recorder and have a trace log for a broken sleep event, but I cant see from the WPR log, whats causing it. The WPR log says it was 97% in DRIPS, where powercfg sleepreport says otherwise, blaiming the PCIe adapter and dGPU for about 40% of the time for the drain:
https://i.imgur.com/2jGa97h.png
I tried 4 different Nvidia drivers, 1909, and also 2004 of Windows, didnt fix this. So the only solution is to use S3.
My 9570 also has a very bad drain during modern standby of around 1100mW/h or around 1.1% per hour, where S3 is around 0.4% per hour.
I have to look into how to install refind then under Windows. Did you ever do it before and used it for Windows?
Well, the "wake" after the hibernation invokes a normal boot, so before boot Windows, there is still chance to alter the ACPI table. Using rEFInd to automatically execute AcpiPatcher should be OK, you can try to wake from hibernation without executing AcpiPatcher, but I don't know what will happen and will not recommend you to do so. 🤣
Modern standby is always causing problems and Windows itself is full of bugs... About rEFInd, though I haven't used it (I'm using Hackintosh so needs special bootloaders), I think the official guide is sufficient. It's not very complex while it needs some command line operations.
Thank you so much for everything so far, youre super kind, friendly and deeply knowledged. I hope I didn steel to much time from you, you helped me so much with everything and I will go with the refind workaround. I have a few last questions about this.
https://www.rodsbooks.com/refind/installing.html#windows
So I read the install under windows guide. Would I need to edit anything in the refind config? Would it just automatically find the Windows efi boot file and show it as the only and also default option when the laptop boots automatically? How would this all work in detail. Is the Windows boot manager still the first thing which gets loaded, and it loads refind and then refind loads Windows? So I dont need to change anything in Bios, or update the boot partition or anything?
- deactivate secure boot
- mountvol S: /S
- xcopy /E refind S:\EFI\refind\
- rename refind.conf-sample refind.conf
- bcdedit /set "{bootmgr}" path \EFI\refind\refind_x64.efi <- is that correct or whats meant with "path"
- copy AcpiPatcher.efi into refind\tools_x64
- delete everything in refind\drivers_x64 ? https://i.imgur.com/Xc62zkD.png I think I dont need any of those?
Also dismount now I guess, with mountvol S: /P ?
Thats it? Refind will automatically load every file in \tools? What about this "press any key" I got when I executed the AcpiPatcher.efi manually from efi shell, will that be auto skipped by refind?
How would I revert back to default boot load? Just a
bcdedit /set "{bootmgr}" path \EFI\Microsoft\Boot\bootmgfw.efi ?
I am a bit confused with that path in that command, is that correct that way, does it get the correct FSX: ect automatically?
Would refind be loaded actually after a hibernate and you just hit enter to load Windows hibernate?
rEFInd can auto scan the files and find the Windows. After installing rEFInd, the boot process will be: BIOS -> rEFInd -> Windows boot manager, and the step 4 (bcdedit) will change the BIOS boot settings, so no more changes are required. Unmount ESP is good as most times you don't need it, and the command is mountvol S: /D.
The drivers in picture are for different filesystems, if only using Windows, those are not needed.
I think the "press any key" won't block boot process when loaded as driver, so it should be ok. And revert command is right. Here in Windows, the Windows system know what partition it is booted from, so "fsX:" is not needed. Just relative path in that partition is enough.
After hibernation, the BIOS still boot rEFInd, and rEFInd will boot hibernated Windows, so everything will be OK.
Ok I successfully set up refind, it worked auto booting after 5 seconds time out I set in conf file. But it didnt seem to load the AcpiPatcher file automatically. Do I need to change something for this to happen in conf file? I put AcpiPatcher.efi in efi\refind\tools_x64
I moved it from the tools_x64 to the drivers_x64 folder and now it auto loads, so what here mentioned is wrong https://github.com/imbushuo/AcpiS0ixPatcher/releases/tag/1.0.0
Sadly.... what I suspected happened, and it blocks the boot process. It stops at the "press any key to exit" when refind loads the efi file.
Print(L"%EPress any key to exit.%N\n");
SystemTable->ConIn->Reset(SystemTable->ConIn, FALSE); <- not sure if this one is needed
SystemTable->BootServices->WaitForEvent(1, &SystemTable->ConIn->WaitForKey, &Event);
Not sure what should need to be removed from this, mostly just first and third line?
Can you remove this from the AcpiPatcher and recompile, that would be super awesome!
Try this, only the third line is commented out. Should be enough.
AcpiPatcher.zip
Thank you very much. I set it up on my friends laptop, but his wifi isnt working now anymore after S3 wake up even after rebooting Windows, the wifi card is totally gone. Can this be any related to that? Does the ACPI table edit can somehow mess something like that up? Maybe trigger somehow internal "wifi of" flag? Wifi was working, he enterd S3, woke up, and now Wifi is gone, even after reboot.
First, you can try cutting off the power: power off and remove AC power, wait a few seconds, then replug the power and restart. In most situations this will work.
I suspect it is related about the laptop's ACPI, but not about my patch (that patch only modifies a bit to tell Windows not to use S0ix). Maybe something is wrong about the PCIe S3 Sleep or the driver. Does yours work normally? You may check if their BIOS/Windows/Drivers(Wi-Fi and Chipset) version matches.
Furthermore, you may test if S3 sleep works normally in other OS (such as Linux or older Windows 10 that have CsEnabled key). Meanwhile, Microsoft states that it is not supported to switch between S0ix and S3 directly, a reinstall could also be tried though reinstalling programs maybe hard.
Yes mine works normally, tested S3 just moments ago and wake up, but I have the Intel 9260 card, he still has the shitty Kiler wifi card... so maybe it is some bug of the killer driver or card. Sigh... I love this laptop.
That statement from Ms that a switch doesnt work is just a lie. They always claimed that.
Have to look into this now to get Wifi back working. Thank you so much for everything. youre awesome ❤
There is also btw a "cute" bug with the Dell 9570, that after you use S3 and wake up from it under Windows 10, there is some "run away" c0% activity of about 8% on core0 happening, and package power is stuck at around 1.5W idle power, instead of 0,6W which is normal. I never were able to figure out why this is happening. I reported it to Dell, they never wrote back just telling "this laptop doesnt support S3".
OK, I'll close this issue as the problems around the grub shell has been solved. Feel free to contact me via either issue or emails.
One last question on this, for now ^^. Will this actually work on all laptops, or just Dell ones. I guess this method should work on all modern standby laptops, right?
Yes, the AcpiPatcher relies on an ACPI standard, so it will work on all modern standby laptops.
Try this, only the third line is commented out. Should be enough.
AcpiPatcher.zip
Hi,I use this patcher with refind method and get bluescreen,it showed "AMD****.sys error"(It showed within 2 second and reboot).My laptop is lenovo with AMD R5-4600U processor,I don't know why.Does it mean need reinstall windows then use the patcher?
Not sure what would cause this. Maybe AMD or Lenovo broke the ACPI table standards? As I understood, the change the patcher does of bit 21 would be ACPI standard, and would just affect modern standby flag off. Whats the correct name of the sys file, AMD____ what? AMDACPI.sys? Maybe @datasone has an idea what could cause this. You can remove the patcher efi from the refind driver folder from inside an efi shell and then it should boot normally again I guess, and then switch back to Windows boot manager. Those new ZEN2 mobile CPUs are brand new, theyre the first AMD chips I also think which support modern standby. You should be able to directly start/boot the Windows 10 boot manager from your bios via absolute EFI path, or via a EFI shell (look up in this post where datasone explained how to use it). And then Windows 10 also should boot normally, and inside you can restore to Windows 10 boot manager.
Not sure what would cause this. Maybe AMD or Lenovo broke the ACPI table standards? As I understood, the change the patcher does of bit 21 would be ACPI standard, and would just affect modern standby flag off. Whats the correct name of the sys file, AMD____ what? AMDACPI.sys? Maybe @datasone has an idea what could cause this. You can remove the patcher efi from the refind driver folder from inside an efi shell and then it should boot normally again I guess, and then switch back to Windows boot manager. Those new ZEN2 mobile CPUs are bran new, theyre the first AMD chips I also think which support modern standby. You should be able to directly start/boot the Windows 10 boot manager from your bios via absolute EFI path, or via a EFI shell (look up in this post where datasone explained how to use it). And then Windows 10 also should boot normally, and inside you can restore to Windows 10 boot manager.
It's "AmdMicroPEP.sys" with code "SYSTEM_THREAD_EXCEPTION_NOT_HANDLED".I have restored windows boot manager,but modern standby is so annoying and I just want S3 sleep back
Not sure what AMDMicroPep.sys is for, but this https://docs.microsoft.com/en-us/windows-hardware/drivers/bringup/device-power-management suggests it is power related. Weird that setting modern standby flag to disabled causes it to crash. This seems to be a bug or like I said, maybe bit 21 is not for modern standby on this laptop, for whatever reason. Or the ACPI table is somehow different on this AMD laptop, and changing it totally messes it up. Maybe has different data length at all, or a newer ACPI standard like 5.0. @datasone would have a better idea about this I am sure.
I uninstall all the AMD drivers,and windows boot normally this time,but use powercfg /a,it shows only support "Hibernate".I think ACPI in combination with the AMDmicroPEP manage the power policy together and S3 is impossible supported with this laptop.
Sounds like a bug in the AMD driver then I guess, maybe you can report it to AMD directly. Then the laptops firmware doesnt support S3. Sad thing is, this will happen sooner or later with every newer laptops, that they remove all S3 support at all, and they all will just use modern standby. It is a disgusting move and just madness. Just curious, why did you want to disable modern standby on the laptop? Does it work as "amazing" as it does with most Intel laptops? I had higher hopes for maybe it would work better on newer Ryzen laptops. The issue with modern standby is under Windows, that every driver comes from a different developer, if MS would make 100% of the drivers, maybe it would "work" more reliable.
The modern standby drains the battery much more than S3 sleep, and my keyboard backlight is always twinkling during modern standby,when you see the SSD S.M.A.R.T status,you will notice the load/unload cycle increases dozens times.
Sounds awesome (: You should report this all to Lenovo, and make a post about it on their forums. Lenovo is more "open" about bug reports, than Dell for example is. It is a very new CPU + laptop combination, so that it is buggy is mostly "normal". Especially for modern standby, thats not hard to make it run badly...
Does it mean need reinstall windows then use the patcher?
@YDEKQ This may be a case where a reinstall of Windows with S3 enabled from the start is required. If you have a spare HDD lying around, you could try enabling S3 sleep using rEFInd and AcpiPatcher.efi before installing the OS. Then install Windows 10 and then the subsequent Lenovo drivers using their System Update utility.
The part I'm not sure about without digging into it is how to partition your HDD and set up the UEFI part before the OS is installed.
Another thing you could test on your current install (as @makedir alluded to) is just removing the AcpiPatcher.efi driver from rEFInd and still use rEFInd as your bootloader and see if the bluescreen still happens. That would confirm that it's just the patch that's causing your computer to bluescreen and not a different bootloader.
Try this, only the third line is commented out. Should be enough.
AcpiPatcher.zipHi,I use this patcher with refind method and get bluescreen,it showed "AMD****.sys error"(It showed within 2 second and reboot).My laptop is lenovo with AMD R5-4600U processor,I don't know why.Does it mean need reinstall windows then use the patcher?
You may try @hjoelr's suggestion first. The known builds that can switch from modern standby to S3 flawlessly are all Intel's. Maybe AMD's driver are not designed to work in both modes (their software quality is always poor). So a reinstall of Windows may work.
One another reason maybe that the laptop's firmware lacks necessary codes for S3 to work normally (e.g. Intel version of Lenovo's Xiaoxin Pro 13 won't wake from S3 sleep), maybe AMD's driver did something on boot to check S3 sleep availability and then caused BSOD. In that case only the OEM may resolve this problem.
I have reported requirement of S3 sleep with this laptop to Lenovo,they told me S0 is better than S3,but will consider enable Force S3 support on BIOS update.I think some Dell and Thinkpad laptop can enable Force S3,maybe someday this laptop will be supported.