Junfeng Zhang's Windows Programming Notes : Fusion

Internal Manifest vs External Manifest

junfeng — Mon, 11 May 2009 18:00:00 GMT

Internal manifest is the RT_MANIFEST resource in the executable.

External manifest is App.exe.manifest.

In Windows XP, Sxs searches external manifest before internal manifest. If an external manifest is found, the internal manifest is ignored.

In Windows Server 2003 and later, the order is reversed. Internal manifest is preferred over external manifest.

If you use external manifest, and your scenario works in Windows XP, but not Windows Server 2003 and later, please double check the executable does not have an internal manifest

App Config’s root element should be namespace-less

junfeng — Mon, 24 Mar 2008 18:00:00 GMT

The root element for Application config file is <configuration>

<?xml version="1.0" encoding="utf-8" ?>
<configuration >
</configuration>

The application config file is shared with CLR and Windows SxS.

SxS dictates that the root element is <configuration>, and it should be without namespace. If the application config file does not follow the rule, SxS will refuse to start the process.

Assembly Loading and Authorization

junfeng — Mon, 12 Nov 2007 19:00:00 GMT

CLR does not do anything special regarding authorization during assembly loading. It will try to access the file under the current user. However, if an assembly is already loaded, next time when the assembly is requested, CLR will return the assembly from the cache without hitting the file.

When the application impersonates a user, things get a little bit interesting. Sometimes the impersonated user does not have access to the assembly. Sometimes the impersonated user has read access to the assembly, but the appdomain has shadow copy enabled, and the impersonated user does not have write access to the shadow copy location. All those cases will result in access denied when the application tries to load the assembly.

In most cases, this access deny is perfectly acceptable. However, in some cases, you may want the user to be able to use the assembly. For example, you developed a web application. You would like to run the web application under the user accessing the web application, but the user does not necessarily have the right to write to "Temporary ASP.NET files" location where ASP.NET stores the shadow copied assembly.

You can workaround this problem by pre-loading the assemblies using a high privileged user. Since CLR does not touch the file after the assembly is loaded, you can sidestep the access deny problem.

(This technique does not work for Assembly.LoadFrom/LoadFile, for obvious reason.)

However, there is apparent security implications, and you have to evaluate it carefully.

Windows Vista Sxs Activation Context Cache

junfeng — Mon, 01 Oct 2007 18:00:00 GMT

Sxs activation model is built on top of Actication Context. To create an activation context, use the API CreateActCtx.

Activation Context is used very frequently in Windows. For example, a simple operation like start notepad, open the common file dialog, select a file, will call CreateActCtx many times (I measured 18 times in Vista). With the adoption of Sxs model in VC++ libraries, the usage of activation context will certainly be much higher.

However, creating an activation context is a very expensive operation. It has to resolve the full assembly binding closure, which includes probing for policies for all the assemblies, probing for each assembly, and parse each manifest. If you have read the output of sxstrace, you will certainly understand there are a lot work during CreateActCtx.

Fortunately, activation context is fairly static. Given a steady state, it is likely the same input to CreateActCtx will always create an activation context with exactly the same content. This makes it an attractively target for caching.

In Windows Vista, Sxs implements an activation context cache. The article discusses some detail of the Vista activation context cache.

1. What to cache

Only applications from local disk are cached. For applications running off network or CD, the cache has no effect.

2. Location of the cache

From this article (http://blogs.msdn.com/junfeng/archive/2007/06/12/activation-context-creation-flow.aspx) , we understand that the real work of CreateActCtx is done in CSRSS.exe. And this is where the cache is. The main reason is so that the activation context can be shared with multiple processes.

Since each session has a copy of CSRSS.exe, the cache is not shared across use login sessions.

3. Life time of the cache

The cache is only stored in memory. The first time CreateActCtx is called, it adds an entry to the cache. Next time when the same CreateActCtx is called, the result is returned from the cache immediately, saving the expensive probing and xml parsing. The cache is lost when the machine reboots.

4. size of the cache

The cache in Vista RTM has a fixed size, with a Least Recently Used (LRU) replacement algorithm. This may change in the future.

5. Cache Key

The activation context stores the parsed content of all manifests in the full assembly binding closure. Ideally, the cache key should be the path of all the manifests, and their last modified time.

However, if Sxs uses that as the key to the cache, it means Sxs will have to do all the expensive probing, parsing, which makes the cache useless.

To make a compromise, Sxs chooses the path of the entry manifest of CreateActCtx and its last modified time as the key. This means, if one of its dependent assemblies has changed, it is necessary to "touch" (i.e. change the last modified time of) the entry manifest for Sxs to see the change.

Here is an example. You may have a manifest myapp.exe.manifest depending on VC80, and you decides to deploy vc80 privately. So you have a private Microsoft.VC80.CRT.manifest. In Vista, when you change Microsoft.VC80.CRT.manifest, in order for Sxs to see the change in this manifest, you need to change the last modified time of myapp.exe.manifest.

5. WinSxs

If the dependent manifests are part of the application, this update requirement is very reasonable. However, if the assembly you depend on is in the global WinSxs store, you may not get a chance to update your manifest when the assembly in Winsxs changes.

Thus in Vista, Sxs adds a WinSxs store timestamp. Whenever a publisher policy assembly is installed to Winsxs store, Sxs updates the timestamp. The activation context cache saves the Winsxs store timestamp in the cache when the cache is created. When Sxs processes a CreateActCtx request, it checks to see if the cached Winsxs store timestamp matches the real Winsxs store timestamp. If it does not, Sxs throws out the cache, and re-creates it from scratch.

The reason that the timestamp is updated only when a publisher policy assembly is installed, is because Sxs requires a publisher policy when update an assembly in Winsxs store.

6. Disable the SxS Cache

Remember in the post DotLocal (.local) Dll Redirection, we know that for private testing, we can use registry HKLM\Software\Microsoft\WindowsNT\CurrentVersion\Image File Execution Options!DevOverrideEnable:REG_DWORD to enable DotLocal Dll redirection for applications with SxS manifest. Since disabling the SxS cache should be really for testing only, the same registry key is used to disable the SxS cache.

The Unusual Ref/Def Mismatch FileLoadException

junfeng — Mon, 06 Aug 2007 18:00:57 GMT

One of my colleagues has experienced a very strange Ref/Def Mismatch FileLoadException (The located assembly's manifest definition does not match the assembly reference). After a long investigation, we finally track down the cause.

To explain the problem, we have to understand the sequence of assembly loading and the interaction between fusion and CLR.

The key is after LoadLibrary , loader does one more check to make sure the file has not been changed between the original file mapping and LoadLibrary.

In my colleague's case, the assembly is in GAC. During the short period in between, someone did an in-place update of the assembly (When the assembly is mapped, you cannot delete it, but you can move it to a different location. This is how fusion does in-place update of assembly in GAC). Very unlucky indeed.

Since the file mapping is cached per-process, it is necessary to restart the process to load the assembly successfully again.

The bottom line is, CLR assembly loading does not work well against in-place update. Please avoid it if possible.

The sequence of interactions between CLR loader and fusion during Assembly.Load

junfeng — Mon, 06 Aug 2007 10:18:00 GMT

The following describes roughly the sequence of interactions between CLR loader and fusion during Assembly.Load() in .Net framework 2.0.

1. User calls Assembly.Load.

2. Loader pass the assembly reference to fusion.

3. Fusion checks to see if the assembly has already loaded. If it is, the assembly is returned.

4. If not, fusion probes the assembly as described in MSDN. If fusion cannot find the assembly, it returns a failure.

5. If fusion finds an assembly, it asks loader to crack the metadata of the assembly.

6. Loader maps the assembly, usually using file mapping, and cracks the metadata of the assembly. Loader also stores the file mapping in a process wide cache.

7. After fusion gets the metadata of the assembly, it does a ref-def matching. If the check fails, fusion returns error.

8. Otherwise, fusion puts the assembly in a cache, and returns the assembly to loader.

9. Loader does some additional checks. If the checks are good, Loader loads the assembly by calling LoadLibrary.

10. After LoadLibrary, Loader does one more check to make sure the assembly did not change between the original file mapping and LoadLibrary. If the file has changed, Loader throws ref/def mismatch FileLoadException.

11. If everything is good, Loader returns the assembly.

64 bit gacutil.exe

junfeng — Thu, 19 Jul 2007 18:00:34 GMT

32 bit gacutil.exe can install/uninstall/enumerate 64 bit assemblies for GAC, so there is really no need for 64 bit gacutil.exe.

BadImageFormatException maybe thrown when loading a valid assembly

junfeng — Wed, 11 Jul 2007 18:00:42 GMT

We saw some cases when loading a perfect valid assembly, CLR may throw BadImageFormatException occasionally.

In one particular case, we discover that it is caused by anti-virus scanners. Turn off the "Protection Against Unknown Threats" feature in the anti-virus engine and the problem disappears.

RT_MANIFEST resource, and ISOLATION_AWARE_ENABLED

junfeng — Tue, 26 Jun 2007 18:00:00 GMT

RT_MANIFEST

Since Windows XP, Windows reserves a new type of resource RT_MANIFEST for SxS manifests.

Within the RT_MANIFEST resource, Windows reserves ID 1-16. A binary cannot have two IDs of resource type RT_MANIFEST within 1-16. Windows will refuse to load such binary in Windows XP/Windows Server 2003.

Only three IDs are used today in Windows.

excerpt from Winuser.h

#define RT_MANIFEST MAKEINTRESOURCE(24)
#define CREATEPROCESS_MANIFEST_RESOURCE_ID MAKEINTRESOURCE( 1)
#define ISOLATIONAWARE_MANIFEST_RESOURCE_ID MAKEINTRESOURCE(2)
#define ISOLATIONAWARE_NOSTATICIMPORT_MANIFEST_RESOURCE_ID MAKEINTRESOURCE(3)
#define MINIMUM_RESERVED_MANIFEST_RESOURCE_ID MAKEINTRESOURCE( 1 /*inclusive*/)
#define MAXIMUM_RESERVED_MANIFEST_RESOURCE_ID MAKEINTRESOURCE(16 /*inclusive*/)

CREATEPROCESS_MANIFEST_RESOURCE_ID

CREATEPROCESS_MANIFEST_RESOURCE_ID is used primarily for EXEs. If an executable has a resource of type RT_MANIFEST, ID CREATEPROCESS_MANIFEST_RESOURCE_ID, Windows will create a process default activation context for the process. The process default activation context will be used by all components running in the process.

CREATEPROCESS_MANIFEST_RESOURCE_ID can also used by DLLs. When Windows probe for dependencies, if the dll has a resource of type RT_MANIFEST, ID CREATEPROCESS_MANIFEST_RESOURCE_ID, Windows will use that manifest as the dependency.

ISOLATIONAWARE_MANIFEST_RESOURCE_ID

ISOLATIONAWARE_MANIFEST_RESOURCE_ID is used primarily for DLLs. It should be used if the dll wants private dependencies other than the process default. For example, if an dll depends on comctl32.dll version 6.0.0.0. It should have a resource of type RT_MANIFEST, ID ISOLATIONAWARE_MANIFEST_RESOURCE_ID to depend on comctl32.dll version 6.0.0.0, so that even if the process executable wants comctl32.dll version 5.1, the dll itself will still use the right version of comctl32.dll.

When LoadLibrary is called, before loading the dependencies of the dll, the NT library loader checks to see if the dll has a resource of type RT_MANIFEST, ID ISOLATIONAWARE_MANIFEST_RESOURCE_ID. If it does, the loader calls CreateActCtx with the resource, and use the generated activation context to probe the dll's static dependencies. This is reason why the dll can have private dependencies with the ISOLATIONAWARE_MANIFEST_RESOURCE_ID resource.

The activation context created during LoadLibrary is stored in the loader data structure tracking the dll.

Normally this activation context is used only during LoadLibrary, for the dll's static dependencies.

Sometimes, you want to use the activation context outside of probing the dll's static dependencies. You can define macro ISOLATION_AWARE_ENABLED when you compile the module.

ISOLATION_AWARE_ENABLED

When ISOLATION_AWARE_ENABLED is defined, Windows re-defines certain APIs. For example LoadLibraryExW is redefined to IsolationAwareLoadLibraryExW.

When IsolationAwareLoadLibraryExW is first called, it tries to retrieve the activation context stored in the loader data structure when the calling library is loaded. If the library does not have such activation context (for example, the library does not have a manifest of id ISOLATIONAWARE_MANIFEST_RESOURCE_ID), IsolationAwareLoadLibraryExW tries to create a new activation context with the calling library with id ISOLATIONAWARE_NOSTATICIMPORT_MANIFEST_RESOURCE_ID MAKEINTRESOURCE. If the creation fails, IsolationAwareLoadLibraryExW will use the process default activation context.

Once the activation context is determined, IsolationAwareLoadLibraryExW will call ActivateActCtx on the activation context, call the real API (LoadLibraryExW), and on return, it calls DeactivationActCtx. This way, the correct activation context is automatically used.

Not all APIs affected by activation context are wrapped. For example, GetModuleHandleEx is not wrapped, and neither is any of the COM APIs. For a complete list of APIs wrapped by ISOLATION_AWARE_ENABLED, check your copy of Windows SDK.

C:\Program Files\Microsoft SDKs\Windows\v6.0\Include>dir *.inl
Volume in drive C has no label.
Volume Serial Number is ECD1-6DB0

Directory of C:\Program Files\Microsoft SDKs\Windows\v6.0\Include

10/30/2006 01:44 AM           159,222 commctrl.inl
10/30/2006 01:44 AM            32,836 commdlg.inl
10/30/2006 01:44 AM            12,065 prsht.inl
10/30/2006 01:44 AM            23,430 WinBase.Inl
10/30/2006 01:44 AM            36,308 WinUser.Inl

If the APIs you use are not wrapped by ISOLATION_AWARE_ENABLED, you have to do the activation/deactivation yourself properly. You can use the C++ helper class described in MSDN http://msdn2.microsoft.com/en-us/library/aa375197.aspx.

For more information, please see MSDN section about Sxs Isolated Applications and Side-by-side Assemblies.

Diagnose SideBySide failures in Windows XP/Windows Server 2003

junfeng — Tue, 12 Jun 2007 22:00:00 GMT

Since I published my article on how to diagnose SideBySide failures, I have received many feedbacks that since Sxstrace is not available in Windows XP/Windows Server 2003, it is hard to figure out what is wrong in Windows XP/Windows Server 2003.

This article intends to help people diagnose SideBySide failures in Windows XP/Windows Server 2003.

SideBySide failures usually results in error code Win32 error ERROR_SXS_CANT_GEN_ACTCTX (or HRESULT 0x800736B1), or ntstatus code STATUS_SXS_CANT_GEN_ACTCTX (0xc0150002). You may see it when launching a process with Sxs manifest, or loading a dll with sxs manifest.

From this article, we learned that the real work is done by CSRSS.exe.

Since most of the work in Creating Activation Context is probing, we can use the sysinternals tool FileMon.exe to understand what is going on.

Let's run an example.

I am running on Windows Server 2003.

F:\tools>ver

Microsoft Windows [Version 5.2.3790]

There is a tool CoCreate.exe. It has a Sxs manifest depends on common control.

F:\tools>more cocreate.exe.manifest
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
    <assemblyIdentity
        name="CoCreate"
        version="1.0.0.0"
        />

</assembly>

Unfortunately it says it depends on common control version 6.1.0.0, which does not exist anywhere currently.

Let's run the tool anyway.

F:\tools>cocreate
The system cannot execute the specified program.

Just as expected, the tool refuses to run.

Let's look at what event log tells us.

The message is accurate. But it is not really helpful here. What referenced assembly is not installed on my system?

Let's see if Filemon can help us here or not.

Launch filemon, and set the filter to CSRSS, as we want to monitor file access from the process CSRSS.exe.

Re-run CoCreate.exe. Now we have this in FileMon:

Ok. CSRSS.exe did a lot probing for Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.1.0.0.xxx. Given that CoCreate.exe.manifest says it depends on common control version 6.1.0.0, it is pretty clear that the missing referenced assembly is common control version 6.1.0.0.

Warning!!! Please do not attempt to copy files to the Winsxs directories shown in filemon output to workaround the Sxs activation context creation problem. Sxs keeps other metadata about the assembly besides the files in %windir%\Winsxs. Please always use the documented way to install Sxs assemblies.

Activation Context Creation flow

junfeng — Tue, 12 Jun 2007 18:00:10 GMT

The following describes how activation context is created currently in Windows XP/Windows Server 2003/Windows Vista.

1. CreateProcess/CreateActCtx is called.

2. CreateProcess/CreateActCtx does some validation, constructs a message, sends the message to CSRSS.exe, and waits for CSRSS.exe to return.

3. CSRSS.exe receives the message, and creates the activation context as described in http://blogs.msdn.com/junfeng/archive/2006/04/22/580482.aspx.

4. Once the activation context is created, CSRSS returns it to the client.

5. CreateProcess/CreateActCtx proceeds.

The getaway from the flow above is: most work is done in CSRSS.exe.

Genman32 – A tool to generate Sxs manifest for managed assembly for Registration Free COM/.Net Interop

junfeng — Sat, 14 Apr 2007 18:00:00 GMT

Attached to this article is GenMan32, a tool to generate sxs manifest for managed assembly to use in registration free COM/.Net Interop scenario.

(For more information about registration free COM/.Net interop, please read http://blogs.msdn.com/junfeng/archive/2006/05/17/595140.aspx.)

GenMan32 uses reflection API to enumerate all the types in the assembly. For each type, if it requires registration (as determined by System.Runtime.InteropServices.RegistrationServices.TypeRequiresRegistraton), depending on what kind of type it is, the tool generates either a clrClass element, or a clrSurrogate element.

For most basic scenarios, the sxs manifest generated by the tool is sufficient. For more complex scenarios, we may have to edit the generated manifest file before add the manifest to the assembly.

Here is the usage of the tool.

D:\tools>genman32

Microsoft (R) .NET Framework Win32 Manifest File Generation Utility 2.0.60120.0

Syntax: GenMan32 AssemblyName [Options]

Options:

/add Add manifest file to the assembly as a resource.

If /manifest option is provided, use the filename a

s input.

Otherwise generate one from the assembly.

/remove Remove an embedded manifest from the assembly.

/replace Replace embedded manifest with new manifest.

New manifest is specified by /manifest option.

/manifest:filename Specify the manifest file to add or replace.

Used together with option /add or /replace.

/typelib Generate typelib and record all the interfaces in

manifest. This option cannot be used with interop

assemblies.

/reference:filename Specify the dependency of the assembly. To specify

multiple dependencies, specify the /reference optio

n multiple time.

/asmpath:directory Look for assembly references here.

/out:filename Generate manifest. If filename is omitted, the

manifest is generated as AssemblyName.manifest.

/nologo Prevents GenMan32 from displaying logo.

/silent Silent mode. Success messages not displayed.

/? or /help Display this usage message.

We can use the tool to generate a Sxs manifest for managed assembly.

D:\tools>more testlib.cs

using System;

using System.Runtime.InteropServices;

[ComVisible(true)]

public class TestClass

{

public void TestAPI()

{

}

[ComVisible(true)]

public struct TestStruct

{

int testField;

}

D:\tools>genman32 testlib.dll /out:1.man

Microsoft (R) .NET Framework Win32 Manifest File Generation Utility 2.0.60120.0

Win32 Manifest file D:\tools\1.man is created successfully

Let’s look at the generated manifest.

D:\tools>more 1.man

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">

<assemblyIdentity

name="testlib"

version="0.0.0.0"

processorArchitecture="MSIL" />

<clrClass

clsid="{ED653D53-DA9A-35A8-B16E-6C8704AC432D}"

progid="TestClass"

threadingModel="Both"

name="TestClass"

runtimeVersion="v2.0.50727">

</clrClass>

<clrSurrogate

clsid="{D250790F-F50A-33FD-990F-FF5DC3E26E9B}"

name="TestStruct">

</clrSurrogate>

<file name="testlib.dll">

</file>

</assembly>

We can also use this tool to add the manifest to the managed assembly.

D:\tools>genman32 testlib.dll /add /manifest:1.man

Microsoft (R) .NET Framework Win32 Manifest File Generation Utility 2.0.60120.0

Win32 Manifest added to assembly 'D:\tools\testlib.dll' successfully

We can verify the manifest is indeed successfully embedded to the managed assembly.

D:\tools>dumpmanifest -f testlib.dll 1

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">

<assemblyIdentity

name="testlib"

version="0.0.0.0"

processorArchitecture="MSIL" />

<clrClass

clsid="{ED653D53-DA9A-35A8-B16E-6C8704AC432D}"

progid="TestClass"

threadingModel="Both"

name="TestClass"

runtimeVersion="v2.0.50727">

</clrClass>

<clrSurrogate

clsid="{D250790F-F50A-33FD-990F-FF5DC3E26E9B}"

name="TestStruct">

</clrSurrogate>

<file name="testlib.dll">

</file>

</assembly>

Let’s prove ourselves that this is indeed working.

CoCreate.exe simply calls CoCreateInstance. If it fails, CoCreate.exe prints an error message, else it prints success.

D:\tools>more cocreate.exe.manifest

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">

<assemblyIdentity

name="CoCreate"

version="0.0.0.0"

type="win32"/>

</assembly>

D:\tools>cocreate {ED653D53-DA9A-35A8-B16E-6C8704AC432D}

Error: CoCreateInstance({ED653D53-DA9A-35A8-B16E-6C8704AC432D}) failed with hr=

0x80040154.

Let’s add TestLib to CoCreate.exe’s dependency.

D:\tools>more cocreate.exe.manifest

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">

<assemblyIdentity

name="CoCreate"

version="0.0.0.0"

type="win32"/>

<dependency>

<dependentAssembly>

<assemblyIdentity

name="testlib"

version="0.0.0.0"

processorArchitecture="MSIL" />

</dependentAssembly>

</dependency>

</assembly>

D:\tools>cocreate {ED653D53-DA9A-35A8-B16E-6C8704AC432D}

Success!

Good job!

GAC Temp and Tmp

junfeng — Fri, 17 Nov 2006 19:00:00 GMT

I see people asking question about the Temp and Tmp directories under GAC.

Yes they are temporary directory fusion uses during GAC Assembly installation and uninstallation. Tmp is used for installation, and Temp is used for uninstallation.

The use of them is described in my article GAC Assemblies: Install and Uninstall.

The reason that fusion needs two temporary folders, is that fusion will always try to clean up the Temp directory used for uninstallation at the end of each installation/uninstallation. If fusion were to use the same temporary directory for installation and uninstallation, fusion may accidentally remove temporary files used by another assembly installation in progress.

Fusion does not clean up Tmp directory (used for installation). When an installation failed, fusion tries to remove the temporary directory it created during the installation. It does not touch anything else, for the same reason above.

Usually you should not see anything in Tmp unless during assembly installation. You may see things under Temp. When fusion is asked to uninstall an assembly, if the assembly is in use, fusion will be able to move the assembly to the Temp directory, but won't be able to delete it. That is OK though. Next time when get a chance, fusion will try to clean up that directory.

Installing SxS assemblies in Vista

junfeng — Thu, 09 Nov 2006 19:00:00 GMT

When installing SxS assemblies in Vista, you may experience MSI error 1935, with HRESULT 0x80073715.

0x80073715 is Win32 error ERROR_SXS_MANIFEST_IDENTITY_SAME_BUT_CONTENTS_DIFFERENT.

//
// MessageId: ERROR_SXS_MANIFEST_IDENTITY_SAME_BUT_CONTENTS_DIFFERENT
//
// MessageText:
//
// The identities of the manifests are identical but their contents are different.
//

#define ERROR_SXS_MANIFEST_IDENTITY_SAME_BUT_CONTENTS_DIFFERENT 14101L

This error means, you have tried to install two assemblies with the same identity but with different contents.

To workaround the issue, whenever you change the content of the assembly, you need to change the version number of the assembly.

Touch the exe, after you added a manifest for it, in Vista

junfeng — Wed, 25 Oct 2006 18:00:00 GMT

You are an enthusiastic and responsible developer. You love programming, and you love programming the right way.

So you get the latest and greatest Windows Vista. You try your hard-worked amazing.exe application in Vista. Did not work. Apparently, amazing.exe needs admin privilege to do wonderful things. But in Vista, the user by default does not have admin privilege.

You did your research. You understand that you need to add a manifest to your application, and declare that the application requires administrator in the manifest. So you added amazing.exe.manifest, and put it next to amazing.exe.

Did not work. Amazing.exe did not get admin privilege.

You double checked the syntax of the manifest. Yes, it is right. You compared it to another working example. Yes, they are the same. You run amazing.exe again. Still did not work.

You are angry. What is going on, Microsoft?

The truth is, in Windows Vista, in order to improve CreateProcess performance, we cache the fact that an exe has manifest or not. The key to this cache, are the full path of the exe, and the last modified time of the exe file.

After you execute the exe without manifest, when you add a manifest to the exe, in order for the OS to see the manifest, you need to change the last modified time of the exe (or simply say, touch the exe), to invalidate the cache entry for the exe.

The cache only exists in memory, and is never flushed to disk. On reboot the cache starts clean.

At the time we did the work, our measurement shows that the cache improved CreateProcess performance by 10-15% in warm case, when the application does not have manifest.

So remember, touch the exe, after you added a manifest for it, in Vista.