VMDK Mount and write makes computer totally unusable at all sometimes

[githubsearcher11]

Hello. Thanks for making this tool. as VMWare people given up the feature to mount VMDK in windows platform, this is indeed valuable tool for me to make jobs done in sane manor.

Unfortunately, Since ImDisk's (i believe AIM is inherited from ImDisk) last version and till latest version of AIM, there's very nasty bug which totally hangs system(e.g. process creation, data saving, shutting down at all, you must have to force shutdown your computer with total loses of your works :( ) when sometimes you tries to write on mounted VMDK filesystem.

As i don't have any knowledge for debugging windows drivers, i cannot explain more deeply than this (and seems like there's no such debugging log for me to post either..). But seems like nobody reporting this so im doing it.

I'm experiencing this nasty bug since 2020, must be the kernel module that is responsible for this sort of issues..

[githubsearcher11]

also, no such BSOD happens but only hangs system and always triggered file for writting gets corrupted.

[LTRData]

Thanks for your report! I am running some tests now and see if I can reproduce something similar. By the way, have you tried the latest AIM version, 3.11.279?

[githubsearcher11]

Hello. Thank for looking into this issue. i used 3.10.262, will try with more latest version that you suggested. (but im quite sure it will happen again as this seems to be fault of kernel driver..)

[LTRData]

Thanks for testing the new version. I also doubt it would help, but since there were some fixes done in the kernel drivers in this version, there is a chance that it could have an impact.

Also, communication between the kernel driver and the user mode backend that implements the file format support was changed completely, as well as several fixes in DiscUtils libraries that provides support for vmdk and other formats.

I ran some tests yesterday but could not reproduce any similar behavior as the one you mention. There is a possibility that there could be interfering driver behavior with some other installed driver that could cause this too.

[githubsearcher11]

Understood, for now the latest version seems to be stable when compared with older version (ImDisk and AIM 3.10.262 triggered this bug a lot, like 2 times per day when saving/writing is frequently made to mouted VMDK). will update this when if it gets triggered even with current latest version.

and again, thanks for your attention to this :)

[LTRData]

By the way, ImDisk driver is not involved here. The current AIM driver version is 1.2.14.73. It is possible to check version with aim_ll --version or aim_cli --version.

[githubsearcher11]

Hello. after some testing this seems to be reproducible on my side, even on latest version. however, i do indeed use third party driver as you mentioned above, and i also think in this way as seems like nobody experiencing issues like this.

This bug is so nasty to track down as the third party driver i'm using never makes this sort of issues if i doesn't load VMDK via AIM, and vice versa. also most importantly it never BSODs so i cannot make any sort of dumps :(

May i ask some ways to diagnostic how/what sort of driver are interfering? as the machine itself doesn't makes BSOD, it's really hard to diagnostic this sort of issues. would would driver loading order can be related with this (as first loaded driver has priority for IRP... etc)

[LTRData]

Usually, these kind of issues in the past have been related to filter drivers for file system or disk volume stacks, often installed by antimalware applications of various kinds. In some cases we have found out workarounds, have made small adjustments in our driver so that filters see a behavior more closely aligned to what they expect etc. But it is difficult to find out without seeing it in a debugging environment.

You could try to activate Driver Verifier for all installed drivers (verifier.exe in system32 directory). It adds a lot of checks to driver behavior and will cause BSOD more frequently when drivers misbehave in some way.

[githubsearcher11]

Closing as i'm unable to pinpoint and proper debug this issue. skill issue on my side..

[rimaxr]

Hello everyone,

I am encountering the same issue across all versions. The problem arises when you enable write cache on a local disk, and it exacerbates if the local disk has a higher write speed (SSD/NVMe). You can reproduce the issue by mounting a VHD image from a Linux Samba or an iSCSI drive and enabling write cache. Initially, it starts writing the differential file, but after a while, the write speed drops to 0, and the computer hangs. It appears to be losing access to the virtual drive.mipos we tried in windows 10 full or not full updated and windows 11 with the same behavior! I will give you the commands that i use to help you reproduce. 1 .VHD c:\ArsenalImageMounter\aim_cli.exe /mount /filename="\x.x.x.x\Name.vhd" /writeoverlay=C:\LocalDiffs\Name.vhd.diff

2. ISCSI c:\ArsenalImageMounter\aim_cli.exe /mount /readonly /provider=DiscUtils /filename=\?\PhysicalDrive2 /writeoverlay=C:\LocalDiffs\Name.diff