So now that I’ve been introduced to Second Level Address Translation (SLAT) as a requirement for Hyper-V on the upcoming release of Windows 8 (see my recent blog on this discovery at edtittel.com: “Be Prepared for Windows 8 Hyper-V Gotcha“) I’ve been wondering about why it has to be this way. So I dived into the newly-created Windows 8 Developer Preview MSDN forums to see what I could learn there, and in the context of a discussion entitled “Hyper-V cannot be installed on Lenovo Thinkpad W500” I found a lovely source of enlightenment on this topic. While it is technical enough to make some eyes bleed, it does provide a key insight into the SLAT requirement.
Microsoft\’s Virtualization Guy Explains Hyper-V and SLAT
This source is Ben Armstrong’s blog from waaaaaaaaaaaay back in November 2009 entitled “Understanding High-End Video Performance Issues with Hyper-V.” In a very tight nutshell, the upshot of this posting may be summarized as follows:
1. High end graphics cards require frequent and resource-intensive/expensive memory allocations that come from using a PAGE_WRITECOMBINEprotection operation in the hypervisor.
2. This requires the kernel memory manager to flush the translation lookaside buffer and the page cache, which in turn sends an intercept into the hypervisor.
3. Lots of resource intensive hypervisor operations like this turn a (normally) infrequent operation into something frequent enough to hamper or cripple performance. There’s a great diagram in the blog post that shows why a hypervisor falls prey to this limitation, while a virtual machine manager (VMM) like that found in Virtual PC or Virtual Server remains immune to the problem. And interestingly, the faster and more capable the video card in a PC the more likely it is to fall prey to this problem.
One fix mentioned in Armstrong’s blog reads as follows “Get a system with Second Level Address Translation (SLAT).” This lets the hardware handle multiple translation lookaside buffers, on a one-per-VM basis (which is just what’s needed to sidestep the potential performance bottleneck that could otherwise occur). It looks like Microsoft simply opted to avoid potential performance problems from older hardware that might otherwise experience significant delays on the desktop to bypass potential customer complaints. In light of Armstrong’s admonitions to use the SVGA driver, choose a low-end graphics card, or turn off advanced graphics features, I find this decision “interesting” (in the sense of the Chinese curse) but also eminently understandable and defensible. But I still sigh to think of my otherwise very capable quad core Yorkfield processors (QX9650s, in fact) being consigned to the scrap heap of history (or turned into hand-me-downs) because they can’t run Windows 8 Hyper-V.
OK, I admit it: I’m dangerous when bored. Earlier this week, I was stuck in an all-day conference where I started to lose both interest and focus. As is sometimes my wont when that happens, I fired up DriverAgent on my HP dv6t notebook PC. No sooner fired up and run than I found a new driver for the unit’s built-in Nvidia GeForce GT 320 M graphics adapter. Here’s what Gabe Topala’s excellent SIW (System Information for Windows) has to say about that component:
SIW provides the current details on my notebook graphics situation
At first, I turned up the Verde 280.26 driver (which is what Nvidia still recommends for this chipset on their site) but when I installed it on my machine, Windows 7 presented me with a black screen the next time I rebooted, which immediately told me this graphics driver and my particular configuration weren’t suited to each other. I rebooted again in safe mode using HP’s equivalent of the “press-and-hold F8″ maneuver immediately after BIOS boot complete to get a generic VGA driver that would actually show me something on the screen.
Next, I launched Control Panel, and took advantage of Device Manager’s “Roll Back Driver” button on the Driver tab in the Properties window for the affected device. Luckily for me, this worked like a charm and my system was working again after one more reboot to switch over to the previous driver version.
The Roll Back Driver button can occasionally be a real life-saver
This also got me to thinking about what I would have had to do to get back up and running if there hadn’t been a driver to roll back, or the rollback effort had failed. My quickest fix would be to try the Last Known Good Configuration for the system (another boot option in the F8 menu). Next, I would download a known good working driver to a USB stick, then install that driver in Safe Mode, and try again. I’m pretty sure either one or the other (if not both) of these approaches would restore the unit to proper operation. As it was in my case, I’m pretty sure that none of my meeting colleagues noticed that anything was amiss with my system: it took less than five minutes to set things right.
Eventually I tried the beta 285.27 graphics driver in this machine, and I’m happy to report it’s working just fine. This graphics chipset is something of a wimp, but using MSI Afterburner with the settings turned up as much as I dare, it works OK for me.
Rats! I’m working out of town this week, and when I tried to grab the “new Windows Dev Center” Web page yesterday, it wasn’t up and running just yet. Now, I just tried again and there it is! The Developer Preview versions of Windows 8 builds (including both check builds with debugging code inserted, and unchecked builds for performance testing and just plain fooling around) are available for download. I won’t be able to grab and go anywhere with this stuff until I get back home tomorrow afternoon, but don’t let me stop you from beating me to that punch. Enjoy!
[Added 10 AM 9/14/2011] See this Windows 8 Developer Preview Hands-On article from Laptop Magazine for a great overview of the UI, plus new features and functions. A very nice piece of work, but too short on screen caps and illustrations; however, given the speed of its production, I totally understand why this might be the case. Read it to get a pretty good sense of what you’ll find in this Alpha version of the Windows 8 OS.
Apexwm is an active but anonymous IT professional who posts all over UK forums, and who also blogs prolifically for ZDNet in the UK. He recently posted a fascinating item entitled “Windows 7 driver signing conundrum” wherein he recounts a vexacious “chicken-and-egg” problem. The issue has to do with trying to slipstream a driver for a particular device into a Windows 7 image — in this case, an integrated wireless network adapter from RALink Technology — when the manufacturer only makes an Installshield program available to install the driver, but which must be installed manually after Windows itself is installed.
In attempting to automate the install, the author used a test machine to get the list of necessary files from Driver Details in Device Manager, and also grabbed the related oem*.inf file from the C:\Windows\inf folder to complete the collection of items to attempt an automated and unattended install. Imagine his frustration when this effort produces the following error message:
Windows cannot verify the digital signatures for the drivers required by this device. Error Code 52.
The drivers are in fact signed, and the problem is apparently well-documented all over the Internet for drivers of all kinds. But alas, no easy fix is available, without turning to 3rd party software products to remedy this known Windows defect. I’m sure apexwm isn’t the only Windows admin who would voice his sentiments on this approach “No thanks. I’m not about to start installing a bunch of unknown 3rd party products to try and help with a Windows problem.”
If I were in those shoes, however, I would try to take advantage of Windows’ ability to run post-install scripts after the initial installation process completes (which is how additional common applications such as Office, 7-Zip, FileZilla, and so forth, often occur at the tail end of automated installation processes). It seems to me that if the driver uses an InstallShield .exe file, there should be some way to script or automate its installation as a post-install task.
I do get apexwm’s complaint that Linux/Unix does a much better job of integrating drivers into its kernel directly, and that compilation into the kernel is an option for those few odd drivers that aren’t already included under this umbrella. But I’m a member of the “where there’s a will, there’s also a way” club of Windows-heads and suggest that he needn’t have given up in defeat.
In the past couple of weeks, I’ve gone through some systematic exercises to reduce the disk space consumed on my Windows 7 system/boot drives, especially on notebook/laptop systems where disk space is always precious and sometimes scarce, but also on a couple of my desktops where I’m running SSDs for the speed they bring to start-up, shut-down, application lauches, and context switching maneuvers. Here are some pointers to recent blogs I’ve written on various related topics on my personal Website at edtittel.som in the Windows 7 Tips and Tricks section:
- More Noodling on System Drive Space-Saving: Move those VHDs! (Moved Windows XP VHD to a subsidiary grive. Space saved: 6.8 GB)
- Nvidia: Why Do I Need 3D by Default? (Uninstalled Nvidia PhysX, 3D, and Nvidia Update drivers for a savings of nearly 35 MB of RAM, and disk space savings of nearly 1 GB.)
- Interesting tips and tweaks for PST File cleanup & optimization (Used the ScanPST.exe repair tool and compacted PST files to save around 2 GB of system disk space.)
All told I was able to reduce system disk size by at least 5 GB on each system where I tried to use two or more of these techniques. In one case, the savings was over 10 GB where I was able to reduce drivers, compact PSTs, and move the Windows XP VHD to my F: drive. I like it! Got any similar tips to share? Please do, and I’ll write them up if I can put them to work, too.
Here’s a concluding recommendation: try out the free WinDirStat graphical file system display utility. It will show you which files on your drives are the biggest, and point you at the fattest (if not most vulnerable) targets for cleanup. That’s what got me started down the cleanup road I document in the various aforecited blogs.
I’m working on a book about Windows 7 right now for the Microsoft Technology Association (MTA) program, specifically for Exam 98-349 “Windows Operating System Fundamentals.” And in fact, I’m knee deep in Chapter 4 of that book which takes Windows file management and Windows Explorer as a core topic. That’s why I read Ed Bott’s blog for today “Demystifying Windows Explorer: What ‘Invert Selection’ is good for” with great interest and appreciation.
Headline for Ed Bott’s 9/2/2011 blog
Apparently the appearance of this function in the Building Windows 8 blog earlier this week caused a tempest in a teapot with some readers, who went off on the continued existence of the function in the Windows Explorer of the future (not to mention the Windows 7 present as well). Pet peeves aside, it turns out that “Invert Selection” is a very nice little function, once you understand what it does. Basically, you can pick a list of things you want to keep unchanged in a folder (especially if it’s shorter than the list of things you want to move, delete, or modify), then use “Invert Selection” to de-select those items and select everything else instead.
For example, let’s say you’ve got a folder full of photos that you grabbed from your digital camera. After reviewing 75 snaps, you decide you only want to keep 5. So you pick them, then do ‘Invert Selection,’ then right click any of those entries, and pick “Delete” from the pop-up menu. Presto! All 70 unwanted photos are gone, gone, gone. Easy as pie!
In Windows 7 run Explorer (type
explorer.exe into the Start menu search bar, or click your favorite icon: I usually use the Folder icon that’s pinned to the Task bar at the bottom left of the screen to launch Explorer myself). Then click the Alt key to show the ordinarily hidden “File Edit View Tools Help” menu bar. The Invert Selection item appears at the bottom of the pull-down menu for the Edit entry in this menu bar. And it works like a champ, too.
Yesterday, MS honcho Steven Sinofsky posted an entry to the Building Windows 8 blog entitled “Accessing data in ISO and VHD files.” It explains how, in Sinofsky’s own words “Windows 8 enables easy access to the contents of two important storage formats: ISO and VHD files.”
ISO is, of course, an archive file format that represents a disk image of an optical disk or other storage medium, and usually takes .iso as its file extension. Microsoft uses ISO images to package up downloads of its various OSes and other products but until Windows 8, you’ve had to grab some kind of 3rd party ISO handling program to unpack them in a readable on-disk format. I use Alex Feinman’s excellent ISO Recorder v3.1, which functions as a Windows Explorer shell extension, but there are lots of great tools to do this job on earlier Windows versions.
VHD is a Microsoft virtual hard disk format (originally created by Connectix, since acquired by MS, for the Microsoft Virtual PC–and later Virtual Server and Hyper-V–products). It represents an image of what might appear on a physical hard disk drive, including disk partitions, a file system, files, folders, and so forth. A VHD represents the storage space for a virtual machine in the form of a single portmanteau file that takes the extension .vhd. Microsoft makes the VHD Image Format Specification freely available to third parties under its Open Specification Promise, which “provides broad use of Microsoft patented technology necessary to implement a list of covered specifications…[whose] goal…is to provide our customers and partners with additional options for implementing interoperable solutions.”
What does this all mean? It means you’ll be able to mount and read ISOs and VHDs from inside Windows Explorer in Windows 8, without having to install additional software. Unfortunately, it looks like the planned ISO implementation will be read-only, though. If you want to create ISOs, you’ll still have to install additional software on Windows 8. The same restrictions do not apply to VHDs, though: of them, Sinofsky says “you can…work with the virtual hard disk just like any other file storage in your system, whether you are modifying, adding, or removing files.”
Sounds good! When can we start playing with this new technology?
In my ceaseless trolling for good Enterprise Windows 7 news and info, I regularly scan the Microsoft and TechNet blogs. This morning, I decided to read the whole list of bloggers on TechNet and somewhat belatedly came across a listing called “The Deployment Guys.” I’m really glad I did because I came across quite a few gems there.
Aside from containing one of my all-time favorite “sniglets” — namely, automagically — this site offers up some incredibly useful information particularly when it comes to mastering the ins and outs of the Microsoft Deployment Toolkit 2010, including the following items among many others:
- Supporting different build types using a single deployment share
- Dynamic Computer Naming in ZTI Deployments
- Allowing Better Interaction to App-V Virtual Applications
- Finding Updates for Image Engineering
- New Optimized Desktop Resources
I could go on further, but this should be enough to show you that there’s a raft of great stuff here, along with lots of good tips and tricks about how to make the most of Windows 7/Windows Server 2008 deployment tools and technologies available from MS. If you’re at all like me, you’ll add this to your favorites, and you’ll start picking up on their Twitter or RSS feeds.
OK, so it may be too much of a stretch to compare rooting out a stubborn Registry key to Lady Macbeth’s lamentations, but it’s my blog and I can steal a line from Shakespeare with the best of them. In this case, I’m inspired by Scott Hanselman’s Computer Zen blog post entitled “How to REALLY hurt yourself with PSEXEC – Deleting the Undeletable Registry Key and More.” In a nutshell. this post explains how he got stuck with some Registry keys related to no less than SEVEN virtual network interfaces inside a VM and found himself unable to remove the registry keys responsible for their continued existence — and maddening consumption of system resources — despite running regedit.exe from an administrator account.
This whole story hinges on the wonderful Sysinternals utility called PsExec, which lets administrative users launch programs with arbitrary user rights. Hanselman couldn’t get regedit to delete the registry keys for the bogus virtual network adapters he wanted to remove from his system. Even in an account belonging to the Administrators group he was getting “Access Denied” errors when he tried to remove those registry keys.
PsExec let him load the regedit program and run it interactively at a System level of permissions (where anything is possible, and where “severe tire damage” far too likely for those who don’t proceed carefully, and don’t know in great detail what they are doing). The command syntax looks like this:
psexec -s -i regedit.exe
In this context, it’s also worth repeating Hanselman’s warnings about taking this approach to overpowering built-in Windows restrictions on deleting key registry keys, files, and other objects:
If there was one tool that really “takes the safety off the gun,” it’s PsExec. You can hurt yourself and your system with PsExec in ways where you’ll not realize until it’s too late. There aren’t enough words with big enough fonts and scary enough evocative stock photography to fully express how dangerous this tool is.
Wow! Nothing gets me as excited as the ability to do myself infinite harm, so I dove right into my Sysinternals tool directory and fired up a couple of programs using this very approach to see what I could get away with. Indeed, regedit performed as described and I was able to go in and delete anything I wanted to (which I immediately restored so as not to do any damage). The same trick also works for launching cmd.exe, and then you can use the command line to delete any Windows file you might want to get rid of without restrictions (the remorse could come later if you really shot yourself in the foot).
I think this is a great technique for Windows systems admins to add to their bag of tricks, but it really is one of those approaches that should be treated with extreme care and caution. Unless you know exactly what you’re doing and restrict your actions to repairing mistakes that Windows and other software can inflict on your system, you might be in for a world of hurt with this technique. My advice is to use it only for extremely limited purposes, and only when other tools or techniques just won’t or can’t fix your problems.
I’ve long admired and followed the work of Windows expert Ed Bott, who writes a regular blog for ZDNet (now a CNET property). His recent posting entitled “Stay safe online: 5 secrets every PC (and Mac) owner should know” is a short, sweet and extremely informative primer on what information security experts often like to call “safe computing practices” or “Internet Security Awareness.”
Ed Bott’s Safe Computing Blog