Ed Bott's Windows Expertise

Are you ready to spring forward? In the U.S., at least, Daylight Saving Time begins this weekend.

I know because Windows told me so:

Gosh, it seems like only yesterday that we were falling back.

It’s hard to get used to this earlier start for DST.

Andy Ziegler, a Program Manager on the IE8 team, just published an interesting post on the IE Blog going into some technical details about how Internet Explorer keeps tabs separate from one another. The subject of tab isolation is fascinating, in a geeky way, and extremely relevant even to non-geeks, for two reasons. First, tab isolation is a reliability feature; if one tab crashes, you don’t want to lose all your other tabs. And second, it’s also a security feature, one that browser developers have been wrestling with for years in the form of cross-site scripting and other attacks.

Microsoft takes a lot of heat for being a follower in browser development, but as Ziegler notes, they’ve been ahead of the curve on this one:

On March 5, 2008, Microsoft released the first IE8 beta with Loosely-Coupled IE (or LCIE for short). This was the first mainstream implementation of tab isolation. On September 2, 2008, Google Chrome’s first beta released with “process isolation.” Mozilla Firefox has recently discussed an “Out of Process Plugins” (OOPP) or Electrolysis project aimed at isolating Firefox plug-ins, such as Flash, from the rest of the browser.

You can see the IE8 design at work if you open up a single tab and then check the Processes list in Task Manager. With one tab open, you’ll see two instances of Iexplore.exe. Why two?

IE8 isolates the frame process (title bar, back button, address bar, etc.) from the tabs processes (that show web pages). If anything causes a site to crash (an extension like Flash, or the rendering or scripting engine, etc.), the frame and other tab processes will not crash. IE isolates the whole tab – all of its code, data, and extensions – to keep IE resilient to webpages with issues.

One interesting thing I’ve noticed over the past year or so while working with IE8 is that there isn’t a predictable correlation between the number of tabs and the number of processes. For instance, right now I have 16 IE8 tabs open, but Task Manager shows only nine processes running:

I’ve heard some theories about how IE8 combines tabs into a single process while still maintaining the ability to recover in the event of a crash, but I haven’t seen any official documentation on the subject. Andy, if you’re looking for new blog topics, that’s a good one for you.

Update: I decided to explore a little more intently and found a great blog post from the IE support team that explains how IE manages the number of new tab processes. Geeky but interesting.

Ziegler’s post also contains a terse but interesting competitive analysis of the differences between the sandboxing approaches taken by IE and Google Chrome. Not surprisingly, he argues that Microsoft’s approach is fundamentally more secure. I’ll let you read and decide.

Finally, if your eyes bulged out a bit when you saw the memory in use by each one of those Iexplore.exe processes in the Task Manager shot above, you’re not alone. I watched that phenomenon for several months until I finally got a handle on what’s going on. The first time I saw a single process shoot up over 500 MB, it was fairly alarming, but it’s worth noting that this system has 10GB of RAM and isn’t close to running out of memory. As I’ve noted earlier, Windows believes in the philosophy that empty RAM is wasted RAM.

If I were to open this same assortment of tabs on a machine with, say 2 GB of memory, I’d see a very different memory usage pattern, with each process quickly surrendering memory when another process needs it.

And here’s what’s most interesting of all, and a testament to IE’s ability to recover. From Task Manager, I just forcibly ended the three processes that were consuming most memory on that list. As I killed each process, I saw the tab (or tabs) associated with that process reload in the browser. When I was all done, I hadn’t lost a single tab and Task Manager looked very different:

That’s 12 processes, totaling roughly 598MB of memory. Compare that with the previous load, which involved nine processes using 1,051 MB of memory. For those keeping score, that’s a 43% drop in memory usage. I don’t recommend randomly killing Iexplore.exe processes this way, but it’s comforting to know you can do so with no adverse consequences.

Remember last month when some Windows customers complained that their systems were crashing after installing a round of patches from Windows Update? It turned out the problem wasn’t the MS10-015 update after all. Instead, the systems were infected with a nasty piece of malware that was actually the root cause of the crashes.

Now, roughly three weeks after the initial reports first appeared, the problem has been resolved and Microsoft has re-released the update:

[W]e have revised the installation packages for MS10-015 with new logic that prevents the security update from being installed on systems if certain abnormal conditions exist. Such conditions could be the result of an infection with a computer virus such as the Alureon rootkit. If these conditions are detected, the update will not be installed and the result will be a standard Windows Update error.

Microsoft has also released a standalone scanning tool that you can use to check any system for the presence of malware that will cause this specific problem. I ran the FixIt utility on a test system here and got a clean bill of health:

If you previously hid this update because you were concerned that it might affect your system, you can consider this an all-clear.

Ever wonder how Windows 7 pirates work? So did I.

So I did some research and tried a couple of interesting tools commonly used in the hacking community.

The results were eye-opening.

Details in my new post at ZDNet:

Confessions of a Windows 7 pirate

Questions? Comments? Feel free to leave them here if you don’t want to endure the free-for-all in the Talkback section there.

This week, Microsoft’s latest update to its Windows Activation technologies started appearing on Windows 7 machines via Windows Update. I’ve written about it at ZDNet:

Does that new Windows Activation update really ‘phone home’?

I completely understand why people don’t like activation. It can be a nuisance, although in practice it is a non-issue for most people. If your system is flagged as "non-genuine" and you have to go through the hassle of reactivating it over the phone, that’s 5-10 minutes of your life you’ll never get back. It happens to me occasionally when I restore a backup to a system after performing a major hardware upgrade. And I have never, ever had an issue with reactivating a Windows system over the phone.

In fact, my research shows that the incidence of false positives associated with Windows activation and validation has dropped dramatically in the four years since Windows Genuine Advantage was introduced. The rate of false positives used to be unacceptably high, now it’s barely noticeable and usually explainable (malware and pirated software is the most common explanation). If you have a different story to tell, please let me know in the comments, but be aware I will need full details to (via e-mail) to follow up properly.

Anyway, the story with the latest update is that there’s really nothing new to see. The KB971033 update doesn’t check your system to see whether you’re a pirate; it checks the integrity of the Windows system files to ensure that they haven’t been tampered with. It’s looking for known activation exploits, which can be used by rogue system builders to foist pirated software on unsuspecting customers. Microsoft released similar updates in February 2008 and February 2009 for Windows Vista. The only thing that’s different here is that this one downloads revised signatures every 90 days.

This just showed up overnight via Windows Update:

February 2010 Windows Media Center Cumulative Update for Windows 7

Microsoft has released the February 2010 Cumulative Update for Windows Media Center for Windows 7. This update rollup is intended for computers that are running Windows Media Center on Microsoft Windows 7.

Issues that this cumulative update package fixes

The February 2010 Cumulative Update for Windows Media Center for Windows 7 resolves the following issues:

• Improves the overall experience for systems that are configured by using digital cable card tuners.
• Resolves backward compatibility issues for some legacy Windows Media Center extensibility applications.
• Resolves an issue with how recorded TV shows are managed when switching to a user locale that is based on the Hijri calendar.
• Improves the overall experience when you use Integrated Services Digital Broadcasting (ISDB) tuners. ISDB is a Japanese standard for digital television and digital radio.

The first bullet is probably the most important one. I’ve noticed very few issues on the two CableCARD systems I have running here, but with the opening up of CableCARD tuners to hobbyists and the launch of Ceton’s new tuners imminent, there should be an influx of new digital cable tuners this year.

If anyone spots any issues after this update, be sure to leave a comment.