Registry Parser
← All articles

What is UsrClass.dat? The per-user hive analysts forget

7 min read

Ask most analysts where a user's registry artifacts live and they will say NTUSER.DAT. They are not wrong, but they are not complete. Every Windows user profile carries a second hive, and on modern Windows it holds some of the most valuable evidence in the whole profile. That second hive is UsrClass.dat, and the people who grab NTUSER.DAT and stop there walk past it every day.

This post explains what the UsrClass.dat file is, where it lives, how it maps into the registry namespace, why it behaves differently from NTUSER.DAT, and which artifacts Microsoft quietly moved into it — including the ones that close cases.

What is UsrClass.dat?

UsrClass.dat is the per-user class-registration hive. "Class registration" is the registry's term for the bookkeeping that ties file types, COM objects, ProgIDs, and shell extensions to the code that handles them. When you double-click a .pdf and the right application opens, that decision was driven by class-registration data. NTUSER.DAT is the user's general settings hive; UsrClass.dat is the user's class hive. They are siblings, loaded together at logon, owned by the same user.

The reason this hive exists at all is overrides. The system-wide class registrations live in HKLM. But a user may install software only for themselves, or may want a file association that differs from the machine default. UsrClass.dat is where those per-user class registrations are stored so they can take precedence without touching the machine-wide hive.

Where the UsrClass.dat file lives

The hive is on disk at:

C:\Users\<user>\AppData\Local\Microsoft\Windows\UsrClass.dat

Note the path: AppData\Local, not AppData\Roaming. That location is not an accident, and it is the single most important operational fact about this hive — more on that below. As with any loaded hive, you will also find a transaction-log pair alongside it: UsrClass.dat.LOG1 and UsrClass.dat.LOG2. Acquire those together with the hive. If the hive was dirty at acquisition time, the logs hold pending changes that a transaction-log-aware parser needs in order to give you a consistent view.

How it maps into the registry namespace

When the user logs on, Windows mounts UsrClass.dat at:

HKEY_CURRENT_USER\Software\Classes

So when you browse HKCU\Software\Classes on a live system, you are looking at the contents of UsrClass.dat — not at a subkey of NTUSER.DAT, even though NTUSER.DAT is mounted as the root of HKCU. The shell stitches the two hives together under one HKCU root, which is exactly why the second hive is so easy to overlook: on a live box it hides in plain sight under HKCU.

It gets one layer more interesting. HKEY_CLASSES_ROOT — the HKCR hive everyone has poked at — is not a real standalone hive at all. It is a merged view of HKLM\Software\Classes (machine-wide) and HKCU\Software\Classes (the user's UsrClass.dat). When both define the same class, the per-user entry from UsrClass.dat wins. So UsrClass.dat is one of the two ingredients of HKCR, and the one that carries the individual user's overrides.

For an offline analysis this matters: there is no HKCR file to seize. If you want the user's half of HKCR, you take UsrClass.dat. (For the broader question of which files to pull from an image, see which registry hive to grab.)

Why it does not roam

Here is the behavior that trips people up. NTUSER.DAT lives in the profile root and, in a domain with roaming profiles, it roams — it syncs between machines when the user logs on and off. UsrClass.dat lives under AppData\Local, and Local by definition does not roam. It stays on the machine where it was written.

That difference has two consequences for an investigation:

  • Attribution is cleaner. Artifacts in UsrClass.dat reflect activity on that host. Unlike roaming NTUSER.DAT artifacts, which can drag a user's history across multiple machines, UsrClass.dat content is far less likely to have been written somewhere else and synced in. When you need to argue that something happened on this specific machine, the local-only hive is a stronger anchor.
  • You cannot rely on a domain copy. There is no roamed central version to fall back on. If you did not acquire the local hive from the host, you do not have its content. There is no second copy waiting on the file server.

The artifacts Microsoft moved into it

This is the part that turns UsrClass.dat from a curiosity into a priority. Over successive Windows releases, Microsoft relocated several high-value forensic artifacts out of NTUSER.DAT and into UsrClass.dat. The hive that started as a place to store file associations is now the home of evidence about folder access and program names.

ShellBags. On Windows 7 and later, the meaningful ShellBags live in UsrClass.dat under Local Settings\Software\Microsoft\Windows\Shell\BagMRU and \Bags. NTUSER.DAT still has a Software\Microsoft\Windows\Shell\BagMRU, but on modern systems that copy is nearly empty — a vestige. The folder-navigation history, the USB-device folder trails, the network-share paths, the entries that survive folder deletion — all of that is in UsrClass.dat. An analyst who parses ShellBags only out of NTUSER.DAT on a Windows 10 or 11 host will get a near-empty result and may wrongly conclude the user navigated nowhere. The data was there the whole time, in the hive they did not pull.

MUICache. The MUICache — a list of application display names the shell caches when an executable is run for the first time — also lives in UsrClass.dat, under Local Settings\Software\Microsoft\Windows\Shell\MuiCache. It is a quiet execution-corroboration artifact: each entry implies the named binary was loaded by the shell at some point, with the friendly name and path recorded. It does not carry timestamps or run counts, but as a "this binary existed and was invoked on this host" signal it pairs well with execution artifacts that do.

File associations and COM data. The hive's original job is still its job. Under Software\Classes you have ProgIDs, file-extension mappings, COM CLSID registrations, and shell extension handlers — all scoped to this user. For an investigation, per-user CLSID registrations and unusual shell-extension handlers are worth a look: they are a known persistence and hijack surface, and a per-user entry that overrides a machine default is exactly the kind of thing an attacker uses to stay quiet.

The mistake to not make

The single most common UsrClass.dat error is an acquisition gap, not a parsing one. The collection checklist says "grab NTUSER.DAT for each user," the analyst dutifully does that, and ShellBags come back empty on a modern Windows host. The conclusion — "no folder navigation history" — is wrong. The real conclusion is "I did not collect the hive that holds it."

Fold both per-user hives into your standard collection, every time:

  • ...\<user>\NTUSER.DAT (+ its .LOG1 / .LOG2)
  • ...\<user>\AppData\Local\Microsoft\Windows\UsrClass.dat (+ its .LOG1 / .LOG2)

And do it for each relevant profile. ShellBags and MUICache are per-user; parsing the administrator's UsrClass.dat tells you about the administrator, not about the suspect account. If Volume Shadow Copies are present, pull UsrClass.dat from the snapshots too — older ShellBag and MUICache state in a prior copy can show activity that the live hive has since overwritten.

Open it and look

UsrClass.dat is an ordinary registry hive in the same binary format as NTUSER.DAT, SYSTEM, and SOFTWARE. Anything that parses a hive parses this one. The catch is purely that you have to remember it exists and remember to collect it.

You can analyze it in your browser — drop the UsrClass.dat file into Registry Parser, walk straight to Local Settings\Software\Microsoft\Windows\Shell\BagMRU for the ShellBags and to the MuiCache key for the program names, and inspect the Software\Classes tree for per-user file associations and COM registrations. Nothing is uploaded; the parsing happens locally.

The summary is short. NTUSER.DAT is the hive everyone remembers. UsrClass.dat is the hive everyone forgets — and on modern Windows it is where the ShellBags and the MUICache actually live. Collect both, parse both, and you stop leaving a user's folder-access history sitting on the disk you walked away from.