#4 crash for 51.0b1. It happens to 51.0b1, 51.0a2, and 52.0a2 (20161222), all *starting* 2016-01-11.  About 1/2 are startup, 1/2 decidedly not. I haven't found any other common factor to startup times, OS versions or addons. Caused by a windows update? AV? bp-1cf1040c-644b-4d38-9b52-209522170111 52.0a2 startup crash 0 xul.dll CMapiImp::Login(unsigned long, wchar_t* const, wchar_t* const, unsigned long, unsigned long*) C:/builds/moz2_slave/tb-c-aurora-w32-ntly-000000000/build/mailnews/mapi/mapihook/src/msgMapiImp.cpp:161 1 rpcrt4.dll Invoke 2 rpcrt4.dll NdrStubCall2 3 combase.dll CStdStubBuffer_Invoke d:\rs1\onecore\com\combase\ndr\ndrole\stub.cxx:1520 4 rpcrt4.dll CStdStubBuffer_Invoke 5 combase.dll ObjectMethodExceptionHandlingAction<<lambda_1ba7c1521bf8e7d0ebd8f0b3c0295667> >(<lambda_1ba7c1521bf8e7d0ebd8f0b3c0295667>, ObjectMethodExceptionHandlingInfo*, ExceptionHandlingResult*, void*) d:\rs1\onecore\com\combase\dcomrem\excepn.hxx:91 6 combase.dll DefaultStubInvoke(bool, IServerCall*, IRpcChannelBuffer*, IRpcStubBuffer*, unsigned long*) d:\rs1\onecore\com\combase\dcomrem\channelb.cxx:1891 7 combase.dll ServerCall::ContextInvoke(tagRPCOLEMESSAGE*, IRpcStubBuffer*, CServerChannel*, tagIPIDEntry*, unsigned long*) d:\rs1\onecore\com\combase\dcomrem\ctxchnl.cxx:1541 8 combase.dll AppInvoke(ServerCall*, CServerChannel*, IRpcStubBuffer*, void*, void*, tagIPIDEntry*, WireLocalThis*) d:\rs1\onecore\com\combase\dcomrem\channelb.cxx:1604 9 combase.dll ComInvokeWithLockAndIPID(ServerCall*, tagIPIDEntry*, bool*) d:\rs1\onecore\com\combase\dcomrem\channelb.cxx:2722 10 combase.dll ThreadWndProc(HWND__*, unsigned int, unsigned int, long) d:\rs1\onecore\com\combase\dcomrem\chancont.cxx:734 bp-f0884ad3-b564-4645-9e13-65c062170113 51.0b1 NOT startup 0 xul.dll CMapiImp::Login(unsigned long, wchar_t* const, wchar_t* const, unsigned long, unsigned long*) C:/builds/moz2_slave/tb-rel-c-beta-w32_bld-00000000/build/mailnews/mapi/mapihook/src/msgMapiImp.cpp:161 Ø 1 rpcrt4.dll rpcrt4.dll@0x35a49 Ø 2 rpcrt4.dll rpcrt4.dll@0xb05f0 3 ole32.dll ole32.dll@0x13e7e5 4 ole32.dll ThreadInvoke 5 ole32.dll CStdPSFactoryBuffer_QueryInterface 6 ole32.dll CCtxComChnl::ContextInvoke(tagRPCOLEMESSAGE*, IRpcStubBuffer*, tagIPIDEntry*, unsigned long*) 7 ole32.dll MTAInvoke(tagRPCOLEMESSAGE*, unsigned long, IRpcStubBuffer*, IInternalChannelBuffer*, tagIPIDEntry*, unsigned long*) d:\w7rtm\com\ole32\com\dcomrem\callctrl.cxx:2097 8 ole32.dll STAInvoke(tagRPCOLEMESSAGE*, unsigned long, IRpcStubBuffer*, IInternalChannelBuffer*, void*, tagIPIDEntry*, unsigned long*) 9 ole32.dll HMENU_UserUnmarshal d:\w7rtm\com\ole32\oleprx32\proxy\transmit.cxx:484 10 ole32.dll NdrpCreateNonDelegatedAsyncStub 11 ole32.dll NdrpInitializeStublessVtbl 12 ole32.dll ThreadDispatch(void*) 13 ole32.dll ThreadWndProc(HWND__*, unsigned int, unsigned int, long) 14 user32.dll InternalCallWinProc 15 user32.dll UserCallWinProcCheckWow 16 user32.dll DispatchMessageWorker 17 user32.dll DispatchMessageW 18 xul.dll nsAppShell::ProcessNextNativeEvent(bool) widget/windows/nsAppShell.cpp:375  https://crash-stats.mozilla.com/search/?signature=~CMapiImp&date=%3E%3D2016-12-30T13%3A34%3A18.000Z&date=%3C2017-01-13T13%3A34%3A18.000Z&_sort=-date&_facets=signature&_columns=date&_columns=signature&_columns=version&_columns=build_id&_columns=platform&_columns=uptime&_columns=platform_version&_columns=user_comments#crash-reports
one can say, so far all crashes are windows
Odd. If one goes back to earlier dates, 3 months and 6 months, there are periodic spikes. 3mo. https://crash-stats.mozilla.com/signature/?signature=CMapiImp%3A%3ALogin&date=%3E%3D2016-10-13T14%3A18%3A15.000Z&date=%3C2017-01-13T14%3A18%3A15.000Z#graphs
could be show stopper for 52. #1 crash for 51.0b2]1] and 51.0b1 (if you exclude the Mac-messyness). Assuming this will also impact 52 beta, but can't tell via crash-stats I'm thinking one of these likely caused regression https://mzl.la/2jGkwHr I can't tell which one because we don't have a regression range for this crash.  https://crash-stats.mozilla.com/topcrashers/?product=Thunderbird&version=51.0b2
Looking at https://crash-stats.mozilla.com/report/index/7c044f31-911a-43db-aac3-550b92170120 I see a crash in C++ code here: mailnews/mapi/mapihook/src/msgMapiImp.cpp:161 Clearly there is a hole in the code: account->GetDefaultIdentity(getter_AddRefs(identity)); NS_ENSURE_SUCCESS(rv,MAPI_E_LOGIN_FAILURE); identity->GetKey(id_key); So we're getting the default identity and then dereference it. Hmm, there's an error check, but maybe that passes even of there is no default account. Patch coming.
Created attachment 8828789 [details] [diff] [review] 1330955-mapi-crash.patch (v1).
Created attachment 8828873 [details] [diff] [review] 1330955-mapi-crash.patch (v2). Oops, didn't notice that there was a |rv = | missing. Aceman pointed it out.
Comment on attachment 8828873 [details] [diff] [review] 1330955-mapi-crash.patch (v2). I did not actually build and test, but makes sense.
https://hg.mozilla.org/comm-central/rev/c3771425de0e070de6d5a5f2e6c62e8116f92379 How's that for a fast turnaround ;-)
Comment on attachment 8828873 [details] [diff] [review] 1330955-mapi-crash.patch (v2). Let's take it to TB 52 so Wayne can sleep soundly at night ;-) The fix might shift the problem elsewhere, but at least we don't crash at that spot any more. Thanks Wayne for tirelessly looking at the crash stats. Fixing a bug is good, but fixing a crash is even better since it's obviously the worst bug imaginable! I looked at most of the 19 reports and didn't see a single one with user comments, so I wonder what's going on there.
a query covering more time https://crash-stats.mozilla.com/signature/?product=Thunderbird&_sort=-date&signature=CMapiImp%3A%3ALogin&date=%3E%3D2016-10-21T04%3A09%3A33.000Z&date=%3C2017-01-21T04%3A09%3A33.000Z#comments is much better than comment 3's for getting comments. Numerous "I can't send a picture".
I like these comments: This mail program now sucks. like your Browser. I'm getting to the point where I hate Thunderbird mail. Ah well. I think this MAPI stuff is exercising the (right-click) "Send to > Mail recipient". As I said, it will no longer crash there, but I don't know where the problem of not having a default account will shift next.
If the user hasn't set up any mail account in TB, then it hardly can send out anything. We just need to return a proper error to the MAPI caller application.
I would think prior to 51.0b1 the reporters had successfully sent email in this manner. So something must have changed. But I am at a loss to define it. I am attempting to find a connection. aceman, how would I go about creating a condition where the profile has no default account? I cannot reproduce with profile that has no accounts (autoconfig kicks in to set up a new account) > I like these comments: Heh. Such comments are not uncommon by frustrated users. Goes with the territory. Best to ignore.
(In reply to Wayne Mery (:wsmwk, NI for questions) from comment #13) > aceman, how would I go about creating a condition where the profile has no > default account? I cannot reproduce with profile that has no accounts > (autoconfig kicks in to set up a new account) Can that be dismissed? Or try making a RSS or news account only. I think some of these other accounts can't be default, but TB may stop to request creating a mail account. I know there are many places in code we have to defend as getting the default account throws in JS if there is none.
Aurora (TB 52): https://hg.mozilla.org/releases/comm-aurora/rev/2cb76a40f3f6e8523ca2257955650c0f085d5158
v.fixed in 52.0b2