.NET desktop application crashes in unmanaged MAPI thread RRS feed

  • Question

  • This is a .NET 4.0 (and WPF) application that has an unmanaged C++ component that accesses Outlook PSTs via MAPI. Recently, in one part of that code, where the application accesses the messages of a folder, I made a change to start using IMapiTable::Restrict instead of IMapiTable::FindRow, and I suspect that might be the source of the issue I am seeing.

    The issue is a crash that happens sometime after the application has run but not at a predictable state or time. The thread seems to have been spun up by MAPI and has no frame with code from the application. Concurrent (at the time of the crash) threads that do have frames with application code are different each time the crash happens (and at least so far I haven't been able to discern a pattern).

    I can only trap this exception if I turn on native code debugging (Project Properties > Debug > Enable native code debugging). If I don't do that, the application exits without any sort of indication as to what the exception was.

    That's the exception

    First-chance exception at 0x000007fee8b35cd7 in <application name>: 
    0xC0000005: Access violation reading location 0xffffffffffffffff.

    And that's the callstack

    [Frames below may be incorrect and/or missing, no symbols loaded for PSTPRX32.DLL]  
    user32.dll!UserCallWinProcCheckWow()  + 0x11d bytes 
    user32.dll!DispatchMessageWorker()  + 0x12a bytes   
    kernel32.dll!BaseThreadInitThunk()  + 0xd bytes 
    ntdll.dll!RtlUserThreadStart()  + 0x21 bytes    


    • Does anyone with insight into MAPI know what the issue is or what this thread might be?
    • Can I get missing symbols for the dlls in the stack?
    • Is there any other advice on how to debug this further?

    Sunday, January 26, 2014 4:17 AM


All replies

  • Hello Jaspreet,

    Why do you need to use Extended MAPI from a managed code? 

     Microsoft doesn't recommend and doesn't support using Extended MAPI from a managed code. The "The support guidelines for client-side messaging development" at article states the following:

    MAPI was originally designed and originally developed in the late   1980s. Therefore, MAPI predates managed code in the Microsoft .NET Framework.   We do not provide managed wrappers for MAPI, and we discourage you from using   third-party wrappers. This is because solutions may seem to work in a test   environment, but issues that are related to memory management may occur when an   application is deployed in a production environment and is exposed to   real-world scalability scenarios.

    I'd recommend automating Outlook instead.

    Sunday, January 26, 2014 11:26 AM
  • That sure looks like the IMAP4 store provider. The problem is that every time you touch it, it launches a secondary thread that tries to sync to the IMAP4 server. If you release the object before that thread completes, you will end up with a crash.

    You need to either make sure you keep these objects alive for a long time, or you need to unwrap the IMAP4 store (which is built on top of the PST provider) using the IProxyStoreObject object.

    Dmitry Streblechenko (MVP)
    Redemption - what the Outlook
    Object Model should have been
    Version 5.5 is now available!

    Sunday, January 26, 2014 5:55 PM
  • Hi Eugene

    I'm not enough of an interoperability expert but I think we're doing something fairly well supported. The C++ part of our code base uses MAPI to access PSTs and returns our own (not MAPI) objects to the managed C# part. 

    We arrived at this architecture mainly because of performance reasons. There is no alternate approach (out of what I have seen) that can provide performance even close to this approach. 


    Sunday, January 26, 2014 6:48 PM
  • Hi Dmitry

    That sounds promising. It is indeed an IMAP store. How could you tell from the call stack?



    Sunday, January 26, 2014 6:55 PM
  • PSTPRX32.DLL is the IMAP4 provider. Every time you see a crash with PSTPRX32.DLL on the call stack, there can be only one explanation :-)

    Dmitry Streblechenko (MVP)
    Redemption - what the Outlook
    Object Model should have been
    Version 5.5 is now available!

    Sunday, January 26, 2014 7:00 PM
  • Ah I see. Thanks. 

    Another question... Is it possible to get symbols for the dlls in that stack?


    Sunday, January 26, 2014 8:27 PM
  • No, I don't think so. How would the symbols help? There is really nothing you can do besides using IProxyStoreObject.

    Dmitry Streblechenko (MVP)
    Redemption - what the Outlook
    Object Model should have been
    Version 5.5 is now available!

    Sunday, January 26, 2014 9:00 PM
  • I thought the symbols would be great to have (if availble) mainly to confirm the hypothesis and for future debugging. 

    But thanks again for the tip... I am going to see if getting the IProxyStoreObject fixes my issue.


    Monday, January 27, 2014 7:11 PM