Tag Archives: windows xp

Windows XP Mode hassles for Windows 8 upgraders

One of the reasons for the success of Windows 7 was the provision Microsoft made for customers stuck with applications that only run on Windows XP. Windows XP Mode is a free add-on for Windows 7 Professional that runs Windows XP. It can also hide the XP desktop and run individual applications in their own window, though this is cosmetic and merely hides the desktop. Windows XP Mode uses Virtual PC as its virtualisation platform.

What would expect to happen if you upgraded Windows 7 with XP Mode to Windows 8? Without having researched it, my expectation was that Windows XP Mode would migrate smoothly to Hyper-V in Windows 8.

Not so. Here is the official word:

With the end of extended support for Windows XP in April 2014, Microsoft has decided not to develop Windows XP Mode for Windows 8.  If you’re a Windows 7 customer who uses Windows XP Mode and are planning a move to Windows 8, this article may be helpful to you.  
When you upgrade from Windows 7 to Windows 8, Windows XP Mode is installed on your machine, however Windows Virtual PC is not present anymore. This issue occurs because Windows Virtual PC is not supported on Windows 8. To retrieve data from the Windows XP Mode virtual machine, perform the steps listed in the More Information section.

If you were relying on XP Mode to run some old but essential application, this is definitely worth knowing. Microsoft’s guidance on retrieving the data is unlikely to be much use, since the reason you use XP Mode is to run applications rather than to store data. Some users are not impressed:

This is SHOCKING.  I was using Win 7 Pro and had a fully configured (hours of work) XP Virtual Machine with my complete web development environment in it.  It didn’t even occur to me that it wouldn’t work on Windows 8.  I’ve only just discovered now when I tried to access it to do some updates!

I MUST recover this virtual PC.

Why did the Upgrade Advisor not mention this!?!?  I carefully resolved all the issues highlighted there before moving on.

Of course it is desirable to move off Windows XP completely, even in XP Mode, but the rationale is that it is better to be on a recent and supported version of Windows and to run XP in a virtual environment, than to run Windows XP itself.

Another oddity is that you can run Windows XP on Hyper-V in Windows 8. However you cannot get XP Mode to work unless you perform a repair install that changes the way it is licensed. Yes, it is licensing rather than technical reasons that blocks the XP Mode upgrade:

Note: The Windows XP Mode virtual hard disk will not work on Windows 8 as Windows 8 does not provide the Windows XP Mode license. The Windows XP Mode license is a benefit provided on Windows 7 only.

Users have discovered workarounds. Aside from the repair install mentioned above, you can also use Oracle Virtual Box and trick XP Mode into thinking that it is running on Windows 7 and Virtual PC. You can also run a virtual instance of Windows 7 and run XP Mode within that.

Fixing a slow Windows XP PC

Yesterday I investigated a Windows XP machine that had become so slow it was unusable. It was a Dell Dimension 2350 with 1GB RAM and a 2.00 Ghz Celeron CPU – not too bad a spec for XP – that had been out of use for a while and was being brought back into service for a specific and undemanding task. At first it had performed fine, but after applying Service Pack 3 and installing Microsoft Security Essentials it had ground almost to a halt. The machine performed so badly that trying to troubleshoot it was like wading through glue. You could get task manager up and see plenty of RAM free, but the CPU was stuck on 100%.

After trying a few futile things like updating the BIOS, I installed Process Explorer and Process Monitor from Sysinternals. Looking at the activity summary in Proccess Monitor it was obvious which process was to blame: an instance of svchost.exe started with the command line: c:\windows\system32\svchost.exe –k netsvcs

However, netsvcs is responsible for many different services. I did a bit more poking around with Process Explorer and found the culprit: Windows Automatic Updates. Typing:

net stop wuauserv

at a command prompt fixed the problem temporarily.

It appears that the Windows Update database, which you can find in %windir%\Software Distribution\DataStore, can get corrupted. The Windows Update service goes into a spin and consumes all your computing resources. You can turn Automatic Updates off by right-clicking My Computer, Properties, and Automatic Updates tab; or you can fix it the brute-force way by deleting the DataStore folder and letting Windows recreate it, though you lose your update history; or you can try to repair the database.

Of course there are many reasons why Windows XP might run slowly, and often it is not easy to troubleshoot. There is abundant well-meaning advice on the internet, much of it based on the assumption that malware is involved, but finding the right answer to a particular problem is a matter of luck. In a professional context, it is hardly worth the time and corporates will just re-image the machine.

I do find it interesting that when Windows XP first appeared in 2001 it specified a minimum of 64MB RAM and ran OK in 128MB. Once fully patched with Service Pack 3, automatic updates, Internet Explorer 8 and anti-virus, it needs at least 512MB and in my experience 1GB to be comfortable. Unfortunately you have little choice; if you want to connect to the Internet or run recent applications, you have to update it. Automatic updates is a also a near-essential security feature.

Finally, kudos to the Sysinternals team whose tools are invaluable for solving this kind of problem.

Why Windows Installer pops up when you run an application

Warning: this post is about old Windows hassles; I’ve written it partly because some of us still need to run old versions of Windows and apps, and partly because it reminds me that Windows has in fact improved so that this sort of thing is less common, though there is still immense complexity under its surface which can leak out to cause you grief – especially for people like reviewers and developers who install lots of stuff.

I’ve been retreating to Windows XP recently, in order to tweak an old Visual Basic 6 application. VB6 can be persuaded to run on later versions of Windows, but it is not really happy there. I have an old XP installation that I migrated from a physical machine to a VM on Hyper-V.

I was annoyed to find that when I fired up VB 6, the Windows Installer would pop up – not for VB 6, but for Visual Studio 2005, which was also installed.


Worse still, after thrashing away for a bit it decided that it needed the original DVD:


I actually found the DVD and stuck it in. The installer ground away for ages with its deceptive progress bars – “20 seconds remaining” sitting there for 10 minutes – repeated what looked like a loop several times, then finally let me in to VB. All was well for the rest of that session; but after restarting the machine, if I started VB 6 the very same thing would happen again.

This annoyance is not confined to VB 6; it used to happen a lot in XP days, though in my experience it is much less common with Vista and Windows 7.

I investigated further. This article explains what happens:

What you see is the auto-repair feature of Windows Installer. When an application is launched, Windows Installer performs a health check in order to restore files or registry entries that may have been deleted. Such a health check is not only triggered by clicking a shortcut but also by other events, such as activation of a COM server. The events triggering a health check depend on the operating system.

When you see this auto-repair problem this means that Windows Installer came to the conclusion that some application is broken and needs to be repaired.

A good concept, but in practice one that often fails and causes frustration. The worst part of it is the lack of information. Look at the dialog above, which refers to “the feature you are trying to use”. But which feature? In my case, how can my VB 6 depend on a feature of Visual Studio 2005, which came later and does not include VB 6? In any case, it is a lie, since VB 6 works fine even after the installer fails to fix its missing feature.

Fortunately, the article explains how to troubleshoot. You go to the event viewer, application tab, and MsiInstaller entries will tell you which product and component raised the repair attempt. Unfortunately the component is identified by a GUID. What is it?

To find out, you can try Google, or you can use a utility that queries the Windows Installer database. The best I’ve found is a tool called msiinv; the script mentioned in the post above did not work. You can find msiinv described by Aaron Stebner here, with a download link. Note how Stebner had to change the download locations because they kept breaking; a constant frustration with troubleshooting Windows, as Microsoft regularly moves or removes articles and downloads even when they are still useful.

Running msiinv with its verbose option (which you will need) seems to pretty much dump the entire msi installer database to a text file. You can then search for these GUIDs and find out what they are. You may find even products listed that are not in Control Panel’s Add/Remove programs. You can remove these from the command line like this:

msiexec /x {GUID}

where GUID identifies the product to remove.

In my case I found beta versions of WinFX (which became .NET 3.0). I said this was old stuff! I removed them, restarted Windows, and VB6 started cleanly.

That still does not explain how they got hooked to VB6; the answer is probably somewhere in the msiinv output, but having fixed the issue I’m not inclined to spend more time on it.

Migrating from physical to virtual with Hyper-V and disk2vhd

I have a PC on which I did most of my work for several years. It runs Windows XP, and although I copied any critical data off it long ago, I still wheel it out from time to time because it has Visual Studio 6 and Delphi 7 projects with various add-ins installed, and it is easier to use the existing PC than to replicate the environment in a virtual machine.

These old machines are a nuisance though; so I thought I’d try migrating it to a virtual machine. There are numerous options for this, but I picked Microsoft Hyper-V because I already run several test servers on this platform with success. Having a VM on a server rather than on the desktop with Virtual PC, Virtual Box or similar means it is always easily available and can be backed up centrally.

The operation began smoothly. I installed the free Sysinternals utility Disk2vhd, which uses shadow copy so that it can create a VHD (virtual hard drive) from the system on which it is running. Next, I moved the VHD to the Hyper-V server and created a new virtual machine set to boot from that drive.

Windows XP started up first time without any blue screen problems, though it did ask to be reactivated.


I could not activate yet though, because XP could not find a driver for the network card. The solution was to install the Hyper-V integration services, and here things started to go wrong. Integration services asked to upgrade the HAL (Hardware Abstraction Layer), a key system DLL:


However, on restart I got the very same dialog.

Fortunately I was not the first to have this problem. I was prepared for some hassle and had my XP with SP3 CD ready, so I copied and expanded halaacpi.dll from this CD to my system32 folder and amended boot.ini as suggested:

multi(0)disk(0)rdisk(0)partition(2)\WINDOWS=”Disk2vhd Microsoft Windows XP Professional” /FASTDETECT /NOEXECUTE=OPTIN /HAL=halaacpi.dll

I rebooted and now the integration services installed OK. However, if you do this then I suggest your delete the /HAL=halaacpi.dll argument before rebooting again, as with this in place Windows would not start for me.  In fact, you can delete the special Disk2vhd option in boot.ini completely; it is no longer needed.

After that everything was fine – integration worked, the network came to life and I activated Windows – but performance was poor. To be fair, it was not that good in hardware either. Still, I am working on it. I’ve given the Virtual Machine 1.5GB RAM and dual processors. Removing software made obsolete by the migration, things like the SoundMAX and NVIDIA drivers seemed to help quite a bit. It is usable, and will improve as I fine-tune the setup.

Overall, the process was easier than I expected and getting at my old developer setup is now much more convenient.