none
Register 32bit out-of-process COM object in 64bit part on WOW64

    Question

  • A COM object implemented as 32bit local server (.exe) registering itself on 64bit windows gets redirected by WOW64 by default (http://msdn.microsoft.com/en-us/library/aa384253.aspx). When a client requests an instance, the system will normally search in both parts, unless explicit context flags are set (CLSCTX_ACTIVATE_##_BIT_SERVER). Therefore 64bit clients can instantiate 32bit COM objects and vice versa.

    In my case, the COM object is an add-in for MS Outlook. As of MS Outlook 2010 64bit it was just necessary to write the Outlook specific keys (HKLM\Software\Microsoft\Office\Outlook\Addins\<ProgID>) to the 64bit part of the registry, too. While searching for add-ins obviously includes the 64bit part only, instantiating them is presumably done via the system and works fine. As of Outlook 2013 64bit instantiating the COM object fails, if it is registered in the 32bit part only. When registering in the 64bit part too, it works.

    This leads to two questions:

    1.) Was this change between Outlook 2010 and 2013 made accidentally or intentionally? Are add-ins implemented as 32bit out-of-processes COM objects banned due to any reason?

    2.) May 32bit out-of-processes COM objects be registered in the 64bit part of the registry or must they be in the redirected 32bit part? Would it disregard a client's intent or is it a way to signal compatibilty with 64bit clients? Which COM objects should be registered in the 64bit part: Those implemented in 64bit or those that can be used by 64bit clients (even if they are implemented in 32bit)?

    Please note: I'm not talking about in-process servers (.dll) for which bitness of client and server must match. I'm not asking if it works (I know that it does). I'm not interested in tricks to make things work that are not intended to.

    Although my questions refer to MSO as client intantiating a COM object, the second one can be asked more generally: Think of an Application providing automation, implemented as 32bit exe. By default it's self registration gets redirected to Wow6432Node, but that's no problem. When a client requests an instance, it will be found by the system anyway (unless the client restricts to 64bit servers only). Therefore it's usually not necessary to register the 32bit exe to the 64bit part too, but is it wrong? What does it mean, what are the consequences? Are there any rules, recommendations, ...?

    • Edited by klammeraffe Friday, November 22, 2013 1:56 PM link added
    Monday, November 18, 2013 5:11 PM

All replies

  • Hi klammeraffe,

    Welcome here!

    This forum is for discussing how to develop app not for discussing why it is designed as this.

    If you still want to know the reason, please ask this question as suggestions on :

    http://connect.microsoft.com/

    Thanks for your understanding!

    Regards!


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Tuesday, November 19, 2013 7:44 AM
    Moderator
  • Thanks for your answer. I will ask there about the changed behaviour in Outlook 2013 64bit.

    But I think the second, more important part of my question about how to register 32bit out-of-proc COM objects correctly is a matter of how to develop applications.

    Tuesday, November 19, 2013 10:50 AM
  • Hi klammeraffe,

    Welcome back!

    bit application is run on top of an x64 version of Windows, the WOW64 emulator redirects the Program Files folder and calls to DLL files. But these aren't the only things that are redirected. The WOW64 emulator also redirects certain portions of the Windows registry. This article will show you how registry redirection works.

    I hope it is helpful!

    Regards!


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Wednesday, November 20, 2013 6:03 AM
    Moderator
  • Thanks for your answer, but it would have been more helpful if you read my question.

    I know about redirection and it's implications. My question is about explicitely disabling redirection and registering a 32bit out-of-process COM object (which can be used by 64bit applications) to the 64bit part of the registry. Is it ok or against any rules?

    Wednesday, November 20, 2013 8:58 AM
  • I am sorry for my careless.

    Have you tried this behavior without outlook? I am not sure if this is a common issue or a outlook issue.

    If all of them reproduce the issue, I think it should be the change along with the windows upgrade. And if so, register them on both 32bit and 64bit may be a appropriate way.

    If only outlook could reproduce this issue, then i think it is a outlook issue, maybe you could post this thread on

    http://social.technet.microsoft.com/Forums/office/en-US/home

    Thanks for your understanding!

    Regards!


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Thursday, November 21, 2013 2:35 AM
    Moderator
  • Thank you very much for your answer!

    Yes, I have tried to instantiate 32bit out-of-process COM objects which are registered within the redirected 32bit part (HKLM\Software\Classes\Wow6432Node\CLSID\{…}, respectively HKCU\… for user specific registration) from 64bit processes in several ways (JScript's ActiveXObject, WinAPI's CoCreateInstance). They all succeeded, as expected.

    Calling CoCreateInstance with the CLSCTX_ACTIVATE_64_BIT_SERVER flag fails, as expected. Even if the COM object is registered in the 64bit part too. Which means that CoCreateInstance presumably also checks the bitness of the executable.

    As I mentioned above, Outlook 2010 64bit does load the add-in as well. So it's definitely a change in Outlook 2013 64bit. First I thought it simply uses CoCreateInstance with the CLSCTX_ACTIVATE_64_BIT_SERVER flag, but that can't be true. It rather seems to use it's own lookup procedure which does not include the redirected 32bit part (KEY_WOW32_RES flag, Wow6432Node, etc.). I will ask about that in the forum you mentioned.

    From Windows' point of view, it seems to make no sense to register 32bit out-of-process COM objects in the 64bit part too, since CoCreateInstance searches both parts. Although former versions which had registry reflection (XP, Vista) synchronized HKLM\Software\Classes\CLSID for out-of-process objects (http://msdn.microsoft.com/en-us/library/aa384253.aspx).

    From Outlook's point of view, it seems to make no sense to ignore the 32bit part, since it works with add-ins which are implemented as 32bit out-of-process exe. But since it's behaviour changed between 2010 and 2013, there might be a good reason for it?

    Maybe interesting: Some but not all Office 2013 32bit applications register their out-of-process automation objects to both 32bit and 64bit parts (e.g. OneNote.Application in …\Classes\CLSID\{…}\LocalServer32 and …\Classes\Wow6432Node\CLSID\{…}\LocalServer32, both pointing to "c:\Program Files (x86)\Microsoft Office\Office15\ONENOTE.EXE"), but that might be a bug too?

    • Edited by klammeraffe Friday, November 22, 2013 1:59 PM
    Thursday, November 21, 2013 4:58 PM
  • Hi klammeraffe,

    Thanks for sharing your issue and your suggestions, as far as I know, there is no any microsoft official document which has mentioned it.

    I will report it internally and I advise you to post this on https://connect.microsoft.com/ as suggestions.

    I hope you could determine the behaviour about this next windows version. :)

    Regards!


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Friday, November 22, 2013 3:24 AM
    Moderator
  • I have report it with the info you shared above :)

    Regards!


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Monday, November 25, 2013 2:31 AM
    Moderator