Cool!
Since the error message "The operation on file ### failed" can occur for all sorts of different reasons (including failing hard disks), and there is a risk that folks might try to apply this fix to situations in which it will not help (and then this thread will be congested with angry replies saying "THIS DOESN'T FIX IT!") I will add some more explanation here to help folks who might find this thread in future...
In the vmware.log here, we have the following:
2020-04-27T11:00:44.928-05:00| vcpu-1| I125: AIOWIN32C: '\\.\PhysicalDrive2' : Failed to read: The parameter is incorrect (87).
2020-04-27T11:00:44.928-05:00| vmx| I125: VMXAIOMGR: Retry on read "\\.\PhysicalDrive2" : The parameter is incorrect.
2020-04-27T11:00:44.928-05:00| vmx| I125: VMXAIOMGR: system : err=570002 errCode=87 freeSpace=18446744073709551615
2020-04-27T11:00:44.928-05:00| vmx| I125: VMXAIOMGR: "\\.\PhysicalDrive2" : read s=71739411456 n=1024 ne=1, fai=0
2020-04-27T11:00:44.928-05:00| vmx| I125: VMXAIOMGR: v[0]=242D38BA131:1024
The key part out of all of that gibberish is the error code, 87, which MSDN tells us is ERROR_INVALID_PARAMETER which is described as "The parameter is incorrect". This means we asked the Windows host OS to perform a disk I/O operation which it believes we should have not even asked of it... Basically, the host OS is slapping us on the wrist and telling us to please not do that again. (Which we then do, several times, but oh well.) The I/O request was most likely never even sent to the disk.
I've also highlighted three numerals on the last line, because that piece before the ":" tells us why the parameter was invalid... When opening a physical disk, we open it in "direct" mode (FILE_FLAG_NO_BUFFERING), which makes those I/Os about as fast as they can possibly be, but it also requires that our I/O requests be performed in a multiple of the disk's sector size, and in a memory buffer which is aligned to the sector size. The line starting with v[0] gives the address and size of the I/O buffer we gave to the Windows host OS... The 1024 byte buffer size will be a multiple of the disk's logical sector size, so that's fine, but the address should end in [02468ace]00 if it is going to be sector-aligned. It is not... it ends in 131. The guest has asked us to perform I/O to an unaligned guest memory address, which is well within its right to do, but still is a rather odd thing to do... and we have passed that I/O to the host OS basically unchanged, but the host OS is not OK with the unaligned access, and that causes the failure.
So, to recap, where we are sending an unaligned I/O to the host OS (address ending in something other than 000, 200, 400, 600, 800, a00, c00 or e00, or length not a multiple of 512), and where the resulting errCode is 87, enabling bounce buffers is an appropriate fix: It will cause Workstation to reformulate the I/O in a slightly less-efficient way but which will ensure that it will meet the alignment requirements of the host OS.
There, more information than you ever needed or wanted to know about what happened here and why that fix worked.
Thanks,
--
Darius