If you have ever tried loading a PDM add-in and hit a confusing startup error, understanding why “class not registered” happens when loading SOLIDWORKS PDM add-ins is the first step to fixing it. This issue usually points to a broken or incomplete COM registration, often caused by mismatched permissions or missing system components.
When a SOLIDWORKS PDM add-in fails to load with the message:
Failed to load add-in
Reason: Class not registered
the cause often isn’t the add-in code or COM registration itself: It’s the elevation context in which the host application runs. Windows isolates COM registrations between two different scopes:
| COM Registration Scope | Registry Location | Accessible When |
|---|---|---|
| Per-User | HKEY_CURRENT_USER\Software\Classes\CLSID | The process runs non-elevated (normal user context). |
| Per-Machine | HKEY_LOCAL_MACHINE\Software\Classes\CLSID | The process runs elevated (as Administrator) or system-wide. |
When you register your SOLIDWORKS PDM add-in (e.g. CardSync.dll) using regasm or the PDM Administration tool, it is normally stored under the current user’s profile (HKCU). However, if the host process like File Explorer, PDM Explorer, or even your test harness (Orca.Tests.exe – At Blue Byte Systems, we have developed our very own unit testing framework for add-ins), runs as Administrator, Windows will block access to any COM object registered per user.
That’s exactly what the “Class not registered” dialog means.
SOLIDWORKS PDM Explorer itself is not designed to run elevated. When your own executable or service is launched as Administrator, it now operates in a different COM security boundary and cannot see the user-level registration of your add-in.
In the example of the screenshot above, I’m debugging inside Visual Studio (ADMIN) and launching my process from there. The moment Visual Studio is elevated, every child process (including your test harness) inherits that elevation, and therefore loses access to the per-user COM registry hive.
Microsoft’s Official Explanation
Applications that are run-elevated (whether manifested as RequireAdministrator or selected via Run as Administrator), as well as applications run from an Administrator account where UAC is disabled, cannot access any COM objects configured per-user.
(Source: MSDN – “Manifestation” and Stack Overflow discussion)
How to Fix or Avoid It
- Do not run Visual Studio or your test tool “as Administrator”.
- Verify which hive your CLSID resides in:
- If elevation is required (for example, when writing to Program Files), register your add-in for all users using:
regasm CardSync.dll /codebase /tlb /nologo /regfile:addin.reg
reg import addin.reg /reg:64Our Practical Advice
If your application interacts with SOLIDWORKS PDM’s COM APIs, never run it as Administrator unless the add-in is registered per-machine.
