No volumes attached if move vhd from other pc about arsenal-image-mounter HOT 16 CLOSED

$ aim_ll -a -f PATH_TO_RAMDisk.vhd -o awe -m R:

Creating device...
Created device 000000 -> C:\Portables\RAMDisk.vhd
Device is \\?\PhysicalDrive3
No volumes attached. Disk could be offline or not partitioned.
Done.

The attached drive shows up as having a different size, but directly related to the backing file size:

So my guess is that those two command line arguments aren't interchangeable, perhaps I am missing an option on the second one that is implied on the first.

Yes, this example means an entirely different thing and it is not related to the problem that this thread started with. Your command line adds awealloc but not vhdaccess to the path sent to the driver. This means that there is nothing in the driver stack for the created device that parses the VHD structure in the image file, it will be treated as a raw image file. Similar command line would work for raw image files though, but then you would not get the feature that dynamically allocates and deallocates memory. It will allocate memory for the entire size of the image file.

PS. Other disk formats are not supported, right? Out of curiosity I tried creating the same disk only using VHDX as a format and the output of aim_ll was that it was corrupted and unreadable, didn't test VMDK or VDI.

That is right. The vhdaccess driver only works with VHD image files.

from arsenal-image-mounter.

I would guess that you have formatted it while using devio without 0 as partition number parameter and then use it with that parameter or the other way around. Please try all over again with a new vhd file and make sure that when using devio, you always specify 0.

from arsenal-image-mounter.

I not used devio. Excuse me, I detail:
aim_ll -a -f \?\vhdaccess??\awealloc??\c:\fn.vhd
same command work in pc where vhd created and initialized but not in pc where moved.

from arsenal-image-mounter.

That command does not change the vhd. Have you prepared it with a partition and file system? Does it work if you mount it using Disk Management?

from arsenal-image-mounter.

After I create the vhd I initialized it as GPT then create volume.
This work in pc where create.
I you mount in other pc using Disk Management it result not allocated.

from arsenal-image-mounter.

Sorry for the confusion, but the command line you wrote does not update the vhd file, it just changes a RAM copy of it. What command line did you use to create a partition and file system in the actual vhd image file?

from arsenal-image-mounter.

I not use command line to create a partition and file system.
I only create and initialize (from contextual menu) vhd image file using Disk Management.

from arsenal-image-mounter.

Okay. When you mount the image, is you command line exactly like:
aim_ll -a -f \\?\vhdaccess\??\awealloc\??\c:\fn.vhd

Notice the positions for and number of \ and ? characters.

from arsenal-image-mounter.

Okay. When you mount the image, is you command line exactly like: aim_ll -a -f \\?\vhdaccess\??\awealloc\??\c:\fn.vhd

Notice the positions for and number of \ and ? characters.

aim_ll -a -f \\?\vhdaccess??\awealloc??\c:\fn.vhd
work fine
but when I run aim_ll -l i see:
Image file: ??\vhdaccess??\awealloc??\D:\Alx\temp.vhd
then I run
aim_ll -a -f ??\vhdaccess??\awealloc??\c:\fn.vhd
it work in the same way
Why?
What is the difference between \?\vhdaccess and ??\vhdaccess
?

from arsenal-image-mounter.

Okay. When you mount the image, is you command line exactly like: aim_ll -a -f \\?\vhdaccess\??\awealloc\??\c:\fn.vhd

Notice the positions for and number of \ and ? characters.

aim_ll -a -f \?\vhdaccess??\awealloc??\c:\fn.vhd
work fine
but when I run aim_ll -l i see:
Image file: ??\vhdaccess??\awealloc??\D:\Alx\temp.vhd
then I run
aim_ll -a -f ??\vhdaccess??\awealloc??\c:\fn.vhd
it work in the same way
Why?
What is the difference between \?\vhdaccess and ??\vhdaccess
?

The difference is Win32 paths and native paths. Drivers only work with native paths but user mode applications usually work with Win32 paths.

from arsenal-image-mounter.

Do you mean that

aim_ll -a -f \\?\vhdaccess??\awealloc??\c:\fn.vhd
is a native path

and

aim_ll -a -f \??\vhdaccess??\awealloc??\c:\fn.vhd
is a Win32 path?

from arsenal-image-mounter.

No, the other way around. \??\ indicates a native path and \\?\ indicates a Win32 path.

from arsenal-image-mounter.

Also, if you use a native path directly at command line, you should use -F instead of -f.

from arsenal-image-mounter.

To execute this command need all driver services installated or work also disabling any?

from arsenal-image-mounter.

To execute this command need all driver services installated or work also disabling any?

You need phdskmnt.sys, awealloc.sys and vhdaccess.sys as well as the pnp device object for phdskmnt.sys that is installed by the .inf file.

from arsenal-image-mounter.

I just came across a similar case (perhaps), and while it may do nothing for @lollita since this happened more than a year ago, it didn't feel right opening a new issue with this one remaining open still.

I was first using a VHD I had from a couple of years ago, but after encountering the problem and reading this I recreated it. However I am not entirely sure it is properly formed, the devio details I didn't understand, or perhaps it's just that the two argument lists I used aren't interchangeable. The VHD files are attached in case that helps, they are all essentially an 8 GB variable sized disk with a folder named Temp inside:

• One was created through the Disk Management adding.
• One through Diskpart, since it is also made by Microsoft I suppose it does so in the same manner.
• The last one was using VBoxManage, but partitioned and formatted through Diskpart.

I don't know if the New-VHD command would produce something else, it is the other way of creating them I know of I didn't try because I don't have the Hyper-V component installed.

In any case, they outcome seems to be the same, they get mounted correctly when using the following aim_ll execution:

$ aim_ll -a -f \\?\vhdaccess\??\awealloc\??\PATH_TO_RAMDisk.vhd -m R:

Creating device...
Created device 000000 ->
\\?\vhdaccess\??\awealloc\??\PATH_TO_RAMDisk.vhd
Device is \\?\PhysicalDrive3
Attached disk volume \\?\Volume{abcfc297-0000-0000-0000-100000000000}
Created new volume mount point at R:\
Done.

Occasionally throwing an error for some reason, I can't always replicate it though, so perhaps it is something in the background grabbing a handle on the mountpoint?, it seems to be successfully created nonetheless:

Creating device...
Created device 000000 ->
\\?\vhdaccess\??\awealloc\??\C:\Portables\RAMDisk.vhd
Device is \\?\PhysicalDrive3
Attached disk volume \\?\Volume{abcfc297-0000-0000-0000-100000000000}
  Mounted at R:\
Error setting volume '\\?\Volume{abcfc297-0000-0000-0000-100000000000}\'
mount point to 'R:\': The directory is not empty.
Done.

However, what I thought would be an equivalent set of arguments leads to the problem @lollita was having:

$ aim_ll -a -f PATH_TO_RAMDisk.vhd -o awe -m R:

Creating device...
Created device 000000 -> C:\Portables\RAMDisk.vhd
Device is \\?\PhysicalDrive3
No volumes attached. Disk could be offline or not partitioned.
Done.

The attached drive shows up as having a different size, but directly related to the backing file size:

So my guess is that those two command line arguments aren't interchangeable, perhaps I am missing an option on the second one that is implied on the first.

RAMDisks.zip

PS. Other disk formats are not supported, right? Out of curiosity I tried creating the same disk only using VHDX as a format and the output of aim_ll was that it was corrupted and unreadable, didn't test VMDK or VDI.

from arsenal-image-mounter.