Chris Jackson's Semantic Consonance

Windows 7 Application Compatibility List for IT Professionals

2009-11-17T15:21:07Z

It’s finally here!

We released the Windows 7 Compatibility Center a few weeks ago. This lets you look up one application at a time. You can find that at http://windows.com/compatibility.

Today, we have a downloadable list indicating vendor support. If you want to write some automated matching against your list of application, you can use this – it is an Excel download of all known information from vendors. You can find that at http://www.microsoft.com/downloads/details.aspx?FamilyID=890e522e-e39e-4278-aebc-186f81e29173&displaylang=en.

The final step will be to have this information integrated directly into ACT. The target date for this integration is mid-December 2009. We’re getting there! We’re also planning to keep this data updated bi-weekly.

Enjoy!

How to Remove the RC Designation from the Windows 7 Reports in ACT 5.5

2009-11-06T20:56:30Z

We shipped ACT 5.5 back in April 2009, several months before we shipped Windows 7. Helpfully (I guess) we decided to label it Windows 7 RC in the UI so you could specifically track your testing against the release candidate. We had the idea that we could update this via our web service, so that once we hit RTM we could just push out an update to modify this.

And apparently we forgot to turn this little bit of code on.

So, now we have a bunch of folks around the world who wonder why ACT seems to be in a beta phase and not ready for Windows 7 RTM.

Well, it is ready for Windows 7 RTM, and I bet some of you would like it to look ready. We’re really sorry we can’t do that using the mechanisms we planned to use, so I figured I’d let you in on the secret to the planned update.

We were going to update 2 fields in the database.

So, if you want your ACT UI to look ready for the ~~future~~ present, you can run this bit of SQL:

UPDATE dbo.OS
SET osName='Windows 7'
WHERE osName='Windows 7 RC'
GO
UPDATE dbo.OS
SET osName='Windows Server 2008 R2'
WHERE osName='Windows Server 2008 R2 RC'
GO

Enjoy, and sorry for the inconvenience.

Carrying Custom Application Sound Events Between Sound Schemes in Windows 7

2009-10-28T04:30:58Z

Today, I just might ruffle a few feathers by doing so, but I figured I’d go through and demonstrate the process of reversing some incompletely documented stuff in Windows in order to fix a problem that was causing me some personal pain.

Specifically, I’m going to talk about sound schemes in Windows 7. With Windows Vista, we had only 1 sound scheme (unless you bought Ultimate, in which case the additional sound schemes were provided as Ultimate Extras). With Windows 7, you get multiple sound schemes.

And for a while, I was terrified of using any of them other than the one I had originally selected.

You see, every time I would change the sound scheme, I would lose sounds in a number of my other programs. Pretty much anything that wasn’t Windows. I like my computer making little beeps and boops all the time (seriously – I still add in the Office 97 sounds, because I like the audio feedback I get when deleting, moving copying – it feels bizarre not to have it after more than a decade of always hearing it).

When we released a whole bunch of new themes for Windows 7 on the day we reached General Availability, I had reached the last straw. The themes all changed my sound scheme, and I don’t want to lose the sound from my other programs thank you very much. So, I set out to figure out how to fix that.

Here’s a blog post that described how to set up the sounds:

A Peek Behind the Beep

Put sounds in .current, eh? Well, time to go spelunking. For the sounds that do switch around, I notice more in the registry than just .Current. I notice that each event not only has a .current subkey, it also has a subkey with the name of each of the sound schemes. So, it seems likely that everyone who adds a new set of application sounds would only affect the current sound scheme, and as soon as you changed it, those settings would go away!

A quick check with process monitor would confirm that:

8:08:59.2736148 PM    rundll32.exe    4796    RegOpenKey    HKCU\AppEvents\Schemes\Apps\Communicator\COMMUNICATOR_appinvite\Delta    SUCCESS    Desired Access: Maximum Allowed, Granted Access: All Access
8:08:59.2736558 PM    rundll32.exe    4796    RegQueryValue    HKCU\AppEvents\Schemes\Apps\Communicator\COMMUNICATOR_appinvite\Delta\(Default)    BUFFER OVERFLOW    Length: 144
8:08:59.2737043 PM    rundll32.exe    4796    RegQueryValue    HKCU\AppEvents\Schemes\Apps\Communicator\COMMUNICATOR_appinvite\Delta\(Default)    SUCCESS    Type: REG_SZ, Length: 172, Data: C:\Program Files (x86)\Microsoft Office Communicator\Media\COMMUNICATOR_appinvite.wav
8:08:59.2741839 PM    rundll32.exe    4796    RegCloseKey    HKCU\AppEvents\Schemes\Apps\Communicator\COMMUNICATOR_appinvite\Delta    SUCCESS
8:09:00.4227580 PM    rundll32.exe    4796    RegOpenKey    HKCU\AppEvents\Schemes\Apps\Communicator\COMMUNICATOR_appinvite    SUCCESS    Desired Access: Maximum Allowed, Granted Access: All Access
8:09:00.4227946 PM    rundll32.exe    4796    RegQueryKey    HKCU\AppEvents\Schemes\Apps\Communicator\COMMUNICATOR_appinvite    SUCCESS    Query: HandleTags, HandleTags: 0x0
8:09:00.4228254 PM    rundll32.exe    4796    RegCreateKey    HKCU\AppEvents\Schemes\Apps\Communicator\COMMUNICATOR_appinvite\Delta    SUCCESS    Desired Access: Set Value
8:09:00.4228632 PM    rundll32.exe    4796    RegSetValue    HKCU\AppEvents\Schemes\Apps\Communicator\COMMUNICATOR_appinvite\Delta\(Default)    SUCCESS    Type: REG_SZ, Length: 172, Data: C:\Program Files (x86)\Microsoft Office Communicator\Media\COMMUNICATOR_appinvite.wav
8:09:00.4229075 PM    rundll32.exe    4796    RegCloseKey    HKCU\AppEvents\Schemes\Apps\Communicator\COMMUNICATOR_appinvite\Delta    SUCCESS
8:09:00.4229383 PM    rundll32.exe    4796    RegQueryKey    HKCU\AppEvents\Schemes\Apps\Communicator\COMMUNICATOR_appinvite    SUCCESS    Query: HandleTags, HandleTags: 0x0
8:09:00.4229707 PM    rundll32.exe    4796    RegCreateKey    HKCU\AppEvents\Schemes\Apps\Communicator\COMMUNICATOR_appinvite\.current    SUCCESS    Desired Access: Set Value
8:09:00.4230081 PM    rundll32.exe    4796    RegSetValue    HKCU\AppEvents\Schemes\Apps\Communicator\COMMUNICATOR_appinvite\.Current\(Default)    SUCCESS    Type: REG_SZ, Length: 172, Data: C:\Program Files (x86)\Microsoft Office Communicator\Media\COMMUNICATOR_appinvite.wav
8:09:00.4230401 PM    rundll32.exe    4796    RegCloseKey    HKCU\AppEvents\Schemes\Apps\Communicator\COMMUNICATOR_appinvite\.Current    SUCCESS

Yes, indeed – when you change the sound scheme, you copy the values over from the subkey with the new scheme name into the .current key. And none of the program sounds from external programs contained subkeys for each (or any) of the schemes!

So, I’m thinking I’ve reversed the secret to carrying my program sounds over from scheme to scheme – could it be that simple? Only one way to find out – populate them! But, if there were so few that I could do so easily by hand, then I wouldn’t be reversing this stuff in the first place. So, it looks like it’s time for a PowerShell Script! Here’s what I wrote:

foreach ($app in Get-ChildItem -Path "HKCU:\AppEvents\Schemes\Apps")
{
    if (($app.PSChildName -ne ".Default") -and ($app.PSChildName -ne "Explorer") -and ($app.PSChildName -ne "sapisvr"))
    {
        foreach ($events in Get-ChildItem -Path $app.PSPath)
        {
            $event = $events.PSPath
            foreach ($soundSchemes in Get-ChildItem -Path "HKCU:\AppEvents\Schemes\Names")
            {
                $soundScheme = $soundSchemes.PSChildName
                if (($soundScheme -ne ".Default") -and ($soundScheme -ne ".None"))
                {
                    $defaultPath = $event + "\.current"
                    $newPath = $event + "\" + $soundScheme
                    if (Test-Path $newPath)
                    {
                        Remove-Item -Path $newPath
                    }
                    Copy-Item -Path $defaultPath -Destination $newPath
                }
            }
        }
    }
}

I ran this script, and tried changing my sound scheme. Sure enough, it worked! I was able to swap out my sound schemes, and the other applications which extend the sound scheme mechanism in Windows still generate the sounds which makes their use so much more satisfying! (Or, in the case of Communicator, it’s downright critical to the way I use the application.) Hooray!

Now, this is kind of a klugy workaround, which depends on my reversing and guessing correctly on a couple of things. What could we do differently? Well, ideally the application developer would have enumerated the schemes, which is something they wouldn’t have had to do with Windows Vista (except in the case of Ultimate Extras), and added their sound events to each of the schemes. But, it’s a little bit late for that now – these apps already exist. The sound schemes already exit, and there is no API we can intercept – the apps are just writing to the registry. So, if we wanted to do something about this within Windows, we’d have to do something proactive to mitigate the issue with other programs in response to a sound scheme change event. That’s getting a little bit harder to argue for in a service pack, but you never know. It’s worth a try at least.

For now, you can use my workaround, and carry your sounds around with you from scheme to scheme. Happy dinging!

Windows 7 Compatibility Center Live on the Web

2009-10-21T16:45:10Z

Hooray – I can stop pasting this link into emails!

The Windows 7 Compatibility Center is now live.

Using the uiAccess attribute of requestedExecutionLevel to Improve Applications Providing Remote Control of the Desktop

2009-10-16T01:47:04Z

I’ve run into this exact same problem 3 times now in one week, so I figure that probably doesn’t bode well and I should attempt to do something about it.

With 3 different pieces of software (one of them ours), the remote control functionality is imperfectly implemented. Let’s see if this sounds familiar to anyone. You are the helpdesk. You attempt to connect to a user’s desktop. You have to elevate an application. When you do, you (the helpdesk who actually has the password) doesn’t see the UAC dialog – instead, the end user (who does not have the password) does. Even if you decide to give the user the password (it happens), you then can’t control or even see the elevated application.

Kind of makes it hard to be a helpdesk when that happens.

Here are the 3 solutions that I have seen to this problem:

Do nothing. That’s what our solution did. It just failed every time elevation was involved.
Install a service. That’s what company X did. It requires the user to know an admin password, and that’s a problem for my customers
Run the application elevated. That’s what company Y did. It requires the user to know an admin password (a problem with my customers), and also won’t allow you to interact with any windows running at System integrity level (so an incomplete solution)

Here’s what I wish all 3 had done:

Manifest with uiAccess = true

Now, most people don’t really understand what this is for, and the UAC manifest is typically just a copy/paste affair. But it pays for the remote desktop developer to pay attention to it. For any regular piece of software, you generally want to stay away from it – it’s dangerous, and sidesteps a significant security feature (UIPI). But if you are remoting the desktop, it’s precisely what you want – you need to be able to see everything!

It’s dangerous enough, in fact, that we won’t allow you to set it without digitally signing your application. By default, you also have to have it installed in a secure location (such as Program Files). You can set a group policy to not require a secure location, but there is no option to not require a signature.

However, once set up, it’s really powerful. You’ll be able to remote every possible kind of window – any integrity level at all. No more blank, unresponsive screens. Everything comes across, regardless of integrity level.

You’ll also be able to leverage the group policy that lets you prompt NOT on the secure desktop if you are a UIAccess application – that way you don’t have to lose the defense in depth of using the secure desktop for normal elevation, but you also avoid writing code to remote the secure desktop when your remote desktop application is running.

All in all, you are just full of win.

Now, it’s my job to fix up apps that are written suboptimally, so you may be wondering how I did getting these working?

Our application, rather conveniently, used an external manifest. All I had to do was open up the manifest in Notepad, and type four characters (t-r-u-e) in the uiAccess attribute. Done. Now it works great. (Of course, everyone who downloads it will download a new broken one, so they’ll have to text edit it too – clearly we want to work with the team that makes this to fix it on their end, but you aren’t stuck – you can fix it without depending on anyone else.)
Company x, the one that used a service (claiming of course that it was UACs fault that they had to do this)? I can’t fix it. They used an internal manifest, which has precedence over any external one I might lay down there. I could extract that manifest with mt.exe, edit it, and then re-inject it, but then I invalidate the digital signature. Remember that this is a non-optional requirement for a uiAccess app! So, there is nothing I can do. I’m trying to contact the vendor.
Company y, the one that elevates to admin – this one I didn’t have time to examine – they do a “just in time” install and uninstall, so I couldn’t explore the manifest, but since it’s so transitive it’d be hard for me to do much anyway that would last.

Anyone writing desktop remoting applications, please consider using this. And feel free to contact me if you have questions. I would be delighted to help you.

For the record, here is the corrected manifest for the one I was able to fix:

<?xml version='1.0' encoding='UTF-8' standalone='yes'?>
<assembly xmlns='urn:schemas-microsoft-com:asm.v1'
manifestVersion='1.0'>
<assemblyIdentity
   version="1.0.0.0"
   processorArchitecture="X86"
   name="Microsoft.FixedUpApp.SupportConsole"
   type="win32"
/>
<description>Fixed Up App</description>
    <dependency>
      <dependentAssembly>
        <assemblyIdentity type='win32'
         name='Microsoft.Windows.Common-Controls'
         version='6.0.0.0'
         processorArchitecture='x86'
         publicKeyToken='6595b64144ccf1df'
         language='*'
        />
      </dependentAssembly>
    </dependency>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
    <security>
      <requestedPrivileges>
        <requestedExecutionLevel level="asInvoker"
         uiAccess="true"/>
      </requestedPrivileges>
    </security>
</trustInfo>
</assembly>

Understanding the AdditiveRunAsHighest Flag on Windows 7

2009-10-08T23:32:35Z

This post corrects an error from a previous post.

Back when I was explaining the changes in the operating system layers for Windows 7, I incorrectly described the AdditiveRunAsHighest. Since RunAsHighest is already confusing enough, and AdditiveRunAsHighest is even more confusing (even I got it wrong), I want to make sure I actually get it right (and apologize for not having done so before).

AdditiveRunAsHighest requests that the application receives the RunAsHighest flag if and only if nobody else has requested a higher level of elevation.

That means we will overrule a manifest if that manifest is asInvoker, but we will not overrule a manifest if that manifest is requireAdministrator. It also means we will overrule a layer if that layer requests RunAsInvoker, but we will not overrule a layer if that layer requests RunAsAdministrator.

In short, it means that this flag will only be used to increase your level of elevation (to highestAvailable) and will never be used to decrease it (from requireAdministrator).

The reason why this flag exists? Setups. If we think you are a setup, then the setup detection logic applies the VistaSetup layer, which has (as you might imagine) RunAsAdministrator. We don’t want setups to fail for every standard user out there – they still need to prompt. So, this layer will not cause standard users to stop seeing prompts for setups (or manifested apps for that matter). If we had used the existing RunAsHighest flag, then it would have broken setup detection for standard users – and we love our standard users.

The Curious Case of the Redundant UAC Policies

2009-10-06T23:22:52Z

One of the unfortunate consequences of actually having to ship your software at some point is that you have to make some compromises along the way. The decisions you make can vary based on the time you are called upon to make them. As frustrating as that is for somebody who is trying to understand the system by trying to reverse how we make decisions, it remains a fact of life.

Case in point: for anybody who has explored the updates to the User Account Control (UAC) policies on Windows 7, you may have noticed that there are multiple policies which appear to govern the exact same thing.

In fact, they do govern the exact same thing.

User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode has the following options:

Elevate Without Prompting
Prompt for credentials on the secure desktop
Prompt for consent on the secure desktop
Prompt for credentials
Prompt for consent
Prompt for consent for non-Windows binaries (default)

User Account Control: Behavior of the elevation prompt for standard users has the following options:

Automatically deny elevation requests
Prompt for credentials on the secure desktop
Prompt for credentials (default)

At the same time, you’ll find a policy that configures the secure desktop:

User Account Control: Switch to the secure desktop when prompting for elevation (enabled by default)

What’s going on here – aren’t these directly overlapping?

Well, first let’s help you sort out how to use the policies, next we’ll explain why there are two ways to configure the same thing, and finally we’ll chart out the outcome to give you the easy answers.

A configuration request to use the secure desktop always wins. Whether you configure the admin policy, the standard user policy, or the secure desktop policy, any vote for the secure desktop will cause Windows to use the secure desktop.

So, what happened?

While we were re-doing UAC to make it “less prompty” for Windows 7, we were changing a number of things. We added the ability to exclude Windows binaries. We added a slider instead of an on-off switch. While you are mucking around anyway, you may think, “what if I wanted to have different secure desktop behavior for my standard users than I do for my administrators?” You can’t with only one policy. And it doesn’t take that much additional effort to add a couple of additional options. But you’ll note that there is no secure desktop option for Prompt for consent for non-Windows binaries.

We’d left the secure desktop policy there for application compatibility reasons, but we didn’t use it.

So, we’re happily moving along, when we eventually noticed that there were some accessibility issues in some scenarios when not using the secure desktop, so we needed to have an option to make the “less prompty, but on the secure desktop” setting which, as you can see, doesn’t exist.

Now, if you think about it as if it were your own software, how long would it take you to fix it? It’d take you no time at all to add a new option to the dropdown. You can probably come up with a very easy way to implement the change in consent.exe for reading that policy as well.

But Windows is a complex place. That’s not all you’d have to do. What about the customer experience improvement program? You have a finite, already defined amount of room to feed back all of your configuration and data here. If you change your compression algorithm to incorporate this new option, then you impact all kinds of teams. Could you do it? Sure. But it was at a point in the process when you stop making “blue sky” designs that are the best implementation, and instead fall in the category of “do the minimal change necessary to achieve the required goals”. Architectural changes late in the process aren’t going to win if there are other alternatives. The fastest way was to start using the existing secure desktop policy again. So we did. Better that than to delay shipping.

So, here’s what your secure desktop behavior will be, depending on configuration:

Acct. Type	Account Elevation Policy	Secure Desktop Policy	Secure Desktop Used?
Administrator	Elevate Without Prompting	Enabled	n/a
Administrator	Prompt for credentials on the secure desktop	Enabled	Yes
Administrator	Prompt for consent on the secure desktop	Enabled	Yes
Administrator	Prompt for credentials	Enabled	Yes
Administrator	Prompt for consent	Enabled	Yes
Administrator	Prompt for consent for non-Windows binaries	Enabled	Yes
Administrator	Elevate Without Prompting	Disabled	n/a
Administrator	Prompt for credentials on the secure desktop	Disabled	Yes
Administrator	Prompt for consent on the secure desktop	Disabled	Yes
Administrator	Prompt for credentials	Disabled	No
Administrator	Prompt for consent	Disabled	No
Administrator	Prompt for consent for non-Windows binaries	Disabled	No
Standard User	Automatically deny elevation requests	Enabled	n/a
Standard User	Prompt for credentials on the secure desktop	Enabled	Yes
Standard User	Prompt for credentials	Enabled	Yes
Standard User	Automatically deny elevation requests	Disabled	n/a
Standard User	Prompt for credentials on the secure desktop	Disabled	Yes
Standard User	Prompt for credentials	Disabled	No

Why You Shouldn’t Listen to Me, and Why You Should

2009-09-26T01:34:50Z

Ah, Karma, you rise up at the least convenient times. (This blog post is not meant to imply a belief in preordained futures, divine intervention, or the existence of the Perfectly Normal Beast.)

Yesterday, I had somebody ask me not to speak about something at the Springboard Virtual Round Table. I didn’t react particularly well to this particular piece of … erm … guidance, so in retribution Karma decided to pair me up with a completely drained car battery and an emergency service technician with the world’s worst sense of direction. Which of course gave me plenty of time to think about things.

And I concluded that you shouldn’t listen to me, or, really, anybody. And, at the same time, you should.

(Perhaps I should have put the fact that you should first, to avoid losing readers.)

So, what happened?

I demonstrated Access 2007 and Access 2003 running side by side. What you didn’t see is that I also sequenced (and yes, ran on Windows 7) Access 2.0. Hello 1994. If you ever attend my talks at conferences, you may see me occasionally do something like that – a quick firing up of an app that brings back a wave of nostalgia that sends approximately 5% (max) of the people in the room on a trip down memory lane, and is done quickly enough that the 95% who don’t remember that ancient piece of software aren’t annoyed. Seeing it again positively delighted me, while making me wonder how we possibly ever thought that was good. (Teal with blue shadows? Seriously?)

But I was told (not asked) flat out that I could not run that. It gives the wrong impression. We are trying to convince people that App-V is not an app compat solution, and if it doesn’t run natively on the OS we don’t want to show it running in App-V, because that applies that App-V is a remediation solution.

The engineer in me thought that, while I certainly don’t want to mislead people into thinking App-V is an app compat solution of any significant merit, if you try to make things cut and dry, then you’ll be disappointed. Because the reality we’re trying to portray with messaging collides rather inconveniently with the actual reality where App-V does fix the one problem that keeps Access 2.0 from running natively on Windows 7, and you’d have to apply RunAsAdmin, CorrectFilePaths, or loosen ACLs to get it running without App-V. You see, in my world, the theory never gets to win, it’s reality that gets to win, and reality had spoken loud and clear via my perfectly functional and incredibly silly demo.

But here’s the problem with that thinking: in my world, it’s my job 100% of the time to understand the system top to bottom. I have time to understand subtlety. I have the ability to dive as deep as I want, so long as it helps solve somebody’s problem somewhere. But for the rest of the world, you just want to get done. You don’t have the same luxury of time that I do. And, if my demos were the only information you ever received about App-V because you never had any more time to learn about this one little niche of technology, you’d come out having watched with your own eyes one app not being fixed by it, one app being fixed by it, and you wouldn’t know what the h*ll to think, you’d conclude that we’re all mental, and you’d go off and become a sheep farmer.

As a result, it’s really important that, if we’re the only message you see, we don’t self-contradict (even though the contradiction exists only because we haven’t gone deep enough to resolve the paradox), and we give you the one high-level message that helps you make the best decision, even if the abstraction we give you is a leaky one. We’d rather err on the side of whatever approximation saves you the most time, money, and heartache if we have to approximate.

The same is true of tools. I’ve looked at all kinds of output that suggests that something might have gone wrong, only to find that it works perfectly well. Believe me, the people who make these tools know that they’ll get some things wrong – they just want to get the high-level numbers that you depend on to make decisions right just as often as they can.

I have the same problem when building a hypothesis while debugging an application. I use my imperfect knowledge of a huge system to make what is, hopefully, a pretty good guess about what’s going to happen next, but I’ve concluded and believed stuff really strongly countless times when one small failed assumption along the way led me to the completely wrong conclusion and I wasted a ton of my time.

So, keep in mind that, while we’re always working really hard to distill this enormously complex and sometimes fiercely non-deterministic system into a set of rules you can use to actually get done with your job before we release Windows 14, that rule can be an oversimplification that isn’t always true. No matter how clever the source, nothing should trump what you see with your own eyes. A good source should always lead you to saved time, but in this world you always have to trust but verify.

Also, if you ever have somebody tell you something that you don’t initially agree with, you should spend the time right then and there to understand why they believe so strongly in what they’re saying, in a respectful manner. Unless you like hanging out in parking lots waiting for service vehicles.

Springboard Series Virtual Roundtable - Windows 7 Application Compatibility Part 2: Virtualization

2009-09-23T23:35:05Z

Date: Thursday, September 24
Time: 9:00am Pacific Time

https://ms.istreamplanet.com/springboard

The reviews on Windows 7 have been really great so far, but you obviously can’t start using it if, after installing it, all of the stuff you need in order to get your work done breaks. Application compatibility is so important, in fact, that we managed to get Mark Russinovich to come and talk about it not once, but twice!

In our first episode, Mark talked about the overall challenge, the process, and tools to help you get there. We spoke a little bit about remediation as well, specifically in the context of what we’ve been calling the lightweight remediation. Things like shims or policy changes.

Alas, I was unable to attend this event, because they kind of forgot to invite me. They didn’t forget to script me in, mind you, they just forgot to tell me about it until I already had a customer commitment (which I never back out of). All kinds of formulations on how I could get from Ottawa, ON, Canada to Seattle and back without the customer noticing then ensued, until eventually everyone realized the futility of this discussion. So I recommended several folks who are far smarter than me to join the panel in my stead.

Apparently all of these people were unavailable for this round, because this time, they actually not only remembered to invite me, but actually chose to.

This time around, we’ll be discussing the more heavyweight fixes for app compat problems. Specifically, how does virtualization fit into your application compatibility strategies? We’ll be discussing all of the different flavors of virtualization, dispelling myths, showcasing truths, and helping you get the information you need to develop a comprehensive and sensible strategy.

We hope you’re able to join us live tomorrow!

How to Run Applications Manifested as HighestAvailable With a Logon Script Without Elevation for Members of the Administrators Group

2009-09-13T18:22:51Z

Updated 17-Sept-2009

My friend Aaron has been trying to post a comment with his recommendation. However, it never, never, ever shows up because apparently we either don’t buy good software for our blogging system, or else the software has a personal vendetta from him (perhaps it’s angry at him for not posting often enough himself). But his comment is worthwhile, so here it is:

Rather than use that undocumented (and unsupported) environment variable, why not just change the "regedit" invocation to "REG.EXE IMPORT"? REG.EXE doesn't demand elevation -- it's manifested "asInvoker", and can import .reg files...

Here’s a trick I used to help out a customer:

My customer was using a logon script to set some per-user registry keys when the user logged in. This worked fine for their standard users on Windows XP, and it also worked fine for their standard users on Windows 7. However, it added an extra prompt for the few folks who had exceptions to be members of the Administrators group.

You see, they were using regedit.exe to import a .reg file. And, even though they didn’t need administrator privileges to edit the parts of the registry they wanted to modify, the entire application is manifested as highestAvailable, so it would always prompt for their administrators.

So I cooked up the following .bat file to achieve the same thing without annoying their administrators:

set __COMPAT_LAYER=RunAsInvoker
start regedit.exe

And they were off to the races.

Was there another way? Perhaps. But this let them keep their existing scripts and only have to add a single line at the front, so it was the path of least resistance.

FAQ: When is the Application Compatibility List (Currently Focused on Windows Vista) Going to be Updated for Windows 7?

2009-09-07T14:41:52Z

There is a huge amount of excitement about Windows 7, and people are looking to get moving with app compat immediately so they can start deploying Windows 7 right away! In the enterprise, however, there are a number of risk mitigation strategies that most administrators put into place, which typically includes (among other things) ensuring that the most business critical applications are supported on Windows 7 by the vendor.

We have tried to simplify the process of finding these support statements by creating a portal site, making this list downloadable, and integrating it into the Application Compatibility Toolkit. People like this so much that, an average of around infinity times a day, I’m asked when it’s going to be updated for Windows 7.

It is scheduled to be updated for GA (General Availability). That’s October 22, 2009.

What’s with the delay?

Well, a couple of reasons.

First of all, “compatible” and “supported” are two different things. What matters to most people is supported.

Before most software makers support an application, they test it pretty thoroughly to ensure that there are no significant bugs that could expose them to major risks and/or higher than acceptable support costs. This takes time. Now, we’ve been giving ISVs access to builds for quite some time, and they can use the interim builds to perform software testing and identify any significant issues which will require quite a bit of time to resolve. However, the ISV can’t even begin the thorough testing to ensure that they have a supportable solution on Windows 7 RTM until they actually had access to Windows 7 RTM. So, the same day that many enterprises were able to get that build and wanted this data, ISVs received it and could start their validation for supportability. Being able to instantaneously tell if you can afford to support your software on a given platform is asking rather a lot of any ISV. This gap between RTM and GA provides each ISV a brief window of time to perform thorough testing before customers can reasonably demand to know a support statement.

We then also leverage this time to reach out to those ISVs and find the support statement. You see, ISVs don’t have to report in to us when they make new software or create new support statements – in fact, they never have to call us at all. We tried changing the nature of this relationship once with the Works With Windows Vista logo program, and it was a colossal failure. So, in addition to an ISV needing time to test and validate something, we also need time to find these results and support statements and consolidate them into the database which you can access.

So, we both have a lot of work to do in order to get these lists put together, so much so that 3 months is really kind of stretching it. I know of several vendors already who are pushing out their supported dates for Windows 7 into 2010. What do I do when I find that? I debug their apps. It’s much easier to fix and support an app once the hard part – debugging it – is already done. :-)

Now, compatible is a different story. If you want to be a purist, compatible means it has no bugs on the given platform. Since no bugs on a given platform is, for this purpose, the same as saying no bugs, I can safely say that there is no compatible software for any platform that has ever been made. So, we’re forced to use a different definition – compatible meaning that there are no bugs that *stop me from getting my work done* on a given platform. So, since nobody else knows precisely how you get your work done, the only person who can fairly answer that question is you.

Debugging the Missing .NET Tab for Managed Applications in Process Explorer for Windows 7 x64

2009-08-28T08:08:13Z

I was reading through some documentation on Sysinternals Process Explorer the other day, and one bit that caught my attention was some detail on the .NET tab. So, I pulled up my trusty managed StockViewer application, and went to go and look at that tab.

Only…

…it wasn’t there.

Fascinating.

So I found another managed code process on my system, and tried to look at it’s tab – the excellent Switcher application.

No joy.

OK, so after telling Mark he didn’t know how to write programs (don’t try this at home) it was time to pull out the debugger. With a little help, because I did ask Mark how he was checking to see whether he should be putting the .NET tab on there. He said he was using both perfmon APIs and the ICorPublish APIs.

So, off to the MSDN documentation to start brewing up a hypothesis, and to be honest it just seemed most likely that the ICorPublish APIs would be the culprit, since they were called per process and perfmon itself was working so those APIs were probably going to be working too. Just a hunch.

I browsed through the APIs, and fortunately there were only two. Of those two, one seemed the most likely to be called for this, so I set a breakpoint on it.

bp mscordbi!CorpubPublish::GetProcess.

Sure enough, it was hit. Good guess.

Of course, this bp was hit rather a lot (I had quite a few processes running at the time), so I didn’t want to have to stop and inspect every call. I wanted to stop and inspect the call when it was looking specifically at the process I expected was managed (Stock Viewer) but procexp didn’t think was managed. So, off to Task Manager (sorry, procexp, but you were frozen at a breakpoint in my debugger) to pull the PID for Stock Viewer, which I then translated to hex for the debugger. Voila – breakpoint set.

1:001> bl

1 e 00000642`ff91302c 0001 (0001) 1:**** mscordbi!CorpubPublish::GetProcess "j @rdx=0x16EC '' ; 'gc' "

I hit this breakpoint, and then stepped out of the function. I then inspected rax to see the return code, and found it was 0x80070057. the 8 already indicates bad news, so I was expecting an error message. It was COR_E_ARGUMENT. Now, that wasn’t particularly helpful this time, since there was only one argument (the pid), so the question is – why didn’t it like to answer this question about this process? It would take some additional stepping through.

So, I did some call tracing, and found that GetProcess was calling through some internal APIs, and one of the interfaces was returning 0x80131c30. It appeared to be another COM call, so it could be a failure hresult, but the utility I use to look up error messages wasn’t telling me anything. The error number was not found.

Along the way, Mark had reached out to another Technical Fellow, so at this point I’m thinking to myself, “holy crap, there had better actually be a bug here and not user error” – and this other Technical Fellow pointed me in the direction of Thomas, a Senior Development Lead for the CLR. And what a useful connection this was. He deciphered the error: it’s returned if there is a bitness difference between the caller and the target.

Aha.

Both of the managed apps happened to be specifically flagged as x86 apps. So, to do a quick check that this was the only thing wrong, I only needed to create an AnyCPU managed application, and see if ProcExp would display a .NET tab for it. Indeed it does!

So, mystery solved. ProcExp can’t (today) peer into .NET information for managed processes that are 32-bit on 64-bit Windows (the default compiler setting is to create AnyCPU binaries). The wheels are already churning to figure out how to close up this edge case. I just got unlucky with the two managed apps I happened to be running.

More Application Compatibility Resources for Windows 7

2009-08-25T22:46:28Z

There are a number of efforts going on to help organize application compatibility for Windows 7, in or ongoing effort to improve in this space. Now, the technical information remains fairly stable, but there are a number of different ways to organize that information based on the perspective with which you are approaching that problem.

In fact, that’s probably the hardest part of talking about application compatibility – it crosses pretty much every discipline in IT, from management down the individual contributor. Even within individual contributors, it’s divided between the IT Professional and the Developer audiences.

(As a side note, in nearly every audience I speak to where there are representatives of both disciplines, they tend to completely sort based on discipline. All of the IT Pros will sit on one side of the room, all of the developers sit on the other. You almost never find a situation where people are naturally distributed. And we wonder why communication between these teams, while critical, doesn’t happen as often as we would like – I know I am guilt of that myself!)

So, we’re trying to organize and sort the information and knowledge for you as best we can. Here are just a few ways we have organized things to help out:

Windows XP to Windows 7 Migration Guidance

http://technet.microsoft.com/en-us/windows/ee150430.aspx – this is one way to map out information by the process itself. It’s fairly high level (no kernel debugging tips here) and more geared towards the IT Professional (hence the Technet home). Instead of a big list, there is a flowchart navigation system. Click on the stage in the flowchart you are sitting at, and it lists out resources, with pros and cons, of the tools which are there to help you through that state! Quite a clever navigation scheme.

Application Compatibility Factory

OK, this is one that’s confusing. I know I pick on folks in the marketing discipline from time to time, but that’s only because I think they can act in ways that are as unengineer-like as possible. Sometimes that’s good, sometimes that’s … confusing. This is one of those confusing times.

We took an existing program and brand – Application Compatibility Factory. The name made sense – it used a (predominantly offshore) factory model, optimized for churning through bulk. The program for Windows Vista consisted of around 6 global system integrators.

We then re-used the power of that brand on a whole new model. No, really! It doesn’t look anything like the old model – heck, it isn’t even a factory model, despite having the word Factory occupy 1/3 of the words in the name. No longer is ACF the “stroke a 7 figure check and make a big chunk of work disappear” – it’s now a program that delivers 1-week Proof of Concept engagements.

Here’s basically what happens: a partner (or even Microsoft Consulting Services) comes in to your organization and begins the process of taking a software inventory. (Depending on how many desktops you have, they may not be able to finish, but they’ll be sure to let you know how you can finish up.) Next, they get you started on the process of rationalizing that inventory, so you can focus only on those applications that you specifically want to support on your shiny new operating system, and not everything someone managed to successfully install at some point in time after you handed them a computer. Finally, they do a bit of proof of concept work around remediating applications – likely not making much of a dent in that work, but at least showing you the general approach to that problem and giving you both knowledge and hope.

In the end, the same partner will also be very likely to slide a proposal across the table to help you finish that work, and it’s here that they’re likely to include the factory model. But factories have almost nothing to do with the actual free engagement.

Oh yeah, did I mention the free part? So, if you’re still getting started, this is a great way to leverage the investments we’re making in application compatibility and minimize your risk.

To get started, in the USA you can send email to usappcom@microsoft.com. You can also find information here: http://technet.microsoft.com/en-us/windows/bb510132.aspx. This has a list of the ACF partners in many different countries. Yes, even you, Belgium.

This is all great, but I write code

We’ve got you covered. We recently added an FAQ section to our forums at http://social.msdn.microsoft.com/Forums/en-US/windowscompatibility/threads – you can find it at http://social.msdn.microsoft.com/Forums/en-US/windowscompatibility/thread/7d585c05-0b61-45e7-b554-740382ffb7cc. This forum is a great place to get your specific questions answered.

This is just a taste of some of the organizational work we’re investing in. Keep on letting us know how we can do better! Because it’s bad enough that this stuff is hard technically, it shouldn’t be hard to find what you need!

Why Do Some Operating System Modes Include AdditiveRunAsHighest While Others Do Not?

2009-08-21T00:54:20Z

A little while back, those of us who explain application compatibility for a living and try to help people get their arms around it ran up against those who implement it in the product on the scale of … the whole earth.

Those of us who explain things for a living really prefer (really, really prefer) when the system is internally consistent, because that makes it easier to explain.

Those who build systems really work to make the investments they can, with finite resources, to fix the greatest percentage of applications they can.

And sometimes those goals are not in alignment.

Case in point: remember back in April when i was talking about how we added the new AdditiveRunAsHighest shim to our operating system layers? Well, it turns out that we didn’t touch quite all of them. The following layers have AdditiveRunAsHighest applied:

Win95
Win98
WinXP
WinXPSP1
WinXPSP2
WinXPSP3

The following layers do not have it applied:

NT4SP5
Win2000
Win2000SP2
Win2000SP3
WinSrv03
WinSrv03SP1
VistaRTM
VistaSP1
VistaSP2
WinSrv08SP1

What’s the rhyme or reason here? Well, you can start to tease out some logical ones. First, most people don’t use compatibility modes on server apps. (They may use them on a server, such as when you use terminal services apps, but if you have a high-throughput server application, shimming it up and running it unsupported is probably not high on your list of acceptable mitigations. So, remove Server 2003 and Server 2008. Next, if it worked on Windows Vista, it has already seen UAC, so we don’t really need to have it there. But … what about NT4 and Windows 2000? If those were included, couldn’t we just say, “ever client operating system prior to Windows Vista includes this shim”?

Yes, we could.

And wouldn’t the same arguments that made sense for the other ones make sense here?

Yes, they would.

So, what gives?

Well, in the game of probability (fix the most apps), internal consistency was not the focus. Fixing the largest number of apps was. And there simply were not enough apps that needed the Windows NT 4 and Windows 2000 modes to bring it on the radar that they needed them too. And those of us who do explain these things for a living didn’t notice it until July, when the bug bar was way too high to get this fix in (since it doesn’t actually block you from getting things done, it just makes it harder to explain why the system behaves the way it does).

So, instead of a nice, logical rule, you have a list to memorize. 95, 98, and XP get AdditiveRunAsHighest. Everything else does not. Sorry for making you memorize a list – I’d much rather you were memorizing rules that you could logically explain, but so it goes.

How to Get Free (as in Beer) Help with App Compat Problems for Windows 7

2009-08-15T05:54:22Z

My job takes me around the world talking to both Developers and IT Professionals in order to resolve compatibility bugs with Windows 7 and Windows Vista. But you know what, I’m just one guy – so chances are I’m probably not going to have a chance to look at every piece of software that has ever been written for Windows (because after doing this for several years, I’m beginning to believe that every piece of software that has ever been written for Windows is still being used somewhere – yes, even including that Hello World program you wrote in college, they’re using that at Fabrikam Corp. for some reason).

We have long been experimenting with ways to scale out our ability to reach people and help them out getting software working on the current version of Windows, and (like application compatibility itself) there is no one silver bullet.

But here is one really good idea someone had: let’s take a bunch of the smartest people in the world (Escalation Engineers and Premiere Field Engineers), create a forum, and then bribe people to participate with … get this … a Microsoft branded shirt. That’s right – it turns out that even people who already have 5,000 Microsoft branded shirts in their closets will work for free if you increase their collection to 5,001. There’s something about SWAG that makes geeks’ hearts melt.

So, we created forums for developers:

http://social.msdn.microsoft.com/Forums/en-US/windowscompatibility/

and for IT Professionals:

http://social.technet.microsoft.com/Forums/en-US/w7itproappcompat/threads

(and for partner ISVs:

https://partner.microsoft.com/US/40014662)

If you post your application compatibility questions there, some crazy smart guy or gal will take a look at your question and help you out. Now, it’s not paid support with an SLA (though we’ll help you out with app compat questions there too – feel free to leverage that), but it’s the same people with the same huge brains. (OK, so I’m jealous of the size of their brains. What can I say.) And it’s free. As in beer.

Oh yeah, and eventually they did start giving utilization credit for that too. In addition to the free shirt. I thought it was way cooler when it was just a shirt, but maybe that’s just me. I know I got my shirt already.