32-bit Outlook interface elements unexpectedly render in black, white, or blank

Updated: May 1, 2018 and June 13, 2018

The continued work of the Airspace, Outlook, and Word development teams resulted in Office updates and optimizations that address the remaining 32-bit Outlook rendering issues. This update provides details on two areas of particular interest: Airspace and Large Address Aware (LAA) functionality.

Airspace

Changes to Airspace were mostly completed in the November 2017 updates for Office 2013 and Office 2016. As you likely know, Office updates are cumulative, thus we recommend patching with the latest available updates for Office. A significant finding to share is related to hardware graphics acceleration and virtualization. Some customer feedback indicates many popular virtualization solutions do not support hardware graphics acceleration. Since enabling hardware graphics acceleration is required to fully benefit from the Airspace improvements, if you find the virtual solution that you are administering doesn’t support hardware graphics acceleration, please reach out to the software vendor to request support.

Outlook Large Address Aware Feature

As mentioned in the original post below, Microsoft was working on enabling a "large address aware" (LAA) Outlook. Due to the significant memory handling changes involved with LAA, Outlook development elected to follow the standard channel release model for the new feature in Office 2016 ProPlus. The Outlook LAA feature has made its way into both the Monthly Channel and the Semi-Annual Targeted (SAT) channel of Office 2016 ProPlus as of this writing and should port was ported into the Semi-Annual (SA) channel on May 8, 2018 in summer 2018. LAA Outlook is also included starting with these MSI updates:

• 2013: https://support.microsoft.com/help/4018376
• 2016: https://support.microsoft.com/help/4018372

Initial reports indicate full resolution when both Office is updated (to include the Airspace changes) and an Outlook build that includes the LAA feature is used. Although others have indicated the rendering problems continue, they occur with a low frequency, hardly impacting their help desks. Still others –mostly users of memory-heavy Outlook add-ins– have chosen the 64-bit Office path to resolve the rendering issues. For some background on LAA, you can read the Office marketing team's article on the subject.

Original post...

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. 

• 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. The spike in 2016 for support cases with the rendering issues correlated to the 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:
  • Start any Office application
  • Click the File tab, then Options
  • Then click the Advanced group
  • In the Display section, ensure that the Disable hardware graphics acceleration check box is cleared, as shown here:
    
    Advanced Outlook option to Disable hardware graphics acceleration
• 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 in 2016 by the Excel>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.