Troubleshooting Event ID 52 Errors in MED-V 1.0
Has this ever happened to you? You prepare a Virtual PC image for use with MED-V and you get the following error:
“Failed to start Workspace <workspacename>”.
Event ID 52
This is immediately followed a list of five possible causes. I would like to go over these causes as well as the 6th potential cause.
1. The MED-V Workspace MSI is not installed properly in the virtual machine image: This is a very common cause. This error will only occur if the workspace binaries are not installed at all. You will not get this error if the workspace version is lower than the client as the client will update the workspace to the most recent version.
2. A bootable CD is in the CD-ROM Drive: I see this often with customers using test images. This can occur if there is a bootable CD/DVD on the host system and the virtual PC is using the host CD/DVD drive. This also can occur during testing of the virtual PC still has a bootable ISO file attached to it. This can be somewhat tricky as an attached ISO will not show up when viewing the settings from a VPC console. You can double check by starting the base image in VPC and looking under the “CD” menu and releasing the image. You can also open the *.VMC in Notepad and search for “.iso” as well
3. The policy is not configured properly. Please verify that the domain joining properties are configured correctly and enabled. The domain joining properties are configured using the VM setup tab in the management console: This means to verify that you are using the domain join option through the VM setup script rather than using something outside of this to join the domain. Also ensure that you are using a workspace image that will be joined to a domain if your persistent workspace policy includes single-sign on (SSO.) If you are using the VM setup script to join the domain, you will see other errors instead.
4. Your host OS is virtualized by Hyper-V: While the MED-V Server components work fine on Hyper-V and are supported, the MED-V client is not supported on Hyper-V. Even for testing, while it sometimes may work, you may find layering Type I and Type II Hypervisors problematic whether it be Virtual PC with Hyper-V or another virtualization technology.
5. A GINA replacement was installed after the installation of the MED- V Workspace MSI: If you are using an application that uses a 3rd-party GINA in the guest operating system, this will prevent MED-V from communicating properly with the workspace. Look for the following registry path inside the guest operating system:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\GinaDLL
For MED-V Workspace guest operating systems, the value should be:
%PROGRAMFILES%\Microsoft Enterprise Desktop Virtualization\Workspace\KidaroGina.DLL
Another possibility: A catastrophic operating system failure.
There is a 6th possible reason (and a common one as well.) The workspace startup could be failing due to a catastrophic problem with the underlying guest operating system. Often an Event ID of 52 will be thrown after the MED-V client gives up on initial communication with the workspace operating system. The underlying cause of this could be tied to one or more of the following:
- Virtual Machine fails to boot
- Virtual Machine encounters a STOP error
- VHD disk corruption
They best way to isolate this would be to leverage diagnostic mode. This feature can be enabled by right-clicking the MED-V system icon tray and selecting “Help” and then “MED-V Diagnostics.”
This will bring up the diagnostic dialog. Click the “Enable diagnostic mode” hyper-link and you can view the operating system startup inside a virtual PC window. In the figure below, you can see that the cause of this workspace startup failure appears to be a UNEXPECTED_KERNEL_MODE_TRAP STOP error.
This is one of the main reasons we recommend you configure your System Recovery options inside the Control Panel to not automatically reboot in the event of a system crash. If that option were not configured in this case, you would instead see a workspace constantly rebooting which would also eventually lead to a workspace startup failure of event 52.
We recommend, at a minimum, that the AutoReboot registry value be set to 0:
Registry Key: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\CrashControl
Value: AutoReboot
Steve Thomas | Senior Support Escalation Engineer
