VM can't start because the saved state (SAV) file is invalid

[williamb]

Hi,

I have a Win 7 64-bit host with an XP VM, using VirtualBox 4.0.8 r71778.

When I was finish using my VM, I close the VM window and it prompts me with the following choices:
o Save the machine state
o Send the shutdown signal
o Power off the machine

I always choose "Save the machine state".

From the manual
Save the machine state: With this option, VirtualBox “freezes” the virtual machine by completely saving its state to your local disk. When you start the VM again later, you will find that the VM continues exactly where it was left off. All your programs will still be open, and your computer resumes operation. Saving the state of a virtual machine is thus in some ways similar to suspending a laptop computer (e.g. by closing its lid).

This is exactly what I require - something akin to hibernation.

I have done this a number of times without issue but, on the last occasion, when I went to restart the VM, the following error was displayed:

Code: Select all

Failed to open a session for the virtual machaine ____.  VM cannot start because the saved state file ___ is invalid (VERR_SSM_INTEGRITY_FOOTER). Delete the saved state prior to starting the VM.
Result Code: VBOX_E_FILE_ERROR (0x80BB0004)
Component: Console
Interface: IConsole

VirtualBox error.jpg (80.06 KiB) Viewed 37606 times

I'm extremely concerned because I have 3 days of work that had not been saved because I presumed VirtualBox's save state would be sufficient. Obviously hindsight is, well, hindsight. But I need to be able to open my VM in it's current state with all the applications opened as I last left them. I've searched and haven't found anything else similar to my issue (of the, literally, handful of links that Google returned, none were useful), nor I have I found any suitable recovery tools.

I've taken a backup of the whole directory, but everything I've tried doesn't recover my session. I've even opened the SAV file with a hex editor but there didn't seem to be too much I could understand.

btw, the Discard option is of no use because it will just clean boot my VM - meaning I lose all my work.

Is there anything that anyone can suggest? Please help!

Cheers,
William.

[mpack]

Sorry, I think you're out of luck. According to the error message, the .sav file is corrupted, we can't know to what extent. That's a terminal error message. You say you are aware of the benefits of hindsight, but I'm not sure that you do. This isn't just a lesson about backups, it's about understanding that "saved state" and "hiberation" are unstable states, like a cache that never flushes its data to the main store: it's only a matter of time before you lose data.

[Sasquatch]

btw, the Discard option is of no use because it will just clean boot my VM - meaning I lose all my work.

Ever read the story/joke about Jesus vs Satan in a programming competition? Sounds like you're as smart as Satan in that story, he never saved his work before the power went out, thus loosing the competition. Jesus however saves.
Let's hope your applications have an auto-save option for sudden power loss scenarios.

My apologies if I offend any religious people here, but it's the first thing that came to my mind in this situation.

[williamb]

According to the error message, the .sav file is corrupted, we can't know to what extent.

Does this mean that under particular circumstances, it might be possible to recover/uncorrupt a .sav file?
Is there anything that I can try? If this is my only chance, then I'm willing to give anything a go.

[mpack]

In practice, you can't do anything without a backup. If you were an expert then you could perhaps restore all of the fixed parts of the structure using a hex editor or write a little program of your own to do it. Details of the structure would be found in the VBox sources. If the corruption was limited to the fixed parts (seems unlikely), or otherwise not significant then this fix would be enough to get you going again. However, if you were such an expert then you wouldn't be here asking how to do it, and hiring an expert would cost bigtime, and he may still not succeed.

[mpack]

The thought occurs: have you even tried discarding the saved state thus allowing the VM to boot up? (back up the VM folder so this can be undone if need be). Many modern apps auto save to a temp file on disk (e.g. MS Word/Excel), and hence might offer to recover from what is in essence a crash state similar to what would follow a powercut. Failing that, you surely didn't work for three days with these apps open, never saving anything?

After getting the VM to boot, run a "chkdsk/f" from the command console before doing anything else. If Windows says you have to schedule it for next boot then do so, and reboot right away.

To discard the saved state use:

Code: Select all

VBoxManage discardstate "vmname"

Be sure to get the vm name exactly right (case sensitive).

[jorgensen]

Next time create a writethrough D drive, and save your work here - and make backup of this.
Then you can use Snapshot and State Save without loosing your work when something gets corrupt.

[williamb]

The thought occurs: have you even tried discarding the saved state thus allowing the VM to boot up? (back up the VM folder so this can be undone if need be). Many modern apps auto save to a temp file on disk (e.g. MS Word/Excel), and hence might offer to recover from what is in essence a crash state similar to what would follow a powercut. Failing that, you surely didn't work for three days with these apps open, never saving anything?

I did backup the whole directory and did discard the VM. As expected, the VM clean booted and I was back to square one - unfortunately, the app I use doesn't have auto-save or any recovery facility. Though it does have an extremely large debug log file (which I've now backed up twice) that I can use to recreate my work - but that includes all the do's, undo's and redo's, and no way that I can auto-simulate it - so maybe I'll be starting from square two!

Yes, 3 days of work without a save I've never had an issue before doing this with VirtualBox, so I wasn't expecting my saved state to corrupt. Don't worry, I cursed myself that much for a whole day that I'm not planning on making this mistake again.

[williamb]

Next time create a writethrough D drive, and save your work here - and make backup of this.
Then you can use Snapshot and State Save without loosing your work when something gets corrupt.

This seems like a good idea. I already have a D drive but it's in normal mode, so write-through could be a good idea to retain the data.
My VM's HDDs weren't corrupted so I could discard the state and reboot the VM and all the data was still there - I just lost the "hibernated" state.
In this case though, it was the OS "hibernated" state that I wanted to restore, so a write-through D: wouldn't have been able to help - unless I had saved my work to it

[Sasquatch]

Like I said, if you didn't save your work to disk and kept it all in memory, you will loose everything. Power failure, discarding hibernate state, memory corruption, they all result to the same.

Going for three days without even hitting ctrl+s is, as you say, not the smartest move one can make. You've learned your lesson, I hope you won't make the same mistake again. Good luck.

[williamb]

Like I said, if you didn't save your work to disk and kept it all in memory, you will loose everything. Power failure, discarding hibernate state, memory corruption, they all result to the same.

Out of interest, are these types of VirtualBox issues common or rare?

I'm also going to upgrade from 4.0.8 to 4.1.8 to reduce any possible future issues that may have been resolved since 4.0.8 was released.

[Perryg]

Well you know what Murphy says. Seriously what is it that you were working on? Most things these days auto save at some point in time.

[Sasquatch]

Out of interest, are these types of VirtualBox issues common or rare?

With VB: rare. General file corruption: not that rare. It can happen on occasion. OS doing something stupid with it's file system, disk with a bug in it's firmware and writes the data wrong, parts of the drive that have bad sectors or it's near it's end of life.