Regsvr32.exe is a very simple program, it does very little to contribute to the registration itself. It simply uses LoadLibrary() to load the DLL whose name you passed as an argument, then GetProcAddress() to locate an exported function in the DLL. Which is DllRegisterServer(), if you use the /u option to unregister then it goes looking for DllUnregisterServer(). And calls the function, that's all.
DllRegisterServer was written by the component author. Exactly what it does is unpredictable, anything is possible. But there certainly is commonality, its intention is to write registry keys that the component needs to be usable from another program. You'll want to use SysInternals' Process Monitor, its trace shows exactly what is being done.
You already know about the HKLM\Software\Classes\CLSID\{guid} registry key. Very important, this is what powers the CoCreateInstance() call in a client program. Which creates an object in the server by simply specifying a number (the CLSID), the COM infrastructure ensures that the correct DLL is located and loaded, its DllGetClassObject() entrypoint is the factory function that supplies the object.
Core feature is that the client program doesn't have to know anything about the DLL itself, all it does is supply a number and it magically gets an object created. Which provides lots of flexibility in how the DLL is constructed with no dependency at all on the language in which the DLL source code was written. A feature that for example is taken advantage of when you write a [ComVisible] .NET component, a language like C# doesn't support exporting functions like DllGetClassObject(). Still works (a bit out of scope), the client is completely oblivious about the plumbing in the CLR that makes it work.
Almost any COM server's registration function writes these keys:
HKLM\Classes\Software\CLSID\{guid}\InprocServer32. Written for each coclass implemented by the server. The default value of this key contains the path to the DLL. Tells the COM plumbing which DLL to load to find the DllGetClassObject entrypoint. An out-of-process server (an EXE instead of a DLL) uses the LocalServer32 key instead.ThreadingModel value in CLSID. Specifies the threading requirements for a COM object. Very common is "Apartment", tells the COM infrastructure that the COM object is not thread-safe and that COM should take care of calling the functions inside the server in a thread-safe way. Other common values there are "Both" (the default for .NET components) and "Free", written for components that can handle calls from worker threads by themselves.HKLM\Classes\Software\Interface\{guid}\ProxyStubClsid32. Written for each interface implemented by a COM coclass. Required for any COM object that is not free-threaded, contains the CLSID of a COM object that knows how to marshal calls on the interface methods from one thread to another. A very common value you find there is {00020424-0000-0000-C000-000000000046}, the default marshaller that's included in Windows and knows how to marshal calls based on the content of the type library. A custom one is not unusual either, particularly for a COM server that was started by describing the interfaces in the IDL language. The proxy/stub for such a component can be auto-generated from the IDL.HKLM\Classes\Software\Interface\{guid}\Typelib. Present for servers that depend on the standard marshaller, the default value is the guid of the type library.HKLM\Classes\Software\Typelib\{guid}. Present for servers that depend on the standard marshaller, tells COM where to find the type library it needs.HLKM\Classes\Software\{progid}. Pretty common for servers that support late binding, allowing them to be used from a scripting language like Javascript or VBScript. Where {progid} is a friendly string to identify the component instead of a guid. Powers the CreateObject() runtime support function present in many languages. The CLSID subkey in this key tells the runtime which guid it should use to locate the CLSID key.
You may see many more keys being written. An ActiveX component writes a bunch of keys in CLSID to pass info to the host application and a programming tool like VB6. A server written in .NET adds several keys to help the CLR locate the assembly that contains the [ComVisible] component.
