Answered by:
.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?
- Edited by Jaspreet Bakshi Sunday, January 26, 2014 4:35 AM typo
Sunday, January 26, 2014 4:17 AM
Answers
-
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!- Edited by Dmitry Streblechenko _MVP_MVP Sunday, January 26, 2014 5:56 PM
- Proposed as answer by Eric Legault [MVP - Office Apps and Services]MVP Wednesday, January 29, 2014 3:16 PM
- Marked as answer by George Hua Tuesday, February 4, 2014 6:44 AM
Sunday, January 26, 2014 5: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) http://www.dimastr.com/redemption
Redemption - what the Outlook
Object Model should have been
Version 5.5 is now available!- Marked as answer by George Hua Tuesday, February 4, 2014 6:44 AM
Sunday, January 26, 2014 7:00 PM
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 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.
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) http://www.dimastr.com/redemption
Redemption - what the Outlook
Object Model should have been
Version 5.5 is now available!- Edited by Dmitry Streblechenko _MVP_MVP Sunday, January 26, 2014 5:56 PM
- Proposed as answer by Eric Legault [MVP - Office Apps and Services]MVP Wednesday, January 29, 2014 3:16 PM
- Marked as answer by George Hua Tuesday, February 4, 2014 6:44 AM
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.
Jaspreet
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?
Thanks,
Jaspreet
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) http://www.dimastr.com/redemption
Redemption - what the Outlook
Object Model should have been
Version 5.5 is now available!- Marked as answer by George Hua Tuesday, February 4, 2014 6:44 AM
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?
Jaspreet
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) http://www.dimastr.com/redemption
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.
Jaspreet
Monday, January 27, 2014 7:11 PM