add GoogleDesktopNetwork3.dll with no version number to DLL blocklist to prevent crash [@ GoogleDesktopNetwork3.dll@0x3dfb]

RESOLVED FIXED in Firefox 3.7a1



10 years ago
7 years ago


(Reporter: cbook, Assigned: johnath)


(Depends on: 1 bug, {crash, topcrash})

3.6 Branch
Firefox 3.7a1
Windows XP
crash, topcrash
Dependency tree / graph
Bug Flags:
blocking-firefox3.6 +

Firefox Tracking Flags

(status1.9.2 final-fixed)


(Whiteboard: [crashkill][crashkill-outreach][dll-block], crash signature)


(1 attachment)

Blocking 3.6+ per CrashKill effort.
Flags: blocking-firefox3.6? → blocking-firefox3.6+
Marking all topcrash bugs as P2 (3.6 release blockers, but not 3.6b1 blockers)
Priority: -- → P2
Assigning to Tomcat.
Assignee: nobody → cbook

Comment 4

10 years ago
not able to reproduce so far, will generate a url list.
Is this DLL loaded as part of an add-on, or by direct injection into the components directory?  If the latter, please mark as blocking 519357.  If the former, we should look at blocklisting.

(FWIW, this is one of the DLLs that Chrome explicitly prevents from loading into its renderer processes, due to crash concerns.)
As I recall, this is caused by an old DLL that's left hanging around after a new version of Google Desktop is installed without the old one being explicitly removed. To reproduce you'll need an earlier version of the software. I don't think it's being added directly into the components directory (hard to tell) but think our response should be to blocklist it, so adding this to the dependency list for bug 525103
Blocks: 525103
Summary: Crash [@GoogleDesktopNetwork3.dll@0x3dfb] → add GoogleDesktopNetwork3.dll to DLL blocklist to prevent crash [@GoogleDesktopNetwork3.dll@0x3dfb]
Whiteboard: [crashkill][crashkill-outreach]
(reached out to the lead of the Google Desktop team and referred him to this bug, hopefully we'll get some feedback from them soon)
From our fine friends at Google:

> We just started an autoupdate of all users with our latest version of Google 
> Desktop, which should have a fix for the issue in question.
> To ensure that our testing team sees the same resolution as your testing team, 
> can you have your QA install the latest version of Google Desktop from 
> to see if it resolves the issue?
> On the Chrome point, Chrome itself does not block the DLL. The Chrome renderer 
> process, which does not access the network, does. If your QA does not see a fix 
> with the latest version of Google Desktop, let's then revisit how to work with 
> the DLL in a similar manner.

Comment 4 implies that we weren't able to reproduce this already, but we should keep an eye on the crash stack numbers and see if they're dropping over the next week or so.

Comment 9

9 years ago
Looking at crash stats, the push doesn't seem to have had much effect. 

Firefox 3.5.[1-5] crashes in the last week with this signature: 1451 (

Firefox 3.5.[1-5] crashes in one week last month: 1583 (

In order to figure out whether this should be blocklisted or not, though, we still need an answer to Shaver's question in comment 5 - is this a compdir drop, or a DLL that we need to blocklist?

Socorro has seen a total of 67 crashes on 3.6b3 with this signature, and that version had the compdir lockdown in place. I think that means that the DLL is being loaded through some other vector, but I'd like the Google folks to confirm that. (
Installed the latest version, and it installed the following files into the appdir (c:\program files\mozilla firefox and c:\program files\mozilla firefox 3):


Those components are *also* installed in c:\program files\google\google desktop search along with GoogleDesktopNetwork3.dll

Comment 11

9 years ago
I can confirm jonath's findings that there still is a problem with 3.6b3.  The daily crash volume is actually higher than 3.6b2 for reports in nov.

./ GoogleDesktopNetwork3.dll 3.6b3 200911*

  17 20091118-crashdata.csv GoogleDesktopNetwork3.dll@0x3dfb 3.6b3

   1 20091119-crashdata.csv GoogleDesktopNetwork3.dll@0x106b7 3.6b3
   5 20091119-crashdata.csv GoogleDesktopNetwork3.dll@0x3dfb 3.6b3

  16 20091120-crashdata.csv GoogleDesktopNetwork3.dll@0x3dfb 3.6b3

   1 20091121-crashdata.csv GoogleDesktopNetwork3.dll@0x130d4 3.6b3
   1 20091121-crashdata.csv GoogleDesktopNetwork3.dll@0x3bef 3.6b3
  13 20091121-crashdata.csv GoogleDesktopNetwork3.dll@0x3dfb 3.6b3

./ GoogleDesktopNetwork3.dll 3.6b2 200911*

   1 20091111-crashdata.csv GoogleDesktopNetwork3.dll@0x3dfb 3.6b2
   2 20091113-crashdata.csv GoogleDesktopNetwork3.dll@0x3dfb 3.6b2
   3 20091114-crashdata.csv GoogleDesktopNetwork3.dll@0x3dfb 3.6b2
   2 20091115-crashdata.csv GoogleDesktopNetwork3.dll@0x3dfb 3.6b2

   1 20091116-crashdata.csv GoogleDesktopNetwork3.dll@0x3dfb 3.6b2
   2 20091116-crashdata.csv GoogleDesktopNetwork3.dll@0x3bef 3.6b2

   1 20091117-crashdata.csv GoogleDesktopNetwork3.dll@0x3dfb 3.6b2
   1 20091117-crashdata.csv GoogleDesktopNetwork3.dll@0x2c0f 3.6b2
   1 20091117-crashdata.csv GoogleDesktopNetwork3.dll@0x106b7 3.6b2
   6 20091117-crashdata.csv GoogleDesktopNetwork3.dll@0x3dfb 3.6b2

   1 20091118-crashdata.csv GoogleDesktopNetwork3.dll@0x3dfb 3.6b2
   1 20091119-crashdata.csv GoogleDesktopNetwork3.dll@0x3dfb 3.6b2

Comment 12

9 years ago
in the 3.6 data it looks like we only see 1 or 2 address in the signatures.

in a one day sample of 3.5.5 we see 11

GoogleDesktopNetwork3.dll@0x1036b 3.5.5
GoogleDesktopNetwork3.dll@0x106b7 3.5.5
GoogleDesktopNetwork3.dll@0x130d4 3.5.5
GoogleDesktopNetwork3.dll@0x2c0f 3.5.5
GoogleDesktopNetwork3.dll@0x3b5a 3.5.5
GoogleDesktopNetwork3.dll@0x3bef 3.5.5
GoogleDesktopNetwork3.dll@0x3d99 3.5.5
GoogleDesktopNetwork3.dll@0x3dfb 3.5.5
GoogleDesktopNetwork3.dll@0x41a7 3.5.5
GoogleDesktopNetwork3.dll@0x464c 3.5.5
GoogleDesktopNetwork3.dll@0xe601 3.5.5

That could indicate just a wider spread use pattern in 3.5.5 or maybe we are blocking some, but not all, loading.


9 years ago
Summary: add GoogleDesktopNetwork3.dll to DLL blocklist to prevent crash [@GoogleDesktopNetwork3.dll@0x3dfb] → add GoogleDesktopNetwork3.dll to DLL blocklist to prevent crash [@ GoogleDesktopNetwork3.dll@0x3dfb]
I'm going to suggest that we not block ship on this, as we can address it with the DLL blocklist in a dot-release if the component directory lockdown doesn't resolve the issue.
Flags: blocking-firefox3.6+ → blocking-firefox3.6?
Whiteboard: [crashkill][crashkill-outreach] → [crashkill][crashkill-outreach][dll-block]
Latest discussions with Google indicate that the crashing DLL has no version number, meaning that it's an old DLL kicking about. They've said that if we can add "no version" entries to our DLL blocklist, we probably should.

--> because that's the component we're using for this sort of stuff
--> back to blocking for release
--> johnath for resolution!
Assignee: cbook → nobody
Component: General → Blocklisting
Flags: blocking-firefox3.6? → blocking-firefox3.6+
Product: Firefox →
QA Contact: general → blocklisting
Summary: add GoogleDesktopNetwork3.dll to DLL blocklist to prevent crash [@ GoogleDesktopNetwork3.dll@0x3dfb] → add GoogleDesktopNetwork3.dll with no version number to DLL blocklist to prevent crash [@ GoogleDesktopNetwork3.dll@0x3dfb]
Version: 3.5 Branch → unspecified
(Johnath and I agreed that when we decide to DLL blocklist, it should actually stay in Firefox::General)
Component: Blocklisting → General
Product: → Firefox
QA Contact: blocklisting → general
Target Milestone: --- → Firefox 3.6
Version: unspecified → 3.6 Branch
(In reply to comment #15)
> (Johnath and I agreed that when we decide to DLL blocklist, it should actually
> stay in Firefox::General)

Any rationale for this? As you said in comment #14 is more appropriate, because that's the component you're using for this sort of stuff.

Comment 17

9 years ago
(In reply to comment #16)
> Any rationale for this? As you said in comment #14
> is more appropriate, because that's the
> component you're using for this sort of stuff.

Principally flag management, frankly. I have said at multiple development meetings that all blocklist requests should filter through the existing blocklist component, because it helps ensure that we use the plugin blocklist instead of the DLL blocklist whenever possible. But is not a product that has concepts of "blocking-firefox3.6" or "status-1.9.2".

Bugs should start there, should be analyzed and triaged there, but if it is determined that a Firefox change is the way to go, they come here (or a toolkit component, since that's where the blocklist lives - or maybe eventually it's own component -- not really interested in bogging the process down with bugzilla busywork, though).

Comment 18

9 years ago
johnath: alright, so let's make a component in Firefox for blocklisting. I do not want blocklisting bugs to be buried in general.

Comment 19

9 years ago
alternatively, extending the existing flags to the amo blocklisting component is relatively trivial.

Comment 20

9 years ago
Assignee: nobody → johnath
Attachment #417488 - Flags: review?(vladimir)
Whiteboard: [crashkill][crashkill-outreach][dll-block] → [can land][crashkill][crashkill-outreach][dll-block]
Last Resolved: 9 years ago
Resolution: --- → FIXED
Target Milestone: Firefox 3.6 → Firefox 3.7a1
Pushed to 192:
status1.9.2: --- → final-fixed
Whiteboard: [can land][crashkill][crashkill-outreach][dll-block] → [crashkill][crashkill-outreach][dll-block]
Crash Signature: [@ GoogleDesktopNetwork3.dll@0x3dfb]


7 years ago
Depends on: 750601
You need to log in before you can comment on or make changes to this bug.