What is the meaning of the folder names in Winsxs folder (windows run time assemblies directory)

Background:

Windows shared run-time libraries located at C:\windows\Winsxs folder
Inside Winsxs, there are two important sub folders also located as policies and Manifests
Other than that, there are plenty of run-time assemblies located in side each other sub folders.
All the sub-folders inside Winsxs and policies having same naming format.

Eg Folder Names:

Run times: x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.30729.1_x-ww_6f74963e
Policies: x86_policy.9.0.Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_x-ww_b7353f75

As I know first part of the name (x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.30729.1) describe "processorArchitecture"(x86) , "Name" (Microsoft.VC90.CRT), "publicKeyToken" (1fc8b3b9a1e18e3b) and "Version"(9.0.30729.1) of the assembly or policy.

Question: What is the last part of the assembly(x-ww_6f74963e) or policy(x-ww_b7353f75) folder name describes?

Ok here is the original issue (but quite long story). I deployed my C++ MFC application in windows XP computer that previously installed some of C++ redistribute packages and some security patches of run-time assemblies. So these pre-installed C++ redistribute packages automatically deployed some run-time policies in Winsxs/policies. those policies force to use new run-time assemblies instead of the one uses and deployed by my application. But some times these newer DLLs not there because of some other application removal or assemblies can be corrupted. So I'm finding a way to deploy run time assemblies specifically use for my application (it means my app must use the once deployed by it and ignore the policies). So I think this last part of the sub directory name associate with the identity of application. I need to find it.

Solution

If you can't trust global cache (and on WinXP it is super easy to corrupt it), you might have to install private copies of assemblies and override them in your application config.

Here is a hack I am using to override some assemblies for debugging purposes:

In your exe folder, drop the file named yourexename.exe.config with policy information redirecting real assembly version to something that will never exist in global cache. For example:

<configuration>
    <windows>
        <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
            <dependentAssembly>
                <assemblyIdentity type="win32" name="someassemblyname" processorArchitecture="x86" publicKeyToken="sometoken"/>
                <bindingRedirect oldVersion="1.0.0.0-1.0.999.998" newVersion="1.0.999.999"/>
            </dependentAssembly>
        </assemblyBinding>
    </windows>
</configuration>

Take contents of the assembly that you want to use, drop it into the same folder and edit manifest to have the version you used above. For example

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
    <noInheritable></noInheritable>
    <assemblyIdentity type="win32" name="someassemblyname" version="1.0.999.999" processorArchitecture="x86" publicKeyToken="sometoken"></assemblyIdentity>
    <file name="somedll.dll"/>
</assembly>

In the end you will get following files in your install folder:

yourexename.exe
yourexename.exe.config
somedll.dll
someassemblyname.manifest

And your executable will pick up private copy of the dll.

More info here: Application Configuration Files

EDIT: if you have problems like "the application failed to initialize properly" or "side by side configuration is incorrect" (and you will have them once you start playing with sxs), use sxstrace tool for diagnostics (not available on Windows XP though). That will tell you exactly which assembly causes problems.