+++ This bug was initially created as a clone of Bug #1523818 +++

Still seeing a few crashes. Examples:
bp-7bbaccf3-2f41-4082-83ef-255c20190912 68.1.0
0 xul.dll nsMapiHook::PopulateCompFieldsW(__MIDL___MIDL_itf_msgMapi_0000_0000_0006*, nsIMsgCompFields*) comm/mailnews/mapi/mapihook/src/msgMapiHook.cpp:697 context
1 xul.dll CMapiImp::SendMailW(unsigned long, MIDL___MIDL_itf_msgMapi_0000_0000_0006*, unsigned long, unsigned long) comm/mailnews/mapi/mapihook/src/msgMapiImp.cpp:222 cfi
2 rpcrt4.dll Invoke cfi
3 rpcrt4.dll NdrStubCall2 frame_pointer
4 combase.dll CStdStubBuffer_Invoke d:\rs1\onecore\com\combase\ndr\ndrole\stub.cxx:1520 cfi
5 rpcrt4.dll CStdStubBuffer_Invoke cfi
6 combase.dll ObjectMethodExceptionHandlingAction<<lambda_1ba7c1521bf8e7d0ebd8f0b3c0295667> >(<lambda_1ba7c1521bf8e7d0ebd8f0b3c0295667>, ObjectMethodExceptionHandlingInfo*, ExceptionHandlingResult*, void*) d:\rs1\onecore\com\combase\dcomrem\excepn.hxx:91 cfi
7 combase.dll DefaultStubInvoke(bool, IServerCall*, IRpcChannelBuffer*, IRpcStubBuffer*, unsigned long*) d:\rs1\onecore\com\combase\dcomrem\channelb.cxx:1891 cfi
8 combase.dll ServerCall::ContextInvoke(tagRPCOLEMESSAGE*, IRpcStubBuffer*, CServerChannel*, tagIPIDEntry*, unsigned long*) d:\rs1\onecore\com\combase\dcomrem\ctxchnl.cxx:1541 cfi
9 combase.dll AppInvoke(ServerCall*, CServerChannel*, IRpcStubBuffer*, void*, void*, tagIPIDEntry*, WireLocalThis*) d:\rs1\onecore\com\combase\dcomrem\channelb.cxx:1604 cfi
10 combase.dll ComInvokeWithLockAndIPID(ServerCall*, tagIPIDEntry*, bool*) d:\rs1\onecore\com\combase\dcomrem\channelb.cxx:2721 cfi
11 combase.dll ThreadWndProc(HWND*, unsigned int, unsigned int, long) d:\rs1\onecore\com\combase\dcomrem\chancont.cxx:734 cfi

bp-89b1c902-b228-4ad6-9eff-e4f430190912 68.0

We really need to find out which external application calls us here. The use the new SendMailW() interface and crash here:

nsresult nsMapiHook::PopulateCompFieldsW(lpnsMapiMessageW aMessage,
                                         nsIMsgCompFields *aCompFields) {
  if (aMessage->lpOriginator && aMessage->lpOriginator->lpszAddress)
    aCompFields->SetFrom(
        nsDependentString(aMessage->lpOriginator->lpszAddress));

When this function is called, aMessage cannot be null, the caller checks that. We carefully check all the fields before accessing them.

So this must be the case of a rogue caller passing a corrupt message structure or some other memory corruption. Impossible to solve without a reproducible case.

I don't have any testcases yet. I can offier that >60% of our user population is on Windows 10, but for this crash signature <7% are win10 - quite a disparity.

Mike, does the above observation suggest an approach, or some testing possibilities?

(In reply to Wayne Mery (:wsmwk) from comment #2)

Unfortunately, I cannot guess which app communicating with TB could have such a strange distribution over different Windows versions :-)

In fact, I only can suggest adding a logger writing each case of using TB MAPI DLL into a file (rewriting lart data each time; in that moment, the process name is known and may be logged, since the DLL is used in the calling process address space), and when crashreporter prepares the data to send, also consider that file (possibly conditionally, when crash signature matches?); having the app name+version + MAPI DLL build id in addition to normal TB version info would be good.

Jorg, bug 558374 has a crash scenario.

Recent crash comments run the gamut of send from pdf creator, downsized images from image viewer, MAPI from Microsoft Office and Access, pdf from chrome, Excel. I tested several of these on win7 and no crash.

Examined 6 crashes - no consistency in AV packages afaict

Well, the comment in bug 558374 is from January and related to TB 60.4 which doesn't have CMapiImp::SendMailW, the "W" version. I don't have any of those M$ applications, and every time I try sending from LibreOffice it works.

Do you have a crash signature, some reports to look at or something? How frequent is the crash? One a day? 10, 100, 1000?

We have nothing concrete yet. Just mentioning what we do know, and still collecting data and attempting reach an actually user.

(In reply to Jorg K (GMT+1) (PTO to 15th Dec 2019, sporadically reading bugmail) from comment #7)

Do you have a crash signature, some reports to look at or something? How frequent is the crash? One a day? 10, 100, 1000?

Ryan reports we have no feedback from users who are reporting crashes. The rate is 11 per day, and over 90% is windows 7 and windows 8. So the rate is low. ANd given that most users are on windows 10 but the windows 10 crash rate is near zero, we can assume that in 2020 the crash rate should decrease as windows 7 usage drops.

The majority of crashes are still Windows 7 and 8.1.

Almost no Windows 10 crashes, less than one per day.
bp-9a081c45-393e-4020-bc18-900e10201231
0 xul.dll static nsMapiHook::PopulateCompFieldsW(__MIDL___MIDL_itf_msgMapi_0000_0000_0006*, nsIMsgCompFields*) comm/mailnews/mapi/mapihook/src/msgMapiHook.cpp:703
1 xul.dll CMapiImp::SendMailW(unsigned long, __MIDL___MIDL_itf_msgMapi_0000_0000_0006*, unsigned long, unsigned long) comm/mailnews/mapi/mapihook/src/msgMapiImp.cpp:222
2 rpcrt4.dll Invoke
3 rpcrt4.dll NdrStubCall2
4 combase.dll CStdStubBuffer_Invoke(IRpcStubBuffer*, tagRPCOLEMESSAGE*, IRpcChannelBuffer*) d:\th\com\combase\ndr\ndrole\stub.cxx:1521
5 rpcrt4.dll CStdStubBuffer_Invoke
6 combase.dll ObjectMethodExceptionHandlingAction<<lambda_adf5d6ba83bff890864fd80ca2bbf1eb> >(InvokeStubWithExceptionPolicyAndTracing::__l7::<lambda_adf5d6ba83bff890864fd80ca2bbf1eb>, ObjectMethodExceptionHandlingInfo*, ExceptionHandlingResult*, void*) d:\th\com\combase\dcomrem\excepn.hxx:91
7 combase.dll DefaultStubInvoke(bool, IServerCall*, IRpcChannelBuffer*, IRpcStubBuffer*, unsigned long*) d:\th\com\combase\dcomrem\channelb.cxx:1880
8 combase.dll ServerCall::ContextInvoke(tagRPCOLEMESSAGE*, IRpcStubBuffer*, CServerChannel*, tagIPIDEntry*, unsigned long*) d:\th\com\combase\dcomrem\ctxchnl.cxx:1568
9 combase.dll AppInvoke(ServerCall*, CServerChannel*, IRpcStubBuffer*, void*, void*, tagIPIDEntry*, WireLocalThis*) d:\th\com\combase\dcomrem\channelb.cxx:1606
10 combase.dll ComInvokeWithLockAndIPID(ServerCall*, tagIPIDEntry*, bool*) d:\th\com\combase\dcomrem\channelb.cxx:2686