VERR_SSM_UNEXPECTED_DATA, when I attempt to resume a saved Virtual Machine -> Fixed in SVN

Could you retry with 1.6.2 and include the VBox.log file of the failing resume here?

VirtualBox Log File

I also get this error every time I try to restore my saved VM. Here are the exact things I do:

1. Save my Windows XP Pro SP3 virtual machine. 2. Shut down my Ubuntu 8.04 host machine. 3. Boot back into Ubuntu and start VirtualBox. 4. Start my XP VM.

The progressbar goes all the way across, and then I get this error. It has happened without fail every time and is quite annoying.

I have attached my VirtualBox log file for more information.

Forgot to mention I am using VirtualBox 1.6.2 (Closed source edition).

host: Gentoo, amd64; guest:WinXPSP3

I started having this error every now and then when I try to restore a saved machine state on VirtualBox-1.6.2 (binary).

It seems that if I save the state, then start the VM there is NO problem, I cannot reproduce it.

If I do something (say restart X), I get this problem sometimes.

Any ideas for further testing?

I just got this same error for the first time. Host is Ubuntu Linux 8.04. Guest is Windows XP SP2. I had suspended the VM, them hibernated my Linux host. Upon resuming my Host, I then tried to resume the Guest, and it resulted in the error above.

Only things I can think of would be the facts that one of my shared folders would not have been available on the Host, and my CPU speeds may not have been the same as when the Guest was saved (Intel Core 2 Duo).

My log file is attached.

Ubuntu 8.04 (host). XP SP2 (guest).

Hmm, if a shared folder is not available during resume you would not be able to resume the VM, the GUI would refuse to load the settings (this is another bug which has to be fixed). But your attached log file clearly states that the HGCM unit (which is responsible for shared folders, shared clipboard and some other mechanisms) is causing this problem. The changing CPU frequency doesn't matter here.

hey. got same error, after doing a snapshot save, & then trying to restore. host Ubuntu Hardy (8.04) & guest Win XP, VBox 2.0.

this worked for me: recompile the package/application.

for my install (a default one), the command in Ubuntu 8.04 was "sudo /etc/init.d/vboxdrv setup"

hope this serves as a temporary fix for some. i haven't checked yet if you must do this everytime or not.

for the techs, i had tried using VBoxManage to start my VM a couple times, & might've thrown something off that way (just used sudo VBoxManage --startvm "winky" - but that didn't work, & seemed to go into some VRDP(?) mode for a bit, so i had to recompile & that fixed it). but you should note, it *WAS WORKING* after i did the command line stuff, so i think it's just the snapshot that did it.

thanks for great free software, btw! =)

Just hit this same bug. I had set up an external drive as a shared folder, then did some combination of suspending the VM, unmounting the drive, resuming the VM, etc. (probably several suspend-resume cycles). When I reconnected and mounted the drive again, I got the indicated error message.

Fixed by unmounting the external drive (so the shared folder location didn't exist). That was a workaround...

I've also stumbled upon this bug. It is probably related to some shared folder that might have changed its state or maybe have become unavailable. I don't remember exactly what folder I had mounted, and what folders I changed.

The lack of useful information at the error message isn't helping either.

Shared folders shouldn't prevent the VM from restoring its state.

VirtualBox 1.6.6 (closed source version) running on Gentoo amd64, with Windows XP as guest.

This happened when there is a temporary shared folder. With XP and XP in virtual box 2.2.2: 1-Start vm (with 2 permanent shared folders), save state : resume ok. 2-Start same vm, add temporary shared folder on c:\, save state : resume error.

Replying to Tahiti:

This happened when there is a temporary shared folder. ..., add temporary shared folder on c:\, save state : resume error.

Exactly the same here. This is a way to reproduce this bug.

I've also encountered this error today, and the only thing I did different to before was adding a temporary shared folder "Stick" mapped to drive F:\, which was a 2G USB drive I needed to transfer some data.

Here's what happened (full log attached):

00:00:04.007 Changing the VM state from 'CREATING' to 'CREATED'.
00:00:04.007 SharedFolders host service: adding host mapping.
00:00:04.007     Host path F:\, map name Stick, writable 1
00:00:04.007 SharedFolders host service: add mapping result VINF_SUCCESS
00:00:04.007 SharedFolders host service: adding host mapping.
00:00:04.007     Host path C:\Temp, map name Temp, writable 1
00:00:04.008 SharedFolders host service: add mapping result VINF_SUCCESS
00:00:04.008 Changing the VM state from 'CREATED' to 'LOADING'.
00:00:05.443 SSM: File header: Format V1.2, VirtualBox Version 2.2.2 r46594, 32-bit host, cbGCPhys=8, cbGCPtr=8
00:00:08.898 TM: cTSCTicksPerSecond=0x9e8c5a00 (2659998208) fTSCVirtualized=true  fTSCUseRealTSC=false (state load)
00:00:08.903 PIT: mode=2 count=0x4ad (1197) - 996.81 Hz (ch=0) (restore)
00:00:08.903 RTC: stopped the periodic timer (restore)
00:00:08.903 SharedFolders host service: connected, u32ClientID = 1
00:00:08.903 SharedFolders host service: loading state, u32ClientID = 1
00:00:08.903 SSM: LoadExec failed with rc=VERR_SSM_UNEXPECTED_DATA for unit 'HGCM'!
00:00:08.952 Changing the VM state from 'LOADING' to 'LOAD_FAILURE'.

So it looks like restoring state for temporary folders is b0rked - it doesn't matter if I actually re-connect the USB drive or not, I still get the same error.

I've tested this again on version 2.2.2. It seems to be fixed in that version, because the temporary folders are restored with the machine state.

Not sure if 2.0 has it fixed or not, but I know that 2.2.2 works for me.

Doesn't seem fixed to me; I added another permanent shared folder to a folder on my C: drive yesterday, closed down the VM with saving it's state and today I'm greeted with yet another

00:00:03.221 VirtualBox 2.2.2 r46594 win.x86 (Apr 27 2009 19:32:09) release log
00:00:03.221 Log opened 2009-05-28T10:33:40.248144300Z
00:00:03.221 OS Product: Windows XP Professional
00:00:03.221 OS Release: 5.1.2600
00:00:03.222 OS Service Pack: 2
00:00:03.222 Package type: WINDOWS_32BITS_GENERIC
[...]
00:00:03.992 SharedFolders host service: adding host mapping.
00:00:03.992     Host path C:\Download, map name Download, writable 1
00:00:03.992 SharedFolders host service: add mapping result VINF_SUCCESS
00:00:03.992 SharedFolders host service: adding host mapping.
00:00:03.992     Host path C:\Temp, map name Temp, writable 1
00:00:03.992 SharedFolders host service: add mapping result VINF_SUCCESS
00:00:03.992 Changing the VM state from 'CREATED' to 'LOADING'.
00:00:05.364 SSM: File header: Format V1.2, VirtualBox Version 2.2.2 r46594, 32-bit host, cbGCPhys=8, cbGCPtr=8
00:00:08.819 TM: cTSCTicksPerSecond=0x9e8a8c00 (2659879936) fTSCVirtualized=true  fTSCUseRealTSC=false (state load)
00:00:08.824 PIT: mode=2 count=0x4ad (1197) - 996.81 Hz (ch=0) (restore)
00:00:08.824 RTC: stopped the periodic timer (restore)
00:00:08.824 SharedFolders host service: connected, u32ClientID = 1
00:00:08.824 SharedFolders host service: loading state, u32ClientID = 1
00:00:08.824 SSM: LoadExec failed with rc=VERR_SSM_UNEXPECTED_DATA for unit 'HGCM'!
00:00:08.835 Changing the VM state from 'LOADING' to 'LOAD_FAILURE'.

I just triggered this when trying to resume a Windows (2000) guest from my linux host with a (temporary) shared folder that no longer existed. Recreating the shared directory on the host allowed the guest to resume. The error message for this problem is not entirely obvious :)

Indeed, not fixed. I've stumbled upon this bug again with version 2.2.2.

The "best" fix could be to emulate an empty shared folder for folders that don't exist anymore.

Also, a descriptive error message, explaining exactly what went wrong, and why it went wrong, would be very helpful. Something like: "Could not resume the virtual machine because the shared folder 'foobar' (/home/something/somedir/foobar) is not available."

Windows 7 vbox.log

I have the same issue on a Gentoo Amd64 host, Win7 Guest, Virtualbox binary 2.2.4. I believe my problem also relates to a shared folder which was unmounted when I tried to resume the saved VM. VM now refuses to resume the saved VM even after mounting the relevant directory.

Could not reproduce the problem. Could you please describe how to reproduce it in details? Thanks.

Same problem with VB 2.2.4 (host is Mac OS X 10.4.11, guest is WinXP SP3).

I deleted a shared folder on my Mac desktop but forgot to remove it from the list of shared folders in VB. Booting the guest was fine without any errors, saving the state was fine without any errors, but starting from saved state always failed (just after loading seemed to finish).

Removing this (non-existant anymore) shared folder within VB solved this issue. (BTW: Didn't try to start from saved state with changed shared folders, just tried a fresh boot without bogus shared folder, save state, load state.)

VirtualBox 3.0.0 beta has more detailed logging when such a problem occur. Please could anyone reproduce the problem with VBox 3.0.0 and attach Vbox.log to the ticket? Thanks.

FWIW, I had this same error on Mac OS X 10.4.11 with a VM with 2 shared folders when 1) I had VirtualBox running as a normal application but no virtual machines running, and 2) I attempted to start a virtual machine using loading launchctl item which starts a VM with VBoxVRDP.

After I quit VirtualBox as an application and waited for VBoxXPCOMIPCD and VBoxSVC to exit (not sure they did it voluntarily, I also tried killing them from command line), I could then start the headless VM from launchctl just fine. After launchctl had done its job starting the VM, I could also use VirtualBox as an application just fine to start another VM.

So it looks like there is something wrong in the environment started by launchctl that prevents VBoxVRDP from talking to daemons that already run, but if those daemons are started from launchctl environment, the application will be happy to talk to them. This is of course just speculation. I didn't try 3.0.0 beta nor removing shared folders.

Finally the problem has been reproduced and fixed. The fix will be available in a next VBox version.