Session.Console is null if VM not running

[jdaley]

I'm trying to restore a snapshot using C#:

Code: Select all

IMachine machine = virtualBox.FindMachine("VM1");
Session session = new Session();

machine.LockMachine(session, LockType.LockType_Shared);

IConsole console = session.Console;
ISnapshot snapShot = machine.FindSnapshot("Snapshot");
IProgress snapShotProgress = console.RestoreSnapshot(snapShot);

If the VM is not running, session.Console is null, and thus the call to RestoreSnapshot fails. My reading of the docs and other forum posts is that the console should be available after locking the machine, regardless of whether the VM is running or not? Is this correct?

I have tried reinstalling VirtualBox and rebooting the host with no luck. The VM works fine in the VirtualBox GUI. I can start it, stop it, and restore snapshots. If the VM is running, the C# code retrieves the console object fine, but I need to restore the snapshot while it is not running.

Why would console be null?

Nothing appears in the VBox.log file when I run the C# code. Nothing jumps out when I inspect the session and machine object properties - the session state is locked, the machine "accessible" property is 1 - I don't really know what to look for though. What else can I check?


Host: Windows Server 2008 R2 64-bit, VirtualBox 4.3.12 r93733
Guest: Windows 7 Home Premium 32-bit

[noteirak]

Are you the person who also asked on the dev mailing list?

[jdaley]

Are you the person who also asked on the dev mailing list?

No, that wasn't me, but that is some coincidence.

I found the mail you are talking about: https://www.virtualbox.org/pipermail/vb ... 12426.html

My problem was the same. Visual Studio sets "Prefer 32-bit mode" flag by default on new projects. Changing the project to run as a 64-bit process has fixed it.

[talr]

Hi,

I can can confirm that the bug still exists in version 4.3.20.

According to another forum post (sorry, can't post link):

"Ah right, this *is* one of the remaining todos... in general our COM
components are both available from 32 and 64 bit processes (was a rather
complex exercise to get this done, there is virtually no documentation),
but the Console stuff currently still contains a technical problem
(linking issue) in the 32 bit variant and is therefore "left out".

You now use it from a 64 bit process, and thus the problem is gone.

Klaus"


The COM API is not complete for 32 bit.

We can't build our SW as AnyCPU, and it must be x86 built.
with the current COM bug, we can't do any operation that requires a console object if the machine is down, like doing a restore snapshot which can be done only when machine is off.

1. What is the state of solving this bug? this is a real blocker for us, as we use Visual Studio and C# (hence using COM), going for another VBox front-end will requires a lot of effort and time
2. Will the current COM implementation work at all on x86 Windows? we only tested it on x64 windows