Switching a Windows 8 Consumer Preview from a VHD to Hyper-V

By jay at March 04, 2012 13:39 Tags: , ,

Now that Windows 8 Consumer Preview (CP) is out the doors, I'll start publishing a series of articles about Windows 8 development in various areas, but primarily focused on development.

I'll start today with some tips and tricks that allow to run Windows 8 natively from a VHD, but also run that same VHD from Hyper-V, within Windows 8 Consumer Preview.

The common scenario is simple, you want to try out stuff that worked in the Developer Preview (DP) inside Win8 CP, or run a two instances of the Win8 CP for testing purposes. Chances are you installed the DP on a VHD, from the excellent blog post from Scott Hanselman.

A few things about Hyper-V

Hyper-V’s been here for a while on the Server side, but chances are you never looked at it. Hyper-V will most likely completely replace Virtual PC, as it now supports 64 Bits virtual machines and the very useful dynamic memory feature. Dynamic memory basically add or removes physical memory assigned to the virtual machines depending on the actual demand. This allows to have higher virtual machine density on servers, but on client machines this is also pretty useful because you may not have 32GB of ram, and still want to use it for your primary OS.

This is why this tutorial suggests to have a machine starting with 512MB of RAM, so that it can grow to the appropriate amount, and not arbitrarily reserve 2 or 4GB of ram, just in case.


Running the VHD from Hyper-V

So now that Hyper-V is now included natively in Windows 8, and even though the final SKU in which it will be included is unknown, we can use it from the CP.

If you’re like me, you may have installed the CP directly on a SSD to make it pretty darn fast. Now, here’s how you install Hyper-V :

    1. Open the start menu, type “Feature” and open “Turn Windows Features on and off
    2. Select “Hyper-V” and OK. Reboot. (If the Hyper-V infrastructure is off, then either your CPU does not support hardware virtualization, or it is disabled in your bios)
    3. Launch the “Hyper-V Manager
    4. In the right hand side panel, select “Virtual Switch Manager
    5. Click on “Create a Virtual Switch
    6. Set a relevant network or network adapter name
    7. Select your network card, could be either a wireless or wired network card, then OK.
    8. In the right hand side panel, select “New” and “Virtual Machine
    9. Give it 512MB of RAM and check the “Dynamic Memory” box, then next
    10. Select the virtual network switch you previously created
    11. Select “Use an existing Virtual Hard Disk” and select the Windows 8 DP VHD or VHDX file
    12. Click next twice.
    13. Now in the list of machines in the Hyper-V Manager, right click on your machine and start.


Chances are that your machine will not boot and ask you to replace the disk with a bootable one.


Here’s how to fix that :

    1. Double click on the virtual machine line to open a Display Console
    2. In the Media menu, select “Insert Disk” and select the Windows 8 CP iso file
    3. Reboot the virtual machine using the reset button in the toolbar
    4. Once on the Windows 8 install welcome screen, type Shift+F10, this will show a command line window
    5. Run Diskpart
    6. Type “list volume
    7. Type “select volume 1
    8. Type “list partition” and find the “System Boot” partition or the primary partition
    9. Type “select partition 1” (replace the 1 with the partition listed at the previous step)
    10. Type “active
    11. Then type “exit
    12. Back at the command line, you should be on the X: drive
    13. Type the following “bcdboot c:\windows /s c:” (you may need to replace the second “c:” with the drive that is the System Boot, when installing on a physical machine)
    14. Once done, close the installer window to exit the installation and reboot
    15. You’re done !


Note that this section can be used to register pre-installed Windows 7 or 8 VHD to an existing Windows 7 or 8 physical machine. But in this case, you may need to find the actual hidden boot partition that the Windows Installation creates automatically. You’ll find that partition with the “list partition” command.

Happy Windows 8 CP’ing !

A bit of IT in developer's world: services.exe high CPU usage

By jay at March 24, 2011 12:36 Tags: , , ,

One of the advantages of virtualization is the P2V (Physical to Virtual) process: Converting an "old" build machine to a VM so it can be moved around with the load as-is, snapshotted, backed-up and so on.

This is particularly useful when say, you have a build machine that's been there for a very long time, has a lot of dependencies over old third party software, has been customized by so many people (that have long left the company) that if you wanted to rebuild that machine from scratch, it would literally take you weeks of tweaking to get it to work properly. And that machine is running out of very old hardware that may break at any time. And that the edition of Windows that does not migrate easily to new hardware because of HAL or Mass Storage issues, requiring a reinstallation. That a lot of "ands".

That's the kind of choice you do not need to make: You just take the machine and virtualize it using SCVMM 2008 R2.

But still, even virtualized, the machine been there that long, and things have started falling apart, like having the services.exe process taking 100% of the CPU. And I did not want to have to rebuild that machine just because of that strange behavior.

If you read scott hanselman's blog, you've been recalled that Windows Server 2008 and later has the resource monitor that gives a wealth of information about the services running under services.exe. But if you're out of luck, like running under Windows Server 2003, you can still use Process Explorer. This will give you the similar kind of insight in the Windows Services that are running.

For my particular issue, this was actually the Event Log service that was taking all the resources.


How about I get my CPU back ?

After some digging around, I noticed that :

  • All Event Viewer logging sections in the MMC snap-in were all displaying the same thing, which was actually a mix of all the System, Application and Security logs.
  • Displaying any of these logs was taking a huge amount of time to display.
  • The HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\System\Source was containing something like "System System System System System System System" a hundred of times, the same thing for the keys for the other event logs
  • A whole bunches (thousands) of interesting sources named like some .NET application domain created by the application being built on this machine

To fix it, a few steps in that order :

  • Disable the Event Log service and reboot. You won't be able to stop it, but at the next reboot it will not start.
  • In the C:\WINDOWS\system32\config folder, move the files *.evt to a temporary folder, so they don't get picked up by the service when it'll restart
  • In the registry, for each HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\[System|Security|Application]\Source, replace the content with the one found on the same key on another very similar Windows Server 2003 machine. You can install a brand new machine and pick up the content.
  • If you have, like I did, a whole bunch of sources that look familiar and should not be there under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\[System|Security|Application], remove their keys if you removed them from the "Source" value.
  • Set the Event Log service to "Automatic" and reboot.


The interesting part about the virtualization of that build machine is like in many other occasions, the snapshots, where you can make destructive changes and go back if they were actually too destructive.


What's with the event log "interesting sources" ?

The application being built and tested is running tests on the build machine, and it makes use of application domains and log4net. Log4net has an EventLogAppender that allows the push of specific content to the Windows Event Log. Log4net defaults the name of the source to the application domain name, if there is no entry assembly.

Those tests were actually using a default configuration, and were logging Critical messages to the event log, but the domains were created using a new GUID to avoid supposed name collisions. This is something that did actually more harm than good in the long run, because each new appdomain that was logging to the event log was creating a new event source.

And the build system has been there for a long time. Hence the thousands of "oddly named" event sources.


About me

My name is Jerome Laban, I am a Software Architect, C# MVP and .NET enthustiast from Montréal, QC. You will find my blog on this site, where I'm adding my thoughts on current events, or the things I'm working on, such as the Remote Control for Windows Phone.