Outlook 2013 Add-in no longer works on Windows 10 RRS feed

  • Question

  • I had an Outlook 2013 C# add-in developed using Visual Studio 2013 targeting Outlook 2013.  It was working just fine on my old Windows 7 workstation. Recently I got my workstation reimaged with Windows 10 and I reinstalled Office 2013 and my add-in. The add-in now hangs Outlook on startup.  When I ran it through the debugger it was hanging on a line of code that created a System.Diagnostics.PerformanceCounter.  I added the .NET Framework debugging option (and unchecked 'step over properties and operators) and ran it through the debugger again.  Within Microsoft's PerformanceCounterLib.cs source code file, I was able to see the exact line of code that was hanging, and it was:

    data = (byte[]) perfDataKey.GetValue(item);

    The function it is included in is: internal byte[] GetData(string item) from: internal class PerformanceMonitor in PerformanceCounterLib.cs.  Again, I want to stress that this is Microsoft's code.  FWIW, The GetData function has a comment that reads:

    // Win32 RegQueryValueEx for perf data could deadlock (for a Mutex) up to 2mins in some 
            // scenarios before they detect it and exit gracefully. In the mean time, ERROR_BUSY, 
            // ERROR_NOT_READY etc can be seen by other concurrent calls (which is the reason for the 
            // wait loop and switch case below). We want to wait most certainly more than a 2min window. 
            // The curent wait time of up to 10mins takes care of the known stress deadlock issues. In most 
            // cases we wouldn't wait for more than 2mins anyways but in worst cases how much ever time 
            // we wait may not be sufficient if the Win32 code keeps running into this deadlock again 
            // and again. A condition very rare but possible in theory. We would get back to the user 
            // in this case with InvalidOperationException after the wait time expires.

    A deadlock would definitely explain the hang in Outlook.  But the code comment makes it seem like it would be incredibly rare, and my add-in hangs Outlook 2013 EVERY time. 

    Just to see if it was some other problem with my add-in, I created a brand new VS 2013 Outlook 2013 add-in project and in the startup method (ThisAddIn_Startup) just added the following line of code:

    System.Diagnostics.PerformanceCounter pc = new System.Diagnostics.PerformanceCounter("Processor", "% Processor Time", "_Total");

    The result was the same, it hangs Outlook on startup.  Figuring that maybe WMI was somehow corrupt on my new machine, I then created a Visual Studio Console application with the same line of code as above to just get the Processor counter, and it worked fine.  It is only when I try to create performance counters in an Outlook 2013 project that it hangs on startup.

    So in summary:

    -My Outlook 2013 C# add-in worked fine on my old Windows 7 PC

    -My Outlook 2013 add-in hangs my new Windows 10 PC on the line that creates a new performance counter

    -A brand new Outlook 2013 add-in hangs my new Windows 10 PC when creating a new performance counter object

    -A brand new Console App works OK on my Windows 10 PC when creating a new performance counter object

    So something is wrong with the CLR that runs inside Outlook 2013 (32bit), but I don't know what.  Ideas?

    Tuesday, January 31, 2017 10:44 PM


  • The problem was Microsoft EMET 5.5.  I'm not sure which specific settings were causing the problem, but I just uninstalled EMET and the Outlook add-in no longer froze Outlook when creating a new Performance Counter.
    Wednesday, March 8, 2017 9:48 PM

All replies

  • Hello,

    Most probably running a time-consuming code in the Startup event handler is not a good idea. I'd suggest running the performance counter on a secondary thread or initializing it in the Startup event of the Application class which is fired when Microsoft Outlook is starting, but after all add-in programs have been loaded (not ThisAddIn_Startup). Does it help?

    profile for Eugene Astafiev at Stack Overflow, Q&A for professional and enthusiast programmers

    Tuesday, January 31, 2017 10:55 PM
  • Eugene,

    Even when I try creating the PerformanceCounter with a C# Task (ie not the main Outlook thread) the Task hangs.  If I do Task.Wait() on the main Outlook thread, then Outlook also hangs.

    If you have access to a Windows 10 machine, could you try creating a new Outlook 2013 project with just the following code:

    private void ThisAddIn_Startup(object sender, System.EventArgs e)
                                        System.Diagnostics.PerformanceCounter pc = new System.Diagnostics.PerformanceCounter("Processor", "% Processor Time", "_Total");
            private void ThisAddIn_Shutdown(object sender, System.EventArgs e)

    When you compile and run it, does it hang Outlook 2013?

    Wednesday, February 1, 2017 6:13 PM
  • Hi,

    I failed to reproduce your issue with VS2013/Office2013 15.0.4893.1000 32bit . 

    I suggest you disable others add-ins and check if the issue exists.

    Besides, I suggest you create a blank add-in to check if outlook starts normally.



    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact

    Friday, February 3, 2017 5:17 AM
  • Celeste,

    Another coworker also confirmed that creating a performance counter from an outlook 2013 addin on Win10 also works ok.  I'm 99% certain this is a local environment issue.  I've installed SysInternals Process Monitor to get a better idea of what's going on.   Would it be best to move this thread to a forum for Process Monitor or Windows debugging? 

    Below are the last few lines of the hang (creating a new performance counter from an Outlook 2013 32-bit addin).  As you can see, execution hangs on Thread Create, and I don't know how to continue troubleshooting from there.  The Thread Create line notes "Thread ID: 1528", so I'm assuming it created a new thread with id 1528, but there are no entries in Process Monitor for any threads with TID 1528.  In other words, this is where I lose track of what's causing the hang.  Any ideas?

    12:46:13.2977945 PM    OUTLOOK.EXE    4752    7688    QueryOpen    C:\Windows\Microsoft.NET\Framework\v4.0.30319\CORPerfMonExt.dll    SUCCESS  CreationTime:
     10/30/2015 2:19:56 AM, LastAccessTime: 10/30/2015 2:19:56 AM, LastWriteTime: 10/30/2015 2:19:56 AM, ChangeTime: 12/14/2016 5:53:19 PM, AllocationSize: 126,976, EndOfFile: 126,136, FileAttributes: A
    12:46:13.2979292 PM    OUTLOOK.EXE    4752    7688    CreateFile    C:\Windows\Microsoft.NET\Framework\v4.0.30319\CORPerfMonExt.dll    SUCCESS    Desired
     Access: Read Data/List Directory, Execute/Traverse, Synchronize, Dis, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: n/a, ShareMode: Read, Delete, AllocationSize: n/a, OpenResult: Opened
    12:46:13.3496247 PM    OUTLOOK.EXE    4752    7688    QuerySecurityFile    C:\Windows\Microsoft.NET\Framework\v4.0.30319\CORPerfMonExt.dll    SUCCESS    Information:
    12:46:13.3496848 PM    OUTLOOK.EXE    4752    7688    CreateFileMapping    C:\Windows\Microsoft.NET\Framework\v4.0.30319\CORPerfMonExt.dll    FILE LOCKED WITH ONLY READERS  
      SyncType: SyncTypeCreateSection, PageProtection: PAGE_EXECUTE|PAGE_NOCACHE
    12:46:13.3498120 PM    OUTLOOK.EXE    4752    7688    CreateFileMapping    C:\Windows\Microsoft.NET\Framework\v4.0.30319\CORPerfMonExt.dll    SUCCESS    SyncType:
    12:46:13.3500969 PM    OUTLOOK.EXE    4752    7688    Load Image    C:\Windows\Microsoft.NET\Framework\v4.0.30319\CORPerfMonExt.dll    SUCCESS    Image
     Base: 0x62cc0000, Image Size: 0x1f000
    12:46:13.3529031 PM    OUTLOOK.EXE    4752    7688    CloseFile    C:\Windows\Microsoft.NET\Framework\v4.0.30319\CORPerfMonExt.dll    SUCCESS    
    12:46:13.3530659 PM    OUTLOOK.EXE    4752    7688    RegQueryKey    HKLM    SUCCESS    Query: HandleTags, HandleTags: 0x0
    12:46:13.3530928 PM    OUTLOOK.EXE    4752    7688    RegQueryKey    HKLM    SUCCESS    Query: Name
    12:46:13.3531169 PM    OUTLOOK.EXE    4752    7688    RegOpenKey    HKLM\system\CurrentControlSet\Services\.NETFramework\Performance    REPARSE    Desired
     Access: Read
    12:46:13.3531501 PM    OUTLOOK.EXE    4752    7688    RegOpenKey    HKLM\System\CurrentControlSet\Services\.NETFramework\Performance    SUCCESS    Desired
     Access: Read
    12:46:13.3531745 PM    OUTLOOK.EXE    4752    7688    RegSetInfoKey    HKLM\System\CurrentControlSet\Services\.NETFramework\Performance    SUCCESS    KeySetInformationClass:
     KeySetHandleTagsInformation, Length: 0
    12:46:13.3531856 PM    OUTLOOK.EXE    4752    7688    RegQueryValue    HKLM\System\CurrentControlSet\Services\.NETFramework\Performance\First Counter    SUCCESS  
      Type: REG_DWORD, Length: 4, Data: 6984
    12:46:13.3532133 PM    OUTLOOK.EXE    4752    7688    RegQueryValue    HKLM\System\CurrentControlSet\Services\.NETFramework\Performance\First Help    SUCCESS  
      Type: REG_DWORD, Length: 4, Data: 6985
    12:46:13.3532429 PM    OUTLOOK.EXE    4752    7688    RegQueryKey    HKLM    SUCCESS    Query: HandleTags, HandleTags: 0x0
    12:46:13.3532563 PM    OUTLOOK.EXE    4752    7688    RegQueryKey    HKLM    SUCCESS    Query: Name
    12:46:13.3532721 PM    OUTLOOK.EXE    4752    7688    RegOpenKey    HKLM\system\CurrentControlSet\Services\.NETFramework\Performance    REPARSE    Desired
     Access: Read
    12:46:13.3532915 PM    OUTLOOK.EXE    4752    7688    RegOpenKey    HKLM\System\CurrentControlSet\Services\.NETFramework\Performance    SUCCESS    Desired
     Access: Read
    12:46:13.3533223 PM    OUTLOOK.EXE    4752    7688    RegSetInfoKey    HKLM\System\CurrentControlSet\Services\.NETFramework\Performance    SUCCESS    KeySetInformationClass:
     KeySetHandleTagsInformation, Length: 0
    12:46:13.3533330 PM    OUTLOOK.EXE    4752    7688    RegQueryValue    HKLM\System\CurrentControlSet\Services\.NETFramework\Performance\ProcessNameFormat    NAME NOT FOUND  
      Length: 144
    12:46:13.3533575 PM    OUTLOOK.EXE    4752    7688    RegCloseKey    HKLM\System\CurrentControlSet\Services\.NETFramework\Performance    SUCCESS    
    12:46:13.3537056 PM    OUTLOOK.EXE    4752    7688    Thread Create        SUCCESS    Thread ID: 1528

    Thursday, March 2, 2017 7:38 PM
  • The problem was Microsoft EMET 5.5.  I'm not sure which specific settings were causing the problem, but I just uninstalled EMET and the Outlook add-in no longer froze Outlook when creating a new Performance Counter.
    Wednesday, March 8, 2017 9:48 PM