All VMs abort when trying to resume

[KT]

I have two Linux (Ubuntu) VMs and one Windows 7 VM running on an OS X 10.6.8 host, all of which I have been using without trouble for more than a year.

Yesterday, after updating to VirtualBox 4.2.1, all of them abort when trying to resume from being suspended.

The error message displayed is:

Result Code:
NS_ERROR_CALL_FAILED (0x800706BE)
Component:
ProgressProxy
Interface:
IProgress {c20238e4-3221-4d3f-8891-81ce92d9f913}

Attached is the VBox.log for one of those aborted resumes.

Has anyone seen anything like this? I use these VMs regularly for testing, and I would really like to not have to restart them from scratch each and every time.

[mpack]

The log says it is failing to restore a saved state. Did you upgrade VirtualBox while the VM was in a saved state? Not a good idea. You'll have to discard the saved state, and frankly I recommend that you get out of the habit of using that feature, that way you won't have to remember which VMs have used it when you upgrade.

[KT]

The log says it is failing to restore a saved state. Did you upgrade VirtualBox while the VM was in a saved state? Not a good idea. You'll have to discard the saved state, and frankly I recommend that you get out of the habit of using that feature, that way you won't have to remember which VMs have used it when you upgrade.

Yes, the VMs were probably all suspended when I updated VBox. However, they've all since been aborted (multiple times) attempting to resume. Are you suggesting that a VM created on an early version of VBox can never be resumed on a more recent version? (I don't think that's what you're saying, because I've never had a problem before.)

Also, when you say get out of the habit of using that feature, do you mean suspend-resume? Because that would seem...inconvenient. It would be dismissing a large part of the usefulness/functionality of VBox.

[mpack]

I'm suggesting that memory dumps are dependant on architecture - obviously.

[michaln]

Are you suggesting that a VM created on an early version of VBox can never be resumed on a more recent version?

No. Although there's only so far you can "jump", i.e. restoring VirtualBox 1.6.x saved states with version 4.1.x is definitely not supported. (Which is not to say that it definitely won't work, just that it doesn't, no one will be particularly interested in hearing about that.)

Also, when you say get out of the habit of using that feature, do you mean suspend-resume?

Yes, that's what he means... but he's also not an official Oracle spokesperson (I'm not either, by the way).

Two thoughts. One, it would be nice to know which VirtualBox version you upgraded from. Two, you should really be using the bug tracker (https://www.virtualbox.org/wiki/Bugtracker) for this, not the forum. In this case you have something that clearly looks like a bug, you have a log file which contains at least the proximate cause of the problem, so you should first search existing tickets and if none applies, create a new one. You don't really need to ask whether it's a bug or not

[KT]

Thanks. A bug report: will do.

[mpack]

I have to say that I don't see how this can ever be taken seriously as a bug. ISTM obvious that you can never (in general) be sure of your ability to restore a system to a certain state once a major component of that system has been changed. Obviously if the change is small then you may get away with it... but like I said you could never be sure.

[michaln]

This is a bug, and I don't think it has anything to do with VirtualBox version differences. I strongly suspect that the VirtualBox upgrade is a red herring as we have seen sporadic reports for this issue before. It seems to be fairly difficult to trigger, or at least needs a very specific configuration.