PCA Changes for Windows 7: How To Tell Us You are Not an Installer, Take 2 (because we changed the rules on you)


I have an ongoing conversation with a customer whose application is now popping up a Program Compatibility Assistant dialog box, where it didn’t used to before (on either Windows Vista or Windows 7 beta). What’s going on?

Well, when I cracked the resources for the binary, you can spot right away that it’s going to trigger installer detection, given the presence of the word “Install” in multiple places. You can also turn on shim diagnostics and see that it’s wiring up with GenericInstaller.

But why wasn’t it popping PCA on Windows Vista? Is this a new PCA scenario? I explored that, and discovered that it was Scenario #1 – an app that we detect as a setup doesn’t leave anything behind in Add/Remove Programs. That suggests possible failure.

So, existing scenario, new PCA prompt, and the final bit of evidence: the application doesn’t prompt for UAC Elevation on either Windows Vista or Windows 7. You should now be able to connect all of the dots.

The application has a UAC manifest.

On Windows Vista, the presence of a UAC manifest disables PCA. On Windows 7, that’s not good enough. You have to have one of the new-fangled Windows 7 GUIDs in your manifest to avoid PCA annoyance.

So, if you’re following along, here’s what happened:

  • Customer has an app that looks suspiciously enough like an installer that the operating system is trying to intervene and make things work
  • Developer notices that, doesn’t want/need the elevation, wonders how to make it go away, and discovers our documentation saying how you can turn off setup detection by including a UAC manifest – being good law-abiding citizens, they do exactly that (at their own expense)
  • Unbeknownst to the developer, we came along behind their back and changed the rules to make our previous guidance null and void, and once again we’re annoying their users with dialog boxes that make the developer look bad
  • Now the developer, if they wanted to make their users happy, would have to stop what they are doing, update their currently shipping app to include a manifest for an operating system that isn’t even released yet, so that Windows 7 can be more successful by having a more compatible and friendly OS (at their own expense)
  • Repeat for every subsequent version of Windows, as the Windows 7 GUID would no longer indicate Windows 8 compatibility either when it comes along

Does anyone else see anything wrong with this picture?

I’m trying to see what we can do about this, because I don’t think we’re being fair to developers right now. I believe that an asInvoker manifest is a pretty darned good indication that you’re not an installer, both from the perspective of GenericInstaller and PCA. I have absolutely no idea why somebody would disagree.

In the interim, rather than gripe about this (if you only know how many not-so-polite words and pejorative phrases I have already deleted from this blog post, you’d likely be very disappointed in me), I figured I’d tell you how you can fix it until whenever / if ever we address this:

Shim your application with SpecificNonInstaller.

I know of no other way to tell setup detection that “hey, you’re wrong” that will survive into the future. Because UAC Manifests only work on Windows Vista, Windows 7 Manifests will presumably only work on Windows 7, and who knows what you’ll need in the future?

What I don’t understand about PCA is, why haven’t we learned our lesson that asking the user a question every time we’re confused isn’t the right approach? <sigh />

Comments (10)

  1. Christian Häfner, DATEV eG says:

    Great post Chris! Thank you very much

  2. qtormanen says:

    Thanks for the explanation. I added the <supportedOS> and associated elements to my installer bootstrap and made it stop invoking the PCA, except for one scenario.

    I found that running my bootstrap directly from the web (choosing Run when linking to in on the web) causes the bootstrap to still run in the Windows Vista context and therefore invoke PCA, whereas saving it first (choosing Save when linking to it on the web) causes it to run in the Windows 7 context and not invoke PCA.

    Any ideas on this point?

  3. cjacks says:

    qtormanen-

    Is this with an internal or an external manifest? Do you have a repro? Running from the web should not affect detection of the Win7 manifest.

  4. qtormanen says:

    Chris,

    I have the manifest embedded as a resource. Feel free to see if you see the same thing running http://www.deltamotion.com/out/RMCToolsInstall32-new.exe on a 64-bit Windows 7 RC system. This installer should fail due to its condition requiring that the OS be 32-bit (since we have a separate 64-bit installer).

    I used the Resource Monitor to check the context it was being loaded in as well.

  5. cjacks says:

    Hi gtormanen,

    Got the repro – we’re investigating now. Thanks for reporting this! I love it when my blog goes 2-way instead of just being me running my mouth. 🙂

  6. cjacks says:

    @gtormanen – thanks for reporting this. While we won’t meet the RTM bar, we’re going to get this into a Windows Update coming soon (read: the fix is already done, we just have to get it into the appropriate ship vehicle).

  7. Ron Bauer says:

    I also have another side effect from this change.  I have a process that tracks processes via JobObjects.  With Vista I had to add a Manifest file to all my processes so PCA would not track them and I could continue to track with my custom tool.  It appears I need to modify the manifests again with a compatibility tag for Windows7.  The problem is I will have to do this for every new OS, or find an alternative to jobObjects.

  8. SEanS says:

    Better now than later on, well done Chris.

    Will you mail us when you’ve come up with a fix or work-a-around? PLEASE????

    Thanks and good luck, SEanS

  9. cjacks says:

    @SEanS – The workarounds are described above, that was the point of this post. 🙂 You can manifest your application as Windows 7 aware if you are the developer, or you can shim with SpecificNonInstaller if you are an IT Pro working with somebody else’s software.

Skip to main content