The use 'Windows repair Install' procedure, of which I've been the most 'feverous' apologist, in this particular situation is a 'bazooka-to-kill-a-fly' type of solution, meaning, it does more than it has to to fix the issue.
The problem itself is probably just one little thing in the registry or at the start of the partition, or some flags somewhere, that I found the Repair Install procedure fixed, and in terms of economy of time (my time) I found it was quicker to do the Repair Install instead of debugging the exact cause.
That being said, I had some hope Parallels would do this debugging and would create an utility to fix the problem. But it would be time consuming, and from Parallels point-of-view they probably think it isn't worth it for the limited amount of users it affects. Although I'm a bit puzzled by the following fact: if this problem doesn't occur if you use Parallels build >5600 then Parallels must know what is the exact cause of the problem, on the other hand, if it still occurs in the latest releases, XP isn't dead yet, and there aren't any commercially available XP CDs with SP3 (only with SP2), and SP3 is about to get pushed to Automatic Updates in July.
Last edited by a moderator: Jul 6, 2008