Why Does a Win10 Drive Cloned with DD or GParted Have GRUB?

I have a desktop computer with Windows 10 installed on its sole internal (NVMe) drive. I boot this machine with Ubuntu 22.04, installed on a USB drive. In Ubuntu, I use GParted to copy partitions from the NVMe drive, or run dd to clone the whole NVMe drive, to an empty 256GB USB drive.

Then I attempt to boot the USB drive. Either way (i.e., whether cloned with GParted or dd), the 256GB USB drive's boot process ends with this message:

GNU GRUB version 2.06

Minimal BASH-like line editing is supported. For the first word, TAB lists possible command completions. Anywhere else TAB lists possible device or file completions.

grub>

If the clone was imperfect, I would expect to see a Windows message, or a Windows boot repair screen. But why does GRUB enter the picture?

None of these drives have ever been used in a dual-boot system. I may have used the USB drive for a bootable Ubuntu USB installation, but I always delete all partitions on a disk before installing a new system. So I don't know how GRUB managed to arrive and persist on any of these drives.

I'd like to understand why a supposedly identical clone produces an error that does not appear when booting the source drive. If there's a fix, of course, I'd like to have that too.

So far, I have a partial answer. The part I can answer comes at the end of my question: what is the fix? A simplified version of the fix that removed GRUB from the GPT system drive on my machine was as follows: in Windows 10, use a partition editor (I used MiniTool Partition Wizard) to assign a drive letter (let's say drive F) to the FAT-formatted EFI (or, in my case, ESP) volume. In an admin cmd window, use F: and then DIR to see the EFI folder. Use CD EFI to get into that folder, DIR to view its contents, and RMDIR /S UBUNTU to delete the Ubuntu boot directory, assuming DIR displays such a directory. Back in MiniTool, remove the drive letter. If that doesn't work, the linked source has other possible solutions.

Regarding the mystery of how an Ubuntu boot partition could appear on the clone but not on the original drive, the comment by user535733 appears correct: there was such a partition on the source drive as well. That still leaves the question of why the Ubuntu boot partition came alive when I booted the target USB drive, but did not disrupt booting of the source SSD.

Finally, on the question of how the Ubuntu boot directory got onto this all-Windows system in the first place, the situation remains unclear. I don't think I ever even tried a dual-boot setup on that machine. I am left to wonder whether a USB-booted tool like Yannubuntu's Boot Repair Disk could have added such a directory.

In any case, the fix removed the last barrier to creation of a bootable Windows 10 installation on a USB thumb drive.