-
-
Notifications
You must be signed in to change notification settings - Fork 69
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Hangs on write into .vdi or .vmdk mounted image #15
Comments
I have tried the Arsenal Image Mounter v3.9.228 and got the same bug but, with slightly different stack trace at ~60GB point. I've took it after termination of the hanged Stack trace of one thread with cycles after
|
I've minimized the reproduction steps and just copy now 40GB single file. It got stuck on ~10GB get copied. I think this somehow related to the physical memory size which in mine case is 64GB. The .vdi file can be created through the Arsenal Image Mounter UI as is. Then updated .NET Desktop runtime up to 6.0.11. Reproduced the issue. Then I've made |
I've updated .NET Desktop runtime up to 7.0.0. The case with the Then I downgraded to .NET Desktop runtime 5.0.17. Run Arsenal Image Mounter v3.6.188 and got the same bug as for the ImDisk without ability to revive the system. The stack trace was looking the same with the WriteFile in the middle. |
Thanks for your report. I'll do some tests soon and see what I can reproduce here. Could this possibly be related to cache of some kind? If you look at Task Manager, memory tab, while this happens, do you notice a huge increase of used memory that slowly drops down to normal levels again during the period where the drive appears hung? Do you notice any differences when the target image file is stored in different locations such as on system volume, external disks, network shares etc? If you want to forcefully remove an Arsenal Image Mounter mounted disk, the best option is usually to use If you kill the |
No. Memory hasn't any noticeable consumption.
I didn't notice the difference. But I've only tested it for 2 volumes from HDD and SSD.
There is no such utility, only
Currently this is the only way to revive the system. By timeout. |
Thanks for testing. I have done some tests here, but I cannot reproduce anything like this.
You need to download
If possible, could you test with |
Can't say it is clearly related to the ImDisk or Arsenal Image Mounter. There is another driver which uses mounting - VeraCrypt. I've feelings it somehow involved into the issue. I am using 1.25.9 has installed over 1.24-update7 using .inf file directly (currently there is an issue with the installation of the last installer on Windows 7 x64 and another issue with uninstalling of a previous version). May be you could test using mine case? |
Thanks for more details, I'll do some tests together with VeraCrypt as well and see what I can find. One thing that really surprises me here, is that you get slower I/O with vhd format. That is usually the fastest and most efficient, since it does not use DiscUtils implementation but instead a separate highly optimized kernel driver implementation. Or more specifically, that is in the case of AIM, maybe you compared performance when using ImDisk instead? Could you try with a mounted vhd in AIM and see if you still get the hang? Also, is it the same if you use Windows built-in features for mounting the vhd (in Disk Management)? |
I have done some tests now with VeraCrypt installed and running as well. I can however still not reproduce any similar problem. |
I've tried to retest the case and got stuck on another issue. If try to run Arsenal Image Mounter and create .vdi or .vhd image then, the app does freeze with the
The Arsenal Image Mounter GUI still usable and I can just remove the item with the exception:
The Arsenal app still shows the But, I've disable all suspicious or relevant drivers before the test: Veracrypt, VirtualBox, ImDisk. Did remove Seems the Veracrypt somehow has forced to load together with the Arsenal driver. Update: |
I would recommend that you search registry for references to veracrypt.sys. I did not expect it to load as a filter driver in another stack in this way, but it seems like it does in your case. Or something else might be interfering in some way. Not sure really what is going on. If you have another machine or virtual machine etc where you can try out configuration changes, could you try and see if you can reproduce it there and if not, which of applications installed can you install there too without this issue happening? |
Got the stack trace from the Process Hacker one of threads has having the cycles. It does change over the time, but the WriteFile been blocked on something. The whole system suffers from WriteFile blocking and none of application can be closed or terminated which had call to WriteFile recently. Even can not be terminated through the Process Hacker itself. The Process Hacker somehow survived that and I could take a single stack dump. Only the hard reset can reset the system, which means it is a critical bug.
Can't say how the notepad could save the stack trace into a file, may be the blocking is not stable.
How to reproduce:
I have reproduced it on both .vdi (fastes coping) and .vmdk (slower, the stack trace is taken from). The .vhd is too slow to reach the 50GB point (< 10MB/s on any files) and might be not affected because of slowness (I feel there is might be some kind of a race condition with high speed writes).
The text was updated successfully, but these errors were encountered: