CreateObject("Outlook.Application") not working on some computers with Office 365

Question

I have a client site running our Windows desktop software on a number of computers with 64 bit Office 365.

On most of their computers, our software is able to send email via Outlook.

However, two of their computers were upgraded to 365 last year (by their IT technician, not us), and both fail when they attempt to send email from our software.

Outlook works fine on its own, and so does our software - on both of these computers. But these two both can't send email from our software. (The other computers, which send email fine, are running exactly the same version of our software.)

When sending email, our software first checks for the existence of "Outlook.Application" or "Outlook.Application.*" keys in the Windows Registry to determine whether Outlook is installed. If not found, our program logic assumes that Outlook isn't installed, and attempts to use MAPI instead to send mail through another email client like Thunderbird (or through Outlook using MAPI). However, these computers both then crashed, because MAPI doesn't work on 64bit computers.

When I investigated these two problem computers, I found that they both had no "Outlook.Application" or "Outlook.Application.16" keys anywhere in their Windows Registry. I have never encountered this before. How and why would Office 365 install without creating these Registry entries? (I had just installed Office 365 on two computers here in my office, and they both had these keys and worked perfectly. And we have never encountered this before, at any of our other user sites.)

I discussed this with their IT technician. He did a complete uninstall of Office 365, and installed them from scratch, using the "on-line" install (that I had used on my computers - I sent him the URL to be sure). However, after this they were still unable to send email. When I investigated, I found that the Registry keys were still missing.

Their IT technician then asked me to export all the "Outlook.Application" and "Outlook.Application.16" keys in "Computer\HKEY_CLASSES_ROOT" and send them to him. He imported these on both those computers, but it did not fix the problem.

However, because the keys now existed, our software then attempted to send email directly through Outlook, using OLE. However it crashed on the line where it tried to create an Outlook Application Object:

loApp = CreateObject("Outlook.Application.16")

I built a special version with some extra test code in it. After failing to run the above line, it tried to run a line:

loApp = CreateObject("Outlook.Application")

This also failed - presumably because some Outlook application components have not been installed.

I did some fairly extensive Google searches for posts that might identify a solution, but found nothing that seemed to fit. A couple of posts suggested running an Office "Repair" from the installation tool.

I mentioned this to their technician, and he did this. Interestingly, when I then checked (using RegEdit), it had created a lot more "Outlook.Application" and "Outlook.Application.16" Registry keys. But our software still fails on both the "CreateObject" lines in that test version, and single "CreateObject" line in the normal version.

Both their technician and I are completely mystified (and now out of our depth in the Microsoft black arts of Office 365 installation and Windows).

Has anyone encountered this scenario before, and / or can suggest where we might go from here?

---

OK, the original post was getting a bit long, and I didn't want to clutter it with too much information. So here is some further info:

In answer to Eugene's questions:

1. Using RegEdit, I searched the entire Registry - for one of the computers that didn't work, and one that did (plus my own here, which also worked fine).
2. Their technician installed the latest 64 bit 365. If I understand correctly, the initial install was done from an ISO file. When that didn't work, he tried again using the "on line" install (which I had successfully used here). He used the "on line" install again for the "repair". I don't have current build numbers, but could obtain these later in the week if relevant. But they should be up-to-date.
3. No we can't reproduce the problem ourselves in-house, and have never seen it before at any other client site.
4. The site is running the same antivirus software on all computers (those that work, and those that don't). So I suspect that this won't be the cause.

Registry keys that match perfectly on those two computers are:

Computer\HKEY_CLASSES_ROOT\CLSID\{0006F03A-0000-0000-C000-000000000046}
Computer\HKEY_CLASSES_ROOT\Outlook.Application
Computer\HKEY_CLASSES_ROOT\Outlook.Application.16
Computer\HKEY_CLASSES_ROOT\WOW6432Node\CLSID\{0006F03A-0000-0000-C000-000000000046}

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{0006F03A-0000-0000-C000-000000000046}
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Outlook.Application
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Outlook.Application.16
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Classes\WOW6432Node\CLSID\{0006F03A-0000-0000-C000-000000000046}

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\AppVMachineRegistryStore\Integration\Backup\Software\RegisteredApplications
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\AppVMachineRegistryStore\Integration\Ownership\Software\Classes\Outlook.Application
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\AppVMachineRegistryStore\Integration\Ownership\Software\Classes\Outlook.Application.16
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\AppVMachineRegistryStore\Integration\Ownership\Software\RegisteredApplications

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY\MACHINE\Software\Classes\CLSID\{0006F03A-0000-0000-C000-000000000046}
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY\MACHINE\Software\Classes\Outlook.Application
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY\MACHINE\Software\Classes\Outlook.Application.16
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY\MACHINE\Software\Classes\Wow6432Node\CLSID\{0006F03A-0000-0000-C000-000000000046}\InprocServer32
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY\MACHINE\Software\RegisteredApplications
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\RegisteredApplications
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Classes\CLSID\{0006F03A-0000-0000-C000-000000000046}
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\RegisteredApplications

Something that may be significant: The Windows Registry on the computer that does not work has four extra keys (that are not in the computer that does work):

Computer\HKEY_CLASSES_ROOT\PackagedCom\ProgIdIndex\Outlook.Application
Computer\HKEY_CLASSES_ROOT\PackagedCom\ProgIdIndex\Outlook.Application\Microsoft.Office.Desktop.Outlook_16051.12325.20298.0_x86__8wekyb3d8bbwe
Computer\HKEY_CLASSES_ROOT\PackagedCom\ProgIdIndex\Outlook.Application.16
Computer\HKEY_CLASSES_ROOT\PackagedCom\ProgIdIndex\Outlook.Application.16\Microsoft.Office.Desktop.Outlook_16051.12325.20298.0_x86__8wekyb3d8bbwe

That computer (which doesn't work) also has a folder C:\ProgramData\Packages\Microsoft.Office.Desktop.Outlook_8wekyb3d8bbwe\ with 3 subfolders in it (with system generated names):

• The first (created in 2019) has a subfolder "\SystemAppData" which is empty.
• The other two (both with same date/time in early 2020) are completely empty (i.e. have no SystemAppData subfolder)

I wonder whether these keys may somehow be causing mischief. Early next week the technician and I plan to back up these keys, and then delete them.

Does anyone know what these keys are about? (I found a blog that may be relevant: https://blogs.windows.com/windowsdeveloper/2017/04/13/com-server-ole-document-support-desktop-bridge/ But then again, it may not be.)

Answer 1

Eureka!!! Deleting those extra legacy Registry keys did the trick.

Computer\HKEY_CLASSES_ROOT\PackagedCom\ProgIdIndex\Outlook.Application
Computer\HKEY_CLASSES_ROOT\PackagedCom\ProgIdIndex\Outlook.Application\Microsoft.Office.Desktop.Outlook_16051.12325.20298.0_x86__8wekyb3d8bbwe
Computer\HKEY_CLASSES_ROOT\PackagedCom\ProgIdIndex\Outlook.Application.16
Computer\HKEY_CLASSES_ROOT\PackagedCom\ProgIdIndex\Outlook.Application.16\Microsoft.Office.Desktop.Outlook_16051.12325.20298.0_x86__8wekyb3d8bbwe

Our software immediately was able to create Outlook Application objects, and send email via Outlook.

It seems that these extra keys dated back to an earlier attempted install by the client (before their current technician became involved). There were about 20 or so other 'Outlook*' keys in that part of the Registry with '8wekyb3d8bbwe' in their name. I subsequently deleted these too - on the the assumption that they were all legacy garbage. (As a rule, it is pretty dangerous to delete things you don't understand - but so far, so good. Although I am too chicken to delete a host of others in that location for Access, Excel, PowerPoint, Word with with '8wekyb3d8bbwe' in their name too.)

Answer 2

Keep in mind that older version of Windows Store Outlook ran in a sandbox and was not externally accessible. Uninstall it and reinstall again from the store - you will get a regular C2R version.

Answer 3

I had the same problem; it came from a brand-new computer!

What worked for me was the early binding. Select: Tools > Reference > Microsoft Outlook 16 object library.

Dim objOL As Outlook.Application
Set objOL = New Outlook.Application
Set objOL = Nothing

At the end, setting objOL to Nothing is crucial, otherwise the instance stays open, and it causes problems with Outlook.

Reference.

Answer 4

Tested and works with Office365. Install the Nuget Package Microsoft.Office.Interop.Outlook in your C# project. This project has a windows form with a Send Button.

       private void buttonSendEmail_Click(object sender, EventArgs e)
        {
         
            string[] attachFiles = new string[] {
                @"C:\temp\test.txt"
            };
            SendMailWithOutlook("Subject1", "This is an example.", "youremail@here.com", attachFiles, MailSendType.ShowModal);
        }

    
        public bool SendMailWithOutlook(string subject, string htmlBody, string recipients, string[] filePaths, MailSendType sendType)
        {
            try
            {
                // create the outlook application. see nuget package 
                Microsoft.Office.Interop.Outlook.Application outlookApp = new Microsoft.Office.Interop.Outlook.Application();
                if (outlookApp == null)
                    return false;

                // create a new mail item.
                Microsoft.Office.Interop.Outlook.MailItem mail = (Microsoft.Office.Interop.Outlook.MailItem)outlookApp.CreateItem(Microsoft.Office.Interop.Outlook.OlItemType.olMailItem);

                // set html body. 
                // add the body of the email
                mail.HTMLBody = htmlBody;

                //Add attachments.
                if (filePaths != null)
                {
                    foreach (string file in filePaths)
                    {
                        //attach the file
                        Microsoft.Office.Interop.Outlook.Attachment oAttach = mail.Attachments.Add(file);
                    }
                }

                mail.Subject = subject;
                mail.To = recipients;

                if (sendType == MailSendType.SendDirect)
                    mail.Send();
                else if (sendType == MailSendType.ShowModal)
                    mail.Display(true);
                else if (sendType == MailSendType.ShowModeless)
                    mail.Display(false);

                mail = null;
                outlookApp = null;
                return true;
            }
            catch (Exception ex)
            {
                Debug.WriteLine("Email send error: " + ex.Message);
                return false;
            }
        }

Answer 5

in one of our installations I found beside the correct references in HKLM also in HKCU\Software\classes\interface\ all the office keys {0006*} instantiated, but more or less empty, at least witout the typelib subkey references. Deleting all of these empty keys out of the HKCU path, wich Windows prefers instead the HKLM, solved the isue in that case.