Whoever solves this Microsoft certificate puzzle, please come forward !!!

Which SkuSiPolicy file did you delete? From the EFI volume on the first or second disk? If you made a second disk with its own EFI volume, that is a different copy of SkuSiPolicy than the first one.

If you picked a specific boot manager or specific boot device, then the EFI volume that belongs to that one has the SkuSiPolicy that is enforced.

EFI volume:

SKUSiPolicy file which I deleted was in the EFI partition of nonbooting Windows. Its EFI partition size is 200 MB and is easily identifiable. Working Windows EFI partition size is 260 MB.

suatcini54 said:

Then I used Rufus v4.14. This was able to format and create the USB drive with CA2023 and SKUSiPolicy. CA2023 and SKUSiPolicy options came checked by default.

Click to expand...

Have you tried it with SkuSiPolicy unchecked?

garlin said:

Have you tried it with SkuSiPolicy unchecked?

Click to expand...

No. This was a test disk. I never used it to repair Windows or anything.

By the way, this is the directory (below screenshot) from which I deleted SkuSiPolicy file. In this directory I also have bootmgfw.efi file. This bootmgfw.efi I just xcopied to this directory today.

You didn't follow the instructions correctly.

1. From diskpart, you assigned the 104 MB EFI volume to drive letter S. The volume is readable now from S:

2. From "mountvol S: /s", you asked Windows to re-assign S: to your active EFI volume. Don't use "mountvol /S" for the other volume.

mountvol

/s Mounts the EFI system partition on the specified drive.

Click to expand...

Thank you all for your contributions. I had to disable Secure Boot and update the non-booting Windows installation with winload.efi Secure Boot violation error.

Unless Microsoft finds solutions to the problems 1) Media Creation Tool can not make really-booting bootable USB flash disks without user intervention and 2) make dual-booting easier to boot in case of SVN increases, I have to bear the burden of tackling the problems myself.

Happy computing.

garlin said:

You didn't follow the instructions correctly.

1. From diskpart, you assigned the 104 MB EFI volume to drive letter S. The volume is readable now from S:

2. From "mountvol S: /s", you asked Windows to re-assign S: to your active EFI volume. Don't use "mountvol /S" for the other volume.

mountvol

Click to expand...

I am sorry for the confusion I had caused. Lesson learned.

Aynı sorunu, aynı adımları takip ederek kendi cihazımda da oluşturabildim. Anladığım kadarıyla teorik olarak secure boot'u kapatmadan yeni bir yükleme medyası/dual boot oluşturabilmek mümkün ancak 2023 sertifikalarıyla imzalanmış tüm dosyaları tek tek değiştirmek gerekiyor. Dolayısıyla pratikte secure boot'u kapatıp, yüklemeyi yapıp tekrar açmak en zahmetsiz yol. MS'in yeni bir ISO yayınlamasını beklememiz gerekecek.

I could reproduce the same issue by following the same steps. AFAIU, while it is possible to create a bootable installation medium/dual boot without disabling secure boot in theory, it takes too much as you'll need to find and replace all files signed with 2023 certs. Therefore, disabling secure boot before installation, and then turn it back on seems the easiest way for now. We'll need to wait for MS to publish a newer ISO.

I can't update SkuSiPolicy to version 3.0.0.16, the recovery partition triggers a winload.efi 0xc0000428 error. I restored an earlier backup yesterday. Today, I tried again but disabled the recovery partition first, it still fails with the same error.

If I understand correctly from this thread, I have to wait for Microsoft to update winload.efi before I can update SkuSiPolicy?

I am now backing up the computers right before updating SkuSiPolicy so I can roll back if necessary.