MMC 2.0自动化对象模型能否在64位Windows环境中启动MMC32？

这个问题我之前帮好几个开发者排查过，确实挺闹心的——你遇到的情况其实是MMC 2.0自动化对象模型的一个隐性限制，官方文档里根本没明说，但实际跑起来就是这么回事儿。

首先明确给你答案：通过MMC 2.0自动化对象模型，确实没办法直接实例化32位的MMC Application。哪怕你的调用程序是编译为x86的32位进程，在64位Windows上，COM的跨位数调用机制会默认启动64位的MMC COM服务器，导致你拿到的始终是MMC64的实例，自然加载不了依赖32位管理单元的.msc文件，就会出现“MMC无法创建管理单元”的提示。

那该怎么解决你的问题呢？其实换个思路就行——直接绕开自动化对象模型，手动启动32位的MMC进程：

64位Windows的C:\Windows\SysWOW64文件夹里放的就是32位的系统程序，其中就有mmc.exe（也就是你说的MMC32）。你可以在C#代码里用Process.Start直接启动它，同时带上你的.msc文件路径和-32参数，示例代码如下：

using System.Diagnostics;

// 启动32位MMC并加载指定的控制台文件
var processStartInfo = new ProcessStartInfo
{
    FileName = @"C:\Windows\SysWOW64\mmc.exe",
    Arguments = @"C:\你的文件路径\目标文件.msc -32",
    UseShellExecute = false
};
Process.Start(processStartInfo);

这种方式和你之前在命令行里操作的逻辑完全一致，能直接打开需要32位管理单元的.msc文件，而且不需要依赖坑人的自动化对象模型。

至于为什么自动化对象模型会有这个限制？主要是因为MMC的自动化API根本没提供选择启动位数的接口，而且系统层面的COM注册也没有为32位MMC单独提供可调用的自动化对象CLSID，所以不管你怎么折腾，用自动化模型拿到的都是64位实例。

内容来源于stack exchange