Why “Class Not Registered” Happens When Loading SOLIDWORKS PDM Add-ins
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-inReason: 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 Our 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.
