1458238 - Crash spike in win10 1803 with a11y and sticky password manager

Status: RESOLVED WONTFIX

(External Software Affecting Firefox :: Other, defect, P2)

Description

[[:philipp]]

This bug was filed from the Socorro interface and is
report bp-7e465d17-99fb-419a-a7d9-ca7b40180501.
=============================================================

Top 10 frames of crashing thread:

0 kernelbase.dll WaitForMultipleObjectsEx 
1 kernelbase.dll WaitForMultipleObjects 
2 combase.dll FeatureDevelopmentProperties::ForEachPropertyScopeUntilFound<<lambda_32d9488df7173826dca13609ecd7b2f1> > onecore\com\combase\featuredevelopmentproperties\lib\featuredevelopmentproperties.cpp:472
3 combase.dll FeatureDevelopmentProperties::Query onecore\com\combase\featuredevelopmentproperties\lib\featuredevelopmentproperties.cpp:951
4 combase.dll CAsyncCall::GetAllocationLookaside onecore\com\combase\dcomrem\call.cxx:969
5 combase.dll ObjectLibrary::Details::AddAllocation_AllocationHeaderLayer<CAsyncCall, ObjectLibrary::Details::AddAllocation_LookasideLayer<CAsyncCall, ObjectLibrary::Details::AddAllocation_CachingLayer<ObjectLibrary::AllocationCachingOptions<8>, CAsyncCall, ObjectLibrary::Details::AddAllocation_InheritedAllocatorLayer<CAsyncCall, ObjectLibrary::AddComReferenceCounting<ObjectLibrary::ComReferenceCountingOptions<65>, CAsyncCall, ObjectLibrary::ForwardedBases<CMessageCall> > > > > >::AddAllocation_Alloc onecore\com\combase\objectlibrary\inc\allocation.hpp:580
6 combase.dll ClientCall::CreateTransportCallObject onecore\com\combase\dcomrem\channelb.cxx:3647
7 combase.dll CClientChannel::InitCallObject onecore\com\combase\dcomrem\channelb.cxx:3600
8 combase.dll NdrExtNegotiateTransferSyntax onecore\com\combase\ndr\ndrole64\proxy.cxx:206
9 rpcrt4.dll NdrpClientCall3 

=============================================================

i'm unsure in what component to file this. a couple of hours after the general rollout of the windows 10 april update (1803) by microsoft started, there are a number of browser crash signatures spiking up on that platform. the reports all seem to have accessibility turned on, which is instantiated by "sticky password manager". (can we reach out to that company btw, why they are hooking into the browser this way?)

so far those signatures are accounting for 40% of browser crashes on release from early data of the win1803 rollout.

perhaps the crashing is somewhat similar to bug 1424505?

Comment 1

[(No longer employed by Mozilla) Aaron Klotz]

This is definitely something new. Those other crashes were access violations; these ones are stack overflows.

Comment 2

[Adam Stevenson [:adamopenweb]]

Reaching out to them on their website and over LinkedIn.

Comment 3

[James Teh [:Jamie]]

If you manage to establish contact, would you mind looping me in? Even if we can't convince them to use something other than a11y, I may be able to get somewhere if I can figure out exactly how they're doing things.

Comment 4

[Mike Taylor [:miketaylr]]

(ni? adam for Comment #3)

Comment 5

[Adam Stevenson [:adamopenweb]]

Will do James.

I heard back from their support that they've forwarded my message to the CTO, should be hearing backing soon.

Comment 6

[(No longer employed by Mozilla) Aaron Klotz]

Should we open a channel with Microsoft as well?

Comment 7

[Adam Stevenson [:adamopenweb]]

If we do, we have a mailing list with Microsoft. I can add anyone that needs access.

Comment 8

[James Teh [:Jamie]]

I have a separate channel to the accessibility folks at Microsoft. It's highly likely this is related to UI Automation, so it's probably worth me following up with them directly. A crash dump would be a good thing to have, though, which means we'd need to find someone who can reproduce it who's willing to sign off on providing one.

Comment 9

[Adam Stevenson [:adamopenweb]]

Update from CTO: 
"Our extension developer is already looking on this case and will contact you soon."

Comment 10

[[:philipp]]

apparently this produces crashes in roboform-x64.dll as well (don't know why users would install multiple password managers at a time though). all of them have accessibility on apparently triggered by sticky passwords too.

an example where the user also notes the third-party interference in the comment would be bp-8a723745-c1ba-47e0-a14d-e87430180501

Comment 11

[Adam Stevenson [:adamopenweb]]

Heard back from them. Looping in :Jamie on the thread.

Comment 12

[[:philipp]]

the volume of this crash is declining quickly since the start of the week - i'm not sure which factor contributed to that though (firefox 60.0, windows patchday, update in the 3rd-party app)...

Comment 13

[Julien Cristau [:jcristau] (back April 22)]

wontfix for 60 based on comment 12

Comment 14

[BugBot [:suhaib / :marco/ :calixte]]

Redirect a needinfo that is pending on an inactive user to the triage owner.
:haik, since the bug has high priority and high severity, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 15

[Haik Aftandilian [:haik]]

The volume is very low now (1 or 2 crashes a day) down from the 40% of Release crashes when the bug was filed.