Search

CAtlServiceModuleT::winmain() CoInitialize not called (800401f0) by Markus Stier

Closed
as Duplicate Help for as Duplicate

3
0
Sign in
 to vote
Type: Bug
ID: 582774
Opened: 8/3/2010 12:31:03 AM
Access Restriction: Public
1
Workaround(s)
2
User(s) can reproduce this bug
I've implemented a Windows service using ATL based on CAtlServiceModuleT. Works fine if installed as service (MyService /service). If I register MyService as localServer (MyService /regserver) CoInitialize is not called in winmain().

The same code worked for VS2005.

It turns out that InitializeCom() has been moved from the constructor of CAtlExeModuleT (which was called from CAtlServiceModuleT) to CAtlExeModuleT::winmain(). CAtlServiceModuleT::winmain does not call InitializeCom which leads to HRESULT 800401f0.
Details (expand)

Visual Studio/Silverlight/Tooling version

Visual Studio 2010

What category (if any) best represents this feedback?

 

Steps to reproduce

Create an ATL based Windows service project (MyService).
Add an arbitrary COM object to the service (MyObject).
Create a COM client which creates an instance of MyObject.
Build service and client.
Install the service (MyService /service)
Start the client, confirm that everything works as expected.
Uninstall the service (MyService /unregserver)
Register the service as local server (MyService /regserver)
Start the client.
Server crashes with 0x800401f0, CoInitialize not called



Product Language

German

Operating System

Windows Vista

Operating System Language

German

Actual results

0x800401f0

Expected results

S_OK :)
File Attachments
0 attachments
Sign in to post a comment.
Posted by James Harris-TriPerta on 4/5/2012 at 10:30 AM
I have Visual Studio 2010 with Service Pack 1 and the problem still exists. Works fine if run as a service but not if running as local for debugging. What is the fix ?
Posted by Luke727 on 5/24/2011 at 1:04 PM
Just ran into this problem; yikes. Would be nice to have a followup on if there is an official fix or what the original bug was.
Posted by Roman Ryltsov on 5/11/2011 at 2:51 AM
It's obviolsuly a breaking change as compared to previous versions of ATL. I see it is marked as duplicate, can you provide more information on its being duplicate to what exactly? Is there already a solution from MS for it, where exactly we should be putting those missing InitializeCom/UninitializeCom calls?
Posted by Microsoft on 8/3/2010 at 7:52 PM
Thanks for your feedback. We are routing this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.
Sign in to post a workaround.
Posted by Roman Ryltsov on 5/11/2011 at 3:30 AM
OK, this is what I did so far to make thing work. In atlbase.h, in CAtlServiceModuleT::Start the line with pT->Run is replaced with the following fragment:

* * *

        #pragma region Run wrapped by InitializeCom/UninitializeCom
        // FIX: See http://connect.microsoft.com/VisualStudio/feedback/details/582774/catlservicemodulet-winmain-coinitialize-not-called-800401f0
#ifndef _ATL_NO_COM_SUPPORT
        HRESULT hr = E_FAIL;
        hr = T::InitializeCom();
        if (FAILED(hr))
        {
            // Ignore RPC_E_CHANGED_MODE if CLR is loaded. Error is due to CLR initializing
            // COM and InitializeCOM trying to initialize COM with different flags.
            if (hr != RPC_E_CHANGED_MODE || GetModuleHandle(_T("Mscoree.dll")) == NULL)
                return hr;
        } else
            m_bComInitialized = true;
        m_status.dwWin32ExitCode = pT->Run(nShowCmd);
        if (m_bComInitialized)
            T::UninitializeCom();
#else
        m_status.dwWin32ExitCode = pT->Run(nShowCmd);
#endif
        #pragma endregion

* * *

I can't believe the bug survived through SP1.

© 2012 Microsoft Corporation. All rights reserved. Microsoft Connect Terms of Use | Trademarks | Privacy Statement