It's shameful that Parallels seems to be making no effort to resolve this. This didn't work in 15 and doesn't work in 16. I spent a huge amount of time experimenting and poring over logs a few weeks ago and, I think, narrowed the problem (or at least the part of it that results in the <100mb import sizes.) I believe the problem is specific to installations where their drive has only a GPT partition table i.e. it doesn't have a hybrid MBR partition table that mirrors the GPT table. I would expect this to be true of anyone who has purchased a new MacbookPro in the past few years and installed a fresh copy of Windows 10.
The logs seem to indicate that, at first pass, Parallels at least notes the existence of the bootcamp partition properly but that looks more like something primarily for logging purposes. GPT partitioned drives still have a "protective" MBR partition that basically just bookmarks the beginning and end of the drive to prevent a non-GPT aware program from erasing the disk. The first partition on the disk (before the APFS container and bootcamp partitions) is the EFI partition containing the bootloader and some rudimentary drivers. It's formatted FAT32 and on my 16" MacBook Pro is about 300MB. What parallels seems to be doing is coming across the protective MBR header followed by the FAT32 partition and decides that must be the BootCamp partition so it imports that and then when it comes to the end of the partition and there is no more MBR information, decides it's the end of the disk or gives up or something, resulting in a quite useless disk image of the MacBooks' EFI partition. One particularly obnoxious part of this is that it doesn't even generate an error and attempts to boot a VM from the useless disk it just created, which of course finally leads to an error about no operating system installed.
It's also possible there could be some path issues where the process is running as root using relatively paths and therefore pointing to files in root's folder instead of the user's but I was unable to tell if that caused any real problem and could have just been junk in the logs.
So maybe very few customers actually buy a new mac, but a fresh windows install on a bootcamp partition and then decide to import it and that's why Parallel's hasn't bothered to even look at this. It certainly seems like something the software should be capable of and I think there is enough information here to point them in a promising direction. Let's hope they read this.
The logs seem to indicate that, at first pass, Parallels at least notes the existence of the bootcamp partition properly but that looks more like something primarily for logging purposes. GPT partitioned drives still have a "protective" MBR partition that basically just bookmarks the beginning and end of the drive to prevent a non-GPT aware program from erasing the disk. The first partition on the disk (before the APFS container and bootcamp partitions) is the EFI partition containing the bootloader and some rudimentary drivers. It's formatted FAT32 and on my 16" MacBook Pro is about 300MB. What parallels seems to be doing is coming across the protective MBR header followed by the FAT32 partition and decides that must be the BootCamp partition so it imports that and then when it comes to the end of the partition and there is no more MBR information, decides it's the end of the disk or gives up or something, resulting in a quite useless disk image of the MacBooks' EFI partition. One particularly obnoxious part of this is that it doesn't even generate an error and attempts to boot a VM from the useless disk it just created, which of course finally leads to an error about no operating system installed.
It's also possible there could be some path issues where the process is running as root using relatively paths and therefore pointing to files in root's folder instead of the user's but I was unable to tell if that caused any real problem and could have just been junk in the logs.
So maybe very few customers actually buy a new mac, but a fresh windows install on a bootcamp partition and then decide to import it and that's why Parallel's hasn't bothered to even look at this. It certainly seems like something the software should be capable of and I think there is enough information here to point them in a promising direction. Let's hope they read this.
