Office VSTO add-in possible permission issues - HRESULT 0x80004004 (E_ABORT)

We've developed a C# Office VSTO add-in, that communicates with a running Outlook instance (or starts a new one), and it is showing signs of having permission issues on some customers PCs while trying to create Outlook tasks or appointments...

The exception message is the following:

Operation aborted (Exception from HRESULT: 0x80004004 (E_ABORT))

This happens here:

Outlook.Account DefaultAccount = null;
Outlook.Application outlookApp = GetOutlookApp();    //returns Application object of running Outlook instance / creates a new instance - it works for them.

DefaultAccount = GetAccountForFolder(outlookApp);    //returns the default account of the user. Tried it with a simple setup, only one account etc. - it works for them
String defaultemailaddress;

//CODE RUNS UNTIL THIS POINT
if (DefaultAccount == null)    //if somehow this would end up NULL, which is not the case, because: see code snippet below!
{
    defaultemailaddress = outlookApp.Session.CurrentUser.AddressEntry.Address;
}
else
{
    defaultemailaddress = DefaultAccount.SmtpAddress;    //this could be the problem, but I can't debug it further, and it works in the code block below, to get the AccountType, so I don't understand why I couldn't get the SmtpAddress without a hard exception
}
//FAILS BEFORE THIS LINE COULD RUN.
String email = "test@emailserver.com";

After getting in contact with the user, they told us, that they're running under a really limited permission set and network.

Weird thing is, this snippet of code actually runs smoothly for them, which proves, that the connection is working between Outlook and the other Office add-in:

Outlook.Application oApp = GetOutlookApp();
Outlook.Account DefaultAccount = GetAccountForFolder(oApp);
String AccountType = DefaultAccount.AccountType.ToString();

The IT department already tried to adjust the security policies of Outlook on the affected PC. They allowed Programmatic Access.

They can't start the tools with administrator privileges, but it shouldn't be necessary. The fact that those last 3 lines of code work (which gets the account type) proves that the application is indeed starting up correctly, but it looks like it can only run certain features...

I also want to note, that they are using Exchange, but apparently they don't have sync issues (if these could affect anything, at all...)

EDIT: Here's the implementation of GetAccountForFolder, which gets the default Outlook.Account object. This is a code snippet that I've found laying around, and found it was working great.

public static Outlook.Account GetAccountForFolder(Outlook.Application outlookApp)
{
    // Obtain the store on which the folder resides.
    Outlook.Store store = outlookApp.Session.DefaultStore;

    // Enumerate the accounts defined for the session.
    foreach (Outlook.Account account in outlookApp.Session.Accounts)
    {
        // Match the DefaultStore.StoreID of the account
        // with the Store.StoreID for the currect folder.
        if (account.DeliveryStore.StoreID == store.StoreID)
        {
            // Return the account whose default delivery store
            // matches the store of the given folder.
            return account;
        }
    }
    // No account matches, so return null.
    return null;
}

The problem is that you have race condition in a COM Add-In object. You should make an artificial delay in your method. Simple make the retries until you succeed, like this:

bool isDone = false;
while (!isDone)
{
    try
    {
        // your action with Add-In here...

        isDone = true;
    }
    catch (System.Runtime.InteropServices.COMException exception)
    {
        // small delay
        Thread.Sleep(10);
    }
}