Closed DavidXanatos closed 5 months ago
Thanks for the report!
Since ImDisk is deprecated and very rarely changed nowadays, it has very low priority and it will take a few weeks before I can start looking at it.
Have you looked at alternatives such as Arsenal Image Mounter instead? The aim_cli.exe command line tool mounts images supported by DiscUtils libraries as full disks and is usually better and more compatible with modern Windows versions. https://github.com/ArsenalRecon/Arsenal-Image-Mounter/
And shortly there after the entire system becomes unresponsive and needs to be hard reset.
This part of the stack is suspiciously equal: https://github.com/LTRData/ImDisk/issues/15
11, KernelBase.dll!WriteFile+0x7b
12, kernel32.dll!WriteFile+0x36
13, DomainNeutralILStubClass.IL_STUB_PInvoke(Microsoft.Win32.SafeHandles.SafeFileHandle, Byte*, Int32, Int32 ByRef, IntPtr) + 0xc8 <-- mscorlib.ni.dll+0x63c9e8
14, System.IO.FileStream.WriteFileNative(Microsoft.Win32.SafeHandles.SafeFileHandle, Byte[], Int32, Int32, System.Threading.NativeOverlapped*, Int32 ByRef) + 0x83 <-- mscorlib.ni.dll+0x5ad683
15, System.IO.FileStream.WriteCore(Byte[], Int32, Int32) + 0x5d <-- mscorlib.ni.dll+0x5ad5dd
And shortly there after the entire system becomes unresponsive and needs to be hard reset.
This part of the stack is suspiciously equal: https://github.com/LTRData/ImDisk/issues/15
11, KernelBase.dll!WriteFile+0x7b 12, kernel32.dll!WriteFile+0x36 13, DomainNeutralILStubClass.IL_STUB_PInvoke(Microsoft.Win32.SafeHandles.SafeFileHandle, Byte*, Int32, Int32 ByRef, IntPtr) + 0xc8 <-- mscorlib.ni.dll+0x63c9e8 14, System.IO.FileStream.WriteFileNative(Microsoft.Win32.SafeHandles.SafeFileHandle, Byte[], Int32, Int32, System.Threading.NativeOverlapped*, Int32 ByRef) + 0x83 <-- mscorlib.ni.dll+0x5ad683 15, System.IO.FileStream.WriteCore(Byte[], Int32, Int32) + 0x5d <-- mscorlib.ni.dll+0x5ad5dd
Not really sure what you mean. That is the implementation of writing to a .NET FileStream
by calling Win32 WriteFile
API.
Not really sure what you mean. That is the implementation of writing to a .NET FileStream by calling Win32 WriteFile API.
The dead lock was around the WriteFile in all cases. Looks like the dead lock inside the Win32 API.
Not really sure what you mean. That is the implementation of writing to a .NET FileStream by calling Win32 WriteFile API.
The dead lock was around the WriteFile in all cases. Looks like the dead lock inside the Win32 API.
Yes, but the deadlock is probably in the file system due to some kind of lock needed to flush the write operation, but the same lock is already held elsewhere in the file system mounted on the virtual drive, waiting for the write operation to complete.
I can investigate this in a few weeks probably. But if possible, I strongly recommend trying some other image mounting tool than ImDisk when things like this happen.
Thanks for the report!
Since ImDisk is deprecated and very rarely changed nowadays, it has very low priority and it will take a few weeks before I can start looking at it.
Have you looked at alternatives such as Arsenal Image Mounter instead? The aim_cli.exe command line tool mounts images supported by DiscUtils libraries as full disks and is usually better and more compatible with modern Windows versions. https://github.com/ArsenalRecon/Arsenal-Image-Mounter/
Well the general advantages of Arsenal Image Mounter are in my actual use case more disadvantages, I don't want the mounted images to be visible in Disk Manager. The idea is to mount up to a couple dozen images to folders and use them transparently.
Sometimes less is better LOL, hence a fix would be greatly appreciated.
I have updated DiscUtilsDevio to use latest DiscUtils with some fixes that could potentially solve this. The same changes in DiscUtils has solved similar issues in other projects at least.
https://ltr-data.se/opencode.html#ImDisk
There are now three versions of DiscUtilsDevio. For .NET Framework 4.6, .NET Framework 4.8 and .NET 6.0. If you have .NET 6.0 installed, try that version first. It makes use of several modern optimizations in .NET runtimes. Otherwise, try the 4.8 version.
When using the ImDisk driver with a file image proxy tool like DiskUtilsDevio.exe from the ImDiskTK package writing a lot of files to a 10GB image I can reliably dead lock the entire system (windows 10 22H2 x64)
I attached a stack trace of the worker thread of the DiskUtilsDevio.exe utility.
Inspecting the stack trace of cmd.exe which I used to copy files to the virtual disk, its hanging at the same time in ntoskrnl.exe!CcCanIWrite Ntfs.sys!NtfsCopyWriteA
And shortly there after the entire system becomes unresponsive and needs to be hard reset.