Closed Bug 1139497 Opened 10 years ago Closed 9 years ago

Rise of "* | BaseThreadInitThunk" crashes in 37 Beta (nprotect)

Categories

(Firefox :: General, defect, P2)

Product:
Firefox
Component:
General
Platform:
x86
Windows 7
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
firefox37 + wontfix
firefox38 + wontfix
firefox38.0.5 + wontfix
firefox39 + wontfix
firefox40 + wontfix
firefox41 --- ?
firefox42 --- ?
firefox43 --- ?
firefox-esr38 39+ affected

People

(Reporter: kairo, Assigned: bobowen)

References

(Blocks 1 open bug)

Details

(Keywords: crash, topcrash)

Crash Data

[Tracking Requested - why for this release]: I'm filing this as separate as bug 846239 has a specific 3rd party connection and we probably have a different one here. We have those signatures at 2.1% (#2) + 1.6% (#8) on early 37.0b2 data, so pretty significant volume in general (see links in Crash Signature field for reports and stats). Correlations aren't exactly clear to me, I'm pasting them here because Socorro seems to not correctly show them in its UI (those are for yesterday, from https://crash-analysis.mozilla.com/crash_analysis/20150303/20150303_Firefox_37.0-interesting-modules.txt.gz if you want to look yourself): zzz_AsmCodeRange_Begin | BaseThreadInitThunk|0xc000070a / 0x00000000 (599 crashes) 89% (533/599) vs. 18% (16185/87854) rtutils.dll 88% (529/599) vs. 18% (15957/87854) rasman.dll 88% (529/599) vs. 18% (15957/87854) rasapi32.dll 78% (465/599) vs. 13% (11132/87854) SensApi.dll 97% (584/599) vs. 43% (38036/87854) urlmon.dll 50% (302/599) vs. 7% (5888/87854) d3d10.dll 50% (302/599) vs. 7% (5888/87854) d3d10core.dll 98% (586/599) vs. 58% (51192/87854) apphelp.dll 51% (307/599) vs. 18% (15769/87854) d3d10_1core.dll 51% (307/599) vs. 18% (15769/87854) d3d10_1.dll 26% (155/599) vs. 1% (721/87854) npggNT.des 32% (189/599) vs. 10% (8989/87854) igd10umd32.dll 100% (599/599) vs. 85% (75070/87854) RpcRtRemote.dll 98% (585/599) vs. 84% (73794/87854) wship6.dll 100% (598/599) vs. 86% (75770/87854) Wldap32.dll 100% (599/599) vs. 87% (76092/87854) WSHTCPIP.DLL 15% (92/599) vs. 2% (2050/87854) D3Dx10_40.dll 17% (99/599) vs. 4% (3620/87854) atiuxpag.dll 17% (99/599) vs. 4% (3724/87854) aticfx32.dll 17% (99/599) vs. 4% (3814/87854) atidxx32.dll 100% (599/599) vs. 89% (78025/87854) samlib.dll 100% (599/599) vs. 89% (78265/87854) Wpc.dll 100% (599/599) vs. 89% (78266/87854) wevtapi.dll 100% (599/599) vs. 89% (78274/87854) explorerframe.dll 100% (599/599) vs. 89% (78472/87854) pnrpnsp.dll 100% (599/599) vs. 89% (78496/87854) duser.dll 100% (599/599) vs. 89% (78496/87854) dui70.dll 98% (585/599) vs. 87% (76822/87854) sspicli.dll 99% (594/599) vs. 89% (78327/87854) ntdsapi.dll 98% (585/599) vs. 88% (77269/87854) FWPUCLNT.DLL 100% (599/599) vs. 91% (79550/87854) lpk.dll 100% (599/599) vs. 91% (80266/87854) NapiNSP.dll 100% (599/599) vs. 91% (80378/87854) DWrite.dll 100% (599/599) vs. 92% (80610/87854) cryptsp.dll 99% (593/599) vs. 91% (79741/87854) d2d1.dll 10% (62/599) vs. 2% (1899/87854) iNetSafe.dll 10% (62/599) vs. 2% (1972/87854) safemon.dll 15% (91/599) vs. 7% (6286/87854) ncrypt.dll 99% (594/599) vs. 91% (80194/87854) nlaapi.dll 99% (593/599) vs. 91% (80141/87854) d3d11.dll 99% (593/599) vs. 91% (80143/87854) dxgi.dll 98% (585/599) vs. 90% (79471/87854) iertutil.dll 100% (599/599) vs. 93% (81689/87854) profapi.dll 98% (585/599) vs. 91% (79678/87854) wininet.dll 9% (51/599) vs. 2% (1518/87854) I18N.dll 100% (599/599) vs. 93% (81924/87854) propsys.dll 100% (599/599) vs. 93% (81930/87854) devobj.dll 100% (599/599) vs. 93% (81930/87854) samcli.dll 100% (599/599) vs. 93% (81942/87854) sechost.dll 100% (599/599) vs. 93% (81947/87854) wkscli.dll 100% (599/599) vs. 93% (81947/87854) CRYPTBASE.dll 100% (599/599) vs. 93% (81947/87854) netutils.dll 100% (599/599) vs. 93% (81947/87854) srvcli.dll 100% (599/599) vs. 93% (81948/87854) KERNELBASE.dll 100% (599/599) vs. 93% (82088/87854) cfgmgr32.dll 100% (599/599) vs. 94% (82207/87854) powrprof.dll 99% (593/599) vs. 93% (81409/87854) MMDevAPI.dll 100% (599/599) vs. 94% (82377/87854) winnsi.dll 100% (599/599) vs. 94% (82377/87854) nsi.dll 100% (599/599) vs. 94% (82393/87854) IPHLPAPI.DLL 100% (599/599) vs. 94% (82394/87854) dwmapi.dll 7% (42/599) vs. 1% (798/87854) DETOURED.DLL 7% (42/599) vs. 1% (834/87854) SCDETOUR.DLL 100% (598/599) vs. 94% (82399/87854) wbemcomn.dll 99% (592/599) vs. 93% (81718/87854) nssckbi.dll 99% (592/599) vs. 93% (81846/87854) nssdbm3.dll 99% (592/599) vs. 93% (81859/87854) softokn3.dll 10% (59/599) vs. 4% (3812/87854) bcryptprimitives.dll 100% (599/599) vs. 95% (83103/87854) msctf.dll 99% (592/599) vs. 93% (82141/87854) freebl3.dll 6% (36/599) vs. 1% (635/87854) ScDetour.Dll 6% (36/599) vs. 1% (663/87854) Detoured.dll 100% (598/599) vs. 95% (83122/87854) wbemprox.dll 99% (594/599) vs. 94% (82558/87854) fastprox.dll 99% (594/599) vs. 94% (82635/87854) wbemsvc.dll RtlpCallQueryRegistryRoutine | BaseThreadInitThunk|0xc000070a / 0x00000000 (470 crashes) 75% (352/470) vs. 18% (15769/87854) d3d10_1core.dll 75% (352/470) vs. 18% (15769/87854) d3d10_1.dll 50% (236/470) vs. 1% (721/87854) npggNT.des 98% (461/470) vs. 58% (51192/87854) apphelp.dll 28% (131/470) vs. 4% (3814/87854) atidxx32.dll 27% (128/470) vs. 4% (3620/87854) atiuxpag.dll 27% (125/470) vs. 4% (3724/87854) aticfx32.dll 25% (118/470) vs. 4% (3392/87854) nvwgf2um.dll 31% (144/470) vs. 10% (8989/87854) igd10umd32.dll 29% (137/470) vs. 13% (11132/87854) SensApi.dll 23% (107/470) vs. 7% (5888/87854) d3d10.dll 23% (107/470) vs. 7% (5888/87854) d3d10core.dll 29% (138/470) vs. 14% (12092/87854) WLIDNSP.DLL 100% (470/470) vs. 85% (75070/87854) RpcRtRemote.dll 31% (144/470) vs. 16% (14326/87854) mdnsNSP.dll 98% (462/470) vs. 84% (73794/87854) wship6.dll 100% (470/470) vs. 86% (75770/87854) Wldap32.dll 100% (470/470) vs. 87% (76092/87854) WSHTCPIP.DLL 17% (81/470) vs. 4% (3812/87854) bcryptprimitives.dll 100% (470/470) vs. 87% (76822/87854) sspicli.dll 13% (63/470) vs. 1% (840/87854) nvspcap.dll 31% (144/470) vs. 18% (16185/87854) rtutils.dll 30% (140/470) vs. 18% (15957/87854) rasman.dll 30% (140/470) vs. 18% (15957/87854) rasapi32.dll 100% (470/470) vs. 89% (78025/87854) samlib.dll 97% (454/470) vs. 85% (75076/87854) AudioSes.dll 100% (470/470) vs. 89% (78265/87854) Wpc.dll 100% (470/470) vs. 89% (78266/87854) wevtapi.dll 100% (470/470) vs. 89% (78274/87854) explorerframe.dll 100% (470/470) vs. 89% (78472/87854) pnrpnsp.dll 100% (470/470) vs. 89% (78496/87854) duser.dll 100% (470/470) vs. 89% (78496/87854) dui70.dll 11% (50/470) vs. 1% (467/87854) guard32.dll 11% (50/470) vs. 1% (501/87854) fltLib.dll 100% (470/470) vs. 91% (79550/87854) lpk.dll 23% (109/470) vs. 14% (12347/87854) idmmkb.dll 97% (456/470) vs. 88% (77269/87854) FWPUCLNT.DLL 100% (470/470) vs. 91% (80194/87854) nlaapi.dll 100% (470/470) vs. 91% (80266/87854) NapiNSP.dll 100% (470/470) vs. 91% (80378/87854) DWrite.dll 100% (470/470) vs. 92% (80610/87854) cryptsp.dll 29% (137/470) vs. 21% (18642/87854) bcrypt.dll 8% (37/470) vs. 0% (395/87854) DpOSet.dll 8% (37/470) vs. 0% (396/87854) DpOFeedb.dll 100% (470/470) vs. 93% (81689/87854) profapi.dll 98% (459/470) vs. 91% (79741/87854) d2d1.dll 100% (470/470) vs. 93% (81924/87854) propsys.dll 100% (470/470) vs. 93% (81930/87854) devobj.dll 100% (470/470) vs. 93% (81930/87854) samcli.dll 100% (470/470) vs. 93% (81942/87854) sechost.dll 100% (470/470) vs. 93% (81947/87854) wkscli.dll 100% (470/470) vs. 93% (81947/87854) CRYPTBASE.dll 100% (470/470) vs. 93% (81947/87854) netutils.dll 100% (470/470) vs. 93% (81947/87854) srvcli.dll 100% (470/470) vs. 93% (81948/87854) KERNELBASE.dll 100% (470/470) vs. 93% (82088/87854) cfgmgr32.dll 98% (459/470) vs. 91% (80141/87854) d3d11.dll 98% (459/470) vs. 91% (80143/87854) dxgi.dll 100% (470/470) vs. 94% (82207/87854) powrprof.dll 100% (470/470) vs. 94% (82377/87854) winnsi.dll 100% (470/470) vs. 94% (82377/87854) nsi.dll 100% (470/470) vs. 94% (82393/87854) IPHLPAPI.DLL 100% (470/470) vs. 94% (82394/87854) dwmapi.dll 100% (470/470) vs. 94% (82399/87854) wbemcomn.dll 99% (466/470) vs. 93% (81718/87854) nssckbi.dll 99% (466/470) vs. 93% (81846/87854) nssdbm3.dll 99% (466/470) vs. 93% (81859/87854) softokn3.dll 97% (456/470) vs. 91% (80095/87854) psapi.dll 99% (466/470) vs. 93% (82141/87854) freebl3.dll 100% (470/470) vs. 95% (83103/87854) msctf.dll 100% (470/470) vs. 95% (83122/87854) wbemprox.dll 6% (29/470) vs. 1% (720/87854) avcuf32.dll zzz_AsmCodeRange_End | BaseThreadInitThunk|0xc000070a / 0x00000000 (162 crashes) 91% (148/162) vs. 18% (15957/87854) rasman.dll 91% (148/162) vs. 18% (15957/87854) rasapi32.dll 91% (148/162) vs. 18% (16185/87854) rtutils.dll 85% (138/162) vs. 13% (11132/87854) SensApi.dll 70% (113/162) vs. 7% (5888/87854) d3d10.dll 70% (113/162) vs. 7% (5888/87854) d3d10core.dll 57% (93/162) vs. 1% (721/87854) npggNT.des 99% (161/162) vs. 43% (38036/87854) urlmon.dll 70% (113/162) vs. 18% (15769/87854) d3d10_1core.dll 70% (113/162) vs. 18% (15769/87854) d3d10_1.dll 97% (157/162) vs. 58% (51192/87854) apphelp.dll 28% (45/162) vs. 4% (3392/87854) nvwgf2um.dll 23% (37/162) vs. 4% (3620/87854) atiuxpag.dll 23% (37/162) vs. 4% (3724/87854) aticfx32.dll 23% (37/162) vs. 4% (3814/87854) atidxx32.dll 100% (162/162) vs. 85% (75070/87854) RpcRtRemote.dll 96% (156/162) vs. 82% (72200/87854) normaliz.dll 100% (162/162) vs. 86% (75770/87854) Wldap32.dll 100% (162/162) vs. 87% (76092/87854) WSHTCPIP.DLL 97% (157/162) vs. 84% (73794/87854) wship6.dll 100% (162/162) vs. 87% (76822/87854) sspicli.dll 100% (162/162) vs. 89% (78025/87854) samlib.dll 100% (162/162) vs. 89% (78265/87854) Wpc.dll 100% (162/162) vs. 89% (78266/87854) wevtapi.dll 100% (162/162) vs. 89% (78274/87854) explorerframe.dll 100% (162/162) vs. 89% (78327/87854) ntdsapi.dll 21% (34/162) vs. 10% (8989/87854) igd10umd32.dll 100% (162/162) vs. 89% (78472/87854) pnrpnsp.dll 100% (162/162) vs. 89% (78496/87854) duser.dll 100% (162/162) vs. 89% (78496/87854) dui70.dll 100% (162/162) vs. 91% (79550/87854) lpk.dll 100% (162/162) vs. 91% (79741/87854) d2d1.dll 97% (157/162) vs. 88% (77269/87854) FWPUCLNT.DLL 99% (161/162) vs. 90% (79471/87854) iertutil.dll 100% (162/162) vs. 91% (80141/87854) d3d11.dll 100% (162/162) vs. 91% (80143/87854) dxgi.dll 100% (162/162) vs. 91% (80194/87854) nlaapi.dll 100% (162/162) vs. 91% (80266/87854) NapiNSP.dll 100% (162/162) vs. 91% (80378/87854) DWrite.dll 100% (162/162) vs. 92% (80610/87854) cryptsp.dll 22% (36/162) vs. 14% (12347/87854) idmmkb.dll 100% (162/162) vs. 93% (81409/87854) MMDevAPI.dll 7% (12/162) vs. 0% (67/87854) WTFastDrv.dll 100% (162/162) vs. 93% (81689/87854) profapi.dll 100% (162/162) vs. 93% (81718/87854) nssckbi.dll 100% (162/162) vs. 93% (81846/87854) nssdbm3.dll 100% (162/162) vs. 93% (81859/87854) softokn3.dll 100% (162/162) vs. 93% (81924/87854) propsys.dll 100% (162/162) vs. 93% (81930/87854) devobj.dll 100% (162/162) vs. 93% (81930/87854) samcli.dll 100% (162/162) vs. 93% (81942/87854) sechost.dll 100% (162/162) vs. 93% (81947/87854) CRYPTBASE.dll 100% (162/162) vs. 93% (81947/87854) netutils.dll 100% (162/162) vs. 93% (81947/87854) srvcli.dll 100% (162/162) vs. 93% (81947/87854) wkscli.dll 100% (162/162) vs. 93% (81948/87854) KERNELBASE.dll 100% (162/162) vs. 93% (82088/87854) cfgmgr32.dll 100% (162/162) vs. 93% (82141/87854) freebl3.dll 100% (162/162) vs. 94% (82207/87854) powrprof.dll 100% (162/162) vs. 94% (82377/87854) nsi.dll 100% (162/162) vs. 94% (82377/87854) winnsi.dll 100% (162/162) vs. 94% (82393/87854) IPHLPAPI.DLL 100% (162/162) vs. 94% (82394/87854) dwmapi.dll 100% (162/162) vs. 94% (82399/87854) wbemcomn.dll 10% (17/162) vs. 4% (3812/87854) bcryptprimitives.dll 6% (10/162) vs. 0% (127/87854) escortdrv.dll 6% (10/162) vs. 0% (127/87854) escengine.dll 100% (162/162) vs. 94% (82558/87854) fastprox.dll 100% (162/162) vs. 94% (82635/87854) wbemsvc.dll 6% (10/162) vs. 0% (218/87854) safetycrt.dll 96% (156/162) vs. 91% (79678/87854) wininet.dll 100% (162/162) vs. 95% (83103/87854) msctf.dll 100% (162/162) vs. 95% (83122/87854) wbemprox.dll 6% (9/162) vs. 0% (338/87854) PrxerDrv.dll 6% (9/162) vs. 0% (361/87854) PrxerNsp.dll RtlQueryRegistryValues | BaseThreadInitThunk|0xc000070a / 0x00000000 (73 crashes) 77% (56/73) vs. 13% (11132/87854) SensApi.dll 81% (59/73) vs. 18% (15957/87854) rasapi32.dll 81% (59/73) vs. 18% (15957/87854) rasman.dll 81% (59/73) vs. 18% (16185/87854) rtutils.dll 62% (45/73) vs. 7% (5888/87854) d3d10.dll 62% (45/73) vs. 7% (5888/87854) d3d10core.dll 62% (45/73) vs. 18% (15769/87854) d3d10_1core.dll 62% (45/73) vs. 18% (15769/87854) d3d10_1.dll 86% (63/73) vs. 43% (38036/87854) urlmon.dll 100% (73/73) vs. 58% (51192/87854) apphelp.dll 37% (27/73) vs. 10% (8989/87854) igd10umd32.dll 23% (17/73) vs. 0% (208/87854) sprotector.dll 23% (17/73) vs. 0% (323/87854) mshtml.dll 22% (16/73) vs. 1% (467/87854) guard32.dll 22% (16/73) vs. 1% (501/87854) fltLib.dll 22% (16/73) vs. 1% (720/87854) avcuf32.dll 100% (73/73) vs. 84% (73794/87854) wship6.dll 100% (73/73) vs. 85% (75070/87854) RpcRtRemote.dll 100% (73/73) vs. 86% (75770/87854) Wldap32.dll 14% (10/73) vs. 0% (159/87854) SetPointSmoothFirefox.dll 18% (13/73) vs. 4% (3814/87854) atidxx32.dll 100% (73/73) vs. 87% (76092/87854) WSHTCPIP.DLL 14% (10/73) vs. 1% (551/87854) lpxpcom.dll 100% (73/73) vs. 87% (76822/87854) sspicli.dll 100% (73/73) vs. 88% (77269/87854) FWPUCLNT.DLL 100% (73/73) vs. 89% (78025/87854) samlib.dll 15% (11/73) vs. 4% (3620/87854) atiuxpag.dll 100% (73/73) vs. 89% (78265/87854) Wpc.dll 100% (73/73) vs. 89% (78266/87854) wevtapi.dll 100% (73/73) vs. 89% (78274/87854) explorerframe.dll 100% (73/73) vs. 89% (78327/87854) ntdsapi.dll 15% (11/73) vs. 4% (3724/87854) aticfx32.dll 100% (73/73) vs. 89% (78472/87854) pnrpnsp.dll 100% (73/73) vs. 89% (78496/87854) duser.dll 100% (73/73) vs. 89% (78496/87854) dui70.dll 100% (73/73) vs. 91% (79550/87854) lpk.dll 100% (73/73) vs. 91% (79741/87854) d2d1.dll 100% (73/73) vs. 91% (80095/87854) psapi.dll 100% (73/73) vs. 91% (80141/87854) d3d11.dll 100% (73/73) vs. 91% (80143/87854) dxgi.dll 100% (73/73) vs. 91% (80266/87854) NapiNSP.dll 100% (73/73) vs. 91% (80378/87854) DWrite.dll 100% (73/73) vs. 92% (80610/87854) cryptsp.dll 22% (16/73) vs. 14% (12092/87854) WLIDNSP.DLL 100% (73/73) vs. 93% (81409/87854) MMDevAPI.dll 8% (6/73) vs. 1% (840/87854) nvspcap.dll 11% (8/73) vs. 4% (3392/87854) nvwgf2um.dll 100% (73/73) vs. 93% (81689/87854) profapi.dll 100% (73/73) vs. 93% (81718/87854) nssckbi.dll 100% (73/73) vs. 93% (81846/87854) nssdbm3.dll 100% (73/73) vs. 93% (81859/87854) softokn3.dll 100% (73/73) vs. 93% (81924/87854) propsys.dll 100% (73/73) vs. 93% (81930/87854) devobj.dll 100% (73/73) vs. 93% (81930/87854) samcli.dll 100% (73/73) vs. 93% (81935/87854) rasadhlp.dll 100% (73/73) vs. 93% (81942/87854) sechost.dll 100% (73/73) vs. 93% (81947/87854) CRYPTBASE.dll 100% (73/73) vs. 93% (81947/87854) netutils.dll 100% (73/73) vs. 93% (81947/87854) srvcli.dll 100% (73/73) vs. 93% (81947/87854) wkscli.dll 100% (73/73) vs. 93% (81948/87854) KERNELBASE.dll 100% (73/73) vs. 93% (82088/87854) cfgmgr32.dll 8% (6/73) vs. 2% (1490/87854) nvapi.dll 100% (73/73) vs. 93% (82141/87854) freebl3.dll 100% (73/73) vs. 94% (82207/87854) powrprof.dll 7% (5/73) vs. 0% (425/87854) apcrtldr.dll 7% (5/73) vs. 1% (472/87854) IdcSrvStub.dll 100% (73/73) vs. 94% (82377/87854) nsi.dll 100% (73/73) vs. 94% (82377/87854) winnsi.dll 100% (73/73) vs. 94% (82393/87854) IPHLPAPI.DLL 100% (73/73) vs. 94% (82394/87854) dwmapi.dll 100% (73/73) vs. 94% (82399/87854) wbemcomn.dll 100% (73/73) vs. 94% (82558/87854) fastprox.dll 97% (71/73) vs. 91% (80194/87854) nlaapi.dll 100% (73/73) vs. 94% (82635/87854) wbemsvc.dll 100% (73/73) vs. 95% (83103/87854) msctf.dll 100% (73/73) vs. 95% (83122/87854) wbemprox.dll 7% (5/73) vs. 2% (1518/87854) I18N.dll
Crash Signature: [@ zzz_AsmCodeRange_Begin | BaseThreadInitThunk ] [@ RtlpCallQueryRegistryRoutine | BaseThreadInitThunk ] → [@ zzz_AsmCodeRange_Begin | BaseThreadInitThunk ] [@ RtlpCallQueryRegistryRoutine | BaseThreadInitThunk ] [@ zzz_AsmCodeRange_End | BaseThreadInitThunk ] [@ RtlQueryRegistryValues | BaseThreadInitThunk ]
Tracking topcrash. I'm assuming 37+ are affected. dmajor - Can you help with initial debugging?
status-firefox37: --- → affected
status-firefox38: --- → affected
status-firefox39: --- → affected
tracking-firefox37: ? → +
tracking-firefox38: --- → +
tracking-firefox39: --- → +
Flags: needinfo?(dmajor)
Keywords: crash, topcrash
This has a pretty high correlation with "nProtect GameGuard": 26% (155/599) vs. 1% (721/87854) npggNT.des 50% (236/470) vs. 1% (721/87854) npggNT.des 57% (93/162) vs. 1% (721/87854) npggNT.des Given the nature of that binary, I don't expect that we can prevent it. As a starting point can you find someone at nProtect to see if they know of any issues?
Flags: needinfo?(dmajor) → needinfo?(lmandel)
OS: Linux → Windows 7
Hardware: x86_64 → x86
I sent the following e-mail to support@nprotect.com: Hello, I manage the Mozilla Firefox release management team. We are currently tracking a top crash in our Firefox 37 Beta program that looks to be associated with nProtect GameGuard. Details can be found in our open Bugzilla bug tracker [1]. I'd like to know whether you have seen similar reports on your side. Can you please pass this information on to your engineering/development team for investigation? Your engineers can interact directly with ours through Bugzilla or I can arrange an introduction via e-mail if needed. Thank you, Lawrence Mandel Senior Manager, Firefox Releases [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1139497
Flags: needinfo?(lmandel)
Severity: normal → critical
The nprotect support address seems to be a mailing list with many members. I've received several bounce notifications and no actual response. Let's try Twitter: https://twitter.com/mmmandel/status/577505758662782976
David - I haven't had any response from nprotect. You said that you don't expect that we can prevent it in comment 2. Do you think there's anything that we can do on our side to mitigate this issue?
Flags: needinfo?(dmajor)
No, I don't have any good ideas. The effect is pretty far removed from the cause in this one, so I don't even know what the real underlying problem is.
Flags: needinfo?(dmajor)
I tried calling the listed 24/7 support number at 1-855-466-7768 and got a general mailbox answer machine. I left a message with my name and number. Their faq stated that they have live support online but I was unable to find that on their site. I'm not feeling very confident about our ability to get a fix from nProtect. If we can detect that a user has crashed multiple times due to GameGuard, it may be best to try and find a way to inform them of this and suggest that they consider uninstalling GameGuard.
I'm marking this as wontfix for 37 as there's not much more that we're likely to accomplish here in the next week.
status-firefox37: affected → wontfix
Do we have a path for giving users information related to specific crashes? I remember some discussion of linking from crashpad to SUMO. For what it's worth, there seem to be many reports around the web that GameGuard create problems so that if the game itself hangs or crashes, other processes may also crash. See: * https://code.google.com/p/chromium/issues/detail?id=334533&q=gameguard&colspec=ID%20Pri%20M%20Week%20ReleaseBlock%20Cr%20Status%20Owner%20Summary%20OS%20Modified * https://code.google.com/p/chromium/issues/detail?id=319408
It's especially unfortunate that in both of those bugs, the nProtect developers had to deploy a fix on their side. As far as I know the self-support stuff still doesn't exist yet.
(In reply to David Major [:dmajor] from comment #10) > It's especially unfortunate that in both of those bugs, the nProtect > developers had to deploy a fix on their side. So, this bug does not exist anymore, right?
Those were old Chrome bugs. This is a new issue.
This still exists at a fairly high volume on the release channel. Unless nProtect fixes this issue, people who install GameGuard in order to be able to play particular games may have some problems with other apps crashing. If nProtect doesn't fix the issue that causes the crash or hang on their end, then we will probably see a rise in this crash signature on 38 and 39 as they move to release.
It's possible that some of these crashes are related to the chromium sandbox. As the thumbnail process is a content process, it is getting sandboxed. It's possible that various DLLs that may get loaded into the process are causing problems with the way the sandbox works. It's also possible that on Vista 64-bit some anti-virus programs are detecting the wow_helper.exe program (used as part of the sandbox start-up on Vista and WinXP 64-bit) as a virus and blocking it. I've seen this happen with Nightly on Vista this morning with Panda Anti-virus. I've changed the content sandbox to Nightly only in bug 1158849, which I've requested for uplift. The GMP process also uses the sandbox and was released in Fx33 I believe. But it wasn't working on Vista 64-bit until Fx35, when the wow_helper was added. It may be that GMP isn't currently used enough for this to cause visible issues, but with EME coming in Fx38 that may change. I also noticed that wow_helper.exe is not signed, whereas the other EXEs seem to be. Don't know if that can contribute to it being deemed a virus. Crashes that are not on Vista or WinXP 64-bit cannot be down to wow_helper, but could be due to other DLLs interfering with the sandbox. I've not seen this happen, but Chromium has a list of DLLs that they evict from the child process. I'm not quite sure how the eviction works at the moment, we already have the underlying code for it, I'll look into that. However, I've copied the DLL blacklist and extra code from Chromium and have this compiling. It would be good if we had some way of reliably reproducing these crashes, so I can test this. I've installed various AVs and other nasties onto a VM, to see if I can reproduce.
Do you suspect that these crash reports are from thumbnail processes? Is there a way I could check that from a minidump? Or, does the act of sandboxing the thumbnail process also mess with the main process?
Flags: needinfo?(bobowen.code)
(In reply to David Major [:dmajor] from comment #15) > Do you suspect that these crash reports are from thumbnail processes? Is > there a way I could check that from a minidump? > > Or, does the act of sandboxing the thumbnail process also mess with the main > process? If the thumbnail process is crashing on start up, which is what would happen if there was an issue with wow_helper on Vista 64-bit, then I think it will be the firefox.exe process that is crashing. If it is the process crashing at other times, because of other DLLs then I would have thought it would be the plugin-container.exe process. Unless they are causing the crash at process start up.
Flags: needinfo?(bobowen.code)
These are definitely firefox.exe. A lot of them are near startup but a lot of the aren't. The ones I'm looking at are almost all Win7. (Although it's possible that XP/Win8 crashes got different signatures)
I've managed to reproduce a crash with GameGuard, by creating a dual boot for Windows 7 32-bit and installing Rohan Blood Feud. The game uses GameGuard, which refuses to load in a Virtual Box or VMWare Player. If you start Firefox with the game running, you get npggNT.des loaded in the chrome process. If you then trigger a sandboxed child process (either GMP or thumbnail content process) the child process fails to start and crashes the chrome process. The signature isn't quite the same as this one, but it may well be that they are all related: https://crash-stats.mozilla.com/report/index/bp-73222c41-bab6-44b2-b747-a534d2150503 I can now test the new Chromium code I've pulled in against this (no bug yet). This intercepts a function that is involved in the DLL loading and prevents it. I've also started working on a bug looking at why these child process problems cause the chrome process to crash (bug 1146874). I've fixed a problem in the sandbox broker, but it seems that the other IPC process start up code doesn't cope well with the child process not starting either and it crashes slightly later on. It's a bank holiday in the UK on Monday, so I'll get back to these on Tuesday. The change to turn off the sandbox on the thumbnail content process has been uplifted to Fx38, 38.05, esr38 and 39. needino?ing mreavy and cpearce, just so they are aware of the GMP crash.
Assignee: nobody → bobowen.code
Flags: needinfo?(mreavy)
Flags: needinfo?(cpearce)
Thanks. It would be good to uplift this to 39.
Flags: needinfo?(cpearce)
(In reply to Bob Owen (:bobowen) from comment #18) > The signature isn't quite the same as this one, but it may well be that they > are all related: > https://crash-stats.mozilla.com/report/index/bp-73222c41-bab6-44b2-b747- > a534d2150503 Yes! Glad to hear you found a repro. That MD4Transform signature is one of the issues we're looking at in bug 1153824, except in that bug it's with Norton Internet Security rather than GameGuard.
Too late for 38. However: * we could take a patch in 38.0.5 if it is safe * ditto for ESR 38.
status-firefox38: affected → wontfix
status-firefox38.0.5: --- → affected
status-firefox-esr38: --- → affected
tracking-firefox38.0.5: --- → +
tracking-firefox-esr38: --- → 39+
Thanks for the heads up, Bob.
Flags: needinfo?(mreavy)
This crash affects Adobe's CDM, but is not an EME release blocker.
Priority: -- → P1
Just to update on the GameGuard conflict. I have emailed and heard back from an nProtect GameGuard contact. They are looking into the issue and asked for more detailed steps to reproduce, which I have provided. I'll update again when I hear anything new.
Too late to do anything wrt 38.0.5.
status-firefox38.0.5: affected → wontfix
Sounds like the fix in bug 1146874 may help but not completely fix this. It's too early to tell from the 39 beta crash data how frequent the crash is but let's keep an eye on it. Bob, did you hear back from GameGuard?
Flags: needinfo?(bobowen.code)
(In reply to Liz Henry (:lizzard) from comment #26) > Bob, did you hear back from GameGuard? I had another email exchange on the 19th May, where they confirmed they were looking into it. I emailed again yesterday, but no response yet.
Flags: needinfo?(bobowen.code)
(In reply to Bob Owen (:bobowen) from comment #27) > (In reply to Liz Henry (:lizzard) from comment #26) > > > Bob, did you hear back from GameGuard? > > I had another email exchange on the 19th May, where they confirmed they were > looking into it. > I emailed again yesterday, but no response yet. Just had a reply saying that they are preparing a module to resolve this conflict. So hopefully we'll have some good news soon.
status-firefox40: --- → ?
status-firefox41: --- → ?
Summary: Rise of "* | BaseThreadInitThunk" crashes in 37 Beta → Rise of "* | BaseThreadInitThunk" crashes in 37 Beta (nprotect)
Wontfix for 39. Tracking for 40. Not sure if 40 is affected but we should follow up and keep an eye on this.
tracking-firefox40: --- → +
Promising news from the GameGuard people yesterday. It says that they have prepared a fix and it will be applied to all of their games ... "one by one, in a short period." I've asked for clarification as to how long that might be. I've checked my test-case and that's not working yet. I'll keep trying over the next week, to see if it is resolved. (By the way failure to start the content process, doesn't crash the main process anymore (bug 1146874), but without a content process nothing renders. I filed bug 1165945 for improving how we handle that.)
Bob, is this GameGuard crash still an issue? Does this bug need to block our EME launch with Adobe (meta bug 1032660)?
Flags: needinfo?(bobowen.code)
(In reply to Chris Peterson [:cpeterson] from comment #31) > Bob, is this GameGuard crash still an issue? Does this bug need to block our > EME launch with Adobe (meta bug 1032660)? Last time I heard from them, they said they had a fix and were rolling it out (I'm not sure what that entails, but it sounds like it's on a game by game basis). However, when I checked last week my test game still caused the crash. I'll have to reboot to test, so I'll try and check again tomorrow and re-email them.
Flags: needinfo?(bobowen.code)
(In reply to Chris Peterson [:cpeterson] from comment #31) > Bob, is this GameGuard crash still an issue? Does this bug need to block our > EME launch with Adobe (meta bug 1032660)? Still failing for my test game. I've re-emailed the GameGuard contact and asked for some idea as to when their fix will be fully deployed.
I've heard back from GameGuard and they've updated six games and said that the rest should be updated in the next couple of weeks. I don't know how many that is, although I did ask. I tested one of the updated games on the list: Rumble Fighter : http://rumblefighter.gamescampus.com/ I could see that this was using npggNT.des - Usermode Filtering Library Rev 870 (Rohan is using Rev 858). At first this seemed to get past the initial bug and the sandboxed plugin-container.exe process was starting. However, it was crashing very regularly, which was not happening without the game running. I tried installing and running a debug version of Firefox Nightly to see if I could see where it was crashing, but this worked OK. So, I re-installed the non-debug version of Nightly from scratch and the issues seemed to go away. This does still concern me slightly as I imagine most people wouldn't be installing from scratch, but hopefully it was just an issue with my installation. We will probably have to wait and see if people are still experiencing other problems, but it certainly seems to have fixed the initial conflict. I'll re-test Rohan over the next couple of weeks as well.
(In reply to Bob Owen (:bobowen) from comment #34) > I've heard back from GameGuard and they've updated six games and said that > the rest should be updated in the next couple of weeks. @ Bob, can we close this bug as fixed or WFM? It sounds like there is no more work that can be done from our side. @ KaiRo, is BaseThreadInitThunk still a top crash?
status-firefox42: --- → ?
status-firefox43: --- → ?
Flags: needinfo?(kairo)
Flags: needinfo?(bobowen.code)
(In reply to Chris Peterson [:cpeterson] from comment #35) > (In reply to Bob Owen (:bobowen) from comment #34) > > I've heard back from GameGuard and they've updated six games and said that > > the rest should be updated in the next couple of weeks. > > @ Bob, can we close this bug as fixed or WFM? It sounds like there is no > more work that can be done from our side. I don't really mind, but do we not normally keep something open to track things on our side?
Flags: needinfo?(bobowen.code)
Good point. I'm moving this bug from priority P1 to P2 because we want to track the issue, but it does not need to block our EME launch.
Priority: P1 → P2
(In reply to Chris Peterson [:cpeterson] from comment #35) > @ KaiRo, is BaseThreadInitThunk still a top crash? Not a top crash, but it has had its lows and spikes over time. Or maybe we just have finally lost almost all of those users due to all the crashes and no fixes in a long time.
Flags: needinfo?(kairo)
I will stop tracking it. It is too late for 40 and we have been tracking this bug for several versions now without results.
status-firefox40: ? → wontfix
I retested Rohan and the original problem was fixed. However when I restarted, an update kicked in and the issue with plugin-container.exe crashing I mentioned in comment 34 re-emerged. I have informed GameGuard and they will look into it. I didn't have a chance to check if a crash was reported before I left.
(In reply to Bob Owen (:bobowen) from comment #40) > I retested Rohan and the original problem was fixed. > > However when I restarted, an update kicked in and the issue with > plugin-container.exe crashing I mentioned in comment 34 re-emerged. > > I have informed GameGuard and they will look into it. > > I didn't have a chance to check if a crash was reported before I left. I've retested this a couple of times recently with two different games protected by GameGuard and I can run Nightly and all three child processes (content, GMP and NPAPI) with the sandbox. No, problems after an update either. So, I think we can finally close this and open a new bug should issues re-occur.
Flags: needinfo?(kairo)
(In reply to Bob Owen (:bobowen) from comment #41) > So, I think we can finally close this and open a new bug should issues > re-occur. If you think so, feel free to do so. Crashes with the signatures in the bug continue, but at a quite low level, so I don't care.
Flags: needinfo?(kairo)
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #42) > (In reply to Bob Owen (:bobowen) from comment #41) > > So, I think we can finally close this and open a new bug should issues > > re-occur. > > If you think so, feel free to do so. Crashes with the signatures in the bug > continue, but at a quite low level, so I don't care. Yes, BaseThreadInitThunk is at the start of most threads, so I suspect we could see it for other reasons as well.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.