Closed
Bug 627716
Opened 13 years ago
Closed 13 years ago
Crash [@ STAN_GetNSSCertificate ] with the spdg.dll malware
Categories
(Toolkit :: Blocklist Policy Requests, defect)
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
Reporter | ||
Updated•13 years ago
|
Assignee: nobody → nobody
Component: Security → Libraries
Product: Core → NSS
QA Contact: toolkit → libraries
Version: Trunk → trunk
Comment 1•13 years ago
|
||
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.
Comment 2•13 years ago
|
||
cc'ing kai, this is a early top4 topcrahs for beta11
This is the highest non-abort crash on beta 11 ATM.
blocking2.0: --- → ?
Comment 4•13 years ago
|
||
I'm looking at this now.
Comment 5•13 years ago
|
||
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]
Comment 6•13 years ago
|
||
We should find out, is this a crash that got introduced with a recent version of NSS?
Comment 7•13 years ago
|
||
(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.
Comment 8•13 years ago
|
||
But in the calling frame, it appears to have a valid address, so I don't have any idea what's happening there.
Comment 9•13 years ago
|
||
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.
Comment 10•13 years ago
|
||
(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.
Comment 11•13 years ago
|
||
(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.
Comment 12•13 years ago
|
||
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.
Comment 14•13 years ago
|
||
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.
Comment 15•13 years ago
|
||
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
Comment 16•13 years ago
|
||
(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.
Reporter | ||
Comment 17•13 years ago
|
||
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
Updated•13 years ago
|
Assignee: nobody → nobody
blocking2.0: ? → -
Component: Libraries → Blocklisting
Product: NSS → addons.mozilla.org
QA Contact: libraries → blocklisting
Whiteboard: [hardblocker]
Version: trunk → unspecified
Comment 18•13 years ago
|
||
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,
Comment 19•13 years ago
|
||
does seem to affect 4.0 more than 3.6.x and earlier.
Comment 21•13 years ago
|
||
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)?
Comment 22•13 years ago
|
||
the signature continues to have 100% correlation to spdg.dll, and there is no version info for the .dll with any of reports.
Comment 23•13 years ago
|
||
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
Comment 24•13 years ago
|
||
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
Comment 25•13 years ago
|
||
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
Comment 26•13 years ago
|
||
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.
Comment 27•13 years ago
|
||
Attached spdg.dll, hopefully you can find out a bit more about this file as this is fairly unknown at Google. Sincerely, Pontus
Comment 28•13 years ago
|
||
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.
Comment 29•13 years ago
|
||
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
Comment 30•13 years ago
|
||
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.
Comment 31•13 years ago
|
||
Here is the Depency Walker log file, SPDG.DLL -> Error opening file. Permission denied (5). .rar for size issues. Enjoy, Pontus
Comment 32•13 years ago
|
||
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
Comment 33•13 years ago
|
||
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.
Reporter | ||
Updated•13 years ago
|
Summary: Crash [@ STAN_GetNSSCertificate ] with loaded spdg.dll, probably a malware → Crash [@ STAN_GetNSSCertificate ] with the spdg.dll malware
Comment 34•13 years ago
|
||
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
Comment 35•13 years ago
|
||
use procmon or regedit to find the references in your registry to spdg.dll. you can export them before you delete them...
Comment 36•13 years ago
|
||
timeless: regedit can not find any references to spdg.dll in the registry. Quite odd :/
Comment 37•13 years ago
|
||
try procmon...
Assignee | ||
Updated•13 years ago
|
Crash Signature: [@ STAN_GetNSSCertificate ]
Reporter | ||
Updated•13 years ago
|
Blocks: malware-attacks
Reporter | ||
Comment 38•13 years ago
|
||
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: 13 years ago
Resolution: --- → WONTFIX
Assignee | ||
Updated•8 years ago
|
Product: addons.mozilla.org → Toolkit
Comment hidden (spam) |
You need to log in
before you can comment on or make changes to this bug.
Description
•