Troubleshooting a MED-V “VM Window Disappeared Unexpectedly” error

I ran into an existing issue with a customer the other day. The customer had many users which were having trouble starting their MED-V workspaces. All of the users affected were getting this error message upon startup:

They were using revertible workspaces for browser compatibility. Deleting the Image folder worked and downloading the image resolved the issue but the customer was in search of root cause. The customer had told me no major changes to the policy had been made. Running the startup in diagnostic mode, did not yield much more information either. At this point it was time to take a look at the devlog.log file. This is a software tracing file we use internally to debug MED-V. The log file is obfuscated by default.

De-obfuscating the log revealed a little more:

902 14/06 13:20:29.163 MEDVClient.exe ERROR ClientUIManager Failed to start the workspace. System log name: Kidaro.SystemLogs.SYSTEM_LOG_EVENT_ERROR_STARTING_WORKSPACE_VM, id: ERROR_STARTING_WORKSPACE_VM, parameters: parameter name: reason, parameter value: VM window disappeared unexpectedly.parameter name: workspace, parameter value: Revert-XP

Further up I found more specifics:

875 14/06 13:20:28.992 MEDVClient.exe INFO VirtualPcController VM Window appeared. Process ID is: 983214; Window handle is: 10336

876 14/06 13:20:29.112 MEDVClient.exe ERROR VirtualPcController Exception thrown while applying VM settings after launch. Exception: System.ArgumentException: The handle supplied is probably invalid

When the MED-V client tried to apply VM settings to the image, there appeared to be a conflict. Looking at the image store I noticed there was an existing *.VSV (virtual PC saved state file) in the image directory for this image version. While the encryption key date stamp was current, the date stamp of the *.VSV was from the previous day. I also took note that when I checked other machines, I came to three interesting conclusions:

1.) There should not be a saved state file in that directory when using revertible workspaces. It should be kept in a base subdirectory beneath the version subdirectory

2.) All of the machines experiencing this issue had saved state files in v1 directory not the base subdirectory where it should be when in a stopped state.

3.) The administrator had obviously made a policy change.

I asked the customer to locate machines that were *NOT* experiencing this problem. Once this was done, I began to assess what were the differences. Some were because the users were not in and have not even logged on that day. Others were working because they had not stopped their workspaces in several days. So we checked some machines that were still working. I went to the MED-V client system tray and pulled up the diagnostics and found the policy version on display had refreshed to the same version but there was another telling item. The following dialog box was also displayed:

So a major change was made to the workspace policy. Normally you will get this message in environments when you make significant change such as changing network configuration from NAT mode to bridged mode. Incidentally, switching from Bridged to NAT or performing serious modifications may also warrant the workspace shutting down and restarting the VM as opposed to the default behavior with starting and stopping workspaces which is just to save the state of the VM. The server’s clientpolicy.xml had a date and time stamp greater than all of the saved-state files on the failing clients.

Sure enough when I restarted the workspace, the original error of the premature VM window closing of course appeared. Now we know this issue is tied to a policy change. Now the question is what. I knew of some nightmare things you should never do, but did not want to jump to conclusions although I pretty much figured out what had happened. Finding a client that had yet to log on since the policy change was a stroke of luck. It had something in common with the failing clients: a saved state file with a date and time stamp earlier than the policy change.

Never Change an Existing Workspace Policy from Persistent to Revertible with the Same Image

The root cause of this issue is that the image mode in the workspace had been changed from persistent to revertible after being deployed. If the workspace is stopped without the workspace being shutdown, the saved state file remains and you will get an error when starting the workspace.

This is the main reason why it is not a good idea to change the type of workspace used post deployment. We do not recommend doing this and even the management console will prompt with this message when making this change in the MED-V management console:

Of course if this has already happened, what is the best course of remediation? You may be able to get away with deleting the saved state file (*.VSV) however it is recommended that you delete the entire image folder C:\MED-V Images\<image name> not just the version folder when this happens.

Steve Thomas | Senior Support Escalation Engineer