Parallels 10 - Problem ID 53 when rollback mode is enabled

Our office houses two shared workstations running Windows 8.1 as the Guest OS, for use with an esignature software. After hiring some new employees we noticed issues with the VMs (blue screens). After correcting the cause of the issue and setting up some GPOs, the VMs were running smoothly, however, due to user error we were frequently having to restore from a snapshot. After growing tired of this, we restored to a snapshot, enabled rollback mode, and locked Parallels' settings. For quite some time this worked without issue, however, one of the workstations recently stopped working. Upon launching Parallels, and auto-launching the VM, a message is displayed stating that a snapshot could be created due to Problem ID: 53.

I have already attempted the troubleshooting steps located at http://kb.parallels.com/en/122818 but this did not correct the issue. I've even attempted to copy the VM from the operational workstation onto the one having issues, and launch the VM from there with the same issue occurring. The kicker here is that by disabling rollback mode entirely (Ask me what to do still results in problem id: 53) the VM is able to boot and function without issue, I can take snapshots manually and restore with no inconvenience or issue.

As the issue seems to be isolated to this workstation, I have already removed the VMs from within Parallels, removed the application, ran PDremove from http://kb.parallels.com/Attachments/kcs-35959/PDremove.zip and attempted to reinstall the most up-to-date copy of Parallels 10. Still after building a new VM using the HDD from the operational VM, I am stuck with Problem ID: 53. Meanwhile, the other workstation is operating in rollback mode on a daily basis with no issues whatsoever. Is there any further troubleshooting or advice that can be provided?

Host OS: OS X Yosemite 10.10.5
Guest OS: Windows 8.1 Enterprise
Parallels Version: 10 (most recent)

 

As a follow-up with additional information, our secondary workstation is now presenting this behavior. There was an important tidbit that I had neglected to mention previously, with the exception of a single user on each machine, the users sharing access do not have administrative access on either machine.

 

I certainly do not wish to seem impatient, but I've seen a good deal of activity in this forum by Parallels staff during the past week, and have noticed that my secondary posting to this thread had to be manually approved, but received no response at that time. The fact that these machines are not operating in rollback mode places us in a potentially compromising position, if this is not remedied soon. If we're unable to correct this issue with Parallels, we may be forced to migrate to an alternative to ensure our operations can run smoothly.

 

Hello TedR1,

the reported behavior can happen if the work of virtual machine/Parallels Desktop/Mac has been finished improperly (power fail, crash, etc). every time one starts virtual machine in Roll Back mode, Parallels Desktop creates a temporary snapshot. After work is finished it removes it or saves (depending on the configuration). If during the work there is a crash, snapshot is not removed and Parallels Desktop will fail to recreate it, because it's already there.

there are 2 possible solutions:
1) If you want to save changes, you can run the command to merge snapshots: http://kb.parallels.com/en/111736
NOTE: this will merge ALL your snapshots.
2) Locate <VM_path>/<VM_name.pvm>/<vm_name>-0-.hdd/DiskDescriptor.xml file here and I will edit it for you. Also, please attach the output of the following command in Terminal:
ls -la <VM_path>/<VM_name.pvm>
the example is
ls -la /Users/Shared/Parallels/Windows 10.pvm/

 

I attempted the command to merge all snapshots, but this did not correct the issue. As this could not resolve the matter, I've attached the information for the second set of troubleshooting steps below.

DiskDescriptor.xml

Code:

<?xml version='1.0' encoding='UTF-8'?>
<Parallels_disk_image Version="1.0">
    <Disk_Parameters>
        <Disk_size>134217728</Disk_size>
        <Cylinders>262144</Cylinders>
        <PhysicalSectorSize>4096</PhysicalSectorSize>
        <Heads>16</Heads>
        <Sectors>32</Sectors>
        <Padding>0</Padding>
        <Encryption>
            <Engine>{00000000-0000-0000-0000-000000000000}</Engine>
            <Data></Data>
        </Encryption>
        <UID>{d8c3f18f-7d05-418c-af39-4eea8b300758}</UID>
        <Name>Windows 8.1-0 SSD</Name>
        <Miscellaneous>
            <CompatLevel>level2</CompatLevel>
            <SuspendState>0</SuspendState>
            <Bootable>1</Bootable>
            <ChangeState>0</ChangeState>
            <GuestToolsVersion>10.2.2-29105</GuestToolsVersion>
            <DupBlocksCnt>0</DupBlocksCnt>
            <CorruptBlocksCnt>0</CorruptBlocksCnt>
            <UnrefBlocksCnt>0</UnrefBlocksCnt>
            <OutOfDiskBlocksCnt>0</OutOfDiskBlocksCnt>
        </Miscellaneous>
    </Disk_Parameters>
    <StorageData>
        <Storage>
            <Start>0</Start>
            <End>134217728</End>
            <Blocksize>2048</Blocksize>
            <Image>
                <GUID>{5fbaabe3-6958-40ff-92a7-860e329aab41}</GUID>
                <Type>Compressed</Type>
                <File>Windows 8.1-0.hdd.0.{5fbaabe3-6958-40ff-92a7-860e329aab41}.hds</File>
            </Image>
        </Storage>
    </StorageData>
    <Snapshots>
        <Shot>
            <GUID>{5fbaabe3-6958-40ff-92a7-860e329aab41}</GUID>
            <ParentGUID>{00000000-0000-0000-0000-000000000000}</ParentGUID>
        </Shot>
    </Snapshots>
</Parallels_disk_image>

Terminal Output

Code:

drwxrwxrwx@ 15 fcusr  staff        510 Sep 28 08:41 .
drwxrwxrwt   5 root   admin        170 Sep 18 13:54 ..
-rw-r--r--+  1 fcusr  staff      16384 Sep 28 08:24 NVRAM.dat
drwxrwxrwx+  8 fcusr  staff        272 Sep 18 09:26 Snapshots
-rw-r--r--+  1 root   staff        698 Sep 28 08:24 Snapshots.xml
-rw-rw-rw-+  1 fcusr  staff      30255 Sep 28 08:41 VmInfo.pvi
drwxr-xr-x@  7 fcusr  staff        238 Sep 28 08:40 Windows 8.1-0.hdd
drwxr-xr-x+  3 fcusr  staff        102 Sep 18 08:25 Windows 8.1.app
-rwxrwxrwx+  1 fcusr  staff      24177 Sep 28 08:41 config.pvs
-rwxrwxrwx+  1 fcusr  staff      24177 Sep 28 08:41 config.pvs.backup
-rw-rw-rw-+  1 fcusr  staff    1474560 Sep 18 08:23 floppy.fdd
-rw-rw-rw-+  1 fcusr  staff   13993302 Sep 28 08:41 parallels.log
-rw-r--r--+  1 root   staff      86322 Sep 28 08:41 statistic.log
-rw-r--r--@  1 fcusr  staff          0 Sep 28 08:41 {74c584d8-e1a8-4088-9334-193961426926}.mem
-rw-rw-rw-+  1 fcusr  staff  268435456 Sep 28 08:41 {74c584d8-e1a8-4088-9334-193961426926}.mem.sh

 

Hi, descriptor looks fine, pls give me one more output of the following command:
ls -la <VM_path>/<VM_name.pvm>/Windows 8.1-0.hdd

 

Terminal Output
ls -la /Users/Shared/Parallels/Windows\ 8.1.pvm/Windows\ 8.1-0.hdd/

Code:

drwxr-xr-x@  7 fcusr  staff          238 Sep 28 08:52 .
drwxrwxrwx@ 15 fcusr  staff          510 Sep 28 08:53 ..
-rw-r--r--+  1 fcusr  staff         1521 Sep 28 08:52 DiskDescriptor.xml
-rw-r--r--+  1 fcusr  staff         1692 Sep 28 08:40 DiskDescriptor.xml.Backup
-rw-r--r--+  1 fcusr  staff            0 Jun 17 10:03 Windows 8.1-0.hdd
-rw-r--r--+  1 fcusr  staff  23461888000 Sep 28 08:40 Windows 8.1-0.hdd.0.{5fbaabe3-6958-40ff-92a7-860e329aab41}.hds
-rw-r--r--+  1 fcusr  staff        19136 Sep 28 08:25 Windows 8.1-0.hdd.drh

 

that also looks fine. please attempt to replicate the issue and once the error appears, please generate a problem report (http://kb.parallels.com/en/9058 ). After the report is sent you will see its unique 8-digit number in the pop-up window on your screen. please specify this ID here

 

Problem report 75998456 has been submitted.

 

well, from what I see the hdd used by VM is located on thd59197 Desktop
/Users/thd59197/Desktop/Windows 8.1-0.hdd
you attached the information from hdd located in the VM bundle that is not in use. this means that hdd has been manually moved. my recommendations should be followed with the hdd located on the Desktop (merge snapshots or attach here diskdescriptor and the output of ls -la /Users/thd59197/Desktop/Windows\ 8.1-0.hdd) and I'll modify it for you.

Note: from what I see in report VM has 3 snapshots and all will be lost if you merge them.

My general recommendation is to put hdd back in the pvm bundle. the one that's already there can be removed/renamed (before removing check it's size - if it's less than ~100mb then it most probably has no data. but it can happen that there is data but hdd was just disconnected). after moving hdd in pvm bundle you should specify new path to hdd opening VM config (http://kb.parallels.com/en/117287 ) > Hardware > Hard disk > Source. Also make sure "Connected" checkbox is ticked.

 

On this single workstation, a copy of the HDD from the other VM was stored on a user's Desktop, from when that machine was functional, and we were needing to recreate the VM following troubleshooting for error code 53. This was then copied to the contents of the .pvm, but it appears to not have transferred fully and a lazy admin altered the Parallels config for the VM to load from that Desktop, rather than retransfer the file. I've since copied the HDD from that location into the pvm, and changed the VM hardware config to load the HDD that is located in the .pvm

After recopying the HDD and a successful transfer, I was able to merge snapshots on this workstation, delete the snapshots.xml file, and then restore rollback mode functionality. I'll attempt a snapshot merge on the other workstation and report my findings.

Edit: Restoring to an older snapshot and deleting new ones used to document issues with the VM, before merging snapshots allowed the second VM to be operational. Issue resolved.

 

glad to hear, Ted=)