Answers to Several Application Manifest Mysteries and Questions
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.