Starting in mid-2016, some Outlook 2013 and Outlook 2016 users began noticing rendering issues and posting reports in our forums and communities. Then, in late 2016, similar reports started filtering into our support teams. The symptoms have included:
- Buttons on the Outlook ribbon failing to paint properly
- Email messages displaying either blank or black in the Reading Pane
- The Navigation Pane failing to draw all folders properly
- Various rectangles appearing in the Outlook user interface (UI)
The frequency of the problem has varied by user. Some have seen drawing failures once a week, while others two, three, or more times per day. These problems can affect all Office deployment technologies, including perpetual (also called MSI) and subscription (also known as Click-to-Run or C2R for short).
In this post, we describe the architecture of the Office/Outlook rendering model. Additionally, we share steps to proactively mitigate the rendering issues. And lastly, we give you a peek inside the continued development efforts aimed at resolving these problems.
Background
Outlook is the main messaging application within the Office suite. Outlook uses shared Microsoft Office (MSO) code to perform many functions. Examples include Outlook's use of Microsoft Word for spell checking and HTML rendering and Outlook's use of shared Office ADAL code to perform Modern Authentication related operations.
Office 2013 introduced a new rendering engine called Airspace to all the Office applications. Airspace's promise was to better leverage the hardware based graphics from DirectX in Windows 8 to enable new design experiences like animations and layered composition. Outlook continues to use Word and other shared office code like Airspace in the 2016 version.
The initial release of Airspace as the Office/Outlook rendering engine came at a time when many devices did not have sufficient video hardware to accommodate the new rendering feature set. As a result, many users and firms forcibly deployed policies to disable hardware graphics acceleration, despite the fact that Office code was designed to turn the feature off if the hardware did not support it. Such policies still exist in many enterprises, although in most cases today, they could safely be removed (except for a few, very specific instances).
Rendering Issue Specifics
The players in the various iterations of the Outlook rendering problem are:
- Outlook (our hero)
- AirSpace (Office rendering engine)
- Word (key for many Outlook functions)
- Windows 32-bit application virtual address space composition (the law)
The primary cause of the rendering failure is memory pressure within the 32-bit Outlook process. Technically speaking, Outlook runs out of space for memory allocations within the process' virtual address space, resulting in rendering failures.
This memory pressure comes in two forms, both viewable with the VMMAP tool:
- A smaller than required available contiguous memory block (example: a texture requires a 128 kb memory block to render, but the smallest contiguous block available is 96 kb)
- Low virtual memory available to the Outlook process (less than 250 MB free of the 2 GB total that Windows gives to all 32-bit processes)
Interested readers can dive deeper with VMMAP here, and download the tool here.
Contributors to memory pressure in Outlook include the following:
- High resolution monitors
- Outlook content spread across multiple monitors
- Touch screens used to scroll through email and other messages within the UI (because of the bandwidth required to render screen content)
- Use of unneeded or excessive COM add-ins
- Large numbers of PST files added in the Outlook profile
- DirectX failures due to older drivers
- Dock/undock scenarios where resolution changes suddenly
- Heavy use workflows (keeping many messages open, keeping many attachments open, crafting email with lots of graphic effects from WordArt, etc...)
The rendering issue seems to surface most frequently on high-resolution monitors. Older monitors rendered in 1600x1200 pixels. However, newer monitors may render at 3840x2160, or four times more pixels. Last year's spike in support cases for the rendering issues correlates to increased adoption of higher-end hardware. Drawing the same UI surface for Outlook requires more pixels on the higher-res screens, and more pixels translate to more memory required, hence the quicker exhaustion of memory resources dedicated to the Outlook process. In simple terms, a full screen Outlook window that required 8 MB on an older monitor now requires 32 MB on a 4K display. Factor in lots of redraws and you understand how memory is quickly exhausted, leading to rendering failures.
And a final note on high-res monitors: there is no vendor bias involved... the resolution on Microsoft Surface is similar to devices from Lenovo, Dell, or other hardware manufacturers, each vulnerable to 32-bit Outlook rendering pains.
Mitigation
The best mitigation for these issues -without question- is to move to 64-bit Microsoft Office. Windows provides four thousand times the addressable user-mode memory to 64-bit processes than it does to 32-bit processes. More memory is the best way to fight memory depletion issues.
Note Some may get stuck on this recommendation, mostly due to add-in compatibility concerns and other concerns. Maybe your add-in vendor provides a 32-bit version of the add-in without an option for a 64-bit version. If this is your situation, we advise that you open a support case with your add-in vendor and insist on a 64-bit version of their product. The 32-bit limitation is immutable, hardware continues to get better, and extending Outlook with COM Add-ins is commonplace. 32-bit is not the future of desktop computing.
Once you verify that you have rendering issues caused by a low memory state within the Outlook process, determined on your own or by working in tandem with Microsoft Support, there are steps you should take immediately to start mitigation:
- Patch to the latest available versions of Outlook, Word, and MSO
- Ensure hardware graphics acceleration is enabled
- Update video drivers to the latest provided by the video card manufacturer
For impacted users that cannot go to 64-bit Office for one reason or another, and for whom the previous steps do not fully resolve the rendering problems, there are other options to relieve memory pressure. To this end, some or all the following may help:
- Restart Outlook regularly
- Change DPI settings to greater than 200% on high-res monitors
- Modify your Outlook workflow
- Keep fewer Outlook windows/messages open
- Disable or remove unneeded Outlook COM Add-ins
- Remove PST files from the profile when not used
- Avoid touch-scrolling through messages
- Avoid multiple monitor use with Outlook
- For extreme cases:
- Use OWA
- Use Office 2010/Outlook 2010 (works past the problem since Office 2013 introduced Airspace)
- Update to Office 2016/Outlook 2016 (where we first implement product changes)
Roadmap
During the first eight months of 2017, the Airspace, Outlook, and Word development teams shipped over twenty code changes and optimizations into Office to reduce the frequency and severity of the 32-bit Outlook rendering issues. These changes address the glaring problems found during investigations of this past year. The bulk of this work shipped in June 2017, and further coding and testing continue through the time of this writing in order to eliminate other problems that we've isolated.
Today, we are researching more complex rendering scenarios like multi-mon and docking/undocking scenarios for potential solutions. We are working on enabling a "large address aware" (LAA) Outlook, a step taken last year by the Excel team, and recently introduced to Office Insider Fast by Outlook development. LAA promises to increase available process memory on 64-bit Windows to 4 GB, or a factor of one hundred percent.
While the LAA increase is less than that of moving to a native 64-bit Office deployment, the important note is that Microsoft is looking at every possible angle to improve Outlook rendering. So far, all fixes taken are present in MSI builds of Office 2013 and 2016. Other development work outside the scope of this blog is happening too. Some of these ideas may only prove safe in Evergreen builds of Office 2016. Time will tell.
Going forward, we plan to ship more fixes as we isolate problems. Due to the complexity of these issues and the number of teams involved, we expect that related changes will ship not all at once, but rather in a phased manner over the coming months. This approach mandates that our customers keep current on Office patch levels. And of course, if you have questions, we invite you to open a support ticket and work with our support teams to assist.