macOS 10.14.8
Virtual Box 6.1.26 r145957 (Qt5.6.3)
Windows 10 Enterprise 64 bit VM (last updated Windows in the last few weeks)
I use the VM to do Windows administration (AD, Group Policy). I don't store user files of the normal type there.
When I attempt to open the VM from a Saved State, I get:
==================
Failed to open a session for the virtual machine Win10Ent64bit 2019-05-15T10-31.
Details:
GIM#0: SavedVERR_SSM_LOAD_CONFIG_MISMATCH GIM provider 0 differs from the configured one (2). [ver=1 pass=final] ().
Result Code:
NS_ERROR_FAILURE (0x80004005)
Component:
ConsoleWrap
Interface:
IConsole {872da645-4a9b-1727-bee2-5585105b9eed}
==================
I reinstalled Virtual Box (current version on the web site; same as what I was running).
What's the fastest way to get back and running? Can I replace the .vdi and .vbox files with earlier versions?
It is likely irrelevant, but I have an Ubuntu server VM that (still) runs fine.
thanks
VERR_SSM_LOAD_CONFIG_MISMATCH Windows 10 VM
-
- Site Moderator
- Posts: 39134
- Joined: 4. Sep 2008, 17:09
- Primary OS: MS Windows 10
- VBox Version: PUEL
- Guest OSses: Mostly XP
Re: VERR_SSM_LOAD_CONFIG_MISMATCH Windows 10 VM
SSM_LOAD_MISMATCH means you have a saved state file (.sav) from a previous version of VirtualBox. SAV files are not portable.
You have to right click the VM in the manager and choose "Discard saved state". Then I suggest that you stop using saved states - in the modern era there is really very little need for this feature.
You have to right click the VM in the manager and choose "Discard saved state". Then I suggest that you stop using saved states - in the modern era there is really very little need for this feature.
Re: VERR_SSM_LOAD_CONFIG_MISMATCH Windows 10 VM
Thank you a million for that; you made my morning.
If I shut the VM down, it takes about 1' 10" to get to the (Windows) desktop (MacBook Pro a number of years old, but it does have an SSD). I realize that's not forever, but opening from a saved state is much faster. Curious if 'by very little need' you mean to shut down the VM.
thanks
I open the VM occasionally, and have been ending the 'session' after doing my work using by saving the machine state.mpack wrote:SSM_LOAD_MISMATCH means you have a saved state file (.sav) from a previous version of VirtualBox. SAV files are not portable.
You have to right click the VM in the manager and choose "Discard saved state". Then I suggest that you stop using saved states - in the modern era there is really very little need for this feature.
If I shut the VM down, it takes about 1' 10" to get to the (Windows) desktop (MacBook Pro a number of years old, but it does have an SSD). I realize that's not forever, but opening from a saved state is much faster. Curious if 'by very little need' you mean to shut down the VM.
thanks
-
- Site Moderator
- Posts: 20945
- Joined: 30. Dec 2009, 20:14
- Primary OS: MS Windows 10
- VBox Version: PUEL
- Guest OSses: Windows, Linux
Re: VERR_SSM_LOAD_CONFIG_MISMATCH Windows 10 VM
The biggest thing to remember when using saved-state is to not upgrade Virtualbox if important VMs are save-stated. Start then full-shut-down before upgrading Virtualbox.
It should theoretically be possible to re-downgrade Virtualbox if an important still-save-stated VM must be restored after upgrade.
It should theoretically be possible to re-downgrade Virtualbox if an important still-save-stated VM must be restored after upgrade.
Re: VERR_SSM_LOAD_CONFIG_MISMATCH Windows 10 VM
That was what I did (to cause the problem). Thanks!scottgus1 wrote:The biggest thing to remember when using saved-state is to not upgrade Virtualbox if important VMs are save-stated. Start then full-shut-down before upgrading Virtualbox.
It should theoretically be possible to re-downgrade Virtualbox if an important still-save-stated VM must be restored after upgrade.
-
- Site Moderator
- Posts: 39134
- Joined: 4. Sep 2008, 17:09
- Primary OS: MS Windows 10
- VBox Version: PUEL
- Guest OSses: Mostly XP
Re: VERR_SSM_LOAD_CONFIG_MISMATCH Windows 10 VM
If you doubt your own ability to remember to shut down all VMs before an upgrade - and I would certainly doubt mine - then IMO the safest option is to accept the 70 extra seconds it takes to boot a VM (which you only use occassionally) from hdd. On those days just take an extra sip or two of coffee or something productive like that...