none
App crash during MapiInitialize RRS feed

  • Question

  • Hello,

    I'm not certain whether or not this is the correct place to report a bug in Mapi32.dll but anyway here it goes:

    With the following software/OS combination

    - Windows 10 (64)

    - Outlook 2016 (32) incl. Mapi32.dll (1.0.2536.0 (th1.150709-1700))

    I get the easily reproducible app crash (Unhandled exception at 0x56e716db in MapiInitialize.exe: 0xC0000409: 0xc0000409)

    It's easily reproducible with an standard MFC dialog app:

    Header:

    -------

    HINSTANCE m_hMAPI;

    LPMAPIINITIALIZE m_pfMAPIInitialize;

    LPMAPIUNINITIALIZE m_pfMAPIUninitialize;

    Implementation:

    ---------------

    void CMapiInitializeDlg::InitMapi(void)

    {

    if (m_hMAPI != NULL)

    return;

    m_hMAPI = ::LoadLibrary(_T("mapi32.dll"));

    m_pfMAPIInitialize = (LPMAPIINITIALIZE)::GetProcAddress(m_hMAPI, "MAPIInitialize");

    m_pfMAPIUninitialize = (LPMAPIUNINITIALIZE)::GetProcAddress(m_hMAPI, "MAPIUninitialize");

    if (m_pfMAPIInitialize != NULL)

    m_pfMAPIInitialize(NULL);

    }

    void CMapiInitializeDlg::UninitMapi(void)

    {

    if (m_hMAPI == NULL)

    return;

    if (m_pfMAPIUninitialize != NULL)

    m_pfMAPIUninitialize();

    ::FreeLibrary(m_hMAPI);

    m_hMAPI = NULL;

    m_pfMAPIInitialize = NULL;

    m_pfMAPIUninitialize = NULL;

    }

    Now, when I do call the above functions like this:

    InitMapi();

    UninitMapi();

    InitMapi();

    UninitMapi();

    I get an app crash while in the second call to InitMapi() and here in particular while calling m_pfMAPIInitialize(NULL);

    I face the error just after upgrading from Outlook 2013 to Outlook 2016.

    Did somebody else face this error as well? Hope someone can help me with this one...

    Best regards

     

    Monday, November 16, 2015 8:30 AM

All replies

  • Hello Christian,

    Why do you need to call MAPIInitialize twice? Do you run the code on the main thread?

    Anyway, you may use https://officespdev.uservoice.com for submitting issues.

    Monday, November 16, 2015 8:42 AM
  • You might find this guidance helpful. How to: Link to MAPI Functions

     I can't say for certain if it's still applicable to Win 10 and Outlook 2016 but it does point out some things to consider when using LoadLibrary.

    Monday, November 16, 2015 2:53 PM
  • Do not statically link to mapi32.dll or load it - you need to load msmapi32.dll. Take a look at the MFCMAPI source code for an example on how to locate and load the MAPI dll.

    Dmitry Streblechenko (MVP)
    http://www.dimastr.com/redemption
    Redemption - what the Outlook
    Object Model should have been
    Version 5.5 is now available!

    Monday, November 16, 2015 4:46 PM
  • Thank you...

    Why do you need to call  MAPIInitialize twice?

     

    Well, the MAPI is being used in a COM-Dll. It loads the mapi32.dll when needed and unloads it when the COM-Dll itself is unloaded.

    Do not statically link to mapi32.dll or load it - you need to load msmapi32.dll

    As far as I understand the msmapi32.dll is part of MS Outlook. But I don't know what default mail Client our customer is using on his system. That's why we need the more general approach with mapi32.dll.

    Before Outlook 2016 everything's worked fine.

    Interesting though is that when the mapi32.dll is loaded only once (i.e. kept in memory) one can successfully call MapiInit and MapiUnit as much as he want.

    Thus it appears to me as if MapiInitialize() remembers the mapi32 handle at process scope, which is not removed in MapiInitialize() and being accessed after a second call to LoadLibrary(_T("mapi32.dll")) which results in a crash.


    Tuesday, November 17, 2015 7:53 AM
  • If your code is in Outlook addin, MAPIIInitialize was already called on the primary Outlook thread. You only need it on a secondary thread.

    In case of COM addin, Outlook loads the MAPI system anyway, so you can use GetModuuleHandle('olmapi32.dll").


    Dmitry Streblechenko (MVP)
    http://www.dimastr.com/redemption
    Redemption - what the Outlook
    Object Model should have been
    Version 5.5 is now available!

    Tuesday, November 17, 2015 2:03 PM
  • Thank you...

    Why do you need to call  MAPIInitialize twice?

     

    Well, the MAPI is being used in a COM-Dll. It loads the mapi32.dll when needed and unloads it when the COM-Dll itself is unloaded.

    Do not statically link to mapi32.dll or load it - you need to load msmapi32.dll

    As far as I understand the msmapi32.dll is part of MS Outlook. But I don't know what default mail Client our customer is using on his system. That's why we need the more general approach with mapi32.dll.

    Before Outlook 2016 everything's worked fine.

    Interesting though is that when the mapi32.dll is loaded only once (i.e. kept in memory) one can successfully call MapiInit and MapiUnit as much as he want.

    Thus it appears to me as if MapiInitialize() remembers the mapi32 handle at process scope, which is not removed in MapiInitialize() and being accessed after a second call to LoadLibrary(_T("mapi32.dll")) which results in a crash.


    Just guessing, but maybe Outlook 2016 now fails from a double init because of a regression. However, if you could make the fix in your code, it would be a lot easier than trying to get an Outlook fix and deploy that with your add-in.
    Tuesday, November 17, 2015 6:16 PM
  • It is perfectly fine to call MAPIInitialize more than once per thread, the MAPI system just bumps up the reference count. Outlook 2016 supports that just fine.


    Dmitry Streblechenko (MVP)
    http://www.dimastr.com/redemption
    Redemption - what the Outlook
    Object Model should have been
    Version 5.5 is now available!

    Tuesday, November 17, 2015 9:20 PM
  • Well, it doesn't sound like it according to the OP. He could prove or disprove it by removing the second call.

    Better yet, a backtrace/call stack would be helpful to know where it is crashing.

    Wednesday, November 18, 2015 1:29 AM
  • The problem is most likely due to loading a wrong MAPI dll. I call MAPIInitilize multiple times under Outlook 2016 with no sideeffects.

    Dmitry Streblechenko (MVP)
    http://www.dimastr.com/redemption
    Redemption - what the Outlook
    Object Model should have been
    Version 5.5 is now available!

    Wednesday, November 18, 2015 4:07 AM
  • Thank you...

    I think I didn't clearly make my point.

    Here's the scenario:

    1. My (standalone) application starts (MyApp)

    2. MyApp instantiates a (self written) COM object (MyCOMObj) which is implemented in a separate COM DLL (but no Outlook Addin) and invokes the function MyCOMObj.IsMailObject(Filename)

    3. The function "MyCOMObj.IsMailObject" does

            - m_hMAPI = LoadLibrary(_T("mapi32.dll"));

            - gets the MapiInitialize and MapiUninitialize function pointers by ::GetProcAddress(m_hMAPI, ...)

            - calls MapiInitialize(NULL)

            - and some other stuff...

    4. Back to MyApp. When MyCOMObj goes out of scope, its destructor is called which does:

            - MapiUninitialize

            - call FreeLibrary(m_hMAPI)

    So now the COM object is dead, mapi32.dll and (as Outlook (2016) is the default mail client) msmapi32.dll are definitively no longer in memory.

    5. OK. MyApp is still running and

    6. again creates an instance of MyCOMObj and invokes MyCOMObj.IsMailObject(Filename)

    7. What's happening now in MyCOMObj.IsMailObject:

            - m_hMAPI = LoadLibrary(_T("mapi32.dll")); OK!

    - the function pointer retrieval for MapiInitialize and MapiUninitialize succeed, too!

    - The call to MapiInitialize(NULL) leads to a crash! (buffer overrun)

    Since we're using COM objects which manage the loading and unloading of the mapi.dll, we can't manage it in an external application by only loading it once.

    As mentioned in my initial description I was able to reproduce this crash with a simple MFC-Dialog application. Follows the winDbg analyzed crash dump:

    Loading Dump File [C:\Users\christian\AppData\Local\CrashDumps\MapiInitialize.exe.5020.dmp]

    User Mini Dump File: Only registers, stack and portions of memory are available

    ************* Symbol Path validation summary **************

    Response                         Time (ms)     Location

    OK                                             C:\Windows\symbols\dll

    OK                                             C:\mysymbols

    Deferred                                       srv*C:\mysymbols*http://msdl.microsoft.com/download/symbols

    Symbol search path is: C:\Windows\symbols\dll;C:\mysymbols;srv*C:\mysymbols*http://msdl.microsoft.com/download/symbols

    Executable search path is:

    Windows 10 Version 10240 MP (8 procs) Free x86 compatible

    Product: WinNt, suite: SingleUserTS

    Built by: 10.0.10240.16384 (th1.150709-1700)

    Machine Name:

    Debug session time: Wed Nov 18 13:09:53.000 2015 (UTC + 1:00)

    System Uptime: not available

    Process Uptime: 0 days 0:00:21.000

    .......................................................

    Loading unloaded module list

    .......

    This dump file has an exception of interest stored in it.

    The stored exception information can be accessed via .ecxr.

    (139c.1688): Security check failure or stack buffer overrun - code c0000409 (first/second chance not available)

    Unable to load image C:\Program Files (x86)\Common Files\SYSTEM\MSMAPI\1033\MSMAPI32.DLL, Win32 error 0n2

    *** WARNING: Unable to verify timestamp for MSMAPI32.DLL

    *** ERROR: Module load completed but symbols could not be loaded for MSMAPI32.DLL

    eax=0061ea02 ebx=00000000 ecx=00000005 edx=00000000 esi=0061ea02 edi=66fba9d0

    eip=66fb17e8 esp=0061e77c ebp=0061e788 iopl=0         nv up ei pl zr na pe nc

    cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000246

    MSMAPI32+0x17e8:

    66fb17e8 cd29            int     29h

    0:000> !analyze -v

    *******************************************************************************

    *                                                                             *

    *                        Exception Analysis                                   *

    *                                                                             *

    *******************************************************************************

    *** WARNING: Unable to verify checksum for MapiInitialize.exe

    CONTEXT:  (.ecxr)

    eax=0061ea02 ebx=00000000 ecx=00000005 edx=00000000 esi=0061ea02 edi=66fba9d0

    eip=66fb17e8 esp=0061e77c ebp=0061e788 iopl=0         nv up ei pl zr na pe nc

    cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000246

    MSMAPI32+0x17e8:

    66fb17e8 cd29            int     29h

    Resetting default scope

    FAULTING_IP:

    MSMAPI32+17e8

    66fb17e8 cd29            int     29h

    EXCEPTION_RECORD:  (.exr -1)

    ExceptionAddress: 66fb17e8 (MSMAPI32+0x000017e8)

       ExceptionCode: c0000409 (Security check failure or stack buffer overrun)

      ExceptionFlags: 00000001

    NumberParameters: 1

       Parameter[0]: 00000005

    Subcode: 0x5 FAST_FAIL_INVALID_ARG

    PROCESS_NAME:  MapiInitialize.exe

    ERROR_CODE: (NTSTATUS) 0xc0000409 - Das System hat in dieser Anwendung den  berlauf eines stapelbasierten Puffers ermittelt. Dieser  berlauf k nnte einem b sartigen Benutzer erm glichen, die Steuerung der Anwendung zu  bernehmen.

    EXCEPTION_CODE: (NTSTATUS) 0xc0000409 - Das System hat in dieser Anwendung den  berlauf eines stapelbasierten Puffers ermittelt. Dieser  berlauf k nnte einem b sartigen Benutzer erm glichen, die Steuerung der Anwendung zu  bernehmen.

    EXCEPTION_PARAMETER1:  00000005

    NTGLOBALFLAG:  0

    APPLICATION_VERIFIER_FLAGS:  0

    APP:  mapiinitialize.exe

    ANALYSIS_VERSION: 10.0.10240.9 x86fre

    BUGCHECK_STR:  INVALID_ARG_FAILURE_SEHOP

    DEFAULT_BUCKET_ID:  INVALID_ARG_FAILURE_SEHOP

    LAST_CONTROL_TRANSFER:  from 66fb15b4 to 66fb17e8

    STACK_TEXT: 

    WARNING: Stack unwind information not available. Following frames may be wrong.

    0061e788 66fb15b4 0061ea02 00000000 00000000 MSMAPI32+0x17e8

    0061ec10 66fb106b 66fb1000 66fb168b 80004005 MSMAPI32+0x15b4

    0061f054 66fb17c6 66fb1437 66fb9c34 66fb1000 MSMAPI32+0x106b

    0061f068 60d95744 00000000 0061f16c 0061f094 MSMAPI32+0x17c6

    0061f088 00ea347a 00000000 0061f24c 00841048 mapi32!MAPIInitialize+0x64

    0061f16c 00ea338b 0061f5b4 00841048 00520cda MapiInitialize!CMapiInitializeDlg::InitMapi+0xba

    0061f24c 65667c12 00000000 00000176 00000004 MapiInitialize!CMapiInitializeDlg::OnMAPICrashClicked+0x3b

    0061f290 6566835a 0061fc24 000003e8 00000000 mfc100ud!_AfxDispatchCmdMsg+0xb2

    0061f2f4 656c2163 000003e8 00000000 00000000 mfc100ud!CCmdTarget::OnCmdMsg+0x2ea

    0061f330 6579f314 000003e8 00000000 00000000 mfc100ud!CDialog::OnCmdMsg+0x23

    0061f394 6541836a 000003e8 00520cda 0061fc24 mfc100ud!CWnd::OnCommand+0x174

    0061f3a8 6579de39 000003e8 00520cda 24574e14 mfc100ud!CDialogEx::OnCommand+0x3a

    0061f52c 6579dd82 00000111 000003e8 00520cda mfc100ud!CWnd::OnWndMsg+0x79

    0061f54c 6579a253 00000111 000003e8 00520cda mfc100ud!CWnd::WindowProc+0x32

    0061f5cc 6579a846 0061fc24 016211a6 00000111 mfc100ud!AfxCallWndProc+0xf3

    0061f5ec 655832cb 016211a6 00000111 000003e8 mfc100ud!AfxWndProc+0xa6

    0061f628 76954923 016211a6 00000111 000003e8 mfc100ud!AfxWndProcBase+0x5b

    0061f654 76934790 65583270 016211a6 00000111 user32!_InternalCallWinProc+0x2b

    0061f6fc 76933c8a 65583270 00000000 00000111 user32!UserCallWinProcCheckWow+0x1f0

    0061f760 76933a33 010fb4e0 00000000 00520cda user32!SendMessageWorker+0x1ea

    0061f798 68760b8d 016211a6 00000111 000003e8 user32!SendMessageW+0x143

    0061f7b8 68760adb 00520cda 00000202 00000000 comctl32!Button_NotifyParent+0x39

    0061f7d0 6878ead9 6878e2c0 00000000 000b0035 comctl32!Button_ReleaseCapture+0x7f

    0061f820 76954923 00520cda 00000202 00000000 comctl32!Button_WndProc+0x819

    0061f84c 76934790 6878e2c0 00520cda 00000202 user32!_InternalCallWinProc+0x2b

    0061f8f4 76934091 6878e2c0 00000000 00000202 user32!UserCallWinProcCheckWow+0x1f0

    0061f960 76949e41 0061fd18 0061fb04 7f9bc000 user32!DispatchMessageWorker+0x231

    0061f990 657d7723 016211a6 00841000 7659d358 user32!IsDialogMessageW+0x101

    0061f9a8 657a4f7e 00841000 0061fc24 0061f9d0 mfc100ud!CWnd::IsDialogMessageW+0x73

    0061f9b8 656c2132 00841000 0061fc24 038e1cc8 mfc100ud!CWnd::PreTranslateInput+0x6e

    0061f9d0 654182f2 00841000 0061fc24 0061f9f4 mfc100ud!CDialog::PreTranslateMessage+0xf2

    0061f9e0 657a057d 00841000 0061fc24 016211a6 mfc100ud!CDialogEx::PreTranslateMessage+0x32

    0061f9f4 65776e6f 016211a6 00841000 0061fa14 mfc100ud!CWnd::WalkPreTranslateTree+0x8d

    0061fa10 65777f25 00841000 00eb02e0 0061fa30 mfc100ud!AfxInternalPreTranslateMessage+0x4f

    0061fa20 65776ee5 00841000 00eb02e0 0061fa50 mfc100ud!CWinThread::PreTranslateMessage+0x25

    0061fa30 65776d21 00841000 0061fa4c 65583479 mfc100ud!AfxPreTranslateMessage+0x25

    0061fa50 657782fe 00eb02e0 0061fa68 65776d71 mfc100ud!AfxInternalPumpMessage+0xe1

    0061fa5c 65776d71 00eb02e0 0061fa90 657a5167 mfc100ud!CWinThread::PumpMessage+0xe

    0061fa68 657a5167 00000000 00000000 0061fc24 mfc100ud!AfxPumpMessage+0x21

    0061fa90 656c3372 00000004 245741c4 0061fd18 mfc100ud!CWnd::RunModalLoop+0x1d7

    0061fafc 00ea2461 4170a15b 00ea1857 00ea1857 mfc100ud!CDialog::DoModal+0x1f2

    0061fd24 657d2d34 cccccccc cccccccc cccccccc MapiInitialize!CMapiInitializeApp::InitInstance+0x111

    I'm convinced that msmapi32.dll provided by Outlook 2016 is the culprit here as the crash does not occur using msmapi32.dll provided by Outlook 2013.

    Best regards.


    Wednesday, November 18, 2015 12:44 PM
  • As a test, can you hardcode the path to msmapi32.dll and load it instead of mapi32.dll?

    Dmitry Streblechenko (MVP)
    http://www.dimastr.com/redemption
    Redemption - what the Outlook
    Object Model should have been
    Version 5.5 is now available!

    Wednesday, November 18, 2015 2:03 PM
  • Hello Dmitry,

    I hardcoded it and yes, it works!!! So there must something wrong with mapi32.dll I suppose???

    Best regards, Christian


    Wednesday, November 18, 2015 2:40 PM
  • Great! So all you can do now is borrow the code from MFCMAPI that located and loads the mapi dll :-)

    Dmitry Streblechenko (MVP)
    http://www.dimastr.com/redemption
    Redemption - what the Outlook
    Object Model should have been
    Version 5.5 is now available!

    Wednesday, November 18, 2015 2:48 PM
  • The MAPI Stub Library was written by the developer of MFCMAPI.  It might be easier to use than trying to extract code from the MFCMAPI source.

    Wednesday, November 18, 2015 3:04 PM
  • Hello!

    I copied the Code from MFCMAPI to load and initialize the msmapi32.dll and I have the same crash when calling it a second time (also unloading mapi32.dll and msmapi32.dll with FreeLibrary after the first call).

    The mapi32.dll was loaded so I can call the function FGetComponentPath to obtain the path to msmapi32.dll and then unloaded.
    If I leave this step out and retrieve the path from the registry key "DllPathEx" it works without crashing on the second run.

    Also I can see the following first chance exception when exiting the test application though which can also be seen with the MFCMAPI application.

    First-chance exception at 0x775f8cbc (ntdll.dll) in MapiInitialize.exe: 0xC0000008: An invalid handle was specified.

    If you want you can take a look in the demo application (created with VS2010) which I created. It is contained in a Password free zip container

    MapiInitialize (Demp application)

    Best regards


    • Edited by Christian-Köhler Monday, November 23, 2015 11:59 AM Missed some information
    Monday, November 23, 2015 11:03 AM
  • I have tweaked the demo app to use the MAPI Stub LIbrary.  It successfully calls MAPIInitialize, MAPIUninitialize and unloads the MAPI DLL without crashing.  MAPIInitialize takes care of locating and loading MAPI so no separate calls are required.  There are no crashes when matched multiple MAPIInitialize and MAPIUninitialize calls are made or when MAPIInitialize is called again after the DLL has been unloaded. You can download the project at NewMapiInitialize.zip
    • Edited by RLWA32 Monday, November 23, 2015 7:37 PM
    Monday, November 23, 2015 7:19 PM
  • Thank you for sticking with me and thank you for tweaking the demo app.

    Unfortunately the tweaked app crashes with the following exception when I click the sequence:

    1. MapiInitialize
    2. MapiUninitialize
    3. Unload msmapi32.dll
    4. MapiInitialize

    Unhandled exception at 0x668b17e8 in MapiInitialize.exe: 0xC0000409: 0xc0000409.

    Here's the stack

      MSMAPI32.DLL!668b17e8()  
      [Frames below may be incorrect and/or missing, no symbols loaded for MSMAPI32.DLL] 
      MSMAPI32.DLL!668b15b4()  
      MSMAPI32.DLL!668b106b()  
      MSMAPI32.DLL!668b168b()  
    > MapiInitialize.exe!__InlineInterlockedCompareExchangePointer(void * volatile * Destination=0x00c6dfa0, void * ExChange=0x00c681f0, void * Comperand=0x668b8c20)  Line 2488 + 0x14 bytes C++
      0033ec34() 
      00753678() 
      006b4df0() 

    Did you receive the Crash with the untweaked demo app?

    This is my System configuration:

    • Windows 10 64bit
    • Outlook 2016 32 bit
    • Visual Studio 2010
    •  C:\Program Files (x86)\Microsoft Office\root\VFS\ProgramFilesCommonX86\System\MSMAPI\1033\MSMAPI32.DLL Version 16.00.6001.1038 (October, 31, 2015)
    • C:\Windows\SysWow64\mapi32.dll Version 1.0.2536.0 (July, 10, 2015)

    Best regards


    Tuesday, November 24, 2015 7:06 AM
  • Yes, I did experience the crash you described with the demo app. 

    I tested the tweaked demo on Windows 7 SP1 32 bit, Outlook 2010 SP1 32 bit, Visual Studio 2010 SP1.  I'll see how it behaves with Outlook 2013 32 bit on Win7 32 bit.  I cannot replicate your system configuration, but I'll let you know what I find on this end anyway.

    The stack overflow exception just doesn't make sense to me.

    Update--

    I'm scratching my head in wonderment.  The demo app performed flawlessly -- no crashes when it was built with VS 2013 Update 5 and run against Outlook 2013 SP1 on Win7.  The tweaked demo app also performed properly

    Update 2 --

    I ran both the demo app and the tweaked demo (both built with VS2013 Update 5) against Outlook 2010 SP1 on Win7.  Again, both apps performed properly without crashes.

    I'm starting to wonder if VS2010 might be the problem?


    • Edited by RLWA32 Tuesday, November 24, 2015 2:50 PM
    Tuesday, November 24, 2015 12:30 PM
  • Hello,
    it took some time but here are the things I tested:

    I've setup a two fresh virtual machines with the following config:
    1.
    - Windows 10 (64)
    - Visual Studio 2015
    2.
    - Windows 7 (64)
    - Visual Studio 2015

    On both machines I tested both the demo app and the tweaked demo app with the following result:
    - With Outlook 2010 (32) installed both apps were performing withour error
    - With Outlook 2013 (32) installed both apps were performing withour error
    - With Outlook 2016 (32) installed both apps did crash with the stack I posted earlier!!!

    That was as I said with VS 2015. And it is the same result I get using VS 2010!

    So, I'm not sure whether this problem has anything to do with VS 2010 at all. I still suspect a problem with MS Outlook 2016.
    And one more thing is very interesting. While both Outlook 2010 and Outlook 2013 come with an MAPI dll named OLMAPI32.DLL the 2016 version of Outlook comes with the MAPI named MSMAPI32.dll.
    To me that is an indication that Microsoft changed something that required - for whatever reason - a dll rename. And most probably that went along with some code change.

    Now, I'm pretty sure that installing Outlook 2016 leads to the crash!

    Best regards,
    Christian


    Wednesday, December 2, 2015 9:50 AM
  • Thanks for the interesting follow-up.  There are various options in MFCMAPI under the Session | Mapi initialization submenu  to load and unload MAPI.  Can you use MFCMAPI to induce a crash on Outlook 2016?  It might help narrow down the offending DLL.  Or just let MFCMAPI choose its own DLLs for the MAPIInitialize call...
    Wednesday, December 2, 2015 12:03 PM
  • Thank you for sticking with me and thank you for tweaking the demo app.

    Unfortunately the tweaked app crashes with the following exception when I click the sequence:

    1. MapiInitialize
    2. MapiUninitialize
    3. Unload msmapi32.dll
    4. MapiInitialize

    Unhandled exception at 0x668b17e8 in MapiInitialize.exe: 0xC0000409: 0xc0000409.

    Here's the stack

      MSMAPI32.DLL!668b17e8()  
      [Frames below may be incorrect and/or missing, no symbols loaded for MSMAPI32.DLL] 
      MSMAPI32.DLL!668b15b4()  
      MSMAPI32.DLL!668b106b()  
      MSMAPI32.DLL!668b168b()  
    > MapiInitialize.exe!__InlineInterlockedCompareExchangePointer(void * volatile * Destination=0x00c6dfa0, void * ExChange=0x00c681f0, void * Comperand=0x668b8c20)  Line 2488 + 0x14 bytes C++
      0033ec34() 
      00753678() 
      006b4df0() 

    Did you receive the Crash with the untweaked demo app?

    This is my System configuration:

    • Windows 10 64bit
    • Outlook 2016 32 bit
    • Visual Studio 2010
    •  C:\Program Files (x86)\Microsoft Office\root\VFS\ProgramFilesCommonX86\System\MSMAPI\1033\MSMAPI32.DLL Version 16.00.6001.1038 (October, 31, 2015)
    • C:\Windows\SysWow64\mapi32.dll Version 1.0.2536.0 (July, 10, 2015)

    Best regards



    Have you considered Microsofts AppVerifier? Its a real gem. Add Outlook and your extension.dll (or MapiInitialize.exe) and the MAPI libraries with default checking. Then perform the steps to reproduce the bug under the debugger. AppVerifier will break if it detects a problem in the checks that you specify in its settings. BTW, it does have a large perf hit and will slow Outlook to a crawl, but its worth a try. 
    • Edited by Joel_Z Wednesday, December 2, 2015 9:02 PM
    Wednesday, December 2, 2015 9:01 PM
  • Do not unload/reload msmapi32.dll - a lot of work had been done in Outlook 2016 around the marshaling, and MAPI system assumes that some dlls are always loaded.


    Dmitry Streblechenko (MVP)
    http://www.dimastr.com/redemption
    Redemption - what the Outlook
    Object Model should have been
    Version 5.5 is now available!

    Thursday, December 3, 2015 12:04 AM
  • Do not unload/reload msmapi32.dll - a lot of work had been done in Outlook 2016 around the marshaling, and MAPI system assumes that some dlls are always loaded.


    Interesting stuff.  I know you don't speak for Microsoft.  Having said that, are you aware if there will be documentation ( or MSDN blog discussions) of such changes in Outlook 2016's MAPI implementation?
    Thursday, December 3, 2015 2:10 PM
  • I doubt it...


    Dmitry Streblechenko (MVP)
    http://www.dimastr.com/redemption
    Redemption - what the Outlook
    Object Model should have been
    Version 5.5 is now available!

    Thursday, December 3, 2015 3:49 PM
  • Hello,

    I just wanted to give you a short update on this issue.

    Now after several Office 2016 updates the problem with the MAPI seems to exist no longer. Our application no longer crashes. Seems like MS has fixed this problem.

    Thank you very very much for all your effort and time that you've invested to help me solve this problem.

    Best regards,

    Christian

    Friday, July 7, 2017 8:06 AM