I recently upgraded my primary laptop to Vista Ultimate. Reluctantly I gave up the security of Windows XP and the comforts of a long-lived laptop build -- not that XP was my dream OS, but I had gotten used to its quirks and I knew what to expect. That said, it was getting long in the tooth and Vista did have a certain allure.
After the upgrade (actually a reformat and a clean install), I installed Virtual PC 2007 SP1. When I tried to start my primary development machine, I got the following error: "The virtual machine [VPC NAME] can't be started because it is being used by another program, or marked as read-only...." Once my mild stoke abated, I did what every good developer does... I Googled the error and found the following articles describing other experiences with the same (or similar issue):
The trouble was that all of these articles focused on security changes in Vista: either the current user (me) doesn't have access to the files or 2) for whatever reason, VPC needed to run with elevated permissions (as an Administrator). As it turns out, I did have to adjust permissions on the files. There were some remnants of permissions left over from my XP machine. Unfortunately, resetting the permissions didn't fix the problem.
In looking through various settings, I noticed a curious attribute setting - the "read only" flag appeared to be set. Unfortuately, unchecking the read-only flag on the folder where my virtual machine was stored seemed to have no effect. Every time I clicked O.K., closed the properties page and reopened to check the setting, I was presented with exactly the same situation -- the read only flag appeared to be set. This lead to another Google search and another wild goose chase, that allowed me to learn the read only attribute mysteriously getting set is something that a good many other folks are struggling with when using Vista. And, in fact, I learned that the read only attribute is only settable at the file level, not at the folder level. You can click on the check box next to read only flag all day long and nothing will happen to the folder -- it will, however, set the flag on the underlying files. That said, the read only flag on the individual files was unchecked in my case.
To cut the chase, I had to drop to a command prompt and use the ATTRIB command (DOS old school). I ran the following:
ATTRIB -R G:\*.* /S
In this case, G: is the USB drive where my virtual machine is stored. Once I ran this command, my virtual machine started right up. Best part... it only took five hours, lots of Google searches and a VERY frustrating, non-productive call to Microsoft support (grist for another post).
From this experience I learned a few things:
- MSDN incidents cannot be used 24 hours a day, 7 days a week as the web site suggests (http://msdn.microsoft.com/en-us/subscriptions/bb266240.aspx). In fact, even though development is my business and not being able to write code, for me, is by definition "being down," Microsoft wanted to charge me $500 to open a "critical business" incident (apparently my MSDN incident can't be used for "production" problems...curious). If I didn't want to go that route, I had to wait until tomorrow to speak with Virtual PC support. Why? Apparently after being transferred to various groups no less than five times, having the CSR tell me "my machine is updating and I can't generate a case number for you" and then being hung up on, the last CSR said I missed Virtual PC support by 7 minutes -- she couldn't transfer because I'd be rerouted back to the level one CSRs. So much for support.
- Google is awesome for finding answers to problems -- assuming you know what to search for. Having done this a few times, I evening got anecdotal solutions that lead to a fix.
- Vista is generally a good operating system -- admittedly my experience beyond this problem -- has been positive. However, these "minor" security changes seemed to have caused great consternation.
Hopefully this post will prevent others from suffering my fate.
I had the same issue. However, moving the files from the USB drive to the C: drive solved the problem for me.
I had the same problem, but running Virtual PC as the administrator fixed it.
Try to give necessary rights to your user on the folder where virtual machines exist. It worked for me.
Same problem as well - running the dos command helped iron everything out for me
Thanks for the post.
Post a Comment