Sandboxing Flash with Chrome

Perhaps the most brilliant feature of Google’s Chrome browser is that it installs itself without any admin rights required inside each user’s profile directory. The first important consequence of this is that Chrome can go viral inside of corporate departments officially standardized on IE6 because it doesn’t require any tech savvy to install Chrome outside of the protected “Program Files” directories. The second consequence is that, since the user always has full permissions to its install directories, Chrome can and does silently and continuously update itself.

The updating works extremely well. It happens quietly in the background. After an update has occurred, the next time Chrome is started it is the new version. Chrome does have security bugs, but it uses Integrity levels to sandbox itself and patches are continuously and silently rolled out which keeps the browser safe.


Recently Chrome started distributing its own private copy of Adobe Flash. That means that Google believe that Flash is necessary. Since Flash is necessary, Chrome will always have the latest version of Flash and it will be silently updated along with Chrome itself. For all other browsers, there is no automatic update process for Flash. The standard ActiveX installation process for IE is painful and failure prone. For this reason alone, Chrome distributing its own Flash is great but since Flash is also riddled with security problems, this is a huge win.

Adobe seems to be happy with this Google-love, especially since they are being flamed publically and repeatedly by Steve Jobs. It is interesting but I think what is really going on is that Google recognizes that if Flash doesn’t work right or you get a malware while using their Chrome, Google takes the blame.

Whatever the motivation, it is a win. I’m ready to let Chrome handle updating my Flash and stop wasting my time worrying about whether I have the current version and whether it is safe. In fact, I can’t think of a good reason to have Flash floating around on my system as a global service outside of its Chrome sandbox.

Adobe provides a tool to globally uninstall Flash which removes both the ActiveX and Netscape-compatible plug-in versions but leaves Chrome’s private Flash runtime untouched.



ProcExp: The .NET Performance counters are corrupt

Imagine my surprise when Process Explorer v12.04 giving me a big nasty bonk when trying to examine a .NET process that I’m working on.


Process Explorer
The .NET performance counters on this system are corrupt.
Run Exctrlst from the Microsoft Windows Resource Kit to repair them.


I downloaded and installed exctrst from Microsoft. It didn’t do anything useful to solve the problem. After thrashing around for a while, I came across this KB article: BUG: PDH-Based Applications Stop Responding for 60 Seconds Before Exiting on Windows XP.

In the resolution it talks about disabling .NET core performance counters in the registry

To prevent the delay, you can turn off the .NET Framework performance counters:

  1. Locate the following key in the registry:
  2. Change the Library value from mscoree.dll to donotload_mscoree.dll.

If you later decide to turn on the .NET Framework counters, change the Library value back tomscoree.dll.

Out of desperation, I took a look at my registry.

PS> get-itemproperty HKLM:\System\CurrentControlSet\Services\.NETFramework\Performance | select library


Doh! Something, disabled my .NET Performance Counters in the registry just as described in that KB Article. I run daily as a non-admin so it can only have been an installer. I’m not sure which one is the culprit, unfortunately. I recently upgraded to ProcExp 12.x from 11.x. It may be that my counters have been disabled forever and 12.x is the first version to complain or it could be something I installed recently. I don’t know.

Restoring the Library key to the value “mscoree.dll” sovled the problem.


%d bloggers like this: