Getting intermittent AccessViolationExceptions when accessing stores from Outlook.Stores object

Question

We have a very strange situation in which we get random AccessViolationExceptions when trying to access stores (in particular our own) via the Outlook.Stores.
Here's a code snippet of how we're calling this (currently done in our Outlook.ExplorerEvents_ActivateEventHandler handler, and only the first time is is called)
Outlook.NameSpace ns = ThisAddIn.OutlookApplication.GetNamespace("MAPI");
Outlook.Stores stores = ns.Stores;
Outlook.Store store = null;
int nStoreCount = stores.Count;
for (int i = 1; i < nStoreCount; i++)
store = stores[i];
String name = store.DisplayName;
store = null;
When we get to the point of accessing a store via index, we will sometimes get the AccessViolationException, but only sometimes and only (as far as I can tell, since the order isn't always the same from run to run) our message store.
We originally had this bit of code in our ThisAddin_Startup sequence, but it would actually crash Outlook completely when the exception occurred, so I moved it out of there and it at least now doesn't bring down the whole application.
MFCMAPI has no trouble opening the message store ever.
I have seen some references in my research to problems with .net 4.0 and earlier with regards to SynchronizationContext being null, and we are using 4.0 and getting null SynchronizationContext.current values. But we get that when the exception doesn't happen,
too, so I don't know if that's a red herring. However, this code is a back-port from a newer version of our software that was coded against .Net 4.5, and we don't see the issue there at all. As this is going into a patch, build with VS2010, we can't change
the target platform.
I have tried moving the call to worker threads, and I even saw one suggestion of trying to do it in our Outlook.ExplorerEvents_SelectionChangeEventHandler code, but nothing seems to work.
I should note that after the exception occurs, and the Outlook Explorer window opens and populates, if the user manually clicks our message store node, the MSProviderInit->IMSProvider::Logon sequence fires, and fires without the MDB_NO_DIALOG flag being
sent in. During Outlook's start-up, we get that sequence of calls several times, but always with the MDB_NO_DIALOG set, so we return MAPI_E_LOGON_FAILED and don't execute the code which creates our IMsgStore object. So the user's manual operation causes our
IMsgStore to get created and everything is fine. The reason the above code is added is to try to simulate the user's manual action and sort of 'tickle' the store creation process.
When the AccessViolationException does not occur, we get the full MSProviderInit->IMSProvider::Logon, etc sequence. When it does except, we don't even get our MSProviderInit entry point called. It's almost as if our dll gets loaded and then Outlook loses
it.
Any thoughts on this?

Answer 1

Hi Kevin Delgado,
>>if somebody knows what these other flags mean/are defined as in the context of the IMSProvider::Logon call, that would be great<<
Did you mean that the value of ulFlags? If yes, you can refer to the document below:
ulFlags                               
[in] A bitmask of flags that controls how the logon is performed. The following flags can be set:
MAPI_DEFERRED_ERRORS                   
The call is allowed to succeed even if the underlying object is not available to the calling implementation. If the object is not available, a subsequent call to the object might raise an error.
MAPI_UNICODE                   
The passed-in strings are in Unicode format. If MAPI_UNICODE is not set, the strings are in ANSI format.
MDB_NO_DIALOG                   
Prevents the display of logon dialog boxes. If this flag is set, the error value MAPI_E_LOGON_FAILED is returned if the logon is unsuccessful. If this flag is not set, the message store provider can prompt the user to correct a name or password, to insert
a disk, or to perform other actions that are necessary to establish connection to the store.
MDB_NO_MAIL                   
The message store should not be used for sending or receiving mail. The flag signals MAPI not to notify the MAPI spooler that this message store is being opened. If this flag is set and the message store is tightly coupled with a transport provider,
the provider does not need to call the IMAPISupport::SpoolerNotify method.
MDB_TEMPORARY                   
Logs on the store so that information can be retrieved programmatically from the profile section, without use of dialog boxes. This flag instructs MAPI that the store is not to be added to the message store table and that the store cannot be made permanent.
If this flag is set, message store providers do not need to call the IMAPISupport::ModifyProfile method.
MDB_WRITE                   
Requests read/write permission.
Also you can get more detail about IMSProvider::Logon function from link below:
https://msdn.microsoft.com/en-us/library/office/cc842201.aspx
Hope it is hlepful.
Regards & Fei
We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
Click
HERE to participate the survey.