There are several possible things that might be going wrong.
1.) The Kali installer may have installed a traditional BIOS/MBR-style version of GRUB instead of an UEFI version. If your firmware prefers UEFI-style boot over legacy BIOS style, this bootloader will be completely ineffective, as the firmware just won't load the old-style Master Boot Record at all, once it sees that the Windows UEFI bootloader is in place.
2.) The Kali installer may have installed an UEFI version of GRUB, but without the shim.efi that is necessary for Secure Boot - and the Secure Boot implementation of your system's UEFI firmware may silently bypass any bootloader that does not have the necessary Secure Boot signatures, if Secure Boot is enabled.
(Other UEFI implementations will output a scary security error message if Secure Boot is enabled and they encounter a bootloader with a missing or invalid Secure Boot signature. That at least would make this case easier to troubleshoot.)
3.) The Kali installer may have successfully installed a Secure Boot-capable UEFI bootloader, but failed to register it in the firmware NVRAM. Or maybe the firmware implementation will only accept the boot filename of a standard Windows bootloader - that would qualify as a firmware bug.
The first step for identifying between these cases would be letting the system boot to Windows 10, running a Command Prompt as an Administrator, and using the bcdedit /enum firmware command. This will list the boot options registered in NVRAM and the BootOrder settings. If there is no mention of Kali in the output, you can tentatively exclude problem #2 for now - you definitely have at least problem #1 or #3.
If problem #2 seems likely, it can be worked around by disabling Secure Boot, or by clearing the Secure Boot Primary Key (PK) variable. Often (but maybe not always) the UEFI BIOS Setup offers a way to do one or both of these things.
The next step would require booting Kali (or some other Linux) from live USB and using it to gain access to the Kali installation on the HDD. After mounting the Linux partition(s) on the HDD, go to the directory <mountpoint>/usr/lib/grub and list the contents of that directory. If there is a sub-directory named x86_64-efi, you have an UEFI version of GRUB installed and can definitely exclude problem #1.
If, on the other hand, there is a sub-directory named i386-pc, you have a traditional BIOS/MBR version of GRUB installed, confirming problem #1. Fixing it would require chrooting to the HDD-based installation and using the package management tools to replace the grub-pc and grub-pc-bin packages with grub-efi-amd64[-signed] and grub-efi-amd64-bin respectively. (If you cannot disable Secure Boot, get the -signed version of the first package if available, and also the shim package.)
If it turns out you have problem #3, you can fix it by using the efibootmgr command in your Kali Live USB - but only if that Live USB is bootable in the UEFI native style. If the Live USB is booting in the legacy BIOS/MBR style, the legacy compatibility firmware code will hide away the interface that is needed by the efibootmgr command.
Alternative tools for fixing problem #3 in the Windows side:
- there used to be a program named
EasyUEFI from the same manufacturer as EasyBCD. Even the completely free version of that program would have been sufficient. Unfortunately, only a trial version of it is now available for free.
- there seems to be a program called
BOOTICE from a Chinese developer that apparently could do the job. I haven't tested it.
- I think Windows 10's native
bcdedit command might be able to register a new UEFI bootloader, but the procedure seems a bit awkward and I haven't tested this.
- You can use
mountvol X: /S as an administrator to gain access to the EFI System Partition in Windows. Once done, hide the ESP again with mountvol X: /D.
