Home Tutorials What is the ModuleUsage Registry Key?

What is the ModuleUsage Registry Key?

Posted: July 5, 2009

If your favorite computer system utilizes one of the Microsoft Windows operating systems, you can be sure that there is a registry contained within your much-loved machine. Your computer's registry is essential to every single thing it does, and without it, your computer would not only be incapable of launching your Windows OS, but it would also be entirely hindered from performing any of the fundamental tasks that you rely to perform every day on your computer. This is because, if you were to think of your computer as a living breathing organism, you could view its registry as a vital body part that it could not function or even live without.

What's the Internet Component Download Service

Within your system's registry, you can find the 'Internet Component Download' service. This particular service stores registry entries for each new component you download on your machine. The functional bit of this particular component is that, instead of storing each new registry entry for the elements you download from the Internet in some sort of permanent store within you registry, your computer's Internet Component Download service is capable of managing these entries for you. With the aid of your computer's Internet Component Download service, these registry entries can be employed to write a utility, to clean up your system's code storage, and/or to move your Internet Component Download service to utilize a code cache instead of a permanent store.

Why the 'SharedDLL' Reference Counting Scheme Does Not Suffice

To perform code caching correctly, the process of reference counting must be done correctly and the current, existing 'SharedDLL' reference counting scheme is inadequate. The current SharedDLL mechanism, as a reference counting scheme, will not do because its reference counts are easily and often inflated, and, according to Microsoft, the SharedDLL mechanism will especially fail when dealing with the Internet Component Download. This is because, in the Internet Component Download, OCXs are frequently utilized by several pages, and there is no means for knowing which of the OCXs require and/or need reference counts.

This is where the term ModuleUsage begins to come into play.

ModuleUsage and its Importance in Tracking Usage of Shared Components

To this end, your computer's Internet Component Download service retains a ModuleUsage section, located within your computer's registry, which contains a list of 'clients' and 'owners' for each shared module. In other words, the ModuleUsage section contained within your system's registry is used to track usage of shared components on your computer system. This means that your computer's registry is able to keep track of, not just how many clients a particular module has, but also who is using a shared module.

By remembering which clients are actually utilizing a particular shared module, the registry information contained within the ModuleUsage section and the 'shared module keys' – which are further discussed in detail below – works as a complement to the reference counts in the SharedDLL section of your system's registry. In effect, by complementing one another, this scheme of counting will work correctly and will allow the proper caching of downloaded code.

In addition, this registry information is further helpful when downloading files from the Internet because the Internet Component Download service can employ this information as an efficient and resourceful shortcut for confirming and verifying whether a particular file is an out-of-date version that needs to be overwritten.

Syntax Employed by Registry Entries in the ModuleUsage Section

The registry entries, within the ModuleUsage section of your registry, employ the following syntax:

[ModuleUsage]
[]
.FileVersion=a,b,c,d
.Owner = Friendly Name/ID of Owner
=
=

An Example of a ModuleUsage Registry Entry

Additionally, the following depicts an example of a ModuleUsage section in a model registry. Such an entry would be found under:

My Computer\HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion:

[ModuleUsage]
[c:/isapi/gomscom.asp?TARGET=/windows/system/mfc40.dll]
.FileVersion=0,4,0,0
.Owner ={CLSID of main object rclsid passed to CoGetClassObjectFromURL}
{CLSID of main object rclsid passed to CoGetClassObjectFromURL}=
AnotherAppID=

Types of Shared Module Keys

To understand all of this information better, you should note that there are several different types of shared module keys within your computer's registry.
Remember, keys are a core component of the hierarchical structure of your registry. Keys are the second rung of the Windows registry totem pole, located inside the top rung called hives.
The following provides a brief breakdown of the various types of 'shared module keys':

Key Name Description
<Fully Qualified Path & File Name> This type of shared module key is the full path of the shared module – this key name must utilize "/" rather than "\" because "\" is considered an invalid character in a key's name.
.Owner The particular application that both installs the 'shared module' and generates the original ModuleUsage sections places some identifier in the .Owner key section. In this case, if the DLL already exists and the ModuleUsage key does not, the .Owner key should be set to "Unknown" and the existing DLL should not be removed on uninstall. Note: The .Owner key should always enlist itself as a client, as well.
.File Version This references the version number for the shared module, and at this time, this particular key is not implemented by the Internet Component Download service.
<Client ID> This particular shared module key is the identifier of a client who is utilizing the shared module and each client key's contained Value is comprised of client-specific information. When the client, in question, is the Internet Component Download service, the <Client ID> is {CLSID of the main object RCLSID passed to CoGetClassObjectFromURL. In terms of other clients, this values' client-specific information is supposed to be the full path of the client. The reason for this being that in case the client is accidentally deleted, retrieving it via garbage collection is possible.

Additionally, each and every client of the shared module is expected to increment - and decrement - the current, existing SharedDLLs section of your computer's registry.

With this said, a client only increments this value one time, which occurs when it adds itself as a client to the ModuleUsage section of your registry. The reason for this particular behavior is that it allows migration paths for applications that, currently, only implement a SharedDLLs scheme.

Loading...