I realize you've fixed the problem, but I want to point out what went wrong and how it should be fixed (both by end users and by Ubuntu's developers).
First, Ubuntu's developers have decided -- most unwisely -- to create a GRUB configuration that relies on files in the Ubuntu root (
/) partition, as well as on the EFI System Partition (ESP). This makes GRUB vulnerable to removal of or damage to the Linux partition, and therefore makes it difficult to boot the computer after removing Ubuntu or if the Ubuntu installation is damaged in some way. This vulnerability is unnecessary; it is possible to configure GRUB to look for all its support and configuration files on the ESP. If GRUB were configured in this way (as Fedora does), then deleting Ubuntu would not affect GRUB's ability to redirect to Windows. The system would still boot through GRUB, but it would at least still boot. So, shame on Ubuntu for setting GRUB up the wrong way.
Second, based on the filenames you mentioned, you seem to have run Ubuntu's Boot Repair tool at some point. This tool automatically renames the Windows boot loader,
EFI/Microsoft/Boot/bootmgfw.efi, and places a copy of GRUB in its place. It does the same thing with the EFI fallback boot loader,
EFI/BOOT/bootx64.efi, and drops another copy of GRUB in as
EFI/Microsoft/Boot/bootx64.efi, for reasons that I don't claim to fathom. This is a done as a workaround for a bug in a handful of EFIs. The trouble is that Boot Repair does this by default. On most computers, it is not necessary. When it's subsequently desirable to make changes to the boot configuration, this renaming and replication of GRUB becomes a complication, since users are left guessing about what's going on. So, shame on Boot Repair's developers for being unsubtle about their repairs. (In their defense, though, it would be very difficult for Boot Repair to reliably detect which computers have the bugs that require moving boot files in the way that it does by default.)
One more point is important: In a properly-functioning EFI system, a list of boot programs is held in NVRAM. The EFI tries each of the programs in this list in sequence; if one fails or is absent, the next one is tried. When Ubuntu installs, it adds its version of GRUB to the top of the list. Most EFIs also enable users to specify which boot program to use from a built-in boot manager, but this built-in boot manager is crude on most EFIs.
Sum all these factors up, and the simplest solution to the original problem becomes:
- Undo the Boot Repair tool's changes. This can be done using the Boot Repair tool itself; it has an Advanced Options menu with a check-box called "Restore EFI Backups". Use that and the multiple copies of GRUB will be removed and Windows' boot loader will be restored. Alternatively, this can be done manually. Most importantly, the backup of
bootmgfw.efi (probably called
bkpbootmgfw.efi, although some versions of Boot Repair have used other names) should be copied to
EFI/Microsoft/Boot/bootmgfw.efi on the ESP.
- Delete GRUB in its official/proper location --
EFI/ubuntu/grubx64.efi for Ubuntu. If Secure Boot was active, deleting
EFI/ubuntu/shimx64.efi would be necessary instead. In fact, deleting the whole
EFI/ubuntu directory, or at least renaming it, would do the job in any case.
That's it. With those two things accomplished, the EFI will skip the Ubuntu boot option because it's not longer valid and go on to boot Windows. Some EFIs will also automatically remove the Ubuntu boot option from their boot managers' menus, too, although this practice is not universal.
Note that in your case, Matthew, I don't recommend doing these things; you've got a working configuration, and as they say, "if it ain't broke, don't fix it." You may have a few stray files left on your ESP, but they aren't doing any harm, so it's best to just leave it alone. I've presented my answer in the hope that somebody else will find it useful.