Partager via

Answers to Several Application Manifest Mysteries and Questions

  • Article

Recently, someone asked me this question in e-mail -- “How do I get my application to run elevated when someone launches it?”   Instinctively, I responded with a “You need to manifest it.”  I got a nice long e-mail in return. ;-) I quickly realized that application manifests appear simple but are quite confusing. Manifests are becoming very relevant as they control much more application behavior in Windows 7 and future OS’s. Any application that targets Vista or greater, should contain an application manifest.

Application Manifest Basics

  • An application manifest controls execution behavior of a binary and is defined in XML.
  • An application may or may not have an application manifest.
  • Application manifests can be embedded into an executable or can be an external file.
  • Application manifests have been around since XP. We keep extending them to control more behavior and tend to create new MSDN articles: XP introduced side by side assemblies, Vista added UAC behavior, Windows 7 added switchback and DPIAware. New sections are ignored on previous OS’s.
  • In XP, external manifests have priority and over embedded manifests. In Vista and beyond, embedded manifests have priority over external manifests. For example, if you have an embedded manifest and and external manifest for an application – On XP, the external one will be used; on Vista and later, the embedded one will be used.
  • On Vista and Windows 7, a manifested application with a trustInfo section will control what token will be used to start the process (standard user or admin). Also, all legacy mitigations will be disabled. This includes UAC Virtualization, Installer Detection, and the Program Compatibility Assistant.
  • Windows Client Logo requires applications to be manifested.

Checking for an Embedded Manifest

You might be wondering if your exe’s have embedded manifest and what they look like.  My favorite tool to dump a manifest is sigcheck. Use the –m switch to dump the manifest.  E.g. sigcheck.exe –m myapp.exe

Example output of a manifest with only side by side behavior:

This executable is a native C++ program.

D:\dev\legacyUAC\Debug>sigcheck.exe -m legacyUAC.exe

sigcheck v1.60 - sigcheck Copyright (C) 2004-2009 Mark Russinovich Sysinternals - www.sysinternals.com

D:\dev\legacyUAC\Debug\legacyUAC.exe: Verified: Unsigned File date: 7:43 PM 10/26/2009 Strong Name: Unsigned Publisher: n/a Description: n/a Product: n/a Version: n/a File version: n/a Manifest: <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> <dependency> <dependentAssembly> <assemblyIdentity type="win32" name="Microsoft.VC90.DebugCRT" version="9.0 .21022.8" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity> </dependentAssembly> </dependency> </assembly>

Example output of a manifest with UAC trustInfo section:

This executable is a .NET C# program.

D:\dev\legacyDPI\legacyDPI\bin\Debug>sigcheck.exe -m legacyDPI.exe

sigcheck v1.60 - sigcheck Copyright (C) 2004-2009 Mark Russinovich Sysinternals - www.sysinternals.com

D:\dev\legacyDPI\legacyDPI\bin\Debug\legacyDPI.exe: Verified: Unsigned File date: 3:06 PM 11/12/2009 Strong Name: Unsigned Publisher: Microsoft Description: legacyDPI Product: legacyDPI Version: 1.0.0.0 File version: 1.0.0.0 Manifest: <?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" name="MyApplication.app"/> <trustInfo xmlns="urn:schemas-microsoft-com:asm.v2"> <security> <requestedPrivileges xmlns="urn:schemas-microsoft-com:asm.v3"> <requestedExecutionLevel level="asInvoker" uiAccess="false"/> </requestedPrivileges> </security> </trustInfo> </assembly>

If you are wondering what those three weird characters at the beginning of the manifest are, it is the byte order mark. I talk about it in this post.

External Manifests

An external manifest is a text file that contains the manifest XML.  The file must exist in the same directory as the executable and have the same name with a “.manifest” extension.  For example, if the name of your executable is MyApp.exe, your manifest file would be named “MyApp.exe.manifest”.

Remember, in Vista and beyond, embedded manifests have priority over external manifests. Therefore, if the executable already has an embedded manifest, the external manifest will be ignored.

Embedding a Manifest

There are two ways you can embed a manifest.  You can have the compiler embed it or you can embed it with the manifest tool (mt.exe) included in the Platform SDK.

Embedding at Compile / Build Time

Visual Studio 2008 has functionality to embed manifest for native and managed projects. 

For Visual Studio 2005, Catherine Heller has a great post on how to embed manifests in your build process.

Embedding using mt.exe

The manifest tool is a command line tool that lets you add or merge manifests to an executable.  For usage, check the MSDN article for the Manifest Tool.  Here’s an example for adding a manifest to an executable:

mt.exe -manifest MyApp.exe.manifest -outputresource:MyApp.exe;#1

You will be modifying the binary when you embed the manifest. If your exe was signed, this will invalidate the signature and it will need to be re-signed.

Planning for the Future

Windows 7 introduced “switchback” into the manifest by adding a <compatibility> section to the manifest.  This allows you to state what OS you support. So, if you insert the tag that you support Windows 7, you will get a handful of new behaviors.  Otherwise, your app will “switchback” to the Vista behavior.  The plan is to use this section to make better choices for compatibility behaviors in future OS’s.  When adding manifests to applications, consider adding the supportedOS tag.

Comments

  • Anonymous
    June 13, 2010
    The comment has been removed

  • Anonymous
    June 14, 2010
    Clancy, It sounds like you are now a different user after the upgrade.  User document permissions are isolated by user.  Try taking ownership of the files as described in this forum post: social.answers.microsoft.com/.../a948679b-58d0-4711-b408-96994717d233 Good luck, Pat

  • Anonymous
    January 02, 2014
    Thanks for going to the trouble of writing the article - I know know what these 'manifests' are about after your clear introduction to them!

  • Anonymous
    April 08, 2015
    Hi Pat, will this concept work only with executables or is it possible to configure the manifest for a dll? I have an application.exe and write plugins to run in their container meaning I cannot modify the exe.

  • Anonymous
    April 09, 2015
    Hi Klaus, To be honest, I'm not sure.  From a compatibility standpoint, you should set them on the executable. It looks like at least an external manifest is supported for dll's according to MSDN. It's not clear what attributes are supported.  You can refer to the documentation here: msdn.microsoft.com/.../aa374191(v=vs.85).aspx Pat