Outlook error message 5 when using outlook object model to send emails

Question

We are using VB and accessing Outlook object model from our application to send emails.  We receive the following error message when the Send method of the Outlook email object is called:

Please note that our email functionality is wrapped inside a DLL.  Strangely, if we copy and paste the same code into an executable, we noticed that it works fine.  The process only fails when it is done from within a DLL.  

This started to happen in Outlook 2019 since we upgraded it to version 16.0.13929.20206.  We have updated Outlook to the latest version  16.0.14026.20202 today but nothing has changed and the process still fails.  We are using 32-bit version of Outlook.

Even a simple code of:

1)  Create email object.
2)  Set the body to "test"
3)  Set subject to "test"
4)  Set the recipient email address and resolve
5)  Set sent on behalf of address
6)  Send the email

Fails with the same error message from within our DLL.  We have no idea why the same simple code works from within an executable but fails when it is wrapped inside a DLL.

We also inactivated any add-ins that we could and that did not help.  We also started Outlook in safe mode and that did not help either.

We would greatly appreciate any help. 

Answer 1

Hi @JeffYang-MSFT

Thank you.

I truly am amazed at Microsoft. I posted my question on anther outlook related forum and I was directed to post my question here. If Microsoft does not know what forum is the most appropriate for a question, God help all of us.

Anyway, I have debugged our code a lot deeper and it seems like Microsoft has made changes to their Outlook object model behaviour. In previous versions of Outlook, versions prior to 16.0.13929.20206, accessing mail item's inspector using MailItem.GetInspector method was perfectly fine and was not causing any errors whatsoever anywhere around our code. However, they have, for some God unknown reason, changed their Outlook object model so that sending emails after accessing the inspector object for mail items that have not been displayed to the user will crash and burn despite the fact that the inspector object exists and is attached to the mail item.

I have put some code on our DLL that will check the EntryId of the mail item and only accesses the inspector object if it is set. I have tried this in some simple cases and it seems to have fixed the issue. I will build our application and release it internally with this fix and check all possible scenarios and see if it works in all cases. I will get let you know if this has not fixed the issue in all cases.

One should ask though, why o why do you do this Microsoft? I hope someone will report this to their developers and it gets fixed.

Thanks for your response and have a great day.

Answer 2

• The error is happening/coming the code level, sounds like an exception is not handled or code path is broken. Enable better exception handling and you will know where it's breaking. Fix that first to see if it helps.
• I have a long term recommendation for you, instead of creating a DLL/VBA Macro for distributing of your code, its better you to make a simple Outlook addin with same code, test it thoroughly before the deployment - a better way to copy your code from one machine to another.

Answer 3

Hi @Deva-MSFT

Unfortunately, we cannot develop Add-ins because some of the users will not allow us to install Add-ins.

Anyway, this has nothing to do with exception handling. Microsoft has changed the way Outlook behaves and that is the root of our problems. I did identify the cause of all these issues and fixed them now until Microsoft developers breaks them again. There were error handlers in those places that I have put fixes but when I debugged the code there was no errors that were coming through in those places and we were only getting error 5 when we were calling the Send method of MailItem. Anyway, There are 3 issues that I spotted and fixed with the latest version of Outlook:

1) It seems like accessing MailItem's Inspector object causes a whole lot of issues if the MailItem was not displayed to the user. This was never an issue in the previous versions of the Outlook and have only started to happen from version 16.0.13929.20206. I am now checking the EntryID field to ensure that it is set before accessing the Inspector object.

2) It seems like Closing the inspector and then attempting to send the MailItem through the code is also causing a whole lot of issues. Again this was never an issue in the previous versions of Outlook. So you have to keep the Inspector object open before you can send the MailItem through the code. I am now minimising the Inspector object rather than closing it.

3) When we create a MailItem we use a unique string as the subject line and display the email. We then look for the window handle of the Inspector window using Windows API. We then change the MailItem's subject but we can see that Outlook does not change the subject line at all. We can see this clearly in the draft folder.
The subject line of the MailItem remained as the unique string that we used when we created the MailItem but through the code, the subject line of the mail item is actually right. So this was causing confusion in our code because Outlook and our MailItem had a different subject line for the same MailItem. Even leaving it for a few minutes, doing send and receive in Outlook, clicking on a different folder and clicking back to draft folder was not changing was still showing the old subject line in Outlook drafts folder. I have changed the code and am not relying on the subject line.

All these behaviour changes has caused us so much grief over that last couple of weeks. One would imagine that if a company as big as Microsoft changes a product such as office, they would publish these sort of changes so that developers have half a chance of spotting any issues before their customers complain but unfortunately, I could not find any documentation about any of these behaviour changes and that is the worst part about all of these.

Would be interested if you can tell me if such documentation exists and if so point me in that direction.

Thank you for your comments anyway.