none
Problem with an ATL C++ Outlook Addin RRS feed

  • Question

  • Hi,
    I have made an ATL C++ Outlook Addin.
    Now,if I start Outlook my addin(release version) fails with a win32 exception in the OnConnection method.
    If I start debugging with visual studio, it runs outlook and my addin (release version) runs perfectly.
    In the OnConnection method I create a second Com object with cocreateinstance,
    that 2nd object uses the api rest casablanca and the c++ standard library and ATL.

    My first COM object uses ATL and win32 libraries.

    I have build a static version of the library casablanca and it is linked statically with my addin.
    The standards libraries (C and C++) are linked static inside  casablanca.
    Openssl and boost are linked static inside casablanca too.
    I suppose that I have a library problem,what else?
    I don't know why my addin(release version) runs well if  I launch outlook with the start debugging of visual studio and doesn't run if I start directly Outlook.

    Has someone an idea ?


     
    Wednesday, September 30, 2015 10:38 AM

Answers

  • Thank you very much RLWA32, I didn't know ALTTRACE and the debugview, I will look at this.

    I think my problem is solved : I have made again my outlook addin with only one COM object ( I have put the methods of the second COM object  in the first COM object and the addin is ok now and now I don't need anymore to run Outlook as an administrator. I was not sure before to test it that it will be ok, because the first COM object is an STA object and casablanca uses tasks (secondary threads) but it is ok....

    • Marked as answer by stephane_l2 Monday, October 5, 2015 7:41 AM
    Monday, October 5, 2015 7:40 AM

All replies

  • Can you comment out the CoCreateInstance call that instantiates the 2nd COM object in OnConnection to see if the exception is still generated within that function?

    When you run Outlook outside of a debugger and the exception occurs can you attach the debugger at that time to see the source of the exception?

    Which Win32 exception occurred?

    Wednesday, September 30, 2015 11:00 AM
  • Thank you RLWA32, I have commented out the cocreateinstance and it runs well.

    so It is my second COM object that causes the problem .my second COM object uses the api rest casablanca and the C++ standard library.I think that I have a problem with one these two libraries.perhaps must I try to link the addin  with msvcprt.lib instead of libpcmt.lib ? I have made a static build of casablanca because I had already the problem with a dynamic build.

    Wednesday, September 30, 2015 12:06 PM
  • I think I could try again too with casablanca as a dll and linked dynamically with boost (I think it's the default)...
    Wednesday, September 30, 2015 12:28 PM
  • if you are using the multiple copies of the Standard C++ libraries in your project because it is statically linked with casablanca, openssl and your addin then you need to be very careful about dynamically allocating and freeing memory.  Each statically linked library has it's own heap manager and they are all independent of one another.  Using the DLL version for the addin while keeping the static versions for casablanca and openssl will not alleviate this issue.

    Did you try building the openssl and casablance libraries in debug mode to see if you can get any greater visibility into the problem with the 2nd COM object?

    Wednesday, September 30, 2015 12:35 PM
  • I have another question about this problem. are the librairies win32 64 bits in windows\syswow64 or in windows\system32 on a 64 bits windows ?

    because it's a 64 bits version of the plugin and I was thinking that I hadn't put the dll of boost and casablanca in the system directory when I had tried before the addin with the casablanca dll (linked dynamically)

    Wednesday, September 30, 2015 12:50 PM
  • openssl and zlib are statically linked inside casablanca so  I think there isn't any problem with them.Boost can be linked dynamically or perhaps statically inside casablanca and casablanca is per default  a dll.
    Wednesday, September 30, 2015 1:00 PM
  • I will try again to use the debug version of my plugin with the debug version of casablanca (but it's not a static version. )
    Wednesday, September 30, 2015 1:02 PM
  • The sysWOW64 folder contains the 32 bit compatibility files on a 64 bit system.

    If you are running a 64 bit version of Outlook then your addin and all of the DLLs that it might load should also be 64 bit.

    Wednesday, September 30, 2015 1:18 PM
  • Stephane,

    It looks like the issue is not related to Outlook at all. Try to run a sample application with the same class libraries/references used under the debugger or not and see the result. It should confirm that is a C++ related issue. If so, I'd recommend asking Visual C++ specific questions on the corresponding forum or Visual C++ MFC and ATL forums.

    Wednesday, September 30, 2015 1:18 PM
  • I have two news and the last shows it is a problem related with outlook too: if  I run outlook with start without debugging,my addins runs well.and the second news is that if I don't load the plugin at the starting of outlook and if I run it with start an addin in outlook the addin runs well and is ok.(I have tested it with casablanca linked dynamic and with the addin and the dlls in the directory ADDINS of Outlook).

    so now I will test to move the cocreateinstance of the second com object in OnStartupComplete...
    • Edited by stephane_l2 Thursday, October 1, 2015 3:48 PM
    Thursday, October 1, 2015 3:44 PM
  • I don't see any exlanation why the issue is related to Outlook. Have you ever tried a regular application with the same libraries used?

    Most probably you run Visual Studio as an administrator and Outlook not. If you start without debugging the application is run without admin privileges, but when you start debugging from VS it will be run under administrator. Hope it makes sense.

    Thursday, October 1, 2015 4:03 PM
  • it is not the casablanca library , I think.but you are right if I run outlook as administrator the addin is ok...I think it is because of the cocreateinstance that creates a second COM object.I don't know if I can execute cocreateinstance with administrator privileges?

    otherwise i must perhaps make my addin again with only one COM object but I don't know if it will be ok to run the secondary threads of casablanca in one STA COM object....

    Thursday, October 1, 2015 5:48 PM
  • yes it's that: cocreateinstance in a dll need administrator rights... I have found that:

    http://blogs.msdn.com/b/vistacompatteam/archive/2006/09/28/cocreateinstanceasadmin-or-createelevatedcomobject-sample.aspx

    and that :

    https://msdn.microsoft.com/en-us/library/windows/desktop/ms679687%28v=vs.85%29.aspx

    I will try them tomorrow.....

    Thursday, October 1, 2015 7:14 PM
  • I'm not familiar with casablanca, but I would think carefully about why you need elevated privileges in order to create your 2nd com object.  Does the casablanca documentation confirm this?
    Thursday, October 1, 2015 8:17 PM
  • Stephane,

    As you may see the issue is not related to Outlook. I believe you can reproduce it with a standalone application.

    Thursday, October 1, 2015 10:55 PM
  • yes it is an ATL COM problem.....
    Friday, October 2, 2015 7:35 AM
  • I'd recommend asking Visual C++ specific questions on the corresponding forum or Visual C++ MFC and ATL.
    Friday, October 2, 2015 7:54 AM
  • @RLWA32, it is not casablanca that need administrator rights.

    it's when you use cocreateinstance (to create a COM object ) in a dll......it is an ATL Problem.

    I have just tried to put elevation rights in the registry for my first object but it seems not to be OK.SO i am loooking at the documentation of cocreatinstanceasadmin and the elevation moniker.it is just an ATL COM problem and not a problem with casablanca as I believed in the beginning...(casablanca is even not used in the constructor and the finalconstruct of my second COM object)

    Friday, October 2, 2015 9:16 AM
  • The links you posted refer to how to elevate rights. 

    Can you provide a link to Microsoft documentation of a requirement that calls to CoCreatInstance form within a DLL must be elevated?

    Friday, October 2, 2015 10:26 AM
  • I use cocreateinstance with CLSCTX_INPROC_SERVER.
    Friday, October 2, 2015 1:14 PM
  • CLSCTX_INPROC_SERVER

    The code that creates and manages objects of this class is a DLL that runs in the same process as the caller of the function specifying the class context.

    I don't see how that requires privilege elevation.
    Friday, October 2, 2015 1:23 PM
  • I have commented out the whole code that use casablanca so my 2nd COM object contains fast nothing, and I have the same problem...so it is not casablanca that causes that.

    it is the cocreateinstance that causes this problem, and I see perhaps a solution with impersonation and setThreadToken, but I have found an example where they lower the privilege and I must make the opposite....

    Friday, October 2, 2015 2:19 PM
  • BTW, you never mentioned which Win32 Exception was received in OnConnection?

    Is there any information in the event logs from CoCreateInstance failures?

    You might find some helpful information here https://msdn.microsoft.com/en-us/library/windows/desktop/ms687309%28v=vs.85%29.aspx
    • Edited by RLWA32 Friday, October 2, 2015 2:34 PM added link
    Friday, October 2, 2015 2:27 PM
  • here is the code in the OnCOnnection:

    HRESULT hr = CoCreateInstance(CLSID_WesendComm, NULL, CLSCTX_INPROC_SERVER , IID_IWesendComm, (void**)&m_pWComm);
    		
    CComPtr<CWesendComm> pwc;
    
    
    if ((hr==S_OK)&&(m_pWComm->QueryInterface(IID_IWesendComm, (void**)&pwc) == S_OK))
    		{
    			pwc->FinalConstruct();
    		}
    		else
    		{
    		
    			return E_ABORT;
    		}
    
    AppEvents::DispEventAdvise((IDispatch*)m_app, &__uuidof(Outlook::ApplicationEvents));
    return S_OK;

    I don't see any log for cocreateinstance in the event viewer although I have put 1 to activationfailurelogginglevel

    here are the events logs:

    outlook:

    Erreur lors de l’exécution de complément. Outlook s’est arrêté pendant le rappel « OnConnection » de l’interface « IDTExtensibility2 » tout en appelant le complément « Wesend ».

    - <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
    - <System>
      <Provider Name="Outlook" />
      <EventID Qualifiers="49152">1000</EventID>
      <Level>2</Level>
      <Task>0</Task>
      <Keywords>0x80000000000000</Keywords>
      <TimeCreated SystemTime="2015-10-02T15:01:54.000000000Z" />
      <EventRecordID>124718</EventRecordID>
      <Channel>Application</Channel>
      <Computer>stephane-PC.edipub.com</Computer>
      <Security />
      </System>
    - <EventData>
      <Data>OnConnection</Data>
      <Data>IDTExtensibility2</Data>
      <Data>Wesend</Data>
      </EventData>

     </Event>

    application :

    Nom de l’application défaillante OUTLOOK.EXE, version : 15.0.4753.1003, horodatage : 0x55f26713
    Nom du module défaillant : ntdll.dll, version : 6.1.7601.18798, horodatage : 0x5507b864
    Code d’exception : 0xc0000005
    Décalage d’erreur : 0x000000000005105c
    ID du processus défaillant : 0x1680
    Heure de début de l’application défaillante : 0x01d0fd2345cf1256
    Chemin d’accès de l’application défaillante : C:\Program Files\Microsoft Office 15\root\office15\OUTLOOK.EXE
    Chemin d’accès du module défaillant: C:\Windows\SYSTEM32\ntdll.dll

    - <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
    - <System>
      <Provider Name="Application Error" />
      <EventID Qualifiers="0">1000</EventID>
      <Level>2</Level>
      <Task>100</Task>
      <Keywords>0x80000000000000</Keywords>
      <TimeCreated SystemTime="2015-10-02T15:01:55.000000000Z" />
      <EventRecordID>124719</EventRecordID>
      <Channel>Application</Channel>
      <Computer>stephane-PC.edipub.com</Computer>
      <Security />
      </System>
    - <EventData>
      <Data>OUTLOOK.EXE</Data>
      <Data>15.0.4753.1003</Data>
      <Data>55f26713</Data>
      <Data>ntdll.dll</Data>
      <Data>6.1.7601.18798</Data>
      <Data>5507b864</Data>
      <Data>c0000005</Data>
      <Data>000000000005105c</Data>
      <Data>1680</Data>
      <Data>01d0fd2345cf1256</Data>
      <Data>C:\Program Files\Microsoft Office 15\root\office15\OUTLOOK.EXE</Data>
      <Data>C:\Windows\SYSTEM32\ntdll.dll</Data>
      <Data>84a2f665-6916-11e5-9c6f-3417ebdc25bd</Data>
      </EventData>

     </Event>

    ....


    • Edited by stephane_l2 Friday, October 2, 2015 3:10 PM
    Friday, October 2, 2015 3:09 PM
  • here is the code in the OnCOnnection:

    HRESULT hr = CoCreateInstance(CLSID_WesendComm, NULL, CLSCTX_INPROC_SERVER , IID_IWesendComm, (void**)&m_pWComm);
    		
    CComPtr<CWesendComm> pwc;
    
    
    if ((hr==S_OK)&&(m_pWComm->QueryInterface(IID_IWesendComm, (void**)&pwc) == S_OK))
    		{
    			pwc->FinalConstruct();
    		}
    		else
    		{
    		
    			return E_ABORT;
    		}
    
    AppEvents::DispEventAdvise((IDispatch*)m_app, &__uuidof(Outlook::ApplicationEvents));
    return S_OK;
    Code d’exception : 0xc0000005

    You are receiving an access violation which is probably due to calling through a NULL pointer.  I think if it was a privilege issue you would be receiving a COM error code in the HRESULT returned by CoCreateInstance;

    Two thoughts --

    Check the m_pWComm pointer after the call to CoCreateInstance to make sure it is not NULL.  Is it properly declared for the IID_WesendComm interface?

    Check the pwc pointer after the QueryInterface call to make sure it is not null.

    Why are you calling pwc>FinalConstruct()?

    Friday, October 2, 2015 3:27 PM
  •  I am calling Finalconstruct because the object is uninitialized after a call to cocreateinstance and I can allocate my members variable in Finalconstruct

    but how do you explain that the addin is ok when  I run outlook as administrator but not if not as administrator and is ok too(but without functionalities) when I comment out the cocreatinstance ?

    otherwise I will check the both pointers.....

    Friday, October 2, 2015 3:53 PM
  • It's also possible that there is a problem within the FinalConstruct call.  That's another place to look for a possible access violation.


    Another thing to try is to use some ATLTRACE statements inside the OnConnection code and within the COM objects also to display information, HRESULTs, pointer values and otherwise give a visual indication of how the code is executing and what is happening.  You don't have to run this under a debugger to see the ATLTRACE output -- use the DebugView utility from Microsoft.  It enables you to see Debug output without running your program under a debugger.  You can get it at DebugView

    • Edited by RLWA32 Friday, October 2, 2015 5:59 PM
    Friday, October 2, 2015 4:25 PM
  • Thank you very much RLWA32, I didn't know ALTTRACE and the debugview, I will look at this.

    I think my problem is solved : I have made again my outlook addin with only one COM object ( I have put the methods of the second COM object  in the first COM object and the addin is ok now and now I don't need anymore to run Outlook as an administrator. I was not sure before to test it that it will be ok, because the first COM object is an STA object and casablanca uses tasks (secondary threads) but it is ok....

    • Marked as answer by stephane_l2 Monday, October 5, 2015 7:41 AM
    Monday, October 5, 2015 7:40 AM
  • I'm glad that you managed to get it all working.  From an Outlook perspective, there shouldn't be a problem using secondary threads in your addin as long as all calls to the Outlook Object Model are made from the primary thread.

    Monday, October 5, 2015 10:22 AM