15 replies to this topic

[Olof Lagerkvist]

New beta version of Arsenal Image Mounter
 
We have built a new graphical user interface application for Arsenal Image Mounter. The new application uses Windows Presentation Foundation and makes better use of .NET Framework 4.0 components to adjust the graphical layout to screen resolutions and font scaling.

https://github.com/A...mageMounter.exe
 
The new GUI has some new features. It displays more information about mounted images, like volume GUID values and drive letters and mount points associated with volumes on mounted virtual disks.
 
There have also been improvements to the .NET API as well to make it possible to support the new features. There are for instance now methods to query disk volumes, mount points etc as well as to bring disks and volumes online or offline.
 
In addition to this, there is now also an unmanaged command line tool and API dll that do not require any .NET components. This command line tool is called "aimcmd.exe" and it has a command line syntax very similar to that of imdisk.exe. It should in most cases be easy to switch between imdisk.exe and aimcmd.exe in scripts to switch between mounting with the two drivers. There are also command line switches to install or uninstall the Arsenal Image Mounter virtual SCSI miniport driver.

https://github.com/A...ne applications

aimcmd.zip is the non-.NET command line application. ArsenalImageMounterService.exe is a .NET command line tool with integrated DiscUtils.dll for mounting virtual machine image files using one simple command line tool.
 
https://github.com/A...-Image-Mounter/
 
Description of the new directory structure:
https://github.com/A...y_structure.txt
 
The old "MountTool" GUI and related files and tools are still available in the "MountTool" subdirectory.

 

The GitHub repository directory structure is right now somewhat mixed between an old and new layout. We will try to improve the directory layout in the future but as long as the new things are in beta we keep the old things available at their existing locations as well.

 

There is also a post in the "News" thread that describes the changes.

http://reboot.pro/to...e-5#entry195190

[v77]

In the DriverSetup folder, ArsenalImageMounter-DriverSetup.exe is no longer available, despite the description of the directory structure. Instead, there are ArsenalImageMounterCLISetup.exe and ArsenalImageMounterGUISetup.exe.
I also wonder why this later is much bigger than ArsenalImageMounter-DriverSetup.exe (1.04MB instead of 229KB).

[Olof Lagerkvist]

Thanks for reporting. The description in Directory_structure.txt was actually for ArsenalImageMounterGUISetup.exe. I had mistakenly used the old name but I have corrected that now.

The new driver packages are larger because they also include specific Windows 8 and 8.1 versions and they are for various reasons compressed as zip rather than 7z.

 

Edit: I saw now that there was a similar mistake in the description for DriverSetup\DriverSetup.7z. Corrected that as well and changed the description to reflect that nothing in that archive require .NET.

[misty]

@Olof
Great work. Just completed a very quick test on relatively clean Windows 7 SP1 (32-bit) - the driver installed fine and mounted a raw disk image I'd created using dd (for Windows) - I was then able to partition and format the mounted disk image using diskpart. I liked the previous version of ArsenalImageMounter I tested, however I much prefer the new release without the .NET dependencies.



Misty

[misty]

Also works in WinPE 3.1. I haven't tried integrating the driver - no need as it installed fine in my fairly basic WinPE.

Very well done - thanks Olof

[Olof Lagerkvist]

Thanks a lot for your testing, Misty!

 

[vbox58]

I was keen to try the new Driver V1.06.17 to see if it fixed the problems I had seen with the previous V1.5.14.14 when running under Windows 10.

At first it looked as though the problems had been fixed - I was able to mount and unmount VDI and VMDK files without the ArsenalImageMounter.exe crashing which had previously occurred under Windows 10. (It worked fine under Win8.1)

 

I then put my PC into sleep mode.

When I came to wake up the PC from sleep, the PC turned on but wouldn't show the desktop. I had to reset/reboot the PC.

I tried putting it to sleep again and the same thing happened. I figured it must be to do with the new Arsenal driver so I uninstalled it and went back to the previous version. No more problems with sleep/wake-up.

 

I have tried this on 2 different PCs under Win 8.1 and Win10 with the same results.

 

Hope you can figure out the problem with the new driver which is preventing it from waking from sleep correctly.

Edited by vbox58, 08 September 2015 - 05:27 PM.

[Olof Lagerkvist]

That seems like something I can reproduce. If I install this driver on my laptop it crashes when it wakes up from hibernation/sleep modes. If I disable the virtual SCSI adapter first in Device Manager before entering hibernation or sleep modes, it wakes up correctly afterwards. I'll see what I can find out! Thanks for reporting!

[vbox58]

Glad you were able to reproduce the problem on your laptop, Olof.

I first noticed the problem when my laptop went to sleep and wouldn't resume correctly. I also confirmed that it happens on a desktop PC if it goes into sleep mode.

Not sure if this is the correct forum to ask  - perhaps someone can help me with the command line program aimcmd.exe:

 

Is it possible to use aimcmd to mount a vdi or vmdk file to view the contents in Windows Explorer?

 

I tried using aimcmd -a -f "filename.vdi"

 

The drive is mounted and I can see it in disk manager, but it says it isn't initialised. Do I need to add some other parameters to the command line, or can these files only be mounted correctly through the GUI program?

Thanks for any assistance or pointers.

[Olof Lagerkvist]

I have uploaded a fixed version now. It was all about a stupid mistake made by me a couple of versions ago. The problem I have with this is that most of my tests, particularly automated tests, are done on virtual machines where things like this one are impossible to catch. But I promise to do more testing on physical machines as well!

 

The command line tools are now renamed:

aim_cli.exe (formerly ArsenalImageMounterService.exe)

This is a .NET 4.0 command line tool that has most of the features you find in the .NET GUI application. There are command line switches to mount files like vdi, vhd etc through DiscUtils.dll, which is included embedded in this application.

 

aim_ll.exe (formerly aimcmd.exe)

A non-.NET command line tool with access to most options available in the driver. It is not directly integrated with other libraries though, so it can only mount raw image files, create RAM disks and modify properties for or remove other existing virtual disks. It is possible to mount for example vdi, vhd etc files by running devio.exe and the libraries mentioned in this post and then using proxy command line options with aim_ll.exe to connect to this instance of devio.exe.

 

The syntax will be rather similar to what you would use with ImDisk:

start devio --dll=libsmraw_devio.dll;dllopen shm:proxy1 image_multipart.001+image_multipart.002+image_multipart.003 0
aim_ll -a -t proxy -o shm -f proxy1

(Notice the 0 as last parameter at devio.exe command line, that one is different from when you do this with ImDisk. It tells devio.exe to use the entire disk image and skip partition table parsing and similar.)

 

The new command line applications are available here:

 

https://github.com/A...ne applications

[vbox58]

Thanks for the prompt fix, Olof. All looking good so far.

I've also managed to mount a vdi successfully using the aim_cli.exe , so thanks for the info posted above.

 

I'll let you know if I find any other issues or require further assistance.

 

Thanks again.

[v77]

@Olof:

 

I don't understand what "ll" in "aim_ll.exe" means. Anyhow, it is not obvious, so you should find something else.
Besides, "ArsenalImageMounterService.exe" was indeed a too long file name, but "aim_cli.exe" does not show whether it is the .NET command line tool or the native one.

Therefore, I would rather suggest something like "AIMnet.exe" for the .NET one, and go back to "aimcmd.exe" for the native one, or even "aimcli.exe", but without underscore character because it's ugly.

Anyway, in the current state, this will just bring more confusion, so please do not leave things as is.

[Olof Lagerkvist]

@v77

 

The idea is that aim_cli.exe should be a kind of command line version of the GUI application, with at least close to the same features. The GUI application is called just ArsenalImageMounter.exe and is a kind of "primary" user interface application for using this driver. Therefore, the idea we came up with was that a command line application with similar features should have a similar name but with cli as a suffix, just to clarify that it is a command line interface version.

 

aim_ll.exe stands for "low-level". Probably not entirely obvious and could probably be explained better. But we felt it needed to change to something like this to avoid confusion with aim_cli.exe. This name reflects that it is a kind of "expert user" application with more detailed access to various driver features.

 

But we will of course listen to what users might like, suggest, misunderstand, wish and so on and discuss what we could do to make things easier to understand and use.

[v77]

I was thinking that "cli" was for "client". I sometimes had seen "command line" abbreviated by "cl".

"low-level" ? For me, "native" does not mean "low level"...

In my opinion, a .NET tool should not be considered as the normal thing... (Wonko will like that )

[Olof Lagerkvist]

We are talking about two different tools with different sets of features. They are not just .NET and non-.NET versions of the same thing. Low-level does not refer to "native" vs ".NET" or anything like that. It reflects that this tool is an "expert user" tool to access "low-level" features of the driver. It would have been "low-level" even if it were a .NET application with the same set of features.

 

The other one, aim_cli.exe is simply a command line interface to the features most users would like to use. It does not provide as detailed access to the driver as the low-level tool but is on the other hand more user-friendly in that it integrates with DiscUtils.dll, libewf.dll etc automatically.

 

The .NET based graphical user interface is the "normal thing" in this case. That's what most people use and that's the application that is just called "Arsenal Image Mounter" without any suffix. Therefore, the corresponding command line interface has the same name but with a "_cli" suffix.

 

aim_ll.exe is a quite different thing and is more closely connected to the native API and the driver and built together with them.

[Wonko the Sane]

I was thinking that "cli" was for "client". I sometimes had seen "command line" abbreviated by "cl".

Well, if you use GUI for Graphical User Interface, you need CLI for Command Line Interface.

"low-level" ? For me, "native" does not mean "low level"...

And "native" is actually yet another thing.

In my opinion, a .NET tool should not be considered as the normal thing... (Wonko will like that )

I do, rest assured but it is (unfortunately) the "new normal", OT , and JFYI :
http://social.techne...ation-list.aspx


Wonko