Migrating AddIn from Outlook 2007/2010 to Outlook 2013 -- Error loading OLE Server Type via CreateInstance RRS feed

  • Question

  • Hi,

    I successfully developed an Outlook AddIn for Outlook 2007/2010 a couple of years ago.

    Now the client is planning to upgrade to Outlook 2013 and they want to know if the AddIn will work after the upgrade.

    I have installed Outlook 2013 and Visual Studio 2013 and I have migrated the AddIn project successfully. I had to change the ribbon designer to use the Factory model and remove the TransparentSecurity attribute as documented elsewhere.

    The AddIn loads in Outlook 2013. I can access the PropertyPage for the AddIn via the Options dialog and view the Ribbon in any MailItem.

    The main function of this AddIn is to interface with an ERP database system. Connecting to the database is done via an OLE server dll. The Visual Studio solution includes a c# interop project to wrap the unmanaged code OLE server.

    When I attempt a connection to the database from within Outlook 2013 I get an error message.

    Checking the application error log I find the following message :

    Retrieving the COM class factory for component with CLSID {6BF01E15-8403-4796-A6C6-5F24C931EFC1} failed due to the following error: 800703e6 Invalid access to memory location. (Exception from HRESULT: 0x800703E6)

    The CLSID is correct for the OLE Server that I wish to access.

    Accessing this same OLE Server was working from Outlook 2007/2010.

    I have a simple host application which I can run to test the Interop assembly. This host application is able to load the OLE Server Type and create an instance successfully.

    Is there any chance that something inside the Outlook process has changed so that I need to use a different method when loading the OLE Server via CreateInstance()?

    I have the source code for the OLE Server. If I can compile it I should be able to add some more logging statements to try to pinpoint where the illegal memory access is occurring. The OLE Server relies on other 3rd party vendor database driver dlls so it is conceivable I am in some kind of "dll hell" where the correct versions are being loaded by the simple test host application but then Outlook 2013 is somehow loading different versions.

    Kind Regards,

    Kim Groves

    Regards, (Mr) Kim Groves

    Wednesday, April 16, 2014 3:23 AM

All replies

  • Hello Kim,

    Does your OLE server correspond to Outlook bitness? Are they both x64 or x86? OS?

    What is the target framework version of your add-in?

    Did you have a chance to create a new standalone application, set the target framework and target processor architecture, test it on the problematic PC?

    What code do you use for instantiating the OLE component?

    Wednesday, April 16, 2014 5:07 AM
  • The operating system is Windows Professional 8.1

    The AddIn needs to work with Windows Server 2012 for Remote Desktop access at the client site.

    I agree that the error message indicates a mis-match in the bitness of the host application and dll.

    Outlook 2013 is 32-bit (confirmed in Task Manager)

    All projects in Visual Studio 2013 are built for the x86 platform.

    The OLE Server dll comes from a 32-bit only compiler/linker. It works in the stand-alone x86 test application so it must be 32-bit also.

    The OLE Server dll loads other dll files which are also 32-bit. I have done some tinkering in ProcMon and it appears that the system is not getting as far as attempting to load these files before the invalid memory access error occurs.

    The add-in was working in .Net Framework 3.5 in Outlook 2007/2010. Moving the solution to Visual Studio 2013 I have changed the projects to .Net framework 4.5. I have just tried changing the solution to .Net framework 4 with the same result.

    I have not been able to make any changes to the OLE Server dll. However I have been able to confirm that it is already configured to produce a log file. When the OLE Server is loaded from a standalone application the log file is produced. The log file contains entries for when the server is loaded and unloaded as well as any errors occurred, for example, connecting to an invalid database path in the file system. However when the database connection is attempted from within Outlook, there is no log file produced. So the invalid memory access error occurs before the DLL has performed the basic initiation which opens the log file.

    The OLE Server is connected with this class (cut down for brevity). The "Activator.CreateInstance" line is throwing the invalid memory access error.

    public sealed class Connection : IDisposable {
    internal readonly Type _oleServerType;
    internal Object _oleServerInstance;
    internal static readonly Mutex _processMutex;
    public Connection(string connection) {
    if (connection == null)
    throw new ArgumentNullException("connection");
    if (connection.Length == 0)
    throw new ArgumentException("Connection path is blank.", "connection");
    _openTables = new Dictionary<string, Table>(StringComparer.OrdinalIgnoreCase);
    try {
    _oleServerType = Type.GetTypeFromProgID("Initech.Database.OLE");
    if (_oleServerType == null)
    throw new InitechConnectException(ErrorInitechConnectNotInstalled);
    try {
    _oleServerInstance = Activator.CreateInstance(_oleServerType);
    } catch (Exception ex) {
    Debug.WriteLine("Bitness " + (Environment.Is64BitProcess ? "64" : "32"));
    throw new InitechConnectException(ErrorInitechConnectFailedToInitalise, ex);
    bool bResult = Convert.ToBoolean(
    BindingFlags.InvokeMethod, null,
    _oleServerInstance, new object[] { connection },
    if (!bResult) {
    } else {
       _connectionOpen = true;
    } catch (InitechConnectException) {
    } catch (Exception ex) {
    throw new InitechConnectException("Error while invoking method 'Connect'.", ex);
    } finally {

    Regards, (Mr) Kim Groves

    Wednesday, April 16, 2014 8:00 AM
  • Kim,

    .Net framework 3.5 is based on the CLR 2.0, but .Net framework 4.0 uses the newer version. I'd recommend creating a standalone application with the .Net framework set to 4.0 or 4.5. I bielive the issue is not related to Outlook at all, suppose it comes from interopability.

    Wednesday, April 16, 2014 9:21 AM