Changes to the Operating System Layers (Compatibility Modes) in Windows 7

It’s visible in the beta, but I haven’t heard a lot of people talking about this externally. Regardless, I wanted to shed some light on what happened, and add a bit of the human perspective behind the decision.

If you inspect the operating system layers (called Compatibility Modes in Compatibility Administrator), you’ll find that they contain an important new entry: AdditiveRunAsHighest. Let’s explore this a bit, because it’s pretty important what it does.


First and foremost, AdditiveRunAsHighest is RunAsHighest. (We’ll get to the Additive part in a bit.) It’s an incredibly confusing elevation flag for many folks. It basically means that, if you have the ability to elevate to a higher token, then please do. Otherwise, just stay where you are. That means, if you’re a member of the Administrators group with UAC turned on, and you’re not currently running elevated, you’ll see a prompt. If you are a standard user, you will not. If you have the SeLoadDriver privilege in your token but would otherwise be a standard user, we’ll still split your token, and if you provide the same credentials, we’ll elevate to a token that contains that privilege. (You can’t think too black and white about elevation – not everyone is cleanly either an admin or a standard user.)

I say that it’s confusing because most people don’t fully grok that. Most people, rather, believe that MMC.exe requires being an admin, and that’s why it prompts. It doesn’t require it, you just happen to have a more privileged token available so it’s going to try to use it. If you were running as a standard user, you wouldn’t see a prompt!

OK, so we’re off to a good start – the new shim is related to the most confusing elevation flag we’ve got. How have we made that more interesting?


If you’re an IT Pro, you’ll like this: you always get to win. You see, a developer can specify, in the XML manifest for an application, the run level for that application. But you, as the IT Pro, get to overrule that. If you think the developer made a bad call with their specified run level, just specify what you think, and you’ll win.

But AdditiveRunAsHighest means that you only care to vote if the developer didn’t. So, if you find a manifest specifying run level, you’re voting to take what they asked for. If not, then you are asking for RunAsHighest.

(I guess I find that a little curious because, if you know enough about Windows Vista to add a runlevel to the manifest, it’s not entirely clear why you would need an XP or earlier shim, but so it goes.)

Putting it all together

What this basically means is that, if you were running as a standard user, and you didn’t work, the RunAsHighest will leave you as a standard user, and unless file/registry virt fixes you, you’re still broken. No regression. But, if you were previously a full admin, and now you’re a protected admin, you’ll prompt to get back to full admin, and away you go.

If only it were that simple. But, realistically, nobody is super happy with this outcome. This doesn’t represent what we wanted to do, it represents what we could do in the parameters we were given (which included, of course, the parameter of, “we have to ship an operating system”).

Elevation fixes ~20% of broken applications that used to work on XP

There are truths, half-truths, and statistics. This is a statistic. That’s the bright side. The down side is that the other 80% of applications aren’t fixed by elevation (actually it’s more like 50% when you incorporate this PLUS other fixes in the layer, so that’s a little unfair of me), yet they are prompting you anyway! But, in the absence of other alternatives, it was decided that people are more annoyed by apps not working than they are by prompts. Oh yeah, we know you’re still annoyed by prompts – we just think you’re more annoyed by broken apps.

And, when it came down to it, even if the number of apps fixed were 10%, it would have been a no-brainer for the team. Broken apps are a serious downer.

What does it mean for me?

Well, if you’ve built up a custom shim database that contains operating system emulation layers, their behavior is going to change. You may want to edit them. I typically recommend that you chose only the specific shims that you need, rather than taking a whole layer, and I’d just go that route.

If you’re fiddling with the compatibility tab, it means you’re going to get more prompts.

Several Program Compatibility Assistant scenarios lead to the XPSP2 layer, which will mean more prompts even if you don’t get geeky on us.

It also could mean that more apps work, if you are a consumer with little knowledge of elevation, tokens, administrators, or any of that garbage, and just want your apps to work. That’s who we’re really targeting with this. Someone advanced enough to find the compatibility tab (or lucky enough to have PCA suggest fixing something) but not advanced enough to be reading this and looking to become a shim ninja.

What we would rather do

Like I said, this was a trade-off. And, honestly, a few folks were pretty up in arms about this (and I count myself among them) until we finally got people to stop suggesting that this was a solution people actually were quite fond of and shouldn’t we just drink the kool-aid and believe that it truly was good for us, and instead fess up that they fought it themselves but just couldn’t get it done in the ideal way so had to find the best compromise for the non-ideal choices that lay before them.

We’d rather have a quick, automated way to put in a targeted fix that didn’t mean “keep running as admin” and instead did something less reckless. But that’s hard to do. (Aaron Margosis seems like he’s coming pretty darned close, though – just give him time.)

If we’re going to elevate, we’d like to have a way to kill the prompts somehow. (Aaron won’t be so fond of that one.)

In the end, it’s all a balancing act. Unlike milk, software doesn’t go bad. You shouldn’t have to go buy a new version of something until it offers features that make you happy (or, these days, until you can afford it). But how do we move the software ecosystem forward, without making you pay the price?

I keep saying this, I know, but it keeps being true: app compat is hard.

Comments (6)

  1. Vijay says:

    Fantasic Post Chris !!

    Wish to read many more articles from you !!

  2. after surviving a horrific injury while on deployment in afganistan, my proficiency in IT has suffered due to "TBI" and I want to thank you for taking time to better explain things. "Even though I still have great difficulty understanding it helped"

    I hope to hear more to help me reeducate my brain in the manner it was before being wounded.

    thank you


  3. CD Tom says:

    I’ve just downloaded and installed the RC for windows 7 and find that this release doesn’t have the AgentSvr.exe included with it.  I’m wondering if this is a error on Microsoft or was it done intentionally? One of my applications required it in the compiler and in order to get my app to install on window 7 RC.  The AgentSvr.exe was in the earlier release of Windows 7 but not this one.  If anybody knows why this was done of if the AgentSvr isn’g required in Windows 7 RC I’d like to know.  Thanks

  4. cjacks says:

    Hi CD Tom,

    Yes, Microsoft Agent has been deprecated from Windows 7. See:



  5. Ganesh says:

    Hi Chris, Just have a quick question , Does SUA catch issues even if it has been shimmmed?

  6. cjacks says:

    @Ganesh – For the most part we will, but you’ll notice that SUA gives you a warning if shims are applied. That’s because both shims (unless configured with ShimViaEAT) and AppVerifier use IAT modification. Since both overwrite the function address, clearly only 1 can win (and, in my experience, that tends to be AppVerifier) so you enter kind of an unusual state if your measuring against the same APIs that you’re fixing already.

Skip to main content