Which File Is Used To Hold The Cloaking Clsid

Ever typed a weird error into Google at 2 a.m. and landed on a forum thread from 2009 where someone says "check the cloaking CLSID file" and then logs off forever? Yeah. Me too.

The short version is: people throw around the phrase "cloaking CLSID" like it's one specific thing, but Windows doesn't ship a file literally named that. What they're usually circling around is a COM registration detail — and the file that actually holds the cloaking CLSID is typically a type library or a compiled binary that registers a class under a specific identifier Not complicated — just consistent..

Here's the thing — if you're hunting for which file is used to hold the cloaking clsid, you're probably debugging something annoying: a shell extension, a broken preview handler, or a COM object that won't talk to another process. Let's untangle it without the robot-speak Surprisingly effective..

What Is the Cloaking CLSID

A CLSID is just a globally unique identifier (GUID) for a COM class. COM — Component Object Model — is the dusty but still-load-bearing plumbing under Windows that lets pieces of software talk to each other without knowing how the other was built Surprisingly effective..

"Cloaking" in this context isn't malware. When you use cloaking, a client can hide (or "cloak") its security identity from the server it's calling, or present a specific token so the server thinks it's someone else. It's a COM security term. This matters for things like service isolation and elevation The details matter here..

So when someone asks which file is used to hold the cloaking clsid, they're really asking: where does Windows (or an app) store the class that implements this cloaked COM behavior?

The Registry Points to the File

The CLSID itself lives in the registry under HKEY_CLASSES_ROOT\CLSID\{guid}. But the registry entry is just a pointer. The actual code lives in a file — usually a DLL, sometimes an EXE or OCX.

That file is what "holds" the CLSID. Plus, for cloaking specifically, the class has to support CoSetProxyBlanket or be instantiated with cloaking flags like EOAC_DYNAMIC_CLOAKING. The file that holds it is the one registered under InprocServer32 or LocalServer32 for that CLSID.

Type Libraries and IDL

Sometimes the CLSID is also described in a type library (.Here's the thing — tlb) or defined in an interface description (. Practically speaking, idl) file at build time. That's not the runtime holder — it's the blueprint. But developers will say "the cloaking CLSID is in the TLB" because that's where they declared it.

Why It Matters

Why does this matter? Because most people skip it and then wonder why their COM call fails with "access denied" or "class not registered."

If you're writing a shell extension that needs to run under a different user context, or you're calling a service from a desktop app, cloaking decides who the server thinks you are. Get the file wrong — or register it incorrectly — and nothing works That's the part that actually makes a difference..

And in practice, a lot of "ghost" bugs come from a CLSID pointing to a file that was moved, deleted, or never installed. The registry says the cloaking class exists. The file says otherwise.

Real talk: this is also why some old enterprise apps break after a Windows update. The update nudges a DLL, the CLSID still points to the old path, and the cloaked COM call silently dies.

How It Works

Let's get into the actual mechanics. How do you find, confirm, and use the file that holds a cloaking CLSID?

Step 1: Find the CLSID in the Registry

Open regedit and go to HKEY_CLASSES_ROOT\CLSID. You'll see a wall of GUIDs. If you already know the cloaking CLSID (say, from an error or a docs page), jump to it directly: HKEY_CLASSES_ROOT\CLSID\{your-guid-here}.

Under that key, look for:

• InprocServer32 — path to a DLL
• LocalServer32 — path to an EXE
• ProgID — a friendly name like MyApp.CloakObject

That path is your file.

Step 2: Confirm the File Supports Cloaking

Just because a file is registered under a CLSID doesn't mean it cloaks. You need to check the code or docs. In C++, cloaking is set via:

CoSetProxyBlanket(pProxy, RPC_C_AUTHN_DEFAULT, RPC_C_AUTHZ_NONE,
    NULL, RPC_C_AUTHN_LEVEL_DEFAULT, RPC_C_IMP_LEVEL_IMPERSONATE,
    NULL, EOAC_DYNAMIC_CLOAKING);

If the file's source (or its manifest) references EOAC_DYNAMIC_CLOAKING or EOAC_STATIC_CLOAKING, that's your cloaking class Small thing, real impact..

Step 3: Check Registration Health

A file "holds" the CLSID only if it's actually registered. Run:

regsvr32 /u "C:\path\to\file.dll"
regsvr32 "C:\path\to\file.dll"

If registration fails, the file is either missing a export, blocked by Windows, or built for the wrong architecture (32-bit DLL in a 64-bit host — classic) But it adds up..

Step 4: Watch It at Runtime

Use a tool like Process Monitor (from Sysinternals) and filter for the CLSID or file name. You'll see whether the process actually loads the file when the cloaked object is created. That said, turns out, a lot of "it's registered! " problems are really "it tried to load and Windows said no Most people skip this — try not to..

Step 5: Know the System-Owned Ones

Some cloaking CLSIDs are owned by Windows itself. dllorrpcss.On the flip side, for example, certain shell broker classes in shell32. dll use cloaking internally. If you're asking which file holds those, the answer is a system DLL — and you shouldn't replace it, just reference it correctly Worth keeping that in mind. That alone is useful..

Common Mistakes

Here's what most people get wrong. I know it sounds simple — but it's easy to miss.

Assuming the CLSID name means a separate file. There is no cloaking.clsid file. The CLSID is an ID. The file is whatever the registry says implements it.

Looking in the wrong registry hive. On 64-bit Windows, HKEY_CLASSES_ROOT is a merge of HKLM\Software\Classes and HKCU\Software\Classes. A 32-bit app sees a different view via Wow6432Node. If you're hunting in the wrong one, you'll never find the file Small thing, real impact..

Confusing cloaking with masking or hiding UI. Cloaking in COM is about security context, not making a window invisible. Different beast Simple, but easy to overlook..

Editing the registry to point at a new file without re-registering. The file has to export DllRegisterServer properly. Just changing the path string doesn't magically make the new file "hold" the CLSID.

Trusting old forum answers. A 2011 post saying "it's in msxml3.dll" might've been true for XP. It isn't now Simple, but easy to overlook..

Practical Tips

What actually works when you're stuck on this:

• Use oleview (OLE/COM Object Viewer). It ships with older Windows SDKs and shows you every CLSID, what file backs it, and whether it's registered. Faster than regedit diving.
• Search the file system for the GUID. findstr /s /m "{guid}" *.dll *.exe *.tlb in a target folder can reveal which binary mentions the CLSID string.
• Don't guess the file — trace it. Process Monitor with a registry and file filter is the most honest way to see which file is used to hold the cloaking clsid on your specific machine.
• If it's a vendor app, reinstall before you regedit. Nine times out of ten the file is just unregistered after an update.
• Keep a note of the architecture. 32-bit host can't load 64

-bit DLL, and vice versa—so always confirm whether the calling process is running under WOW64 or native before you assume the binary is broken Simple as that..

One more thing worth mentioning: if you’re working in a managed or scripted environment, don’t overlook registration via manifest or side-by-side (SxS) configuration. In those cases, the “file that holds the cloaking CLSID” is defined by the assembly manifest, not by what you see under HKCR. Some cloaking-capable COM servers are deployed without touching the global registry at all, relying instead on activation contexts that redirect the CLSID lookup at load time. Tools like sxstrace can show you exactly which DLL was resolved through that path when the object was instantiated.

Conclusion

Finding the file that holds a cloaking CLSID isn’t about memorizing a filename—it’s about following the registration, the architecture, and the runtime behavior on the machine in front of you. Worth adding: the CLSID is only a pointer; the real answer lives in the registry InprocServer32 value, the system’s merged hives, and the process that actually loads the binary. Skip the assumptions, trace it with the right tools, and you’ll know not just which file backs the cloaking class, but whether it was ever really loaded at all.