Closed Bug 627716 Opened 9 years ago Closed 8 years ago

Crash [@ STAN_GetNSSCertificate ] with the spdg.dll malware

Categories

(Toolkit :: Blocklist Policy Requests, defect, critical)

x86
Windows XP
defect
Not set
critical

Tracking

()

RESOLVED WONTFIX
Tracking Status
blocking2.0 --- -

People

(Reporter: scoobidiver, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: crash, regression)

Crash Data

Attachments

(3 files)

It is a residual crash signature that exists in 3.6 and the trunk.
It is #114 top crasher in 4.0b9 for the last week.

Signature	STAN_GetNSSCertificate
UUID	bd999bf7-0eee-4702-a4a8-9ed122110119
Time 	2011-01-19 08:09:29.269604
Uptime	11440
Last Crash	11443 seconds (3.2 hours) before submission
Install Age	416027 seconds (4.8 days) since version was first installed.
Product	Firefox
Version	4.0b9
Build ID	20110110191547
Branch	2.0
OS	Windows NT
OS Version	5.1.2600 Dodatek Service Pack 2
CPU	x86
CPU Info	AuthenticAMD family 6 model 6 stepping 2
Crash Reason	EXCEPTION_ACCESS_VIOLATION_READ
Crash Address	0x47c
App Notes 	AdapterVendorID: 10de, AdapterDeviceID: 0110

Frame 	Module 	Signature [Expand] 	Source
0 	nss3.dll 	STAN_GetNSSCertificate 	security/nss/lib/pki/pki3hack.c:941
1 	nss3.dll 	CERT_DupCertificate 	security/nss/lib/certdb/certdb.c:1376
2 	ssl3.dll 	ssl3_HandleCertificate 	security/nss/lib/ssl/ssl3con.c:7942
3 	ssl3.dll 	ssl3_HandleHandshakeMessage 	security/nss/lib/ssl/ssl3con.c:8603
4 	ssl3.dll 	ssl3_HandleHandshake 	security/nss/lib/ssl/ssl3con.c:8727
5 	ssl3.dll 	ssl3_HandleRecord 	security/nss/lib/ssl/ssl3con.c:9066
6 	ssl3.dll 	ssl3_GatherCompleteHandshake 	security/nss/lib/ssl/ssl3gthr.c:209
7 	ssl3.dll 	ssl_GatherRecord1stHandshake 	security/nss/lib/ssl/sslcon.c:1258
8 	ssl3.dll 	ssl_Do1stHandshake 	security/nss/lib/ssl/sslsecur.c:151
9 	ssl3.dll 	ssl_SecureSend 	security/nss/lib/ssl/sslsecur.c:1213
10 	ssl3.dll 	ssl_SecureWrite 	security/nss/lib/ssl/sslsecur.c:1258
11 	ssl3.dll 	ssl_Write 	security/nss/lib/ssl/sslsock.c:1652
12 	xul.dll 	nsSSLThread::Run 	
13 	nspr4.dll 	_PR_NativeRunThread 	nsprpub/pr/src/threads/combined/pruthr.c:426
14 	nspr4.dll 	pr_root 	nsprpub/pr/src/md/windows/w95thred.c:122
15 	mozcrt19.dll 	_callthreadstartex 	obj-firefox/memory/jemalloc/crtsrc/threadex.c:348
16 	mozcrt19.dll 	_threadstartex 	obj-firefox/memory/jemalloc/crtsrc/threadex.c:326
17 	kernel32.dll 	BaseThreadStart 	

More reports at:
http://crash-stats.mozilla.com/report/list?range_value=4&range_unit=weeks&signature=STAN_GetNSSCertificate&version=Firefox%3A4.0b9
Assignee: nobody → nobody
Component: Security → Libraries
Product: Core → NSS
QA Contact: toolkit → libraries
Version: Trunk → trunk
It would be interesting to know the offset of nssCertificate in CERTCertificate. The offset is reasonably large and lot of the crashes are at 0x15d which feels like it could be an offset from near NULL.

There's a null check at http://hg.mozilla.org/mozilla-central/annotate/f9d66f4d17bf/security/nss/lib/certdb/certdb.c#l1376 So perhaps cc is 1 or 2 or something like that.
cc'ing kai, this is a early top4 topcrahs for beta11
This is the highest non-abort crash on beta 11 ATM.
I'm looking at this now.
definite regression that should be on the hardblocker list.

checking --- STAN_GetNSSCertificate 20110208-crashdata.csv
found in: 4.0b11 3.6.13 4.0b10 4.0b12pre 4.0b9 3.5.16
release total-crashes
              STAN_GetNSSCertificate crashes
                         pct.
all     334277  131      0.000391
4.0b11   3484    76      0.021814
3.6.13  190336   34      0.000178
4.0b10   64994   16      0.000246
4.0b12pr  1897    3      0.001581


more reports at
https://crash-stats.mozilla.com/report/list?signature=STAN_GetNSSCertificate

Its interesting that most of the comments are non-english.  just this one in english.

  it's a simpe crash when I open any page !!!

correlations to start up might indicate someone hitting a page that tickles the bug then maybe repeat crashes at session restore.  urls also show maybe some connection to payment/banking systems.

Correlation to startup or time of session
131 total crashes for STAN_GetNSSCertificate on 20110208-crashdata.csv
77 startup crashes inside 30 sec.
95 startup crashes inside 3 min.

urls / domains of sites
  20 jar:file:// ...  omnijar...
  18 \N//
  13 http://www.google.com.br
   6 http://www.orkut.com
   6 //
   4 http://www.tibia.com
   4 http://search.conduit.com
   3 https://secure.tibia.com
   3 http://bbb.globo.com
   2 https://www.facebook.com
   2 http://www.google.fr
   2 http://google.com
   2 http://ad.zanox.com
   + long tail

  4 http://www.tibia.com/community/?subtopic=characters
   4 http://search.conduit.com/?ctid=CT2786678&SearchSource=13
 2 https://www.facebook.com/login.php?login_attempt=1
   2 https://secure.tibia.com/account/?subtopic=createaccountanddownload&noframe=1
   2 http://www.google.fr/webhp?rls=ig
   2 http://google.com/
  1 https://www.volvocarstechinfo.ford.com/
   1 https://www.no-ip.com/login/
   1 https://twitter.com/sessions
   1 https://topup2.levelupgames.com.br/
   1 https://ssl.bigpoint.net/billing/ ...
  1 https://seguro.chaecia.com.br/loja/login_layout.php? ...
   1 https://secure2.segpay.com/billing/poset.cgi?x-eticketid= ..
   1 https://pay.innogames.de/sponsorpay/popup?player_id= ...
   1 https://megapanel.gem.pl/ ..
   1 https://internetbanking.caixa.gov.br/
Keywords: regression
Whiteboard: [hardblocker]
We should find out, is this a crash that got introduced with a recent version of NSS?
(In reply to comment #1)
> It would be interesting to know the offset of nssCertificate in
> CERTCertificate. The offset is reasonably large and lot of the crashes are at
> 0x15d which feels like it could be an offset from near NULL.
> 
> There's a null check at
> http://hg.mozilla.org/mozilla-central/annotate/f9d66f4d17bf/security/nss/lib/certdb/certdb.c#l1376
> So perhaps cc is 1 or 2 or something like that.

In the dump from comment 0, cc == 0x320, which is not quite NULL, but not a valid pointer either.
But in the calling frame, it appears to have a valid address, so I don't have any idea what's happening there.
chofmann: have you looked at module/extension correlations for this crash? I noticed there was some AntiVirus module in the dump I pulled up, among other things:
C:\WINDOWS\system32\spdg.dll
C:\Program Files\Unlocker\UnlockerHook.dll
C:\Documents and Settings\...\Ustawienia lokalne\Dane aplikacji\FLVService\lib\FLVSrvLib.dll
C:\Program Files\Alwil Software\Avast5\snxhk.dll

Also this crash appears to be from a Polish Windows installation, dunno that that matters.
(In reply to comment #6)
> We should find out, is this a crash that got introduced with a recent version
> of NSS?

I saw crashes in 4.0b3 (build 2010-08-05-192522) and 3.0.19 (build 2010-03-14-22) on crash-stats. *All* the crashes on crash-stats that I have access to are on Windows. AFAICT, that means the bug occurs with or in NSS 3.12.6 or earlier versions.
(In reply to comment #7)
> In the dump from comment 0, cc == 0x320, which is not quite NULL, but not a
> valid pointer either. But in the calling frame, it appears to have a
> valid address, so I don't have any idea what's happening there.

When you opened the dump in Visual Studio, did it have the same call stack as is listed in crash-stats? When I open the minidump you sent me, many of the (important) items in the call stack are omitted. For example, ssl3_HandleCertificate isn't listed at all. I don't know if this is an indication that the stack is corrupt or some other problem.
It seems the bad pointer comes from CERT_NewTempCertificate. NewTempCertificate can either return pointers retrieved from one of two caches (NSSCryptoContext_FindCertificateByEncodedCertificate or
NSSTrustDomain_FindCertificateByEncodedCertificate), or it can create the returned object using this call stack:
    stan_GetCERTCertificate 
        nssDecodedPKIXCertificate_Create
          CERT_DecodeDERCertificate
            PORT_ArenaZAlloc

AFAICT, this latter case looks correct. That indicates to me that either there is some kind of stack corruption or one of the certificate caches is corrupt. Finding the place where either of the caches could be corrupted seems difficult.
One *possible* cause may be bug 633378.
See Also: → 633378
Attached file stack from windbg
The stack I got from WinDBG from the dump in comment 0 looks identical to the stack on crash-stats.

Did you download the associated (beta 9) binaries? The debugger often has a hard time reconstructing stacks faithfully without the binaries.
Keywords: topcrash
What is SPDG.DLL in C:\Windows\system32?

> 100% (491/491) vs.   1% (550/38786) spdg.dll

If I am reading this correctly, every crash occurs with this module loaded and very few other crashes do. The crash has only ever happened on Windows. This seems like a pretty uncommon DLL as I cannot find any information about it online as being part of a legit application. Possibly malware?

I also found this on a Polish forum (translated):
http://forum.pclab.pl/topic/645379-Problem-z-spdgdll/
> Hi I have a problem that the program does not run
> (FF, chrome, opera, fsproxy, deluge, utorent) pops
> up an error (error report) where the problem is
> this file (spdg.dll) drive can not find it, so I
> do not know what to do
(In reply to comment #7)
> In the dump from comment 0, cc == 0x320, which is not quite NULL, but not a
> valid pointer either.
> But in the calling frame, it appears to have a valid address, so I don't have
> any idea what's happening there.

Also, a similar problem with the ss parameter which is passed from function to function: the code is correctly passing the ss parameter from function to function but somehow one stack frame has ss==0 even though it is impossible.
In reply to comment 15
According to another Polish forum thread: http://forum.dobreprogramy.pl/problem-spdg-dll-t425108.html, this problem is gone after scanning with an anti-malware software.

The dll block-listing could be a solution.
Summary: Crash [@ STAN_GetNSSCertificate ] → Crash [@ STAN_GetNSSCertificate ] with loaded spdg.dll, probably a malware
Assignee: nobody → nobody
blocking2.0: ? → -
Component: Libraries → Blocklisting
Product: NSS → addons.mozilla.org
QA Contact: libraries → blocklisting
Whiteboard: [hardblocker]
Version: trunk → unspecified
yeah, this signature seems to have a very erratic daily volume pattern suggesting that it is  in at least part a malware problem.  Here is a sample

67 total crashes on feb 7 across several versions:

20110207 67  	25 4.0b102011012116, 
        		24 3.6.132010120307, 	6 3.0.192010031422, 
        		4 4.0b82010121417, 	3 4.0b12pre2011020703, 
        		3 4.0b12pre2011020503, 	1 4.0b11pre2011020103, 
        		1 4.0b11pre2011012803, 

sharp spike on feb 9 to over 600 crashes

20110209 602  	528 4.0b112011020314, 
        		29 3.6.132010120307, 	24 4.0b102011012116, 
        		5 3.0.192010031422, 	4 4.0b92011011019, 
        		4 4.0b12pre2011020603, 	3 4.0b11pre2011012703, 
        		2 4.0b82010121417, 	2 4.0b12pre2011020803, 
        		1 4.0b11pre2011012606,

back down to 118 crashes on feb 15

20110215 118  	74 4.0b112011020314, 
        		35 3.6.132010120307, 	5 4.0b92011011019, 
        		2 4.0b102011012116, 	1 4.0b62010091408, 
        		1 4.0b12pre2011021103, 

almost no crashes on mar1,2

20110301 1 3.6.132010120307 	1 , 
20110302 1 3.6.142011021812 	1 ,

over 400 crashes yesterday

20110305 470  	425 4.0b122011022221, 
        		28 4.0b112011020314, 	13 3.6.132010120307, 
        		1 4.0b92011011019, 	1 4.0b13pre2011030403, 
        		1 4.0b102011012116, 	1 3.0.192010031422,
does seem to affect 4.0 more than 3.6.x and earlier.
It is #55 top crasher in 4.0b12.
Keywords: topcrash
Spiking again over the weekend, 482 crashes on Saturday, 586 on Sunday (478/579 of those on 4.0*) - can we please try to get a block in place, hopefully before we ship 4.0 to masses of users (as the crash seems to be happening mostly on 4)?
the signature continues to have 100% correlation to spdg.dll, and there is no version info for the .dll with any of reports.
most of these seem to occur pretty close to start up.

Correlation to startup or time of session
586 total crashes for STAN_GetNSSCertificate on 20110320-crashdata.csv
295 startup crashes inside 30 sec.
509 startup crashes inside 3 min.
306 repeated crashes inside 3 min. of last crash
_ null start times

os breakdown
STAN_GetNSSCertificateTotal 586
Win5.1  0.71
Win6.0  0.01
Win6.1  0.25

one of the domains shows services.a.m.o link which is  probably an addon update check near start up.

domains of sites
  81 \N//
  70 jar:file://
  30 http://www.orkut.com
  24 //
  15 https://nk.pl

  13 https://services.addons.mozilla.org
      pt-BR/firefox/discovery/pane/4.0/WINNT#{%XXXXXX@personas.mozilla.org
      pl/firefox/discovery/pane/4.0/WINNT#{%XX{972ce4c6-7e08-4474-a285-3208198ce6fd}
      it/firefox/discovery/pane/4.0/WINNT#{%22{972ce4c6-7e08-4474-a285-3208198ce6fd}
      es-ES/firefox/discovery/pane/4.0/WINNT#{%XXKavAntiBanner@Kaspersky.ru

  11 http://www.google.com.br
  10 http://www.orkut.com.br
   9 http://www.google.pl
   9 http://www.google.com
   9 http://video.xnxx.com
   8 https://www.facebook.com
   8 http://www.youtube.com
   8 http://www.tubeum.com
   7 http://search.babylon.com
   7 http://forums.otserv.com.br
   7 http://allegro.pl
   6 https://dl-ssl.google.com
   6 http://www.kelman.pl
   6 http://www.hotmail.com
   6 http://vshare.toolbarhome.com
   6 http://static.ak.fbcdn.net
   6 http://g.msn.com
   5 http://pl48.plemiona.pl
   4 http://www.thesimsresource.com
   4 http://www.remeresmapeditor.com
   4 http://www.redtube.com
   4 http://www.pzw.org.pl
   4 http://www.l2tnt.com.br
   4 http://www.facebook.com
   4 http://w3.my-fantasy.net
   4 http://produto.mercadolivre.com.br
   4 http://login.gadu-gadu.pl
   3 https://twitter.com
   3 https://support.mozilla.com
   3 https://profil.wp.pl
   3 http://www.sklep.airsoftguns.pl
   3 http://www.gmail.com
   3 http://www.autocentrum.pl
   3 http://search.4shared.com
   3 http://portaldota.com.br
   3 http://pl.e-stopwatch.eu
   3 http://mail.google.com
   3 http://google.pl
   3 http://forum.wedkuje.pl
   3 http://ad.zanox.com
both ramped up starting on march 4

date     crashes at
         CERT_DestroyCertificate
grep: spdg.dll: No such file or directory
spdg.dll 0
20110301 0
20110302 4
20110303 2
20110304 262
20110305 978
20110306 713
20110307 516
20110308 311
20110309 577
20110310 429
20110311 495

$ ./stacktrend.sh STAN_GetNSSCertificate spdg.dll 201103* | more

date     crashes at
         STAN_GetNSSCertificate
grep: spdg.dll: No such file or directory
spdg.dll 0
20110301 1
20110302 1
20110303 0
20110304 99
20110305 470
20110306 293
20110307 191
20110308 157
20110309 302
20110310 197
Blocks: 639276
Hi!

I had this problem quite some time now.
Found spdg.dll in C:\Windows\SysWOW64. (64-bit Windows 7).

Scanned it at VirusTotal for some better information about it:
It had already been analyzed once, so I re-analyzed it and compared to the old report.

Old VirusTotal scan on spdg.dll:
http://www.virustotal.com/file-scan/report.html?id=3e64fc7b7887f1c398e6632c14f42b33b88df042e0e07fab86916f6dad55be05-1298012701

The new VirusTotal scan on spdg.dll:
http://www.virustotal.com/file-scan/report.html?id=3e64fc7b7887f1c398e6632c14f42b33b88df042e0e07fab86916f6dad55be05-1301493682

So I tried to rename the file, after causing a crash before renaming it. To see if It would crash again when I visited the Crash Report (since its HTTPS).

Before renaming the spdg.dll:
http://crash-stats.mozilla.com/report/index/bp-a81e0819-62d8-45da-8576-9aa852110330

After renaming the spdg.dll to spdg1.dll in C:\Windows\SysWOW64:
http://crash-stats.mozilla.com/report/index/bp-fd50fa54-4041-4d14-9770-2c3c72110330

Last time I made a bug report for this, but it mysteriously got fixed after I had Ad-Aware running for about 12 hours removing some various cookies and minor threats. Now it's back again. Quite annoying that it runs perfectly on HTTP hosts but whenever a HTTPS request is sent, I'm dead.

Sincerely,
Pontus
Pontus,  this is some good information.  Can you attach or send us a copy of spdg.dll and we will try to get some addtional AV partner help to analyze what this thing is.
Attached spdg.dll, hopefully you can find out a bit more about this file as this is fairly unknown at Google.

Sincerely,
Pontus
Pontus: There is still "spdg.dll" in your second crash report. Load the crash report and look under "modules". Did you try a reboot ?
You can try this if the file appeared again: right click on the file, properties/permissions(?) and remove the permission for everything, including the system and reboot.
Matthias: No I did not reboot, just restarted firefox (or rather, firefox crashed - then started up again after sending crash report.)

I've tried changing the permissions to DENY ALL, for all users. But its not possible to edit away the SYSTEM permissions, and some for my user, as they were greyboxed. Conclusion: New crash, nothing changed.

Changed permissions and tried:
http://crash-stats.mozilla.com/report/index/bp-dcabe013-1b71-4ee8-9940-437f82110330

Just to be sure it could not load the file or anything in advance, I tried once again:
http://crash-stats.mozilla.com/report/index/bp-a431cc57-40f9-4495-8dd4-3b27a2110330

This issue has nothing to do with a reboot, as I have not tried deleting the file itself. I changed name of it, but Mozilla "loaded" it anyway, which is impossible. Must be some error in NSS when Mozilla think spdg.dll is loaded or when it actually is loaded tho. Not so sure about that.

Sincerely,
Pontus
we don't "think" something is loaded. the list of libraries in the crash report is the list of libraries that *are* loaded.

they're still loaded in bp-a431cc57-40f9-4495-8dd4-3b27a2110330

try following the instructions at:
http://www-archive.mozilla.org/quality/help/dependency-walker.html

you should see that the dll is in fact loaded.
Here is the Depency Walker log file, SPDG.DLL -> Error opening file. Permission denied (5). .rar for size issues.

Enjoy,
Pontus
Working with an AV partner preliminary results show that  spdg.dll is capable of connecting to a remote server in order to download a config file and additional code to run in memory.

updates from AV companies will be issued soon to detect and protect against any vulnerabilities associated with this .dll
fwiw, the dwi file shows that spdg is an lsp.

- FIREFOX.EXE
| - XUL.DLL
| | - WS2_32.DLL
| | | - SPDG.DLL

Anyway, if you look at the bottom pain of the dependency walker view, you'll see:

00:00:09.610: Loaded "c:\windows\syswow64\SPDG.DLL" at address 0x10000000 by thread 1.  Successfully hooked module.
00:00:14.727: DllMain(0x10000000, DLL_PROCESS_ATTACH, 0x001AFCFC) in "c:\windows\syswow64\SPDG.DLL" called by thread 1.
00:00:14.727: LoadLibraryA("advapi32.dll") called from "c:\windows\syswow64\SPDG.DLL" at address 0x100011AF by thread 1.
00:00:14.727: LoadLibraryA("advapi32.dll") returned 0x75AB0000 by thread 1.
00:00:14.758: GetProcAddress(0x75AB0000 [c:\windows\syswow64\ADVAPI32.DLL], "GetCurrentHwProfileA") called from "c:\windows\syswow64\SPDG.DLL" at address 0x100011C3 and returned 0x75AF0000 by thread 1.
00:00:14.758: GetProcAddress(0x76250000 [c:\windows\syswow64\WS2_32.DLL], "socket") called from "c:\windows\syswow64\SPDG.DLL" at address 0x10001218 and returned 0x76253F00 by thread 1.
00:00:14.774: GetProcAddress(0x76250000 [c:\windows\syswow64\WS2_32.DLL], "WSAStartup") called from "c:\windows\syswow64\SPDG.DLL" at address 0x10001239 and returned 0x7625C0FB by thread 1.
00:00:14.774: GetProcAddress(0x76250000 [c:\windows\syswow64\WS2_32.DLL], "WSACleanup") called from "c:\windows\syswow64\SPDG.DLL" at address 0x1000125A and returned 0x76253661 by thread 1.
00:00:14.774: GetProcAddress(0x76250000 [c:\windows\syswow64\WS2_32.DLL], "send") called from "c:\windows\syswow64\SPDG.DLL" at address 0x1000127B and returned 0x7625C4C8 by thread 1.
00:00:14.774: GetProcAddress(0x76250000 [c:\windows\syswow64\WS2_32.DLL], "recv") called from "c:\windows\syswow64\SPDG.DLL" at address 0x1000129C and returned 0x762547DF by thread 1.
00:00:14.789: GetProcAddress(0x76250000 [c:\windows\syswow64\WS2_32.DLL], "connect") called from "c:\windows\syswow64\SPDG.DLL" at address 0x100012BD and returned 0x762548BE by thread 1.
00:00:14.789: GetProcAddress(0x76250000 [c:\windows\syswow64\WS2_32.DLL], "closesocket") called from "c:\windows\syswow64\SPDG.DLL" at address 0x100012DE and returned 0x76253BED by thread 1.
00:00:14.789: GetProcAddress(0x76250000 [c:\windows\syswow64\WS2_32.DLL], "gethostbyname") called from "c:\windows\syswow64\SPDG.DLL" at address 0x100012FF and returned 0x76267133 by thread 1.
00:00:14.805: GetProcAddress(0x76250000 [c:\windows\syswow64\WS2_32.DLL], "htons") called from "c:\windows\syswow64\SPDG.DLL" at address 0x10001320 and returned 0x76252FAB by thread 1.
00:00:14.805: GetProcAddress(0x76250000 [c:\windows\syswow64\WS2_32.DLL], "socket") called from "c:\windows\syswow64\SPDG.DLL" at address 0x10001035 and returned 0x76253F00 by thread 1.
00:00:15.101: DllMain(0x10000000, DLL_PROCESS_ATTACH, 0x001AFCFC) in "c:\windows\syswow64\SPDG.DLL" returned 1 (0x1) by thread 1.

Which indicates that it's definitely being loaded on your system. And as chofmann notes, it certainly looks like it's going to do network activity.

Probably my favorite line in the dwi view is in the modules list pane:

(!) SPDG.DLL Error opening file. Åtkomst nekad (5).

Which means "Access denied". No well behaved file would refuse to let your friendly neighborhood debugger gets its properties. This is definitely your evil creature.
Summary: Crash [@ STAN_GetNSSCertificate ] with loaded spdg.dll, probably a malware → Crash [@ STAN_GetNSSCertificate ] with the spdg.dll malware
Ok, I just learned that.. When someone asked me to DENY everything access to spdg.dll - Almost all programs wont work. Because ws2_32.dll gets "lost", not loaded or something. So I cant run my system without using this spdg.dll with infection, anyone got a clean one ? :-)

I don't dare to do a ComboFix at this point, might be the boiling point which corrupts the computer completely.

Sincerely,
Pontus
use procmon or regedit to find the references in your registry to spdg.dll. you can export them before you delete them...
timeless: regedit can not find any references to spdg.dll in the registry. 
Quite odd :/
try procmon...
Crash Signature: [@ STAN_GetNSSCertificate ]
Only one crash in 8.0 (without the spdg.dll) over the last four weeks:
bp-3bf6d549-7813-452d-8e99-668332111120

The blocklisting is no longer required. I close it as WONTFIX.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
Product: addons.mozilla.org → Toolkit
You need to log in before you can comment on or make changes to this bug.