Chris Jackson's Semantic Consonance : Windows 7

Windows 7 Vendor Compatibility Data Now Available in ACT 5.5

Chris Jackson — Wed, 06 Jan 2010 16:59:54 GMT

It’s been a long road to get here, but the checklist is now complete. Vendor data for Windows 7 application compatibility, previously available on the web and as a downloadable Excel sheet, is finally integrated into ACT 5.5!

Here is some information on this data, courtesy of the team:

How many applications do we have data for?

We have data for around 7,000 applications. What is interesting is that there is more work than just 7,000 – each application may map to more than one app ID, and in fact we have data for around 38,000 distinct AppIDs. (Incidentally, if you don’t see data for an application in ACT but it’s on the web, this could be caused by repackaging, by interim releases we are unaware of, or a number of other things. AppIDs are very literal and require perfect fidelity input to deliver comprehensive output.)

How frequently will this data be updated?

Initially, ever 2 weeks, so make sure you sync ever so often to see the latest data. As the vendor input tapers off, we may reduce this in the future.

Will the data have complete parity with the compatibility center?

It’s the same back end, but since we use different AppIDs we have to use heuristics to match between the different AppID schemes. Heuristics, by definition, can be imperfect. Add to this the potential issues above (repackaging, lesser known versions) and this would explain any delta in the data. We’re constantly reviewing our heuristics and improving them, plus we have long term plans to consolidate on a single AppID scheme.

Will I see compatibility status for 64-bit applications?

Today, it’s just 32-bit status, as that is what ACT 5.5 supports. ACT 6.0 will support 64-bit Windows and include 64-bit compatibility status. It should be released later this year.

Congratulations to the team for achieving this long-awaited milestone! I know I have already synced up my database.

Flexera Software Webinar Now Available Online: Best Practices for Windows 7 Application Compatibility

Chris Jackson — Mon, 28 Dec 2009 15:02:49 GMT

A couple of weeks ago, I had a chance to sit in on a webinar delivered by Flexera Software and chat about Windows 7 Application Compatibility. The recording of the webinar is now online and available here:

http://mktg.flexerasoftware.com/mk/get/BPWin7CompatApp_wbnr?mc=eml-flw

Why don’t I see any data for Vendor Assessment for Windows 7 in ACT 5.5?

Chris Jackson — Tue, 22 Dec 2009 18:03:46 GMT

A few weeks ago, I spoke about how our information on vendor data was slowly making it through the channel, beginning with the compatibility center (complete), moving on to the downloadable Application Compatibility List for IT Pros (complete), and finally getting to ACT. I suggested, “The target date for this integration is mid-December 2009.” To call December 22 “mid-December” is already stretching it, and yet it’s still not showing up in ACT. What gives?

Well, let’s talk a little bit about the data and how it has to move through the system. In the end, it all comes from the same database. The compat center, the downloadable list, the data that feeds the upgrade advisor – all from the same source. What is taking so long to turn on the spigot for ACT?

Well, the big challenge is data transformation. First, the App ID has to be translated. The 3 live services all use a new algorithm for determining an application ID. ACT hopes to transition to use this new algorithm in the next version, but it’s one of those “running in place” changes where, after spending a lot of time and money, the end result looks identical to the user, so it’s difficult to justify rushing the transition (particularly since invalidating an existing inventory full of old App IDs is a terrible idea, so the application will need to support both old and new, and be able to differentiate between them). That translation needs to be automated so it can run in perpetuity, and that process has to be build. Then, the web service that feeds ACT is the old version (v1) while the others are using a much newer version (v4), so the old web service interface has to be modified to leverage the new database feeding it. So, there are two feats of engineering that need to be implemented, tested, and proven at scale.

We’re still hoping to have this done the first week of January, but vacations and winter colds are making this more challenging. Rest assured, this data is coming and we are terrible sorry for any inconvenience the delay is causing – we really do want the data to be accessible and convenient and are not neglecting the value this has to customers.

Windows 7 Debugging Demo: Troubleshooting the Broken Microsoft Time Zone Utility

Chris Jackson — Wed, 16 Dec 2009 20:12:11 GMT

Earlier today, I received this request from a customer:

This (http://www.microsoft.com/downloads/details.aspx?FamilyID=07fb0bd8-f390-458d-a629-6f0258ac7cdf) is a .NET 1.1 app and I have installed .NET 1.1 SP1 on Windows 7 32-bit and all .NET 1.1 SP1 security patches but it doesn't run. Gives me this error: An internal error has occurred: Object reference not set to an instance of an object" and then it quits.

Always being up for a challenge, I decided to have a look and see what wasn’t working. Reproducing the error is pretty straightforward. Just run the app – it’ll gladly crash for you. But the question is, why? And can you fix it?

If you hit this with a debugger, you’ll find the following stack when you hit an AV:

0:000> !dumpstack -ee
Current frame: (MethodDesc 0x2098d28 +0x1c SystemTimeZone.ConvertToTimeZoneInfoStructure)
ChildEBP RetAddr Caller,Callee
0018f4f4 0206d4ab (MethodDesc 0x2098d08 +0x43 SystemTimeZone.ToLocalTime)
0018f55c 0206cfc0 (MethodDesc 0x2098cd8 +0x38 SystemTimeZone.Convert)
0018f574 0206a484 (MethodDesc 0x2e5680 +0x15c frmMain.ShowCurrentTimes_Click)
0018f5d8 02067686 (MethodDesc 0x2e56d0 +0x446 frmMain.frmMain_Load)
0018f61c 02060365 (MethodDesc 0x2e5620 +0x2ed frmMain.Main)

Now, you could take a stab at this with SOS and start pulling out objects, but I didn’t believe that this would be the easiest way to solve the problem. Instead, I decided to reverse engineer the code and have a look. If you take a peek at the structure you’re trying to create from the SystemTimeZone class, you’ll find where the instance of the time zone came from – the code was rampaging through the registry looking for it. Here’s the method in question:

public TimeZoneList()
{
    m_TZHash = new Hashtable();
    m_TZList = new ArrayList();
    RegistryKey key = Registry.LocalMachine.OpenSubKey(@"SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\");
    string[] subKeyNames = key.GetSubKeyNames();
    Type t = typeof(TZIStructure);
    int num2 = Marshal.SizeOf(t);
    int num3 = subKeyNames.Length - 1;
    for (int i = 0; i <= num3; i++)
    {
        RegistryKey key2 = key.OpenSubKey(subKeyNames[i]);
        SystemTimeZone zone = new SystemTimeZone();
        SystemTimeZone zone2 = zone;
        zone2.DaylightName = StringType.FromObject(key2.GetValue("Dlt"));
        zone2.DisplayName = StringType.FromObject(key2.GetValue("Display"));
        zone2.Index = IntegerType.FromObject(key2.GetValue("Index"));
        zone2.MapId = StringType.FromObject(key2.GetValue("MapID"));
        zone2.StandardName = StringType.FromObject(key2.GetValue("Std"));
        zone2.Name = key2.Name.Substring(key2.Name.LastIndexOf(@"\") + 1);
        zone2 = null;
        byte[] buffer = (byte[]) key2.GetValue("TZI");
        key2.Close();
        if ((buffer != null) && (buffer.Length >= num2))
        {
            GCHandle handle = GCHandle.Alloc(buffer, GCHandleType.Pinned);
            IntPtr ptr = handle.AddrOfPinnedObject();
            zone.TZI = (TZIStructure) Marshal.PtrToStructure(ptr, t);
            handle.Free();
            if (!m_TZHash.Contains(zone.Index))
            {
                m_TZHash.Add(zone.Index, zone);
                m_TZList.Add(zone);
            }
        }
    }
    key.Close();
}

If you spend enough time with the !do command, you can eventually stumble upon the answer, but the easier approach is, again, to stay out of the debugger and leverage your favorite search engine. Here’s a KB article that points out the problem:

http://support.microsoft.com/kb/935369

Relevant information: “The Index registry value does not exist in Windows Vista and in Windows Server 2008.”

Aha. See the source code above? It wants that value, and it’s not there. Root cause found.

Now, on to solutions.

First of all, I wonder if you need a solution at all. If you click on the clock, and then click on Change date and time settings… you will get to the Date and Time control panel. Click on the Additional Clocks tab, and you can add 2 additional clocks for 2 new time zones. If you need more, you can always use Gadgets to fill the rest of your needs. So, for most people, this should provide a built-in solution to the problem – you don’t need the app any more because the OS provides 2 solutions already.

But, if you really really love that particular app, you could always copy that piece of the registry from Windows XP onto your Windows 7 computer, drop it in a new place inside of the registry, and then use the VirtualRegistry shim to redirect that app’s checks of the timezone portion of the registry to the copy you brought over.

Special thanks to my friend Gov for pointing me to the KB article, and for coming up with the VirtualRegistry workaround idea.

Flexera Software Webinar: Best Practices for Windows 7 Application Compatibility

Chris Jackson — Tue, 15 Dec 2009 16:33:39 GMT

Are your business-critical applications compatible with Windows 7? Join Microsoft's "App Compat Guy" Chris Jackson to learn best practices for how IT teams are resolving Windows 7 application compatibility issues. Hear about his experiences with early Windows 7 adopters, including the most common application compatibility issues and their root causes. Tips in this webinar will help your IT team minimize risk and make a smoother move to Windows 7.

Webinar Details
Thursday, December 17
12pm EST (9am PST, 5pm GMT)

One curious observation I have made while doing app compat work over the past few years: The ownership of the project is assigned to the packaging team more so than any other team. Perhaps that’s because it’s the only centralized group dealing with every application, or perhaps it’s because installation failures on the new OS are the first things you notice – the rationale varies. But regardless, the team responsible for packaging definitely is an extremely interested party, if not the outright owner of the project.

As a result, when I sat down for dinner with several execs from Flexera Software (makers of InstallShield and AdminStudio, among other things), they expressed this as an area of great concern for their customers. So, in between our discussion of which tapas was the tastiest (I assure you, there was some extremely tasty tapas), we were brainstorming how we can better work together to help people who are interested in packaging be more successful when an app compat project comes along.

One idea? Let’s work on a webinar together. Flexera has a pretty successful webinar series, so let’s just partner up on one of those. So, on Thursday, December 17, 2009 at 11:00 am Central, we’ll be doing that. It will be relatively quick and will be presented at an overview level, so if you’re looking for a debugging deep dive this probably isn’t your best bet, but one thing it will emphatically not be is marketing speak. If this perspective is useful to you, come and join us. Feel free to ask the hardest, nastiest questions you can think of!

http://mktg.flexerasoftware.com/mk/get/BPWin7CompatApp_wbnr

How to Hack your Application Compatibility Toolkit 5.5 (ACT 5.5) Database to Locate 16-bit Files in your Application Inventory

Chris Jackson — Tue, 08 Dec 2009 22:02:46 GMT

(Wow, I’m doing a lot more posting today than normal. Things kind of piled up while I was on leave.)

There is a ton of activity going on in the world regarding Windows 7 deployments, and one of the hottest topics we’re finding is x64. People are very interested in moving to the 64-bit version of the operating system, but one obvious question is, will my applications be broken?

The next version of the Application Compatibility Toolkit, ACT 6.0, is scheduled to have far more robust x64 support. (It’s scheduled to support it at all, which is already a bonus.) But what about in the interim?

First of all, there is the Setup Analysis Tool. This will detect 16-bit binaries (probably a problem for 64-bit Windows, unless setup is detecting the bitness of the OS and dropping file appropriately) and driver installation (possibly a problem for 64-bit Windows, unless setup is detecting the bitness of the OS and dropping files appropriately). But this requires a fair amount of work to get configured and running, and it also means that you have to have the setup files. Depending on how managed your environment is, that may be a problem.

If you’re the sort that doesn’t mind undocumented secrets, I’ll let you in on one: ACT already collects the bitness of the files it finds in an inventory scan, it just doesn’t surface that in the UI today. So, how can you view this information? Why, hack the database of course. My SQL skills are so rusty these days I’m beyond embarrassed of what I crufted together, but here is a query I hacked up to display all of the files that are neither 32-bit (user mode 32-bit is probably OK) nor 64-bit (definitely OK) in your ACT database:

USE ACT55
GO

SELECT DISTINCT Applications.appName, Static_App_Properties.fileName, fileModuleType

FROM Static_App_Properties
INNER JOIN Application_Instance_Files
ON Static_App_Properties.identity_hash = Application_Instance_Files.filePropertyID
INNER JOIN Applications
ON Application_Instance_Files.appID = Applications.identity_hash

WHERE fileModuleType<>'32BIT' AND fileModuleType<>'64BIT' AND propertyType='File'

ORDER BY appName
GO

The schema is, as always, undocumented and subject to change, but I have found this helpful in a few scenarios to quickly zero in on apps to specifically test on 64-bit when targeting a mixed environment. I suspect you’ll have to do less hacking with ACT 6.0.

Windows 7 Application Compatibility List for IT Professionals

Chris Jackson — Tue, 17 Nov 2009 15:21:07 GMT

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

Chris Jackson — Fri, 06 Nov 2009 20:56:30 GMT

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

Chris Jackson — Wed, 28 Oct 2009 04:30:58 GMT

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

Chris Jackson — Wed, 21 Oct 2009 16:45:10 GMT

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

Chris Jackson — Fri, 16 Oct 2009 01:47:04 GMT

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

Chris Jackson — Thu, 08 Oct 2009 23:32:35 GMT

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

Chris Jackson — Tue, 06 Oct 2009 23:22:52 GMT

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

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

Chris Jackson — Wed, 23 Sep 2009 23:35:05 GMT

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

Chris Jackson — Sun, 13 Sep 2009 18:22:51 GMT

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.