Tuesday 9 October 2012

The Outlook CRM Addin and memory

For the last few weeks we've been fighting a persistent "Microsoft Outlook has encountered an error and needs to close, we're sorry for the inconvenience" message.

We've contacted Microsoft, worked through their troubleshooting, which basically involves:

  • Removing a bunch of addins they've seen some issues with in the past.
  • Making sure that everything is bang up to date.
  • Following most of the instructions in the white paper "Optimizing and Maintaining Client Performance for Microsoft Dynamics CRM 2011 and CRM Online", available from http://www.microsoft.com/en-us/download/details.aspx?id=23261.
But the problem is quite simple.  Outlook uses a fair bit of memory itself, the CRM add in only increases the amount required and IE is running in process.  We've seen Outlook with the CRM start up requiring anything between 250MiB and 750Mib.  CRM's Addin also leaks a bit of memory.

Add all that to a couple of open windows any you find that Outlook will crash as above when round about 1.1GiB of memory is demanded.  The leak makes it more likely to happen over time, leaving CRM windows open, each of which can demand 40 - 100 MiB open makes it more likely to happen.  But the architecture is a bit of a house of cards.

We've noticed that an unhanded exception bubbles almost all the way to the surface in Outlook, they're then eaten before Outlook closes gracefully.  This prevents investigation of errors with tools expecting an un-handled exception.  Microsoft's Debug Diagnostics tool was a huge help finding issues http://www.microsoft.com/en-us/download/details.aspx?id=26798.  This can produce dumps based on certain events like thrown exceptions which can be debugged using Visual Studio.  Microsoft doesn't read these traces properly, they look up the stack see Enterprise Vault or something similar and just blame that.

We found a number of exceptions that would have been handled, a few out of memory exceptions and quite a few assignments to null pointers.  Malloc returns null when it can't allocate memory, so this can also be an indication of a low memory condition.

The 64bit Outlook client runs beautifully, is faster and doesn't run out of memory.  Sadly it took us a few weeks to get to this condition.  Not helped by Microsoft's working assumption that the 32bit add in is a reliable piece of software.

So we've learned from this:
  • Outlook has shoddy error handling, some logging would be lovely.
  • A big CRM solution is unlikely to run in the 32bit Outlook client.
  • The whole lot is running in process.  Add this to bad error handling and a crash anywhere in Outlook, the an add-in, or the CRM add ins IE integration is going to close Outlook.
  • Don't trust Microsoft's engineers to correctly analyse dump files.
  • Make certain you test your solution in Outlook and offline as early as you can.

No comments:

Post a Comment