OBJECT_DIRECTORY

The OBJECT_DIRECTORY structure (formally _OBJECT_DIRECTORY) is the Object Manager object that the Object Manager itself uses for representing a directory in the object namespace. The directory object is a container of other objects, including more directory objects. All versions of Windows provide for creating directory objects from both kernel mode and user mode through the functions NtCreateDirectoryObject (in user mode only) and ZwCreateDirectoryObject and all versions provide similarly for opening directory objects through NtOpenDirectoryObject and ZwOpenDirectoryObject. These functions give their callers a handle to the directory object. When kernel-mode software that has such a handle feeds it to some such function as ObReferenceObjectByHandle, then the reference it gets back is a pointer to an OBJECT_DIRECTORY.

Variability

The OBJECT_DIRECTORY is highly susceptible to changing between builds. The following changes of size give some rough indication:

Layout

The sizes in the preceding table and the offsets, names and types in the next are from type information in public symbol files for the kernel, starting from Windows 2000 SP3.

OBJECT_DIRECTORY_ENTRY *HashBuckets [37];

OBJECT_DIRECTORY_ENTRY **LookupBucket;

BOOLEAN LookupFound;

USHORT SymbolicLinkUsageCount;

EX_PUSH_LOCK Lock;

DEVICE_MAP *DeviceMap;

union {
    DEVICE_MAP *DeviceMap;
    OBJECT_DIRECTORY *ShadowDirectory;
};

DEVICE_MAP *DeviceMap;

OBJECT_DIRECTORY *ShadowDirectory;

ULONG SessionId;

USHORT Reserved;

USHORT SymbolicLinkUsageCount;

PVOID NamespaceEntry;

PVOID SessionObject;

ULONG Flags;

ULONG SessionId;

Each of the HashBuckets is a single-linked list of potentially many OBJECT_DIRECTORY_ENTRY structures. Each of these points to an object that is in the directory. The gain is, of course, that instead of having one long list of all such objects, the directory has 37 shorter lists of directory entries for objects whose name within the directory have the same hash. The hashing algorithm is surely well known and just as surely doesn’t matter much. All that is required of it is that it (quickly) produces a more or less uniform distribution of (typical) names into hash buckets. Yet perhaps because the details are unimportant, the algorithm does happen to have been left alone. Its code for 32-bit Windows plausibly has been untouched from Windows NT 3.51 to at least the original Windows 10. The essence is that successive characters are converted to upper case for adding to the hash, which in turn has its bits spread in a particular way on each loop. Given Count Unicode characters at address Pointer, the computation for 32-bit Windows goes something very like

ULONG Hash (PWCHAR Pointer, ULONG Count)
{
    ULONG hash = 0;
    while (Count -- != 0) {
        WCHAR ch = *Pointer ++;
        hash = (hash << 1) + hash + (hash >> 1);
        if (ch < L'a') hash += ch;
        else if (ch <= L'z') hash += ch - (L'a' - L'A');
        else hash += RtlUpcaseUnicodeChar (ch);
    }
    return hash;
}

See that the ShadowDirectory litterally grew out of the DeviceMap.

Since the Flags are not in union with a formal definition of bit fields, Microsoft’s names for the flags are presumably defined by macro and don’t show in type information even in the private symbol files that Microsoft keeps to itself. That said, Microsoft’s names for some of the Flags bits are known from the possibly accidental publication of NTOSP.H in the original and Version 1511 editions of the WDK for Windows 10:

Microsoft’s names for the last two flags above aren’t known to have been published.