.NET desktop application crashes in unmanaged MAPI thread

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

PSTPRX32.DLL!000007fee8b35cd7()     
[Frames below may be incorrect and/or missing, no symbols loaded for PSTPRX32.DLL]  
PSTPRX32.DLL!000007fee8b3a9c4()     
PSTPRX32.DLL!000007fee8b3ae2d()     
PSTPRX32.DLL!000007fee8b3b160()     
PSTPRX32.DLL!000007fee8b458de()     
PSTPRX32.DLL!000007fee8b4d7de()     
PSTPRX32.DLL!000007fee8b3f5a0()     
PSTPRX32.DLL!000007fee8b39c57()     
OUTLMIME.DLL!000007fee2c61d60()     
OUTLMIME.DLL!000007fee2c69c92()     
OUTLMIME.DLL!000007fee2c6a56a()     
OUTLMIME.DLL!000007fee2c6a8d5()     
OUTLMIME.DLL!000007fee2c6aa74()     
OUTLMIME.DLL!000007fee2c58b68()     
OUTLMIME.DLL!000007fee2c5b05f()     
OUTLMIME.DLL!000007fee2c5b17c()     
OUTLMIME.DLL!000007fee2c5b58d()     
OUTLMIME.DLL!000007fee2c59750()     
user32.dll!UserCallWinProcCheckWow()  + 0x11d bytes 
user32.dll!DispatchMessageWorker()  + 0x12a bytes   
PSTPRX32.DLL!000007fee8b36876()     
OLMAPI32.DLL!000007fee028554b()     
MSO.DLL!000007fed94230e4()  
MSO.DLL!000007fed9422d9e()  
MSO.DLL!000007fed9422c00()  
MSO.DLL!000007fed942278b()  
MSO.DLL!000007fed92d5079()  
kernel32.dll!BaseThreadInitThunk()  + 0xd bytes 
ntdll.dll!RtlUserThreadStart()  + 0x21 bytes    

Questions:

• 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?

Answer 1

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 http://support.microsoft.com/kb/266353/en 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.

Answer 2

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)
http://www.dimastr.com/redemption Redemption - what the Outlook Object Model should have been Version 5.5 is now available!

Answer 3

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. 

Jaspreet

Answer 4

Hi Dmitry

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

Thanks,

Jaspreet

Answer 5

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)
http://www.dimastr.com/redemption Redemption - what the Outlook Object Model should have been Version 5.5 is now available!

Answer 6

Ah I see. Thanks. 

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

Jaspreet

Answer 7

No, I don't think so. How would the symbols help? There is really nothing you can do besides using IProxyStoreObject.

---

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

Answer 8

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.

Jaspreet