No volumes attached if move vhd from other pc

[lollita]

when move a NTFS vhd from a computer to other i get: No volumes attached. Disk could be offline or not partitioned. I have to reinitialite it and reformat from diskmgmt.msc. Why?

[LTRData]

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.

[lollita]

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.

[LTRData]

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?

[lollita]

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.

[LTRData]

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?

[lollita]

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.

[LTRData]

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.

[lollita]

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 ?

[LTRData]

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.

[lollita]

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?

[LTRData]

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

[LTRData]

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

[lollita]

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

[LTRData]

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.

[jrmoore]

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.

[LTRData]

$ 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.