COM activation on ARM64 hangs when PreferredServerBitness ≠ 0 — missing HRESULT for invalid configuration

[StefanS52u1]

Meaningful HRESULT for invalid PreferredServerBitness on ARM64
Problem
On ARM64 Windows, setting:
HKLM\Software\Classes\AppID{APPID}\PreferredServerBitness = 1 or 2 or 3

causes DCOM activation to hang until timeout, even though:

• the registry is valid
• the server is correctly registered
• permissions are correct
• the configuration is documented
  The SCM/DCOM subsystem does not return a specific error code.
  Instead, the caller receives a generic timeout (e.g., 0x8000401A, 0x80080005, or RPC timeout).
  This behavior makes diagnosis extremely difficult and leads to wasted engineering time.

🚀 Proposal: Add explicit HRESULT for invalid PreferredServerBitness on ARM64 to prevent silent DCOM activation timeouts

Summary

On Windows ARM64, setting:

HKLM\Software\Classes\AppID{APPID}\PreferredServerBitness = 1
or
HKLM\Software\Classes\AppID{APPID}\PreferredServerBitness = 2

causes DCOM activation to hang until timeout, even though the configuration is syntactically valid and documented.
The SCM/DCOM subsystem does not return a meaningful error code.
This makes diagnosis extremely difficult and leads to wasted engineering time.

A clear, immediate HRESULT would make the issue self‑diagnosing.

Problem Details

Current behavior

When PreferredServerBitness is set to 1 (prefer 32‑bit) or 2 (prefer 64‑bit) on an ARM64 system:

• DCOM activation never completes
• SCM attempts to resolve a server architecture that does not exist on ARM64
• The caller eventually receives a generic timeout such as:
  • 0x8000401A
  • 0x80080005
  • RPC timeout codes

There is no indication that the root cause is the invalid PreferredServerBitness value.

Why this is problematic

• The registry value is documented and valid on x86/x64.
• ARM64 has a different architecture model (ARM64 native + x64/x86 emulation).
• The failure mode is non‑diagnostic and time‑based.
• Developers lose hours or days diagnosing a configuration issue that could be detected instantly.

Expected behavior

If Windows detects:

• OS architecture = ARM64
• PreferredServerBitness is not 0

Then DCOM activation should fail fast with a clear HRESULT.

Suggested HRESULT

Any of the following would be acceptable:

• New code:
  0x89A10001 — ARM64_E_INVALID_PREFERRED_SERVER_BITNESS

• Or reuse an existing one:

  • REGDB_E_INVALIDVALUE
  • CO_E_SERVER_WRONG_SERVER_BITNESS
  • CO_E_SERVER_NOT_COMPATIBLE

Suggested event log entry

DCOM Activation Error:
PreferredServerBitness is not supported on ARM64.
Value must be 0. Activation aborted.

Rationale

• ARM64 does not support the x86/x64 bitness selection model.
• The SCM already validates other AppID fields; this is consistent.
• A clear HRESULT dramatically improves developer experience.
• Prevents silent hangs and reduces support load.
• Low‑risk change with high diagnostic value.

Reproduction Steps

1. On Windows ARM64, register any COM LocalServer with an AppID.
2. Set:
   PreferredServerBitness = 1
   or
   PreferredServerBitness = 2
3. Attempt COM activation from any client (ARM64, x64, or x86).
4. Observe:
   • SCM hangs
   • No server process starts
   • Caller receives a timeout after ~1 minute
   • No meaningful error is logged

Proposed Fix

Add a validation check in the SCM/DCOM activation path:

if (IsARM64() && PreferredServerBitness != 0)
{
return ARM64_E_INVALID_PREFERRED_SERVER_BITNESS;
}

This avoids the hang and provides immediate, actionable feedback.

Impact

• Saves developers significant time
• Makes ARM64 COM/DCOM behavior predictable
• Prevents silent failures
• Aligns with Windows’ diagnostic philosophy
• Zero impact on x86/x64 systems

[StefanS52u1]

I spent a lot of time to find this problem. by porting x86/x64 c++ code to arm64. A hr result hint would be nice. And i found no hints on the internet or within claude, chatgpt, etc.