View Single Post
  #22  
Old April 22nd 17, 02:08 AM posted to alt.windows7.general
Paul[_32_]
external usenet poster
 
Posts: 11,873
Default Virtual XP won't start

T wrote:
On 04/21/2017 05:03 PM, Paul wrote:
Paul wrote:
Roger Mills wrote:


My virtual machine is set to shut down when the application closes. I
can't find any .vsv.files.

My wife's main computer at home is still running XP. When we go away
from home (we're away now) for a few days we take the Win 7 Pro
laptop and she uses the Virtual XP Machine on it. Her data is all on
an external USB drive, so we're not desperate to get at the data on
the virtual machine, but it's annoying that she can't run her legacy
applications.

This was set up using the laptop's original HDD - which was then
cloned onto an SSD. I think the HDD is still intact in a cupboard
back at home. I'm tempted to copy all of the virtual machine files
from that onto the SSD, on the assumptions that the files on the SSD
have somehow got corrupted. Do you think that might work?

The issue with cloning the contents of the VHD file, is
"activation". I've occasionally attempted to move OSes protected
by activation, and was met by the OS "freezing", even though
it had drivers suitable to finish booting. To my mind,
the experiment is worth doing, but without an absolute
guarantee you'll benefit from it.

The idea of moving the OS to physical level, is in the
hope it's more visible during boot (i.e. Safe Mode, F8,
enable Boot Logging, or whatever). Just so you can get
a hint as to what is busted.

While Windows Virtual PC is "inflating" the .vsv file when
the VM runs, you don't have an interface to watch. That's
because Terminal Services (the chosen display method)
is not available until the thing is running. If you were
to run the same VM on VPC2007, and it wasn't using
Terminal Services, you might get to see more of the
boot sequence.

These are the only ideas that come to mind. Having watched
it start, I cannot think of anything else to try (due to
the lack of visibility during the boot phase).

The WinXP Mode VM, also runs on VMWare. VMWare had a special
deal with Microsoft, where they agreed to enforce the usage
requirement (could only boot the VM is Win7Pro or better
was the Host), so that's another way to do it. Only a single
version of VMWare supported this. So if say, VMWare today
was Version 7, maybe it was Version 4 or so that supported
WinXP Mode guests. I'm not a VMWare user, so haven't
tried that, and I don't even have a VMWare setup here.

And the purpose of any experiment, is "observation" and figuring
out what subsystem on WinXPMode is busted. As the current running
environment is "useless" for debugging.

I had high hopes you had a hibernating machine, and simply
deleting the .vsv would be enough... Oh, well.

Paul


Well forget this. It seems to start a brand new WinXP Mode
machine, and doesn't just "import" the VHD you've already got.

http://www.duxburysystems.com/docume...ots/vmware.htm

Even though you can get the player, it's not going to help.

http://www.oldapps.com/VMware_player...=6994?download

Paul


Virtual Box ?


Just got it running.

This is fiddly to do (but possible), if the virtual machine is healthy.
Here is the result. It didn't freeze on me. It came damn close.

https://s17.postimg.org/jt66hiz0f/wi...virtualbox.gif

*******

OK, so the first challenge is, if you check back in VirtualPC,
look at the settings for the WinXPMode machine, the VHD disk is
termed a "differencing disk". It isn't a vanilla VHD after all.
VirtualBox doesn't like that VHD at all.

Windows Virtual PC has a "Merge" function. I asked it to merge
the winxpmode.vhd file and make me a new file I called "pig.vhd".
After some amount of grinding, there as a new 5GB pig.vhd file.

I thought for a moment, I'd lost some of the files from the
VirtualPC folder, but they all seem to be back now.

I exited VirtualPC.

I fired up VirtualBox and defined a "New" machine. Declared
it as a WinXP 32 bit machine. Set the memory size to the same
value as the VM used in VirtualPC.

When it came to the Storage node, the CD was already there.
Using the "pig.vhd" file, it's not a differencing disk, but
just a plain VHD, and that attached no problem, as an IDE
drive. Since WinXP does not have a native AHCI driver, you
don't want to attach it to a SATA controller, where AHCI is
the default. The CD is connected to IDE, and "pig.vhd" ends
up on the same IDE controller.

The fun begins, when you try to boot it :-(

The mouse doesn't work worth a damn. I went to the top menu bar
on the running VM, and selected "Insert VM Additions". As (obvious
after a moment of thought), the so-called hardware drivers are
going to be screwed up. Now, I thought a HID was a HID, but it
bucked and fought with me all the way.

I had to dismiss the "new hardware" dialog, interfering with my
attempts to us the VirtualBox additions dialog. Since the dialog
uses the letter "C" for Continue, I was able to "feed" the dialog
control input and coax it along the way.

After the additions were installed, it was time to restart. Well,
the virtual machine would not shut down. I got a black screen.

After giving it a reset from the menu, it started to boot. Things
behaved better after that point.

Now, if the problem Roger is having, happens before the desktop
even appears, he might not get that far.

But it looks like, at least, "yes", you can get the basic machine
running. It is no longer activated, as you can see in my picture above.
This is not intended as a long term solution. Since all the disk
changes should be to the merge output "pig.vhd", I think my original
WinXPMode remains undamaged.

You could try pressing F8 early in the first boot, and try to
get it into Safe Mode.

Now, if you did effect some changes in "pig.vhd", how would you
get them back to the original machine ? I think VirtualPC is a bit
more forgiving of "disk additions", so you can modify the disk
entry in the settings dialog, and try "pig.vhd" in place of the
original "windows XP Mode.vhd" file. After you'd exited VirtualBox
of course.

https://www.virtualbox.org/

On bringing "pig.vhd" back, the activation will likely remain broken.
The "Windows XP Mode.vmcx" file, a VirtualPC text file, contains
a bunch of GUID identifiers, intended to break things, which will
contribute to your misery.

The only hope from all of this, is that a root cause can be found,
a fix applied (somehow) to the differencing disk, and injected
without damaging anything.

Paul
Ads