Why does my Outlook add in randomly stop working? - email

Question

I have a plugin running in Outlook 2013 that is intended to filter out spam. It looks at incoming emails, runs through a half-dozen heuristics, and if 1 or 2 of them return positive, it moves the mail to another folder for inspection; if three or more are tripped, it permanently deletes the mail.
My problem is that it randomly stops working. The add in isn't marked as "disabled" or "inactive"; it just doesn't work anymore. Disabling it and then enabling it brings it back on line, and then it will work fine, including on the mail that it just failed on. And then it will fail randomly again a few messages later. No error is being raised as far as I can see; no exception is being thrown.
I feel like this has something to do with Outlook's limits for add-ins, since it is (a) non-deterministic and (b) seems to happen more often the more checks I do. But nothing I am doing is very heavy; most of it is just checking things in the email address, subject, and headers, or looking for key phrases in the body. Eyeballing it, every message appears to be processed in just a fraction of a second. I guess the first question is, is there a way to see Outlook's decision process on this, i.e. the specific perf statistics it is tracking? (ETA: Does Outlook enforce its restrictions when the add-in is invoked, or just at startup? Everything I can find only refers to startup.)
No single one of the checks seems to be responsible; I've disabled each one individually and it keeps happening.
Here's the central code. SpamMarkerCheckList is a list of delegates for the individual heuristic checks. ClearAllMailMarkers() does things like mark the mail as read, set the priority to normal, remove any flags, etc. headers is a Dictionary with the header names as the keys and lists of strings as the values.
private static void FilterInbox(object mailItem)
{
try
{
if (mailItem != null)
{
var mail = (Outlook.MailItem)mailItem;
var markers = SpamMarkersCount(mail, 3);
if (markers > 2)
{
PermanentlyDeleteEmail(mail);
}
else if (markers > 0)
{
ClearAllMailMarkers(mail);
mail.Move(_sequesteredFolder);
}
}
}
catch (Exception e)
{
MessageBox.Show("FilterSpam caught unexpected exception -- " + e);
}
}
private static int SpamMarkersCount(Outlook.MailItem mail, int threshold)
{
var spamMarkerCount = 0;
var headers = GetHeaderProperties(mail);
var emailAddressList = BuildAddressList(mail, headers);
var fullStringList = GetAllStrings(mail, headers);
foreach (var spamMarkerCheck in SpamMarkerCheckList)
{
if (spamMarkerCheck(mail, headers, emailAddressList, fullStringList))
{
spamMarkerCount++;
if (spamMarkerCount >= threshold)
{
return spamMarkerCount;
}
}
}
return spamMarkerCount;
}
The checks I am doing are:
Non-ASCII characters in the sender's name or address (e.g. hearts, shopping carts, etc.)
Indicators in the headers, like the presence of List-Unsubscribe or failed SPF, DKIM, or DMARC authentication
Email addresses that are badly formed or missing
If it was sent from a fake domain (via doing a DNS lookup)
The presence of the user's email alias in the subject or sender name ("delius1967 is a winner!")
If it was sent from a known blocked list of domains
If it contains specific phrases (e.g. "this is an advertisement")

Answer 1

I'd suggest checking the Windows event viewer for Outlook-specific records. Most probably your add-in fires an exception at runtime.
First and foremost, Microsoft Office applications can disable VSTO Add-ins that behave unexpectedly. If an application does not load your VSTO Add-in, the application might have hard disabled or soft disabled your VSTO Add-in.
Hard disabling can occur when a VSTO Add-in causes the application to close unexpectedly. It might also occur on your development computer if you stop the debugger while the Startup event handler in your VSTO Add-in is executing.
Soft disabling can occur when a VSTO Add-in produces an error that does not cause the application to unexpectedly close. For example, an application might soft disable a VSTO Add-in if it throws an unhandled exception while the Startup event handler is executing.
When you re-enable a soft-disabled VSTO Add-in, the application immediately attempts to load the VSTO Add-in. If the problem that initially caused the application to soft disable the VSTO Add-in has not been fixed, the application will soft disable the VSTO Add-in again. Read more about that in the How to: Re-enable a VSTO Add-in that has been disabled article.
Second, extending the add-in resiliency pillar of Outlook 2010, Outlook 2013 and later versions monitor add-in performance metrics such as add-in startup, shutdown, folder switch, item open, and invoke frequency. Outlook records the elapsed time in milliseconds for each performance monitoring metric.
For example, the startup metric measures the time required by each connected add-in during Outlook startup. Outlook then computes the median startup time over 5 successive iterations. If the median startup time exceeds 1000 milliseconds (1 second), then Outlook disables the add-in and displays a notification to the user that an add-in has been disabled. The user has the option of always enabling the add-in, in which case Outlook will not disable the add-in even if the add-in exceeds the 1000 millisecond performance threshold. Read more about that in the Performance criteria for keeping add-ins enabled section.
You may find the Outlook’s slow add-ins resiliency logic and how to always enable slow add-ins article helpful.
Finally, Outlook uses a single-threaded apartment model and may prevent any calls from secondary threads by throwing exceptions at runtime. You should use the OOM on the main thread only. If you need to do any processing on the background you may consider extracting the required plain data and passing it for processing. Extended MAPI allows running secondary threads also.

Answer 2

I found the proximate cause: garbage collection. After running in the debugger for quite a while, I noticed that the add-in stopped working immediately after a GC event; several more runs through show that this happens consistently.
The ultimate cause was in how I was associating the function with the folder:
private static Outlook.Account emailStore; // outside ThisAddIn_Startup
[...]
emailStore.DeliveryStore.GetDefaultFolder(Outlook.OlDefaultFolders.olFolderInbox).Items.ItemAdd += FilterInbox;
For reasons I do not fully understand, that causes a problem after GC, but this does not:
private static Outlook.Items emailItems; // outside ThisAddIn_Startup
[...]
emailItems = emailStore.DeliveryStore.GetDefaultFolder(Outlook.OlDefaultFolders.olFolderInbox).Items;
emailItems.ItemAdd += FilterInbox;
I get why having it as static is critical, but I don't understand why it makes a difference in the assignment. Anyone with a deeper understanding of C# objects who can explain, I would love to hear it.