32 and 64 bit interoperability on 64-bit Windows

calendar_today Asked Jan 25, 2011
thumb_up 5 upvotes
history Updated April 14, 2026

Direct Answer

It is explained quite well in the MSDN Library docs for CLSCTX. Lots of rules, the default behavior is: If neither the client nor the server specifies a preference, then: If the…. This is an advisory response with reference links, ranked #64th of 95 by community upvote score, from 2011.


The Problem (Q-score 8, ranked #64th of 95 in the VBA Core archive)

The scenario as originally posted in 2011

Is there a good thorough authoritative reference that discusses interoperability between 32-bit and 64-bit processes? Based on googling I have deduced that:

  1. A 32-bit DLL can only reside in a 32-bit process, and a 64-bit DLL only in a 64-bit process.
  2. 32 and 64-bit processes can only communicate using loosely coupled message systems, such as network communications, which means they can communicate using COM/DCOM.
  3. 32 and 64-bit COM components have different registry entries. A component is typically only registered in one of the two and typically only seen in one of the two worlds.
  4. A 32-bit process can only create something registered as a 64-bit COM component if it uses CoCreateInstance with the 64-bit invocation flag, or (and I am guessing on this one, is it possible?) if the 64-bit component is somehow registered in the 32-bit registry but under the hood is still created as an out of process 64-bit process, or if there is a 32-bit shell COM component which creates the 64-bit component and then redirects calls to it?

This suggests that:
1. A 32-bit application can not use GetObject to get hold of a 64-bit version of Excel that is running? Or can it? How is the running object table (ROT) impacted by 32 versus 64-bit issue? Can a 32-bit process create an instance of Excel if only a 64-bit version of Office is installed? I would think the answer would be “no” unless the 32-bit process uses the 64-bit flag in its CoCreateInstance call, or if Excel somehow registered itself in the 32-bit world as well?

Does Microsoft automatically do anything like having CoCreateInstance from a 32-bit process check the 64-bit registry and try to create an out of process 64-bit component if there is none registered in the 32-bit registry? I have seen some release notes from 64-bit Office where Microsoft warns about access from 32-bit applications to 64-bit Excel not working, yet I know of one instance where it seemed to just work.

Is there a good technical factual reference for this?

Why community consensus is tight on this one

Across 95 VBA Core entries in the archive, the accepted answer here holds niche answer (below median) status — meaning voters are unusually aligned on the right fix.


The Verified Solution — niche answer (below median) (+5)

Advisory answer — community consensus with reference links

Note: the verified answer below is a reference / advisory response rather than a copy-ready snippet.

It is explained quite well in the MSDN Library docs for CLSCTX. Lots of rules, the default behavior is:

If neither the client nor the server
specifies a preference, then:

  • If the computer that hosts the server is running Windows XP or
    Windows Server 2003 without Service
    Pack 1 (SP1) or later installed, then
    COM will prefer a 64-bit version of
    the server if available; otherwise it
    will activate a 32-bit version of the
    server.

  • If the computer that hosts the server is running Windows Server 2003
    with SP1 or later installed, then COM
    will try to match the server
    architecture to the client
    architecture. In other words, for a
    32-bit client, COM will activate a
    32-bit server if available; otherwise
    it will activate a 64-bit version of
    the server. For a 64-bit client, COM
    will activate a 64-bit server if
    available; otherwise it will activate
    a 32-bit server.

Check the MSDN article if you want to override this behavior.


When to Use It — vintage (14+ years old, pre-2013)

Ranked #64th in its category — specialized fit

This pattern sits in the 96% tail relative to the top answer. Reach for it when your scenario closely matches the question title; otherwise browse the VBA Core archive for a higher-consensus alternative.

What changed between 2011 and 2026

The answer is 15 years old. The VBA Core object model has been stable across Office 2013, 2016, 2019, 2021, 365, and 2024/2026 LTSC, so the pattern still compiles. Changes that might affect you: 64-bit API declarations (use PtrSafe), blocked macros in downloaded files (Mark-of-the-Web), and the shift toward Office Scripts for web-first workflows.

help
Frequently Asked Questions

This is a below-median answer — when does it still fit?
expand_more

Answer score +5 vs the VBA Core archive median ~4; this entry is niche. The score plus 8 supporting upvotes on the question itself (+8) means the asker and 4 subsequent voters all validated the approach.

This answer links out — what are the reference links worth following?
expand_more

Read the first external link for the canonical reference, then search this archive for a top-10 entry in the same category — advisory answers are best paired with a ranked code snippet to close the loop.

This answer is 15 years old. Is it still relevant in 2026?
expand_more

Published 2011, which is 15 year(s) before today’s Office 2026 build. The VBA Core object model has had no breaking changes in that window. Three things to re-test: (1) blocked macros on downloaded files (Mark-of-the-Web), (2) 64-bit API declarations (PtrSafe, LongPtr), (3) any shift toward Office Scripts for web scenarios.

Which VBA Core pattern ranks just above this one at #63?
expand_more

The pattern one rank above is “Can I compile VBA on workbook open?”. If your use case overlaps, compare both before committing.

Data source: Community-verified Q&A snapshot. Q-score 8, Answer-score 5, original post 2011, ranked #64th of 95 in the VBA Core archive. Last regenerated April 14, 2026.

ms-office