Windows – How to find out which EFI system partition is in use by Windows 10

This sounds like Windows doesn't like the FAT32 that's currently written to your /dev/sda1. Perhaps the disk once used NTFS and Windows is finding some remnants of that...? Working off of that (admittedly iffy) hypothesis, you might try this:

1. Back up the ESP. A file-level backup using cp, zip, tar, or something similar should suffice.
2. Unmount the ESP.
3. Wipe the ESP completely clean with dd, as in dd if=/dev/zero of=/dev/sda1. Be very careful with this command! If you specify the wrong partition, you'll be in deep trouble!
4. Create a fresh FAT filesystem on /dev/sda1, as in mkdosfs /dev/sda1.
5. If necessary, update /etc/fstab with the new filesystem's "UUID" or label.
6. Type mount -a to re-mount the partitions, including the ESP.
7. Use df /boot to double-check that the ESP is correctly mounted.
8. Copy the backup back to the freshly-formatted ESP.
9. Double-check that your critical files (your kernel and boot loader) are present.

You could do something similar using a Windows emergency disk if you wanted to ensure that the filesystem is something that Windows will find palatable; but I don't know the specific commands you'd use to do this in Windows.

Another possibility that occurs to me is that Windows might have a bug that's causing it to misidentify your ESP because of its size. For a while, Windows created an ESP of just 100MB, IIRC. I think that it's bigger than that now, but it's still well short of the 1GiB ESP you've got. Presumably you've made it that size because you're storing Linux kernels there, which is a common practice among Arch users. This size is therefore quite justified, but if it is causing Windows to flake out, you might need to delete the ESP and re-create it as two partitions -- either create two ESPs, one for Windows and one for Arch; or create one /boot partition for Arch and another ESP for both OSes, to be mounted at /boot/efi in Arch. Personally, I think this explanation is far less likely than that Windows is seeing stray (old) data or some slightly malformed FAT data structures and is flaking out. After all, Windows can handle much larger FAT data partitions. Still, if re-creating the ESP as outlined earlier doesn't work, splitting it into two partitions might be worth trying.

I managed to create a copy of Windows EFI.

First, I mounted EFI partition with diskpart:

> diskpart      # start diskpart tool
list volumes    # prints all disks I have: C:, D:, etc
sel vol 8       # on my list EFI partition was unmounted and next to a number 8
assign letter=Z # since I marked EFI partition as selected I can now assign it a letter so that I could use it later on
exit            # I am leaving the tool

Earlier on it failed - when I tried to use assign mount=z I saw error like "cannot mount system EFI partition" even though help command suggested it.

With EFI mounted I could

bcdboot C:\Windows /s Z:

It puts Windows EFI files into EFI partition without affecting existing grub files. As a result grub didn't broke but I now have files required to boot windows in UEFI setup.

After that os-probe was able to find Windows, so update-grub added missing entry to the list.

I guess if someone would find himself in the same situation as I did they must be prepare that:

• windows will create several new partitions, and EFI will be one of them
• since that partition will have about 100 MB and I think it is suggested that it should be bigger we can replace it with one provided by us (plenty of good resources on how to do that, both on Arch wiki and on Microsoft docs depending on which tool we'll use)
• before that we can make a copy of files with windows EFI partition - they are hidden if you cannot see them - or remove it as I did and then go though all the procedure above. You would need Windows installation CD for that.