633446 - Crash [@ ntdll.dll@0x9a0fc ][@ntdll.dll@0x9c7bd] mainly with Norton IPS 2.0

Status: RESOLVED WORKSFORME

(Firefox :: Extension Compatibility, defect)

Description

[Scoobidiver (away)]

It is #32 top crasher in 4.0b11.
Extension correlations give:
97% (68/70) vs.   4% (996/25018) {BBDA0591-3099-440a-AA10-41764D9DB4DB} (2.0) (Norton IPS)

Signature	ntdll.dll@0x9a0fc
UUID	b8dbe392-a9b3-4fa9-954a-01b682110210
Time 	2011-02-10 19:59:41.772999
Uptime	4
Last Crash	7 seconds before submission
Install Age	116 seconds since version was first installed.
Product	Firefox
Version	4.0b11
Build ID	20110203141415
Branch	2.0
OS	Windows NT
OS Version	6.1.7600
CPU	x86
CPU Info	AuthenticAMD family 15 model 107 stepping 2
Crash Reason	0xc000070a / 0x00000000
Crash Address	0x7785a0fc
User Comments	
App Notes 	AdapterVendorID: 10de, AdapterDeviceID: 0641, AdapterDriverVersion: 8.17.12.5896

Frame 	Module 	Signature [Expand] 	Source
0 	ntdll.dll 	ntdll.dll@0x9a0fc 	
1 	kernel32.dll 	BaseThreadInitThunk 	
2 	ntdll.dll 	ntdll.dll@0x5b428 	
3 	ntdll.dll 	ntdll.dll@0x5b3fb 	

More reports at:
https://crash-stats.mozilla.com/report/list?range_value=4&range_unit=weeks&signature=ntdll.dll%400x9a0fc

Comment 1

[Daniel Veditz [:dveditz]]

Probably doesn't block Firefox 3.6.14 and probably isn't our fault:
 - only seen on Windows 7
 - even with a 4-wk crash range no crashes seen before Feb 6 and they
   don't start in earnest until Feb 9 -- some external change/update
   and not a change in Firefox
 - happens in older versions (3.6.10, 3.6.13), but worryingly less
   often than in 3.6.14 with only a fraction of the users

Similar pattern for ntdll.dll@0x9c7bd -- related? 
https://crash-stats.mozilla.com/report/list?range_value=4&range_unit=weeks&signature=ntdll.dll%400x9c7bd

0x9c7bd is also correlated with Norton IPS but not quite as strongly
54% (13/24) vs.   5% (8150/179575) {BBDA0591-3099-440a-AA10-41764D9DB4DB}

(correlation report was for 3.6.13)

Also strongly correlated with multiple cores (especially 4) and rarely happens on 1 core -- is that because it's a threading bug (BaseThreadInitThunk in stack) or because it's a bug on Win7 and Win7 is run on modern hardware that usually is multi-core?

Each of these have jumped up pretty high on the 3.6.14 topcrash report, #2 and #6. Doesn't show up in the 3.6.13 top-300, not even on the 3-day report.

Comment 2

[Daniel Veditz [:dveditz]]

Should say also that it happens a LOT more on the just-updated 3.6.14 build2 beta than it does on the build1 which most users actually have.

Comment 3

[Daniel Veditz [:dveditz]]

This has dropped to #27 so I'm going to say "not blocking", but its possibly a good candidate for blocklisting. Although blocklisting removes this A-V protection from all users, not just the ones who are crashing. Ultimately seems like a better solution to have the crash reporter point people at solutions based on their crash signatures.

Comment 4

[Matthew Middleton (:zzxc)]

A quick way to reproduce this crash is to delete plugin-container.exe from the application folder and attempt to visit youtube.com with Flash enabled.  Since Norton occasionally does this after updates, it could be the cause for the reporting users.

Comment 5

[Ed Morley [:emorley]]

If it helps, a user who is experiencing these crashes has filed a bug here: Bug 639363

Although from comment 4, seems like repo'ing is possible anyway.

Comment 7

[Scoobidiver (away)]

There have been no crashes for the last four weeks.
I close it as WFM.