Well, maybe. But consider:
* I have an Ubuntu VM that has twice "poofed" but most of the time comes up and runs.
* The WinXP VM never crashed on its own, it was running fine thru several Windows reboots and Parallels launches before it started "poofing". The first time it vanished was after Win had come up and was setting up my "personal settings". The next time and every succeeding time, it is very early in boot -- early enough that the next time, Win doesn't know it failed to come up (doesn't offer "safe mode").
Then there's the question, What exactly would be "trashed"? Either the contents of the .hdd, or the contents of the .pvs. The .pvs file is editable. In the prior build I made a new Win VM (this one) and while it was working, I used BBEdit to compare its .pvs to the .pvs of a previous Win VM that poofed every time up. There was only one diff, I think it was Enable write-back disk cache, and I changed the old bad one to match the new, then-good one, and it still failed. So it wasn't the .pvs.
Now I'm trying to imagine what Parallels (or Windows) could have done to the contents of the hdd such that Windows would not crash but the emulator just stops with no message of any kind from either Windows or Parallels. If Windows is corrupted, it would produce some kind of diagnostic, if only a BSOD. Or maybe it would loop or hang but in any case, the VM display screen would remain! And this magical disk corruption, with Ubuntu sometimes fails and sometimes doesn't.
Thus I just don't think that .hdd corruption is a credible explanation. To me the explanation is a bug in Parallels itself, probably a wild memory store, that makes it erroneously think the VM has halted or that the user has clicked the red button. That's the only way I see to account for no message of any kind -- which to me is the most significant symptom of the whole thing! (The dog that didn't howl in the nighttime...)
I think there's a software flag "VM is running" and somehow it is getting set to "false" and so Parallels just cleans up and stops. Speculatively, maybe it gets hit based on the value of some random location in the VM's memory -- which would explain why a Win VM will run great until one day it changes the magic bytes of its disk image to some innocent value that triggers the Parallels bug. And from then on, it poofs.
Last edited: Sep 24, 2006