Run Process Explorer x64 LUA from Program Files without UAC prompts

procexpProcess Explorer by Mark Russinovich is a great improvement over the Task Manager program that ships with Windows. It give a ton of information about processes running on your computer. It keeps presents a full range of stats on every process including memory consumption and CPU time, loaded DLLs and open handle, strings embedded in the binary, environmental variables defined for the process, the full arguments used to start the process and nifty tools to find a process or a handle and a handy restart process. It is a great aid to debugging. ProcExp has some quirks when running on x64 Windows, though.

I have run my workstation as a “User” without admin rights for over 12 years since the days when I started running NT4 on my laptop. I used to have to log out and log in as an “Administrator” to install software or make system changes. There were tweaks you could make to dial back the security for some little things like creating a security role that could change the system date and time (which allows you to open the old-style date and time applet by clicking on the taskbar clock). With Windows 2000, things got a lot better with the runas service (like su(1) on UNIX)  but there were still some painful quirks because, for example, some software expects to be installed by the same admin user account that is using it. That’s where Aaron Margolis’s excellent makemeadmin script comes in. And finally with Windows Vista, we get UAC which, is nothing more than a speedbump warning system if you are an Administrator. However, if you are a non-Admin user it is a graphical just-in-time way to change the security of a running process by giving it Administrator credentials.

One of the main advantages of running with a limited user account (LUA) is that binaries in Program Files where they are protected from tampering by something malicious that you might accidentally invoke. For example, if you got hit with a zero-day browser flaw the worst (and this is very bad) thing that can happen is to have your personal data stolen or corrupted. The system itself cannot be subverted. Rogue usermode binaries cannot be installed and neither can drivers be installed. Hence, you cannot become part of a botnet and this is a very good thing.

Furthermore, most commodity attacks for Windows go straight for installing a rootkit without passing Go. That means instead of doing something bad to you that could succeed they try to do something worse that can’t and they crash doing nothing. That’s not a promise, just a generalization. AppLocker is what you need to take LUA to the next level to prevent unauthorized code from executing at all.

Anyway… Enough back story. Suffice it to say that I run my system without administrative rights and I don’t want to be typing in my admin credentials unless actually necessary.

The problem is that the x64 version of Process Explorer is embedded inside of the 32-bit version. When you invoke the 32-bit version of ProcExp on x64 Windows, procexp.exe extracts procexp64.exe into the same directory where it is currently running and starts procexp64.exe. If you have your Sysinternals tools in Program Files then in Vista or later with UAC turned on this generates a UAC prompt because procexp.exe is trying to write to the protected Program Files directory tree. (On Windows Server 2003 x64 or Windows XP x64 you get an access denied.) After procex64.exe exits the file is deleted.

ProcExp can actually run just fine without elevated permissions unless you need process details for a service or some other process running with another user’s credentials and procexp has a way to elevate itself to deal with that scenario, just like Task Manager.

Here is the trick to get procexp working LUA in Program Files on x64:

  • Download the procexp ZIP archive from Technet
  • Extract the ZIP file somewhere and run procexp.exe
  • Accept the license prompt
  • Make a copy of procexp64.exe (CTRL+C, CTRL+V will suffice)
  • Exit procexp.exe.
  • Delete procexp.exe.
  • Rename your copy of procexp64.exe to procexp.exe
  • Copy procexp.exe to your Sysinternals folder in “C:\Program Files”

Mark Russinovich could also solve this issue to either releasing a standalone x64 binary of procexp or changing the behavior of the extraction so that procexp64.exe doesn’t get deleted on exit (meaning you would just elevate once). In the mean time, the workaround isn’t too painful.


Boot Camp 3.1, from Apple this time

Boot Camp now officially supports Windows 7. As I expected, it is largely a repackaging of drivers previously released for Boot Camp 2.2. Here’s the flyby of what is in the update (I looked at the x64 version).

  • NVidia  display driver, 01/05/2010
  • Binary.aapltp_Bin
  • Binary.AppleBTBroadcom_Bin
  • Binary.AppleBTE_Bin
  • Binary.AppleBT_Bin
  • Binary.AppleDisplay_Bin
  • Binary.AppleiSight_Bin
  • Binary.AppleODD_Bin
  • Binary.asix_ethernet_Bin
  • Binary.AtherosWin7_Bin
  • Binary.Atheros_Bin
  • Binary.Ati_GraphicsWin7_Bin
  • Binary.Ati_Graphics_Bin
  • Binary.BroadcomEthernet_Bin
  • Binary.BroadcomWireless_Bin
  • Binary.Cirrus_Audio_Bin 6.6001.1.21 (all new!)
  • Binary.crystal_beach_Bin
  • Binary.intel_ethernet_Bin
  • Binary.IRFilter_Bin
  • Binary.Keyboard_Bin (same version number as was in Boot Camp 3.0 but I can definitely dim the keyboard more, now)
  • Binary.marvell_ethernet_Bin
  • Binary.MultiTouchMouse_Bin
  • Binary.MultiTP_Bin (same as in 2.2)
  • Binary.null_driver_Bin
  • Binary.Realtek_Bin
  • Binary.Sigmatel_Bin

Available from Apple in x86 and x64 flavors.

Raymond Chen answers my question

Nearly four years ago, I asked Raymond Chen why Microsoft has continued to use cryptic 8.3 filenames in Windows even though long filenames have been supported for many years. I wasn’t paying attention when Raymond answered me a year later. I just stumbled across this today.

Commenter Brian Reiter asks a duplicate of a question that was already submitted to the Suggestion Box: Darren asks why operating system† files still (for the most part) adhere to the old 8.3 naming convention.

It comes down to a handful of interesting reasons:

  1. Once a name is chosen, it can’t be changed for reasons of backwards compatibility with applications that may load a system DLL or invoke a system executable.
  2. By default all long file names are given a short file name. Loading a DLL by reference to a short and long file name into a program will yield two separate references of the DLL in memory.
  3. 8.3 filenames are know to work. If it ain’t broke, don’t fix it. Also, a related point here is that the system component installer technology in Windows XP and prior could only support 8.3 filenames. Pretty much any system component developed prior to Vista had to have 8.3 filenames. That includes some components developed for Vista while the new installer system was under development. (There a

My original question was why does the Framework Design Guidelines for .NET applications specify a totally different naming. The gist is that while native code and legacy components have the gotchas above, .NET assemblies are different because they have additional metadata including version number and public key token. In order to dynamically load an assembly, you either need to know its strong name or its full path and filename. There is very little chance of accidentally loading the wrong assembly unless you are the one building and signing the assemblies in question.

Make your own Apple Boot Camp “3.1” update

Apple loves to tout compatibility with Windows.

Have a Windows application you need to use once in a while? No problem. Every new Mac lets you install Windows XP and Vista and run them at native speeds, using a built-in utility called Boot Camp.

There is something to this and the Apple hardware is awesome but Apple is a bit heel-dragging and sloppy about the way they release drivers for Boot Camp. For example, Windows 7 was finished July 22, 2009 but as of December 15, 2009 it is still officially unsupported by Apple. Windows 7 uses the same driver model as Vista, so that policy from Apple is just recalcitrant and disingenuous. Apple really does provide all the drivers you need to get Windows 7 x86 or x64 to run natively on Mac hardware.

On the other hand, some of the drivers in Boot Camp 3.0 are really flaky. For the latest Macbook Pros that use Cirrus Logic audio controllers, the volume is messed up so the internal speakers are un-hearable and the built-in microphone doesn’t work at all with some applications—notably Skype.

Apple actually does have updated drivers available. They are packaged as Boot Camp Drivers Update 2.2.

Setup is simple and straightforward — just as you’d expect with a Mac.


Except that if you are running Boot Camp 3.0, you are screwed and the setup is very not straightforward and there is no one-click installer from Apple. It is doable, though, and worthwhile.

This update addresses issues with the Apple trackpad and turns off the red digital audio port LED on laptop computers when it is not being used. It also includes support for the Apple Magic mouse and wireless keyboard. It is intended only for use with Microsoft Windows XP and Microsoft Windows Vista running on a Mac computer using Boot Camp.

If, like me, you are running Boot Camp 3.0 with Windows 7 on your MacBook Pro and you want these updates here’s what you have to do.

  • If you don’t already have it, install 7-zip.
  • Download the Boot Camp Drivers Update 2.2 for Windows from
  • After you have BootCamp_Update_2.2.exe, right-click on it and select 7-zip | Extract to “BootCamp_Update_2.2\”.
  • Now you have a directory of files that includes BootCampUpdate32.msp and BootCampUpdate64.msp. The 64 version will work with Windows Vista or 7 x64.
  • Right-click on the appropriate msp file and extract it with 7-zip.
  • Now you have a directory full of weird file and folder names. One of the folders should be named “BootCamp24ToBootCamp223”. Inside there are some files that are named with the pattern Binary.*_Bin:

Binary.Cirrus_Audio_Bin –> Fixes audio levels and microphone
Binary.Keyboard_Bin –> Same version that shipped with Boot Camp 3.0
Binary.MultiTouchMouse_Bin –> Magic Mouse driver
Binary.MultiTP_Bin –>  Fixes accidental select while dragging
Binary.TrackPad_Bin –> I don’t have the older touchpad so I don’t know

    • Each of these files is an archive that you can extract with 7-zip. Once you extract them, you can install the drivers by running DPInst.exe or by pointing the Device Manager at the extracted drivers in the usual way.

Happy updating.

Now that that’s out of the way, can someone explain to me why this had to be so hard?

Why bundle these updates with a smug “Setup is simple and straightforward — just as you’d expect with a Mac” tagline but make sure that the customers who bought the latest hardware and latest OS X cannot install them? It makes no sense.

Why did Boot Camp 3.0 ask me to configure automatic driver updates from Apple but Apple doesn’t actually publish any driver updates though that channel? It makes no sense.

%d bloggers like this: