Yesterday, I myself encountered this problem when I tried to update the 20H2 mirror image pulled from uupdump. It should be solved with the help of a friend who works at Microsoft.
Let me first talk about why this problem occurs. This problem is caused by a problem when UUP Dump is unpacked.
A policy file that should be used for Surface Hub is packaged into the generated image, and then if other devices use this image to perform installation, the policy that should have been given to Surface Hub will be applied incorrectly, and then there will be the problem of not being able to use UEFI boot normally in the post.
Then here is the solution, my system is now 19041.
The following situations are all based on your condition to create a new bootable USB flash drive
First of all, if your device has a TPM, please clean up the TPM of your device. If you turn on Bitlocker, it's better to turn off Bitlocker first, then clean up the TPM, and then turn off the device’s secure boot function.
Next, prepare a bootable U disk, write any non-Windows boot image with EFI Shell (here I used Arch Linux installation image), enter the EFI Shell, enter the following command
dmpstore -d SkuSiPolicyVersion -guid 77FA9ABD-0359-4D32-BD60-28F4E78F784B
dmpstore -d SkuSiPolicyUpdateSigners -guid 77FA9ABD-0359-4D32-BD60-28F4E78F784B
dmpstore -d SecureBootAntiRollbackVersion -guid 77FA9ABD-0359-4D32-BD60-28F4E78F784B
dmpstore -d CurrentPolicy -guid 77FA9ABD-0359-4D32-BD60-28F4E78F784B
dmpstore -d Kernel_DriverSiStatus -guid 77FA9ABD-0359-4D32-BD60-28F4E78F784B
dmpstore -d Kernel_ATPSiStatus -guid 77FA9ABD-0359-4D32-BD60-28F4E78F784B
dmpstore -d Kernel_WinSiStatus -guid 77FA9ABD-0359-4D32-BD60-28F4E78F784B
dmpstore -d Kernel_SkuSiStatus -guid 77FA9ABD-0359-4D32-BD60-28F4E78F784B
dmpstore -d Kernel_SiStatus -guid 77FA9ABD-0359-4D32-BD60-28F4E78F784B
dmpstore -d VsmLocalKey2 -guid 77FA9ABD-0359-4D32-BD60-28F4E78F784B
dmpstore -d RevocationList -guid 77FA9ABD-0359-4D32-BD60-28F4E78F784B
dmpstore -d BootDebugPolicyApplied -guid 77FA9ABD-0359-4D32-BD60-28F4E78F784B
dmpstore -d CurrentActivePolicy -guid 77FA9ABD-0359-4D32-BD60-28F4E78F784B
dmpstore -d BootingDeviceTypeInfo -guid 77FA9ABD-0359-4D32-BD60-28F4E78F784B
dmpstore -d WindowsBootChainSvn -guid 77FA9ABD-0359-4D32-BD60-28F4E78F784B
dmpstore -d SecureBootPlatformID -guid 77FA9ABD-0359-4D32-BD60-28F4E78F784B
dmpstore -d UnlockID -guid EAEC226F-C9A3-477A-A826-DDC716CDC0E3
dmpstore -d UnlockIDCopy -guid EAEC226F-C9A3-477A-A826-DDC716CDC0E3
If you find it too troublesome to type the command line by line, you can create a .nsh file with any name and paste it in. The nsh file is placed in the root directory of the U disk, and then execute fs0:\Your-name.nsh in the EFI Shell, and press Enter.
After this step, you should be able to start any version of Windows installation image or PE, but do not start the system on the hard disk, the problem has not been solved yet.
Next, boot with any PE (I used Linux Live CD), mount the EFI partition of the system. and then make sure that efi\boot\bootx64.efi and efi\microsoft\boot\bootmgfw.efi under the EFI partition, and bootmgfw.efi under C:\Windows\Boot\EFI are replaced with efi\boot\bootx64.efi in the installation image of the current version and the name is changed, and at the same time, delete all the .p7b files in efi\microsoft\boot\ under the EFI partition, and delete C:\Windows\Boot\EFI\winsipolicy.p7b or replaced with the files in the installation disk. After this step, you should be able to enter the desktop.
After entering the desktop, check if there is anything in the CiPolicies and Tokens under C:\Windows\System32\CodeIntegrity except the empty folder, delete all if there is any, and restart the system after doing it. If you need to open the safe boot, you can now.
At this point, the repair should be complete.
As for the principle of this method, my friend said that it is impossible to disclose (involving NDA), but what is certain is that it is not the problem of lack of certificates that was previously guessed on the forum.
