I stumbled into an interesting potential “gotcha” as regards Windows 8 and its much-ballyhooed support for Hyper-V (see Steven Sinofsky’s Building Windows 8 blog entitled “Bringing Hyper-V to ‘Windows 8’” for more information) while researching an article on this topic for SearchWindowsEnterpriseDesktop.com this weekend. Although Microsoft has claimed in the past that Windows 8 will run on any PC that can run Windows 7, the same is most definitely NOT TRUE for Hyper-V support.
To run Hyper-V, a PC must not only run the 64-bit version of Windows 8, its CPU must also support a virtualization technology called Second Level Address Translation (aka SLAT) which, as Sinofsky’s blog states, “…is present in the current generation of 64-bit processors by Intel and AMD,” along with at least 4GB of RAM. Given the memory requirements for VMs, the 4 GB requirement is neither terribly surprising nor onerous. As it turns out, only the ix Intel processors (i3, i5, and i7) and Barcelona-model or later AMD processors (K10 or higher Opteron and Phenom CPUs) support SLAT.
You can check the status of your CPUs by downloading the latest version of Mark Russinovich’s coreinfo.exe utility from the Microsoft Sysinternals Web pages, then launching the utility from a command line launched with administrative privileges. If your CPU will run Windows 8 Hyper-V, you’ll see a display like this one:
The key entries in this display are the EPT (Extended Page Tables) for Intel processors, as shown in the preceding screenshot, and a value in the AMD processor output that may appear as NPT (Nested Page Tables) or RVI (Rapid Virtualization Indexing). Simply put, one of these values must be enabled for Windows 8 Hyper-V to work. What this also means is that even though I have some older quad-core systems that run Windows 7 just fine, with 12-16 GB of memory (and thus plenty able to host multiple VMs except for the SLAT requirement), I won’t be able to use those machines to host Hyper-V VMs when I start digging into Windows 8 later this month. All I can say is “Rats!”
On my continuing quest to save space on the C:/System/Boot drive on my Windows PCs — mostly so I can maximize the value and utility of my desire for SSD speed without forking over $500-600 for a sizable enough drive (256 GB or larger) so I don’t have to worry about saving space — I’ve kept on looking for small changes with big payoffs to keep drive space consumption down. Today, I came across a big one on my i7 test machine. It’s got Windows XP Mode installed, and by default Windows XP mode stores the file named Windows XP Mode.vhd in the C:Users<username>AppDataLocalMicrosoftWindows Virtual PC directory.
On my i7 test machine that vhd consumes 6.8 GB of disk space on a 120 GB Corsair Vertex 2 SSD. On that same machine, I’ve got two internal conventional drives: a 1.0 TB Samsung SpinPoint and a 1.5 TB Samsung SpinPoint, both with over 800 GB of disk space available. So I asked myself this question: “Why not move the VHD?” Sure, it’ll run slower than on an SSD, but I don’t use Windows XP mode frequently enough to justify 5% of its available disk space going to a single VHD file.
That raised the question: “How do I relocate the VHD file?” A quick Google search turned up a nice and very helpful post on social.technet.microsoft.com which provided the following instructions:
Start up the VHD, then use the CTRL-ALT-DEL button to elect the “Shut down” option.
Copy the file named Windows XP Mode.vhd from the C:Users… location to another hard disk
Right-click the Windows XP Mode entry in Windows Virtual PC (or Server) and select the Settings option
Use the Browse button association with Hard Disk 1 to point the program at the new location for the file (in my case that was F:VMsWindows XP Mode.vhd)
Fire up Windows XP Mode to make sure everything is still working OK (worked for me, so hopefully it will also do likewise for you)
Bingo! 6.8 GB gone from the C: drive, and about 6% more free drive space for other uses on my SSD. I love it when little actions bring big wins!
Rashmi U R’s posting on how to move the Windows XP VHD file (Click to Enlarge)
OK, so I’m wondering out loud why nVidia finds it necessary to load my desktop up with the PhysX game accelerator, and various 3D drivers by default when I use none of those things. I know, I know: they want as many people as possible to use this “exiciting new technology.” But I’m about as likely to need PhysX as I am to go out and buy a set of 3-D glasses so I can revel in the glory that is 3D graphics for posting blogs, writing articles, and Tweeting here and there.
Bottom line impact on my system is about 1 GB of drivers, utilities, and consoles that I really don’t want, not because I don’t like or appreciate them, but simply because I don’t use them. I wish nVidia didn’t install all of these items by default but rather, made the selection process that the custom install offers accessible by default instead. Without PhysX, 3D drivers, and the nVidia control panel, Task Manager shows 3 nVidia related tasks (two instances of nvvsvc.exe, the nVidia Driver Helper Service, 3,156K and 1,760K, respectively, and NvXDSynx.exe, Nvidia User Experience Driver component, 3,660K ). With everything loaded without restraint, Task Manager shows 6 tasks that consume a total of 42.26 MB of RAM, as shown in this screen snippet:
By just installing the nVidia device driver only (no Update, no PhysX, nothing 3D) memory consumption drops to 8.375 MB. Granted this wouldn’t do me any good if I played games or used applications that required PhysX (AFAIK, it’s a games only thing) or used 3-D. But I don’t. So a little trimming frees me up some system resources. But the numbers aren’t really that dramatic, not even on a 32-bit system with 4GB of RAM (3,326 M or 3.2 GB usable) installed. But shoot! It’s the principle of the thing…
OK, I admit it. I’m a little bit obsessive about maintaining maximum free space on the 80 GB putative (74.5 GB actual size) Intel X25-M SSD I use as the system drive for my production PC. In my never-ending quest to keep things pared down to the absolute minimum, I will occasionally resort to cleaning up and compressing the PST files associated with Outlook on that machine. To that end, I’ve already moved my Archive.pst file to another drive. But today, I got into compacting my PST files (and completely cleared out the default Archive.pst that Outlook manages to create on my C: system drive, whether I want it to or not), and learned some interesting stuff along the way.
Anybody who follows my system blog knows that my current production system is probably best described as temperamental. Since upgrading to Windows 7 in August of 2009, it’s been a heckofalot better than its previous life under Vista, to be sure, but I’ve had my share of ups and downs with this collection of hardware parts. Here’s a brief description of what’s going on under the hood in this particular box:
Ed’s Production Windows 7 PC
Intel QX9650 (Yorkfield, 45 nm)
2 x 2GB SuperTalent DDR2-800 (5-5-5-18)
GeForce GTX 275
Intel X25-M 80GB SSD
SpinPoint 1.0 GB (7200 RPM)
Zalman CNPS 9500
Gigabyte ODIN 800W
Asus BC-1205PT Blu-ray
Over the past couple of years, I’ve had to deal with numerous instances of blue screens, application hangs, and strange Windows Explorer hangs. I’m also doing increasing work with virtual machines and have found that 4 GB of RAM just isn’t enough to permit me to be productive running regular apps with even one VM open. So I’ve been preparing to upgrade this system to x64 Windows 7 from the current 32-bit x86 version, as documented in my August 2, 2011 blog “Coming Soon (I Hope): Win7 32- to 64-bit Conversion.”
Here’s my problem, depicted in the form of the current Reliability Monitor for the past 20 days: this system has been completely trouble-free pretty much since I wrote the afore-cited blog. Not a single glitch, hitch, blip or hiccup in the interim.
Reliability monitor for August 6 thru August 24
(Click to enlarge)
Frankly, this puts me in a quandry: yeah, sure I do need the extra memory space that converting from 32- to 64-bit Windows 7 will confer thanks to the 8 GB of additional RAM I’ll install into the system to take it up to 12 GB. But I’m slammed with work right now, and it goes against my better instincts to start making major changes to my principal production system right now. I have a 12 GB i7-930 system up and running already anyway, with a GTX 470 graphics card and an even faster Corsair Vertex 2 SSD for the system drive. I’m starting to think that maybe I should migrate to that system instead, and convert this box to test machine status when I upgrade to x64 Windows 7 and add the extra memory. But one thing’s for certain: I’m not doing anything major until the current onslaught of work tapers off a bit. I just don’t have time to make any production changes right now!
I took delivery of my snappy new and way cool Dell Alienware M11x R3 laptop last Thursday, August 4, but it wasn’t until this afternoon (August 9) that I finished a key step in making best use of this machine. I finally got my WiMAX account turned on with wireless service provider Clear. Although the instructions aren’t terribly clear in the emails and Web site information about turning on and using my WiMAX interface, all I had to do was hear these words from the very nice tech support guy who called me and said “Do a new account sign-up with Clear” to know exactly what to do.
I finally got the additional 8 GB of DDR2-800 RAM I ordered for my primary production system —a QX9650-based Quad Core system built around a Gigabyte X38-DQ6 mobo with an Intel X25M 80GB SSD and nVidia 275 GTX graphics card. That means that I’m going to snapshot the current 32-bit version of that system into a VM, make an image and standard backup, then blow everything away and finally rebuild that system around 64-bit Windows 7 Ultimate, to replace an aging and sometimes wonky 32-bit version of the same OS on that system. This build goes all the way back to the initial release of the production version of Windows 7 to MSDN on August 6, 2009. I’ve patched and updated this puppy to keep up with Windows Update ever since and it’s gotten to the point where, as so often happens with heavily used and abused Windows installations, things get flaky from time to time. What does this mean? Today’s System Reliability graph tells the story pretty well:
In attempting to fix erratic mouse behavior on my production desktop, I discovered the need to visualize what USB devices were connected to which ports on my PC. I also wanted to make sure I had USB 2.0 devices connected to USB 2.0-capable ports and hubs, while I was looking into these matters.
To those ends, I tried to run down a reasonably capable but free USB inspection or reporting tool that could tell me what was what on my PC. Ultimately, I wound up with USBView, a simple but effective Microsoft-made utility.
One interesting thing about this task was how to search for what I wanted. “USB scanner” didn’t do it, nor did “USB mapper,” “USB diagnostics,” or “USB ports.” After flailing about for a while, I went to visit a familiar USB Website I turn to from time to time, EveryThingUSB. They recommended a tool called USBinfo, but all the links I could find to the program (especially the latest version, 2.0) were defunct (though I did find a working link to a Version 1.2 download). I also discovered a USB sniffing tool from HHD Software called USB Monitor Lite, for which a free trial download is available (it’s only good for 14 days, after which the buy-in is $40). I also found a nice-looking utility from Nirsoft called USBDeview but it wouldn’t work properly on my PC, and appeared to cause the very kind of erratic mouse behavior that had prompted me to search for such a tool in the first place!
But once I had some program names and looked at what they called themselves, and how they described themselves, my search terms became more relevant to the actual tools and utilities out there in cyberspace. In fact, a search on “USB utilities” proved most useful, and led me to the site where I discovered Microsoft USBView.
USBView lists the hierarchy of USB devices present on your PC. If you haven’t added a bus-attached USB controller to your system, it lists all of the USB Universal Host Controllers (UHCs) on your motherboard at the top of the hierarchy, followed by the USB root hubs attached to the host controllers. If you do have one or more additional USB controllers, you’ll see extra entires at the top two levels of the hierarchy. At the next level down, you’ll see either Port numbers or any secondary hubs that you may have attached to USB ports on your PC or notebook computer. At each level in the hierarchy, any device you highlight in USBView’s left pane displays its properties in the right pane for inspection. Clicking on any Port to which a “Device connected” notification attaches will usually permit you to identify that device by looking at its associated property values.
For my SuperTalent Pico 8GB Flash drive, however, I had to identify it by process of elimination because USBView failed to resolve its vendor ID. All of the other devices were identifiable by type and by vendor in the properties information pane. As it happens, the Pico’s vendor ID resolves to the chip maker’s name for the Flash RAM it contains, rather than the device builder’s name anyway, as I discovered thanks to a handy unofficial list of USB vendor IDs. When in doubt, I also discovered, you can always remove or insert a device to change your configuration, or do both, to conclusively identify any particular USB device anyway.
For others who are incurably curious about what’s on and in their PC’s, or those who must deal with USB problems, some or all of the utilities mentioned here may come in handy. For me, USBView was just what I wanted, so it was the only one to remain resident on my machine.
[notice]Note: USBInfo 1.2 and 2.0 Incompatible with Vista[/notice]
Just for grins, I decided to install USBInfo version 1.2 on my Vista machine to see how it compared to Microsoft’s USBView. I’ll never know, because the program is incompatible with Vista. It uses several obsolete and deprecated DLLs, some of which are no longer available in Vista, and some of which provoke a “contact Microsoft for more information” warning when the program goes looking for them (most notably msvbm50.dll, which dates all the way back to the Visual Basic 5.0 era).Though there are sources for such things online, I decided to forgo this dubious privilege and immediately used Revo Uninstall to get the program back off my machine, with no apparent ill effects. I also found a download for version 2.0 at www.onlinedown.com through mirror 6 or 7, but it too suffered from exactly the same problems. My advice: don’t bother with this software on a Vista system!