我正在使用以下内容：
- Docker for Windows v20.10.11
- Docker 在 Windows 容器模式下运行
- mcr.microsoft.com/windows:1903 基本映像
- 安装在此基础映像之上的专有应用程序
每年我们都会使用公司软件的最新版本创建一个 Docker 映像。然而，今年的版本表现不同。主机安装运行良好。容器化安装在某些情况下无法运行。我可以将应用程序作为一个简单的 EXE 启动，例如使用 Docker 运行命令。该应用程序将启动并显示在“任务列表”中。但是我无法通过 COM API 启动应用程序，这是一个关键要求。该问题似乎与 COM 相关。通常我们可以为我们的软件创建 COM 对象，就像为任何其他应用程序一样。例如，IE 返回一个 COM 对象就好了：
为我们的应用程序创建这些对象在容器之外工作。但是在容器内，我们最新的安装给出了这个错误：
访问权限似乎没问题。我尝试了几个测试来证明这一点。首先，我可以将 MS Word 等其他软件安装到容器中并为此创建 COM 对象：
其次，我尝试在 PowerShell 中检索 + 修改应用程序的 DACL。
更改访问掩码或受托人可能会导致访问被拒绝错误：
这似乎也证实了默认情况下访问权限是好的。
接下来，我确保 COM 知道该应用程序。这似乎很好。运行此 PS 脚本时，我在主机和容器上得到相同的结果：
gci HKLM:\软件\类-ea 0| ? {$ .PSChildName -match '^\w+.\w+$' -and (gp "$($ .PSPath)\CLSID" -ea 0)} | ft PSChildName
该应用程序与其他应用程序一样显示。通过 AppID 查询时，详细信息显示良好。LocalServer32 指向正确的 EXE：
我尝试过的其他一些事情：
- 查询注册表项。安装我们的软件时创建了 7 个密钥。这些在主机安装和容器安装上看起来相同。
- 即使权限看起来不错，我仍然尝试以备用用户身份登录容器。例如“nt authority\system”是另一个虚拟管理员用户。我还更改了“builtin\administrator”用户的密码以启用该用户的登录。最后尝试完全创建新用户并将其添加到管理员用户组。所有这些尝试都有与“builtin\containeradministrator”（默认用户）相同的错误。
- 一个小的检查是确保 CMD.exe / Powershell 以 x64 运行：
- 使用 regsvr32 重新注册与安装关联的 DLL。
- 从不同的基础图像开始。https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/container-base-images。完整的 Win Server 基本映像在错误方面的行为方式完全相同。较小的 Win Server Core 基础映像问题更大，因为我什至无法使用该基础手动启动应用程序的 EXE。最后，我尝试了完整 Windows 基础映像的其他标签，例如 20H2 和 2004。这些标签的结果相同。Multiarch 或 x64 没有区别。
- 包括历史上需要使用 COM 使 MS Office 应用程序正常运行所需的“Ogawa hack”：https ://stackoverflow.com/a/1680214/7991646 。其他 COM 应用程序也可能需要它，但对我的特定安装没有帮助。
我还能做些什么来诊断或解决这个 COM 问题吗？