[Tracking Requested - why for this release]: This bug was filed from the Socorro interface and is report bp-2db1a7b1-dc28-4d83-aa29-d0a1d2150114. ============================================================= This is the #3 crash in 36.0b1 with 3% of all crashes. This one is pretty bad as it's all startup. It's almost exclusively on Win7, and has a 100% correlation with WindowsApiHookDll32.dll and ActiveDetect32.dll, which both have no versions. Not sure where they come from. I'm putting it into JS for now as the stack shows this coming from js::random_initState but I'm not sure if the fault is on our side our those DLLs. 36 is mostly affected here but the signature appears in low volume on other channels, I haven't checked yet if it appears to be the same or a different issue there.

These DLLs are from Lenovo Onekey Theater. Image path: C:\Program Files (x86)\Lenovo\Onekey Theater\ActiveDetect32.dll Image path: C:\Program Files (x86)\Lenovo\Onekey Theater\WindowsApiHookDll32.dll Looks like this app has been around for a while. Not sure what caused these crashes to start now. Timestamp: Fri Dec 18 19:00:59 2009 (4B2B1A9B) Timestamp: Wed Feb 16 18:15:20 2011 (4D5B5D68)

In the minidumps, rand_s tried to call LoadLibrary("advapi32.dll") but the call failed. I found a different version of Onekey Theater on Lenovo's website. It doesn't crash my Win7 VM, but I do see these DLLs hooking LoadLibraryExW. Their hook is probably messing up the load of advapi32.

Chrome had the same crash at crbug.com/379218 and blocked these DLLs. That's likely the only option for us as well. I haven't been able to reproduce the crash but I've confirmed that our blocklist can stop these modules.

Topcrash, tracking.

David, could you fill the uplift requests to aurora & beta? thanks

Comment on attachment 8552830 [details] [diff] [review] Block Lenovo Onekey Theater Approval Request Comment [Feature/regressing bug #]: Lenovo Onekey Theater [User impact if declined]: Startup crashes [Describe test coverage new/current, TreeHerder]: A day on m-c [Risks and why]: Our big-hammer approach will prevent this app from running in FF altogether. Maybe there's a way we could stop the crash without breaking the app, but I can't say without a repro. [String/UUID change made/needed]: None

https://hg.mozilla.org/releases/mozilla-aurora/rev/2dca8b96f733 https://hg.mozilla.org/releases/mozilla-beta/rev/f35aa2298df8

The crash-stats for the last week are as it follows: - 7 crashes for 36.0b5 (down from 600 crashes on 36.0b4) - 18 crashes on 37.0a2 - 4 crashes on 38.0a1 I will monitor these stats for another week before closing.

In the last 7 days there still are a number of: - 41 crashes on 36.0b6 - 24 crashes on 37.0a2 - 7 crashes on 38.0a1. Robert, given these stats and the fact that bug 825600 is still open, do you consider we can close this one?

David can reply to the question in comment #12 better than me.

I think we're good here. We've successfully blocked the crashy Lenovo utility. The few remaining crashes are caused by other binaries. Individually they aren't high enough volume to pursue.

Alrighty then! Closing this issue based on the above results and comments. Thank you!