VMXAIOMGR: Retry on write "\\.\PhysicalDrive4" : Access is denied.

[AdamBzh]

Running latest version of workstation.

My Linux system installed on an SSD which connect to computer by a USB-Sata bridge.

Please do not question why I have to set it up in this way, there is a reason but too long too explain.

And this is something that suppose to work, not I'm using it in an unexpected way.

The VM can be started, and will pass Grub, then it will stuck in Systemd loading stage, then I'm getting an error

"The operation on file "\\.\PhysicalDrive4" failed."

I did some research on this issue, if keep ignoring the error, the VM actually boots up, but when doing anything EFI partition related, it will pop again.

The issue seems caused by Windows (my host system) that is blocking ANY write operation to ALL EFI partition, EVEN IF that EFI partition is NOT where Windows boots from.

I also tried fully disable Windows Defender, didn't help, it seems some kind of kernel level protection is enabled, but my system is freshly installed Windows 21H2, I did not enable any additional security features by my self.

Also searched around, there seems no any registry can magically disable this "feature".

Is there any workaround from VMware side?

Here is the log.

2022-01-25T19:51:49.270Z In(05) vmx VMXAIOMGR: Retry on write "\\.\PhysicalDrive4" : Access is denied.
2022-01-25T19:51:49.270Z In(05) vmx VMXAIOMGR: system : err=50002 errCode=5 freeSpace=18446744073709551615
2022-01-25T19:51:49.270Z In(05) vmx VMXAIOMGR: "\\.\PhysicalDrive4" : write s=1048576 n=4096 ne=1, fai=0
2022-01-25T19:51:49.270Z In(05) vmx VMXAIOMGR: v[0]=18EF8A98000:4096
2022-01-25T19:51:49.270Z In(05) vmx VMXAIOMGR: Retry on write "\\.\PhysicalDrive4" : Access is denied.
2022-01-25T19:51:49.270Z In(05) vmx VMXAIOMGR: system : err=50002 errCode=5 freeSpace=18446744073709551615
2022-01-25T19:51:49.270Z In(05) vmx VMXAIOMGR: "\\.\PhysicalDrive4" : write s=1048576 n=4096 ne=1, fai=0
2022-01-25T19:51:49.270Z In(05) vmx VMXAIOMGR: v[0]=18EF8A98000:4096
2022-01-25T19:51:49.270Z In(05) vmx VMXAIOMGR: Retry on write "\\.\PhysicalDrive4" : Access is denied.
2022-01-25T19:51:49.270Z In(05) vmx VMXAIOMGR: system : err=50002 errCode=5 freeSpace=18446744073709551615
2022-01-25T19:51:49.270Z In(05) vmx VMXAIOMGR: "\\.\PhysicalDrive4" : write s=1048576 n=4096 ne=1, fai=0
2022-01-25T19:51:49.270Z In(05) vmx VMXAIOMGR: v[0]=18EF8A98000:4096
2022-01-25T19:51:49.270Z In(05) vmx VMXAIOMGR: Retry on write "\\.\PhysicalDrive4" : Access is denied.
2022-01-25T19:51:49.270Z In(05) vmx VMXAIOMGR: system : err=50002 errCode=5 freeSpace=18446744073709551615
2022-01-25T19:51:49.270Z In(05) vmx VMXAIOMGR: "\\.\PhysicalDrive4" : write s=1048576 n=4096 ne=1, fai=0
2022-01-25T19:51:49.270Z In(05) vmx VMXAIOMGR: v[0]=18EF8A98000:4096
2022-01-25T19:51:49.270Z In(05) vmx VMXAIOMGR: Retry on write "\\.\PhysicalDrive4" : Access is denied.
2022-01-25T19:51:49.270Z In(05) vmx VMXAIOMGR: system : err=50002 errCode=5 freeSpace=18446744073709551615
2022-01-25T19:51:49.270Z In(05) vmx VMXAIOMGR: "\\.\PhysicalDrive4" : write s=1048576 n=4096 ne=1, fai=0
2022-01-25T19:51:49.270Z In(05) vmx VMXAIOMGR: v[0]=18EF8A98000:4096
2022-01-25T19:51:49.270Z In(05) vmx VMXAIOMGR: Retry on write "\\.\PhysicalDrive4" : Access is denied.
2022-01-25T19:51:49.270Z In(05) vmx VMXAIOMGR: system : err=50002 errCode=5 freeSpace=18446744073709551615
2022-01-25T19:51:49.270Z In(05) vmx VMXAIOMGR: "\\.\PhysicalDrive4" : write s=1048576 n=4096 ne=1, fai=0
2022-01-25T19:51:49.270Z In(05) vmx VMXAIOMGR: v[0]=18EF8A98000:4096
2022-01-25T19:51:49.270Z In(05) vmx Msg_Question:
2022-01-25T19:51:49.270Z In(05) vmx [msg.vmxaiomgr.retrycontabort.rudeunplug] The operation on file "\\.\PhysicalDrive4" failed.
2022-01-25T19:51:49.270Z In(05)+ vmx If the file resides on a remote file system, make sure that the network connection and the server where this disk resides are functioning properly. If the file resides on removable media, reattach the media.
2022-01-25T19:51:49.270Z In(05)+ vmx Select _Retry to attempt the operation again.
2022-01-25T19:51:49.270Z In(05)+ vmx Select Cancel to power off the virtual machine.
2022-01-25T19:51:49.270Z In(05)+ vmx Select _Continue to forward the error to the guest operating system.
2022-01-25T19:51:49.270Z In(05) vmx ----------------------------------------
2022-01-25T19:51:53.738Z In(05) vmx MsgQuestion: msg.vmxaiomgr.retrycontabort.rudeunplug reply=0
2022-01-25T19:51:53.738Z In(05) vmx Win32U_GetFileAttributes: GetFileAttributesExW("\\.\PhysicalDrive4", ...) failed, error: 1
2022-01-25T19:51:53.738Z In(05) vmx Msg_Question:
2022-01-25T19:51:53.738Z In(05) vmx [msg.vmxaiomgr.retrycontabort.rudeunplug] The operation on file "\\.\PhysicalDrive4" failed.
2022-01-25T19:51:53.738Z In(05)+ vmx If the file resides on a remote file system, make sure that the network connection and the server where this disk resides are functioning properly. If the file resides on removable media, reattach the media.
2022-01-25T19:51:53.738Z In(05)+ vmx Select _Retry to attempt the operation again.
2022-01-25T19:51:53.738Z In(05)+ vmx Select Cancel to power off the virtual machine.
2022-01-25T19:51:53.738Z In(05)+ vmx Select _Continue to forward the error to the guest operating system.
2022-01-25T19:51:53.738Z In(05) vmx ----------------------------------------
2022-01-25T19:51:54.885Z In(05) vmx MsgQuestion: msg.vmxaiomgr.retrycontabort.rudeunplug reply=0
2022-01-25T19:51:54.885Z In(05) vmx Win32U_GetFileAttributes: GetFileAttributesExW("\\.\PhysicalDrive4", ...) failed, error: 1
2022-01-25T19:51:54.885Z In(05) vmx Msg_Question:
2022-01-25T19:51:54.885Z In(05) vmx [msg.vmxaiomgr.retrycontabort.rudeunplug] The operation on file "\\.\PhysicalDrive4" failed.
2022-01-25T19:51:54.885Z In(05)+ vmx If the file resides on a remote file system, make sure that the network connection and the server where this disk resides are functioning properly. If the file resides on removable media, reattach the media.
2022-01-25T19:51:54.885Z In(05)+ vmx Select _Retry to attempt the operation again.
2022-01-25T19:51:54.885Z In(05)+ vmx Select Cancel to power off the virtual machine.
2022-01-25T19:51:54.885Z In(05)+ vmx Select _Continue to forward the error to the guest operating system.
2022-01-25T19:51:54.885Z In(05) vmx ----------------------------------------

[continuum]

You should avoid to configure the VMDK with "\\.\PhysicalDrive4
Try to use a partitionedDevice and only select what you really need.
Eventually use a second additional small virtual disk for EFI partition or boot partitions.

Ulli

[ab_]

having this same issue with a VM that used to work fine a few months ago running off an internal SSD. not sure what update broke it. did you ever find a solution?

[AdamBzh]

Thanks for reply.

However, if this is a feature of the software, then it should work, instead of telling user "you should avoid use it"

Regarding your advise, the EFI partition IS REQUIRED to boot the system, I cannot leave it out.

Also I tried select partition instead of whole drive, same thing (I even tried boot a Windows To Go, exact same error).

It is clearly either something broken on VMware side or Microsoft.

another EFI partition on VMDK should work as a workaround, but not really as a solution.

[continuum]

> However, if this is a feature of the software, then it should work, instead of telling user "you should avoid use it"

Your optimism is refreshing - keep it up as long as you can.
Reality will sink in early enough 😎

Ulli

[AdamBzh]

well i managed to solve my issue

there are two different issues

for the issue from my original post, it seems caused by Windows UASP not play well with VMware, forgot where i found the post, but after i upgraded my SSD box firmware it works fine now.

for the other issue, here is my log

2022-03-08T12:25:50.346Z In(05) worker-17772 DISK: DiskConfigureVirtualSSD: Disk 'nvme0:0' identified as Virtual SSD device.
2022-03-08T12:25:50.456Z In(05) vmx W32Util_DismountVolumes: Successfully locked volume \\?\Volume{9ac8d115-9b5f-11ec-851d-d43b04b41d7f} on PhysicalDrive2.
2022-03-08T12:25:50.456Z In(05) vmx W32Util_DismountVolumes: Successfully dismounted volume \\?\Volume{9ac8d115-9b5f-11ec-851d-d43b04b41d7f} on PhysicalDrive2.
2022-03-08T12:25:50.457Z In(05) vmx W32Util_DismountVolumes: Successfully locked volume \\?\Volume{9ac8d114-9b5f-11ec-851d-d43b04b41d7f} on PhysicalDrive2.
2022-03-08T12:25:50.458Z In(05) vmx W32Util_DismountVolumes: Successfully dismounted volume \\?\Volume{9ac8d114-9b5f-11ec-851d-d43b04b41d7f} on PhysicalDrive2.
2022-03-08T12:25:50.458Z In(05) vmx W32Util_DismountVolumes: CreateFileW1 failed on volume \\?\Volume{6f8d8363-8dea-11ec-8517-d43b04b41d7f}: 2
2022-03-08T12:25:50.458Z In(05) vmx W32Util_CloseDismountHandle: Unlocking and closing handles for 2 volumes on PhysicalDrive2...
2022-03-08T12:25:50.458Z In(05) vmx W32Util_CloseDismountHandle: Successfully unlocked volume \\?\Volume{9ac8d115-9b5f-11ec-851d-d43b04b41d7f} on PhysicalDrive2.
2022-03-08T12:25:50.459Z In(05) vmx W32Util_CloseDismountHandle: Successfully unlocked volume \\?\Volume{9ac8d114-9b5f-11ec-851d-d43b04b41d7f} on PhysicalDrive2.

everything else looks normal, but what the hell is "\\?\Volume{6f8d8363-8dea-11ec-8517-d43b04b41d7f}: 2"

my drive only have two partition, and vmware somehow try to dismount a third one.

so i searched the guid around in registry, found it under "HKEY_LOCAL_MACHINE/SYSTEM/MountedDevices"

then i did "mountvol /r", it removed some entries, but the one with 6f8d8363-8dea-11ec-8517-d43b04b41d7f still there, it seems system still thinks the device related still connected.

the data saved there says VeraCryptZ, that maybe what it is, so i made sure i dismounted all VeraCrypt volumes, then deleted all three entries contains 6f8d8363-8dea-11ec-8517-d43b04b41d7f

then it works fine after a restart.

but my question is, why vmware think a volume that not located the physical drive is need to be dismounted?

I hope someone saw this and fix the issue.

[AdamBzh]

kind of a late update here, the issue is with VeraCrypt.

if you opened VeraCrypt once then vmware workstation will have this issue, no matter the order.

if you reboot but did not run VeraCrypt, thent vmware workstation is fine.

Looks like to me that VeraCrypt loaded a FS filter kind of driver, and it is not possible to be unloaded due to Windows design issue.

Only solution is to restart your computer, then don't open VeraCrypt, thus it won't load the driver.