Number 10 Firefox topcrash. http://crash-stats.mozilla.com/report/list?product=Firefox&query_search=signature&query_type=exact&query=&date=&range_value=1&range_unit=weeks&do_query=1&signature=_woutput_l (filing because no bugs were linked from crash-stats and I couldn't find any in a quick search)

Why are this and a whole bunch of other bugs filed today security-sensitive? The crash stats are public, and this bug has no extra data or testcases which would help exploitability.

not sure about the others but this one seems like pretty randomly distributed among a wide variety of sites so finding a way to reproduce and determining exploitability might be hard, and most of the time it takes quite a bit of time to encounter the crash. 1217 total crashes for woutput on 20090819-crashdata.csv 204 start up crashes inside 3 minutes 214.945 (days) total uptime for 1190 of these crashes where user crashed within the last year 260.101 (minutes) avg time since last crash distribution of versions where the crash was found on 20090819-crashdata.csv 614 Firefox 3.5.2 533 Firefox 3.0.13 17 Firefox 3.0.11 16 Firefox 3.0.12 11 Firefox 3.5 7 Firefox 3.5.1 3 Firefox 3.0.8 3 Firefox 3.0.5 3 Firefox 3.0.1 2 Firefox 3.0.7 2 Firefox 3.0.6 2 Firefox 3.0.4 2 Firefox 3.0.3 2 Firefox 3.0.10 users report crashing at 97 \N/// 33 about:blank/// 31 /// 25 http://www.yahoo.co.jp/ 20 http://esearch.rakuten.co.jp/rms 16 http://www.nicovideo.jp/watch 10 http://www.jalan.net/uw 9 http://directory.rakuten.co.jp/rms 8 http://web.travel.rakuten.co.jp/portal 7 https://login.yahoo.com/config 7 http://www.facebook.com/home.php?ref=home 6 https://www.paypal.com/us 6 https://grp02.id.rakuten.co.jp/rms 6 http://dailynews.yahoo.co.jp/fc 5 https://sa.step.rakuten.co.jp/rms 5 https://onlineeast2.bankofamerica.com/cgi-bin 5 http://my.ebay.com/ws 5 http://my.ebay.com.au/ws 5 http://live.nicovideo.jp/ 5 http://closeduser.auctions.yahoo.co.jp/jp 5 http://ch.nicovideo.jp/community 5 about:sessionrestore/// 4 https://www.paypal.com/au 4 https://my.screenname.aol.com/_cqr 4 http://www.yomiuri.co.jp/ and a very long tail that follows

this comment was interesting... firefox is crashing out alot on this machine, others not an issue. using trendmicro security pro 2009. crashes when clicking google links as well. right now internet exploder is more stable on this machine. the stack for this looks like 0 msvcr80.dll _woutput_l 1 msvcr80.dll _vscprintf_helper 2 msvcr80.dll _vscwprintf 3 TMUFEWrapper.dll TMUFEWrapper.dll@0x5dc2

os breakdown 940 _woutput_l Windows NT 5.1.2600 Service Pack 3 104 _woutput_l Windows NT 5.1.2600 Service Pack 2 88 _woutput_l Windows NT 6.0.6001 Service Pack 1 36 _woutput_l Windows NT 6.0.6002 Service Pack 2 16 _woutput_l Windows NT 6.0.6000 6 _woutput_l Windows NT 6.1.7100 1 _woutput_l Windows NT 5.1.2600 Service Pack 3, v.5755 1 _woutput_l Windows NT 5.1.2600 Service Pack 3, v.3264

Check out the following thread: http://www.techsupportforum.com/alternative-computing/mozilla-firefox-browsers/270580-solved-firefox-3-msvcr80-dll-crash.html

Ack, I didn't leave a synopsis. A search for "msvcr80.dll firefox" on google resulted in a number of crashes on Fx3.0.13 that were based on versioning differences with Flash/Java plugins in correspondence with AVG doing a virus scan (or doing one in the background while Fx was running) that caused either a race condition or file-touch to cause a crash (instantly or over time). As for this crash stack, with TMUFEWrapper.dll, Trend Micro seems to be the only anti-virus software that actively searches within that file during a scan. So, this might be occurring with that file alone. A search on bugzilla did not result in finding a crash associated with msvcr80.dll. I hope that helps.

Different stack here: http://crash-stats.mozilla.com/report/index/23689ff3-b31b-4996-ac95-49baa2090826 0 msvcrt.dll _woutput_l 1 msvcrt.dll _vsnwprintf_l 2 msvcrt.dll _vsnwprintf 3 IPHLPAPI.DLL StringCchPrintfW 4 IPHLPAPI.DLL StringCchPrintfW 5 IPHLPAPI.DLL ConvertInterfaceLuidToNameW 6 IPHLPAPI.DLL AddDhcpInfo 7 IPHLPAPI.DLL AddGatewayInfoToAdapter 8 IPHLPAPI.DLL GetAdaptersInfo 9 SmileyCore.dll SmileyCore.dll@0x93da Don't know what kind of crapware SmileyCore.dll is.

smileycore is in the hijackthis log of a report at http://www.bleepingcomputer.com/forums/lofiversion/index.php/t231547.html where firefox user was attacked by popup ads. http://en.securitylab.ru/viruses/383883.php says smiley is part of Adware.DoubleD which gets installed then then installs toolbars in Internet Explorer and Firefox. seems like SmileyCore.dll is another .dll worth considering blocking.

smileycore signatures are trending a bit higher than a few weeks ago but still around 100 per day. 27 total crashes for SmileyCore.dll on 20090805-crashdata.csv 12 total crashes for SmileyCore.dll on 20090806-crashdata.csv 13 total crashes for SmileyCore.dll on 20090807-crashdata.csv 11 total crashes for SmileyCore.dll on 20090808-crashdata.csv 18 total crashes for SmileyCore.dll on 20090809-crashdata.csv 26 total crashes for SmileyCore.dll on 20090810-crashdata.csv 47 total crashes for SmileyCore.dll on 20090811-crashdata.csv 36 total crashes for SmileyCore.dll on 20090812-crashdata.csv 91 total crashes for SmileyCore.dll on 20090813-crashdata.csv 109 total crashes for SmileyCore.dll on 20090814-crashdata.csv 86 total crashes for SmileyCore.dll on 20090815-crashdata.csv 103 total crashes for SmileyCore.dll on 20090816-crashdata.csv 91 total crashes for SmileyCore.dll on 20090817-crashdata.csv 115 total crashes for SmileyCore.dll on 20090818-crashdata.csv 95 total crashes for SmileyCore.dll on 20090819-crashdata.csv 111 total crashes for SmileyCore.dll on 20090820-crashdata.csv 97 total crashes for SmileyCore.dll on 20090821-crashdata.csv 107 total crashes for SmileyCore.dll on 20090822-crashdata.csv 84 total crashes for SmileyCore.dll on 20090823-crashdata.csv 81 total crashes for SmileyCore.dll on 20090824-crashdata.csv 0 total crashes for SmileyCore.dll on 20090825-comments.txt 72 total crashes for SmileyCore.dll on 20090825-crashdata.csv

there is actually a lot of nasty looking junk in http://crash-stats.mozilla.com/report/index/23689ff3-b31b-4996-ac95-49baa2090826 Module|HPFFAddOn.dll|1.5.0.850|HPFFAddOn.pdb|4B83E4394E6442CCA64CCA88F39A328A1|0x00b60000|0x00b91fff|0 Module|NPFFAddOn.dll|3.4.0.4340||6FD6FB397E6B497499C05D4F7AC6529E1|0x02d90000|0x02dc9fff|0 Module|NPCommon.dll|3.4.0.4340||071390CFF88E426089B1BA57A0DB35A41|0x03200000|0x0325bfff|0 see Bug 512122 - KB article: Crash signature - @NPFFAddOn.dll@0x11867 Module|SmileyCore.dll|4.1.3.0||CB58A21CDC8848309C8A0BD76B06F7271|0x022c0000|0x0235efff|0 Module|HPCommon.dll|1.5.0.850||974CEF80C22840C484F8B7A4B251DBAD1|0x02d00000|0x02d51fff|0 and also suspect Module|NPAskSBr.dll|1.0.0.0|NPAskSBr.pdb|4682A0061|0x04620000|0x04625fff|0 Module|A2PLUGIN.DLL|1.0.1.3|a2Plugin.pdb|4682A00D1|0x04670000|0x0467bfff|0 Module|ASKSBAR.DLL|2.3.0.11|||0x04c30000|0x04c70fff|0 and a few more that might be worth research DAPFireFox.dll -- speedbit IPHLPAPI.DLL on the stack there is also interesting. google search shows this is a possibily buggy Windows IP Helper API, but there are tons of sites offering up another version that is sure to get you running.... ack!

bump in the smileycore crashes happened just the day before the bump _woutput crashes. report for the stack signature _woutput 4 total crashes for _woutput on 20090805-crashdata.csv 0 total crashes for _woutput on 20090806-crashdata.csv 4 total crashes for _woutput on 20090807-crashdata.csv 3 total crashes for _woutput on 20090808-crashdata.csv 2 total crashes for _woutput on 20090809-crashdata.csv 6 total crashes for _woutput on 20090810-crashdata.csv 4 total crashes for _woutput on 20090811-crashdata.csv 10 total crashes for _woutput on 20090812-crashdata.csv 9 total crashes for _woutput on 20090813-crashdata.csv 716 total crashes for _woutput on 20090814-crashdata.csv 1178 total crashes for _woutput on 20090815-crashdata.csv 1136 total crashes for _woutput on 20090816-crashdata.csv 1232 total crashes for _woutput on 20090817-crashdata.csv 1279 total crashes for _woutput on 20090818-crashdata.csv 1217 total crashes for _woutput on 20090819-crashdata.csv 1294 total crashes for _woutput on 20090820-crashdata.csv 1251 total crashes for _woutput on 20090821-crashdata.csv 1156 total crashes for _woutput on 20090822-crashdata.csv 1201 total crashes for _woutput on 20090823-crashdata.csv 1217 total crashes for _woutput on 20090824-crashdata.csv 1289 total crashes for _woutput on 20090825-crashdata.csv

we could consider putting information about his crash in with the article about bug 512122, or a general guide about removing viruses helps firefox to run better and crash less.

The module analysis at http://dbaron.org/log/20090922-crashes shows: _woutput_l (65 crashes) 98% (64/65) vs. 1% (74/7100) TMUFEWrapper.dll 98% (64/65) vs. 1% (74/7100) tmufeng.dll 98% (64/65) vs. 1% (75/7100) TPTBConfigurationModule.dll 98% (64/65) vs. 1% (75/7100) HCMSLogger.dll 98% (64/65) vs. 1% (75/7100) FFToolbarComm.dll 98% (64/65) vs. 1% (75/7100) FFTMUFEHelper.dll 98% (64/65) vs. 1% (99/7100) security.dll 97% (63/65) vs. 1% (72/7100) TmTSHelp.dll 98% (64/65) vs. 7% (507/7100) winhttp.dll 78% (51/65) vs. 1% (59/7100) Tmfbeng.dll 98% (64/65) vs. 26% (1843/7100) sxs.dll ... 20% (13/65) vs. 0% (15/7100) tmfbeng.dll 20% (13/65) vs. 0% (35/7100) IMJP9K.DLL 20% (13/65) vs. 0% (35/7100) IMJP9.IME ...

blocking 3.6+ per CrashKill effort.

Marking all topcrash bugs as P2 (3.6 release blockers, but not 3.6b1 blockers)

http://dbaron.org/mozilla/crash-stats/interesting-addons has this highly correlated with a specific addon, need to see if we can lookup what extension this GUID it for. _woutput_l|EXCEPTION_ACCESS_VIOLATION (65 crashes) 98% (64/65) vs. 1% (75/7100) {22181a4d-af90-4ca3-a569-faed9118d6bc}

Google searches for that UUID shows it might be the trend micro toolbar. FF - HKLM\software\mozilla\Firefox\extensions\\{22181a4d-af90-4ca3-a569-faed9118d6bc}: C:\Program Files\Trend Micro\TrendSecure\TISProToolbar\FirefoxExtension [2009/06/07 20:26:39 | 00,000,000 | ---D | M] A few other things also pop up so maybe they also create conflicts.

Carsten; can you confirm that this is being caused by Trend Micro? If so, Dolske can start hammering into it.

the high correlations between stuff like FFToolbarComm.dll (adware/malware/searh redirector) in dbaron's comment 13 and dolske's trend micro find in comment 16 might indicate it's the combination of those two that creates the instability. maybe a case where everyone tries to get there hands on and manipulate the loading uri/content and firefox ends up crashing.

A free trial of the TrendMicro toolbar in question can be downloaded from http://us.trendmicro.com/us/products/personal/internet-security-pro/index.html

FFToolbarComm.dll is part of the trend micro toolbar, for what it's worth, so I don't see any reason to think it's an interaction: it seems like just one thing.

If I look at the URLs on which this crash is happening, they seem predominantly Japanese, so that seems likely to be related. The top URL domains are: 98 \N 38 about:blank 33 item.rakuten.co.jp 33 esearch.rakuten.co.jp 26 www.nicovideo.jp 26 20 www.yahoo.co.jp 20 live.nicovideo.jp 19 www.youtube.com 16 www.google.co.jp 14 viewmorepics.myspace.com 10 www.jalan.net 10 www.google.com 10 news.www.infoseek.co.jp 10 kakaku.com 10 job.rikunabi.com and the top individual URLs are: 19 http://www.yahoo.co.jp/ 6 http://live.nicovideo.jp/editstream 6 http://closeduser.auctions.yahoo.co.jp/jp/show/mystatus?select=closed&hasWinner=1 5 about:sessionrestore 4 http://www.google.com/firefox?client=firefox-a&rls=org.mozilla:en-US:official 4 https://my.screenname.aol.com/[...omitted...] 4 https://chaseonline.chase.com/MyAccounts.aspx 4 http://m.www.yahoo.com/ 3 http://www.nicovideo.jp/ 3 http://www.jaccs.co.jp/kameiten/credit/auto/sueoki.html 3 https://point.rakuten.co.jp/Top/TopDisplay/

I'm in contact with a folks at Trend Micro, and have a ticket open [SR1-1-282513240]. Sounds like they can gather some useful log data if we can contact a user that's hitting this, will search report comments for email / ping SUMO folks. Also need to compare module versions from crash reports with current version, maybe we can just blocklist older versions.

I don't have any crashes from the last month with this signature but only 80 of the thousands of users posting to the forum actually gave crash data.

In the last 500 3.5.4 crashes for this signature, the breakdown by DLL version was: 1 Module|FFTMUFEHelper.dll|1.2.0.1110 6 Module|FFTMUFEHelper.dll|1.3.0.1020 112 Module|FFTMUFEHelper.dll|1.2.0.1073 179 Module|FFTMUFEHelper.dll|1.6.0.1126 199 Module|FFTMUFEHelper.dll|1.2.0.1093 [That's 497, the other 3 involved SmileyCore.dll (mentioned in earlier comments) -- ignoring that for now as it's a different, infrequent problem.] The current version of this DLL in my recent install is 1.6.0.1126, so there isn't a stable version for users to update to (or for us to not blocklist).

I had the Socorro guys run a query over the last 3 months of crashes for this signature (bug 525962), and checked the comments and email fields to see if there were people we could contact. I found just 2 email addresses, and have sent email to those people to see if they're willing to help us diagnose this problem.

(In reply to comment #23) > I'm in contact with a folks at Trend Micro, and have a ticket open > [SR1-1-282513240]. Oops, wrong ticket. I had that closed as a dupe of [SR1-1-282061743] (they accidentally opened 2 tickets for my initial volley of email).

So, I think progress is stuck here. Neither us nor Trend Micro can reproduce this, and I haven't heard anything from them since my last email on 11/8. Last remaining idea was to run Trend Micro with a memory checking tool like Purify. Next possible actions would be to try escalating further up at Trend Micro and blocklisting.

seems to have leveled off at about 1400-1500 crashes per day across all releases. 1471 total crashes for _woutput_l on 20091111-crashdata.csv 1292 total crashes for _woutput_l on 20091112-crashdata.csv 1536 total crashes for _woutput_l on 20091113-crashdata.csv 1445 total crashes for _woutput_l on 20091114-crashdata.csv 1445 total crashes for _woutput_l on 20091115-crashdata.csv 1427 total crashes for _woutput_l on 20091116-crashdata.csv 1448 total crashes for _woutput_l on 20091117-crashdata.csv 1433 total crashes for _woutput_l on 20091118-crashdata.csv

looking through a log of comments over the past several days I see lots of comments about the troubles with paypal on this signature logging into paypal account https://www.paypal.com/cgi-bin/webscr? -scrubbed using paypal account https://www.paypal.com/us/cgi-bin/webscr?cmd=_security-center https://www.paypal.com/us/cgi-bin/webscr?cmd=_ -scrubbed session info https://history.paypal.com/au/cgi-bin/webscr?cmd=_history-details&info= -scrubbed session info returning to accounts https://history.paypal.com/au/cgi-bin/webscr?cmd=_history-details&info= -scubbed session info returning to account https://www.paypal.com/au/cgi-bin/webscr?cmd=_security-center https://www.paypal.com/us/cgi-bin/webscr?cmd=_login-processing&login_cmd=_login-done&login_access= -scrubbed session info https://www.paypal.com/au/cgi-bin/webscr?cmd=_flow& -scrubbed session info this is the third time today in a 10 minute time span where firefox has crashed on the paypal website, please fix this asap. https://www.paypal.com/jp/cgi-bin/webscr?cmd=_login-processing&login_cmd=_login-done&login_access= -scrubbed session info https://www.paypal.com/au/cgi-bin/webscr?cmd=_login-processing&login_cmd=_login-done&login_access= -scrubbed session info https://www.paypal.com/au/cgi-bin/webscr?cmd=p/acc/refund-done&original_id= - scrubbed session info I was on paypal.com just about to enter my password | http://paypal.com https://www.paypal.com/ca/cgi-bin/webscr?cmd=_home&country_lang.x=true

Please don't spam the bug like that, there's no new info there and it makes reading bugs difficult. Add as an attachment if you must.

ok, sorry. some interesting word use comment patterns that might help in figuring out some things to try around on-line financial and e-commerce login and transactions 17 banking, bank, Bank, [bank of?]America 3 password 3 ebay 5 PayPal paypal 4 payment pay 2 http://chaseonline.chase.com, 4 bills bill 2 account. 3 transactions. transactions! TRANSACTION. 2 loging, log about 20% of the crash urls reported for this signature in the last 8 days are https: in the full population of crash urls for the same period only about 2% are https:

Where is this in terms of the topcrash list for Firefox 3.5.5 and Firefox 3.6b4? I'm not sure we can continue to block on this as we don't have a solid STR or rationale for blocklisting at this point.

It's currently #5 for Firefox 3.5.5 and #60 for Firefox 3.6b4, likely because our set of users is different.

its about 0.7% of 3.0.15 crashes, 0.9% of 3.5.5 crashes, and 0.2% of 3.6b4 crashes and we should probably expect that to rise once 3.6 gets wider distribution. checking --- 20091130-crashdata.csv _woutput_l release total-crashes _woutput_l crashes pct. all 233706 1575 0.00673924 3.0.15 50334 369 0.00733103 3.5.5 122547 1070 0.00873134 3.6b4 16576 46 0.0027751 3.6b3 2703 11 0.00406955 3.6b2 1193 0 3.6b1 2776 5 0.00180115 agree that its probably not tied to any firefox release blocking unless we learn something new and unexpected.

Any updates on this? This affects lots of Japanese users. Please blocklist the plug-in ASAP (Bug 519934).

(In reply to comment #34) > It's currently #5 for Firefox 3.5.5 and #60 for Firefox 3.6b4, likely because > our set of users is different. That's because Mozilla Japan has not promoted beta versions to end users, I think. Now 3.6 shipped and this enters the topcrash chart at #10.

Now we are in touch with the Trend Micro HQ, based in Tokyo, Japan. The support team didn't know about this and began investigating.

I have Trend Micro Internet Security Pro 2009 with the toolbar and Firefox crashes on me on a regular basis. I have submitted numerous reports over the past several months. I usually see it when accessing secure sites but that is not always the case. As others have said, it is not always with the same sites (though there are a few where it occurs fairly regularly). I use Firefox on many other machines without it and rarely have any problems. Is there anything I can do to help resolve this?

The Trend Micro team has been investigating the crashes. Stay tuned for further updates.

(In reply to comment #40) > The Trend Micro team has been investigating the crashes. Stay tuned for further > updates. Hi: This is engineer from Trend Micro team, We are investigating this issue, Currently, we could not get much information about this crash, Could you please help to try to contact some user encounter this issue, ask them reproduce this crash, collect the crash dump file and send us to do further analyze. Thanks for your help!

I just had three crashes within a few minutes of each other. Here are the crash reports. http://crash-stats.mozilla.com/report/index/bp-bc8decfd-f410-4074-aa06-4faea2100224 http://crash-stats.mozilla.com/report/index/bp-78b06285-17a7-40b4-8397-5b7062100224 http://crash-stats.mozilla.com/report/index/bp-c79ee5c9-9a92-4f8c-8c71-cdc342100224 Let me know if there is any additional information I can gather for you.

Hi Scott: Thanks for your help, If Ok, Could you please send me the log files at C:\Documents and Settings\%UserName%\Local Settings\Application Data\Trend Micro\TrendSecure\Log Thanks!

Jerry: Did you receive those logs? Have you made any progress on figuring out what's going on here? Is there some way we could help?

FYI, I emailed my logs directly to Jerry Friday evening. I have not heard anything since. Also, just a note for comparison: I was working on building a new machine over the weekend. My old one was running Windows XP, 32-bit on an AMD processor with 32-bit version of Internet Security Pro. The new one is Windows 7, 64-bit on AMD Phenom II x4 running the 64-bit version of Internet Security Pro. Both systems have the same behavior with Firefox crashing. The new machine was up about a half hour before Firefox crashed.

I don't know if this is related, but I noticed this error in the Firefox error console: Error: uncaught exception: [Exception... "Component returned failure code: 0x80004002 (NS_NOINTERFACE) [nsIInterfaceRequestor.getInterface]" nsresult: "0x80004002 (NS_NOINTERFACE)" location: "JS frame :: chrome://tmtoolbar/content/TMTBBtnTrendProtect.js :: onCallbackSyncStatus :: line 656" data: no] The error console doesn't have date/time information so it is hard to know for sure, but it does not appear that this error happens every time Firefox crashes.

One other thing, I also saw quite a few instances of this error: Error: objBrowser is null Source File: chrome://tmtoolbar/content/TMTBBtnTrendProtect.js Line: 662 I can attach the .js file if that's useful for anyone.

currently the #5 topcrash in early firefox 3.6.2 crash data. any progress on analyzing?

I haven't heard anything since I sent the Trend Micro logs to Jerry almost a month ago. An update would be nice.

The Trend team has said their hot-fix will be available at the end of this month.

Yesterday Trend published their support page and hot-fix for Japanese customers: http://esupport.trendmicro.co.jp/Pages/JP-2076783.aspx And we just posted an entry to the Mozilla Japan blog: http://mozilla.jp/blog/entry/5396/ We are asking them how they will provide the hot-fix for overseas customers.

the trend micro fix may help, but there might be other bugs lurking here. this ranked #9 in early 3.6.3 data andf is one of several bugs that have strong correlation to win9x and either was introduced or dramatically increased with firefox 3.6.x. maybe due to changes in win9x support in nspr checking --- 20100403-crashdata.csv _woutput release total-crashes _woutput crashes pct. all 309662 2280 0.00736287 3.0.17 498 1 0.00200803 3.0.18 2333 10 0.00428633 3.5.5 1753 4 0.0022818 3.5.7 2227 7 0.00314324 3.5.8 12315 58 0.0047097 3.6 21088 100 0.00474203 3.6.2 61458 452 0.00735462 3.6b5 953 1 0.00104932 os breakdown 1776 0.778947 Windows NT5.1.2600 Service Pack 3 230 0.100877 Windows NT5.1.2600 Service Pack 2 3 0.00131579 Windows NT5.1.2600 Dodatek Service Pack 3 1 0.000438596 Windows NT5.1.2600 Service Pack 3, v.5913 1 0.000438596 Windows NT5.1.2600 Service Pack 3, v.3264 1 0.000438596 Windows NT5.1.2600 Dodatek Service Pack 2 201 0.0881579 Windows NT6.0.6002 Service Pack 2 53 0.0232456 Windows NT6.0.6001 Service Pack 1 13 0.00570175 Windows NT6.0.6000 1 0.000438596 Windows NT6.1.7100

the missing chunk of crashes in that list above was firefox 3.6.3 3.6.3 155253 1436 0.00924942

Trend's English support page and hot fix are now available at http://esupport.trendmicro.com/pages/My-Firefox-web-browser-crashes-while-browsing.aspx

(In reply to comment #52) > this ranked #9 in early 3.6.3 data andf is one of several bugs that have strong > correlation to win9x and either was introduced or dramatically increased with > firefox 3.6.x. maybe due to changes in win9x support in nspr In case other people aren't reading the bugs Chris has commented in already, Firefox 3.6.x doesn't even support Windows 95 or anything like it. The last version to support Windows 9x was Firefox 2, which didn't support Breakpad. The data pasted in comment 52 correlates to Windows NT5.1.2600 Service Pack 3, which is Windows XP.

BTW, can we send (an automatic) reply to the reporters? Some of them provide his/her email address, so it would be nice to tell them "Your crash was caused by the Trend Toolbar add-on. Please install the hot fix to resolve the issue."

For what it's worth, I've had the hot fix loaded for 3-4 days now and so far no crashes. After many many months, hopefully I'm finally back to good old crash-free Firefox.

Now Trend has stared to deliver the hotfix to their customers via the auto update feature of their product. We should still watch Bug 542201 would be resolved by the hotfix or not.

The Japanese announcement of the auto update is here: http://www.trendmicro.co.jp/support/news.asp?id=1416

ok, where is where this signature is the last few days. around 2000-2200 per day on weekdays, and 1500-1600 on weekends. we can watch to see it go down from here and figure out if there are additional causes for this signature. 20100530 2029 20100531 2208 20100601 2224 20100602 2104 20100603 1649 20100604 1599 20100605 1514 20100606 1507 20100607 1936 20100608 2141