COMADMIN_E_REQUIRES_DIFFERENT_PLATFORM (0X80110449) Fix

Quick answer: Rebuild the COM+ component for the correct platform (x86 or x64), or if you're stuck with a pre-compiled DLL, run the 32-bit COM+ tools from %windir%\SysWOW64\ instead of System32.

Why this happens

You're seeing COMADMIN_E_REQUIRES_DIFFERENT_PLATFORM (0X80110449) when you try to install or configure a COM+ application—say, through Component Services or a script. The error message is blunt: "This operation is not enabled on this platform."

The real cause is almost always a bitness mismatch. COM+ applications are tied to either 32-bit or 64-bit mode. If you've compiled a COM DLL as 32-bit but you're running a 64-bit Windows Server (like Server 2019 or 2022), the 64-bit COM+ runtime won't touch it. Same thing in reverse: a native 64-bit component won't load on a 32-bit OS.

I've seen this most often when someone copies a legacy VB6 COM+ app from an old 32-bit Windows Server 2003 to a modern 64-bit box. The DLL registers fine with regsvr32, but Component Services throws the 0X80110449 when you try to create the application or import the component.

Fix steps

1. Identify the bitness of your COM+ component. Open a command prompt and run:
   

   dumpbin /headers "C:\Path\To\YourComponent.dll" | find "machine"

   
   Look for 14C (x86/32-bit) or 8664 (x64/64-bit). If you see 1C4, that's ARM64—rare but possible.
2. Check your OS architecture. Run:
   

   wmic os get OSArchitecture

   
   This will say "64-bit" or "32-bit." Match the component's bitness to the OS.
3. If the component is 32-bit on a 64-bit OS (most common):
   You have two choices. The clean fix: recompile the DLL as 64-bit in your development environment (e.g., in Visual Studio, set Platform Target to x64). The workaround: use the 32-bit COM+ administration tools. Close Component Services, then open:
• Run %windir%\SysWOW64\comexp.msc — this launches the 32-bit MMC snap-in.
• Create your COM+ application here. It will run under the 32-bit COM+ surrogate (dllhost.exe).
4. If the component is 64-bit on a 32-bit OS:
   This is almost impossible on modern hardware. You must recompile as 32-bit. There's no workaround.
5. Reboot after changing anything. After recompiling or switching tools, restart the COM+ system application and your app. Run net stop COMSysApp && net start COMSysApp from an admin prompt.

Alternative fixes

• Run the 32-bit version of regsvr32. Some components fail registration on 64-bit systems when you use the default regsvr32 (which is 64-bit). Try:
  

  %windir%\SysWOW64\regsvr32 "C:\Path\To\YourComponent.dll"

• Check for missing dependencies. The DLL might depend on a 32-bit runtime (like VC++ redistributable x86) that isn't installed. Run dependency walker (depends.exe or the modern DependenciesGui) to confirm.
• Create a COM+ application manually via script. Sometimes the GUI is cranky. Use PowerShell with the COMAdmin library:
  

  $comAdmin = New-Object -ComObject COMAdmin.COMAdminCatalog
  $applications = $comAdmin.GetCollection("Applications")
  $app = $applications.Add()
  $app.Value("Name") = "MyApp"
  $app.Value("ApplicationAccessChecksEnabled") = $false
  $applications.SaveChanges()
  $components = $applications.GetCollection("Components", $app.Key)
  $comp = $components.Add()
  $comp.Value("CLSID") = "{your-clsid-here}"
  $components.SaveChanges()

  
  Note: the CLSID must match the 32-bit component's registered CLSID in the 32-bit registry hive (HKCR\Wow6432Node\CLSID).

Prevention tip

Before deploying any COM+ component to a server, compile a build for each target platform (x86 and x64) side by side. Label your DLLs clearly—MyComponent_x86.dll and MyComponent_x64.dll. When you drop a new build on a 64-bit server, use the x64 version. This error is entirely avoidable with a little planning. Also, always test on a staging server that matches the production OS architecture.