TLDR; Check your COM DLL for it’s specific dependency graph and ensure those specific dependencies are installed within the container FIRST. Likely will be different for each scenario, but we can monitor regsvr32 exit code to get some general error details.
Lots of info in this thread. I also spent some time sifting through this and other resources, as well as testing several different processing steps and comparing results to an actual live VM vs a windows docker container. Ultimately my findings are as follows:
Findings
regsvr32 /s {PATH} is the correct command and generally functions fine out of the box, however it doesn’t ever appear to return us any error messages or logs which is really what we need to determine the actual problem here. Turns out if you monitor the exit code of the program, you can then compare it to regsvr32’s known error code list (easy enough to find on google), which would more or less correlate to the error message that would actually be shown on the UI. So you could run this powershell script:
$proc = Start-Process "regsvr32.exe" -ArgumentList "/s","`"$dllPath`"" -Wait -PassThru; # double-quote wrapping important
$proc.ExitCode
And compare the exit code to this list:
#define FAIL_ARGS 1 // Invalid Argument
#define FAIL_OLE 2 // OleInitialize Failed
#define FAIL_LOAD 3 // LoadLibrary Failed
#define FAIL_ENTRY 4 // GetProcAddress failed
#define FAIL_REG 5 // DllRegisterServer or DllUnregisterServer failed.
I would imagine most of us where hitting the exit code #3 FAIL_LOAD: LoadLibrary Failed, which likely means a dependency that our COM DLL relies on is NOT present, as this SO post eludes to. More than likely, if you spin up a bare server VM and tried to load the same COM DLL, w/o installing anything else on the server, you’d probably see the same set of errors.
Put simply, all of our COM DLL’s are going to have their own graph of dependencies, some that we don’t even realize they have until we try to load them on a bare bones machine, like docker containers. For some of us, that might be the Visual Basic runtime (vbrun60sp6.exe, which is what seems to install msvbvm60.dll), for others it might be the various Visual C++ Redistributable Packages (my situation).
In my case, as suggested from the previous SO post, I used the depends.exe (outdated, but check out this repo that maintains and improves a version of it w/ a GUI) to check the dependency graph and found a reference to MSVCP120.dll and MSVCR120.dll that were non-existent in my windows docker container (mcr.microsoft.com/windows/servercore:ltsc2022), which correlated to Visual C++ Redistributable Packages for Visual Studio 2013.What made it even more obvious for what I was missing was that when I ran the depends tool on a bare bones VM that had similar issues to my docker container and was able to rectify the issue in the same way on each.
Now when I run regsvr32, the exit code is 0, as expected. If I check the registry, I can verify the component is installed:
Test-Path "Registry::HKEY_CLASSES_ROOT\CLSID\{COMPONENT_GUID}"
Test-Path "Registry::HKEY_CLASSES_ROOT\WOW6432Node\Interface\{COMPONENT_INTERFACE_GUID}"`
Worth noting that I never needed to touch the VB Runtime or manually copy in that msvbvm60.dll, since it wasn’t relevant to my specific COM DLL’s dependency graph.
Hopefully this post helps cut down someone elses startup time (I’m on day two)…