Closed
Bug 665775
Opened 14 years ago
Closed 12 years ago
Blocklist Extensions and dlls to prevent datamngr.dll crashes
Categories
(Toolkit :: Blocklist Policy Requests, defect)
Tracking
()
RESOLVED
WONTFIX
Tracking | Status | |
---|---|---|
firefox5 | + | --- |
People
(Reporter: marcia, Unassigned)
References
Details
(Keywords: qawanted, Whiteboard: [extension][softblock][dll])
Attachments
(1 file)
952 bytes,
patch
|
benjamin
:
review+
|
Details | Diff | Splinter Review |
Spunoff from Bug 622140 Comment 16. This crash has high enough volume that we would like to go forward with a blocklist. In the last week there are 11,284 crashes across all Firefox versions of each signature in Bug 622140.
Module:
datamngr.dll (Imesh) version: 1.0.0.1 (risk to blocklist other valid dlls, see Bug 622140 comment 3 and comment 8)
Extensions (hijacker/adware categories):
* {1FD91A9C-410C-4090-BBCC-55D3450EF433} all versions (jZip.Toolbar, see http://forums.spybot.info/showthread.php?t=62634)
* {c2d64ff7-0ab8-4263-89c9-ea3b0f8f050c} all versions (MediaBar, see http://www.spywareremove.com/removeBearShareMediabar.html)
* {28387537-e3f9-4ed7-860c-11e69af4a8a0} all versions (MediaBar)
* {99079a25-328f-4bd4-be04-00955acaa0a7} all versions (Searchqu toolbar, other name of MediaBar)
Reporter | ||
Updated•14 years ago
|
Summary: Blocklist Extensions and dlls to prevent → Blocklist Extensions and dlls to prevent datamngr.dll crashes
Comment 2•14 years ago
|
||
Please provide more details -- I need Firefox versions and add-on versions to be blocked.
Kev, do you have any contacts at the above?
Comment 3•14 years ago
|
||
(In reply to comment #2)
> I need Firefox versions and add-on versions to be blocked.
Add-on versions were given in comment 0.
Firefox versions: all versions
Comment 4•14 years ago
|
||
Discordia Ltd. is the parent org of all of these toolbars (they also are the parent of Bandoo and lphant), and only makes a contact address available via postal mail. We have no formal contacts, but I'll send a note to their privacy addresses.
Is this not just a candidate for Firefox 4+? Glancing at the bugs I didn't see a lot of mention of 3.x.
I'd go ahead and BL when ready, but not sure it's appropriate to block in older versions of Firefox.
Comment 5•14 years ago
|
||
(In reply to comment #4)
> Is this not just a candidate for Firefox 4+? Glancing at the bugs I didn't
> see a lot of mention of 3.x.
Right for Firefox 4+ if the purpose of the add-on blocklisting is only to add stability.
Reporter | ||
Comment 6•14 years ago
|
||
This shows up in the top 20 non plugin reports for 5.0: https://crash-analysis.mozilla.com/chofmann/20110627/top-5.0.html. I am trying to work to get a better list of Firefox versions, but a cursory glance showed that 3.6, 4.0.x and 5.0 were affected.
Comment 7•14 years ago
|
||
https://crash-stats.mozilla.com/topcrasher/byversion/Firefox/5.0/7 says that [@ @0x0 | datamngr.dll@0xd2d1 ] happens in the following Firefox versions:
7.0a1, 6.0a1, 6.0a2, 5.0a2, 5.0, 4.0a1pre, 4.0, 4.2a1pre, 4.0b9pre, 4.0b9, 4.0b8pre, 4.0b8, 4.0b7pre, 4.0b7, 4.0b6, 4.0b5pre, 4.0b5, 4.0b4, 4.0b3, 4.0b2pre, 4.0b2, 4.0b13pre, 4.0b12pre, 4.0b12, 4.0b11pre, 4.0b11, 4.0b10pre, 4.0b10, 4.0b1, 4.0.1, 3.6.18, 3.7a5pre, 3.7a5, 3.7a4webm, 3.7a3, 3.7a2, 3.7a1pre, 3.7a1, 3.6b5, 3.0, 3.6b4, 3.6b3, 3.6b2, 3.6b1, 3.6.9, 3.6.8, 3.6.7, 3.6.6, 3.6.4, 3.6.3plugin1, 3.6.3, 3.6.2, 3.6.17, 3.6.16, 3.6.15pre, 3.6.15, 3.6.14, 3.6.13, 3.6.12, 3.6.11, 3.6.10, 3.6, 3.5b99, 3.5b4, 3.5.9, 3.5.8, 3.5.7, 3.5.6, 3.5.5, 3.5.4, 3.5.3, 3.5.2, 3.5.19, 3.5.18, 3.5.17, 3.5.16, 3.5.15, 3.5.13, 3.5.11, 3.5.10, 3.5.1, 3.5, 3.1b3, 3.1b2, 3.1b1, 3.0b5, 3.0b4, 3.0b2, 3.0b1, 3.0a8, 3.0.9, 3.0.8, 3.0.7, 3.0.6, 3.0.5, 3.0.4, 3.0.3, 3.0.19, 3.0.17, 3.0.16, 3.0.15, 3.0.14, 3.0.11, 3.0.10, 3.0.1
Judging from that, I think all Firefox versions should be in the blocking.
Comment 8•14 years ago
|
||
(In reply to comment #3)
> (In reply to comment #2)
> > I need Firefox versions and add-on versions to be blocked.
> Add-on versions were given in comment 0.
> Firefox versions: all versions
This was filed as a crash block, so all extension versions in all versions of Firefox is too extreme. Given our problems not being able to unblock things in the past, I'm not willing to use that range for a crash block.
Comment 9•14 years ago
|
||
Justin, can you explain this further. Why is this too extreme?
Comment 10•14 years ago
|
||
(In reply to comment #6)
> This shows up in the top 20 non plugin reports for 5.0:
> https://crash-analysis.mozilla.com/chofmann/20110627/top-5.0.html. I am
> trying to work to get a better list of Firefox versions, but a cursory
> glance showed that 3.6, 4.0.x and 5.0 were affected.
With combined signatures, it is:
* #4 top browser crasher in 5.0 (4696 crashes/week)
* #5 top browser crasher in 4.0.1 (4657 crashes/week)
* #18 top browser crasher in 3.6.18 (972 crashes/week)
So if the add-on blocklisting is restricted to the top-10 crashers, it's Firefox 4 and above, to the top-20 crashers, it's all Firefox versions.
(In reply to comment #8)
> This was filed as a crash block, so all extension versions in all versions
> of Firefox is too extreme. Given our problems not being able to unblock
> things in the past, I'm not willing to use that range for a crash block.
These extensions are known as hijacker and will stay as that for future versions. It's probably the hijacking process that makes Firefox crash.
But, anyway, here are the current versions:
* {c2d64ff7-0ab8-4263-89c9-ea3b0f8f050c} (MediaBar): 4.3.0.00
* {28387537-e3f9-4ed7-860c-11e69af4a8a0} (MediaBar): 4.3.0.00
* {99079a25-328f-4bd4-be04-00955acaa0a7} (Searchqu toolbar): 4.3.0.00
In recent crash stats, I see no longer correlations with jZip.Toolbar, so don't blocklist it.
Comment 11•14 years ago
|
||
I've staged softblocks for the 3 guids in comment #10 for versions <= 4.3.0.00 in all versions of Firefox. Please test: https://wiki.mozilla.org/Blocklisting/Testing
Assignee: nobody → fligtar
OS: Mac OS X → Windows 2000
Hardware: x86 → All
Whiteboard: [extension][softblock][needs testing]
Reporter | ||
Comment 12•13 years ago
|
||
fligtar: Sorry I missed the bugmail on this. I will test this today.
(In reply to comment #11)
> I've staged softblocks for the 3 guids in comment #10 for versions <=
> 4.3.0.00 in all versions of Firefox. Please test:
> https://wiki.mozilla.org/Blocklisting/Testing
Reporter | ||
Comment 13•13 years ago
|
||
I was able to test {c2d64ff7-0ab8-4263-89c9-ea3b0f8f050c} so far and confirm that the soft block works for that GUID. But I am having trouble locating the searchqu and the other GUID for Media Bar. I will udpate the bug when I have confirmed both of those.
Reporter | ||
Comment 14•13 years ago
|
||
When I download Bandoo version 7, I get 4.3.1.00 of searchqu {99079a25-328f-4bd4-be04-00955acaa0a7}. I have not yet been able to locate the earlier version of that toolbar or the other version of the mediabar.
Comment 15•13 years ago
|
||
Are we softblocking by design, or might this be a better hardblock candidate given comment #8 and unblocking.
Comment 16•13 years ago
|
||
Asa, we want to get these blocked since it adds up to a lot of crashes. We have only been able to verify one of the versions since Marcia has had trouble installing the earlier ones. Do we go ahead and just block the 3 anyhow? What do you think?
Reporter | ||
Comment 17•13 years ago
|
||
Asa asked me about volume - the combined signatures make it harder to give it an overall ranking, but a quick crash stats query of "contains" datamngr.dll shows roughly 7000 crashes in the last week across all versions. If you look at a span of 4 weeks across all versions the total is 46K. So I think that would be a pretty compelling reason to blocklist this dll.
Comment 18•13 years ago
|
||
Blocked in production.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Whiteboard: [extension][softblock][needs testing] → [extension][softblock]
Comment 19•13 years ago
|
||
Now the latest version is 4.3.1.00 as crashy as the blocked 4.3.0.00: no change in crash ranking.
It would haven't happen if all versions have been blocked as requested in comment 0.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 20•13 years ago
|
||
So for all these dlls we end up with over 700 a day. What is the next level of blocking we can do here. Do we have to block everything? Is there an intermediate step?
Comment 21•13 years ago
|
||
I've updated the block to cover 4.3.1.00.
Why are they still releasing new versions that crash? Can we try outreach again?
Status: REOPENED → RESOLVED
Closed: 13 years ago → 13 years ago
Resolution: --- → FIXED
Comment 22•13 years ago
|
||
(In reply to comment #21)
> I've updated the block to cover 4.3.1.00.
>
> Why are they still releasing new versions that crash? Can we try outreach
> again?
We never could outreach as they don't have a useful contact. And this is as far as we know malware, they surely will always just bump the version when they find out it doesn't work as they like.
Comment 23•13 years ago
|
||
Hello, I'm with the dev team of Bandoo and we are trying hard to resolve the problem you report
The datamngr.dll bug which caused the reported crashes was already fixed and released couple of weeks ago. As more users get the fix we should see less crashes
The different toolbars which were blocked are independent from the datamngr.dll
Blocking the toolbars is not going to prevent or reduce crashes
The latest version of Bandoo available at http://bandoo.com/ has the fixed component along with toolbar version 4.3.1.0
This is not malware, we don't want to bump the version number up just to make it work, we want to fix the problem and keep the users' systems stable
Can you confirm that our latest release has indeed solved the reported bug and remove the toolbar from the blacklist?
Comment 24•13 years ago
|
||
The datamngr dll has not been blocklisted, only MediaBar and Searchqu toolbars.
Anyway, the new datamngr.dll still makes Firefox crash.
Here are 5.0 correlations per module and crash signature over the last day:
* @0x0 | datamngr.dll@0x1b661|EXCEPTION_ACCESS_VIOLATION_EXEC (266 crashes)
100% (266/266) vs. 3% (3427/99477) datamngr.dll
82% (218/266) vs. 3% (3112/99477) 1.0.0.1
18% (48/266) vs. 0% (315/99477) 3.0.0.42011
* @0x0 | datamngr.dll@0x1b661|EXCEPTION_ACCESS_VIOLATION_READ (49 crashes)
100% (49/49) vs. 3% (3427/99477) datamngr.dll
80% (39/49) vs. 3% (3112/99477) 1.0.0.1
20% (10/49) vs. 0% (315/99477) 3.0.0.42011
Comment 25•13 years ago
|
||
I believe we did fix the problem but we did not update the file version which is 1.0.0.1 and as a result you see crash reports from users with this file version.
We will update the file version and check again that it fixes the problem.
In any case, this dll has nothing to do with the blocklisted toolbars.
Blocking these toolbars will not prevent the reported problem
Are the blocklisted toolbars causing any crashes?
If not, can you remove them from the block list?
Comment 26•13 years ago
|
||
(In reply to comment #25)
> I believe we did fix the problem but we did not update the file version
> which is 1.0.0.1 and as a result you see crash reports from users with this
> file version.
18% of datamngr.dll users crashes with version 3.0.0.42011, which is the latest.
> In any case, this dll has nothing to do with the blocklisted toolbars.
> Blocking these toolbars will not prevent the reported problem
You're right. Indeed, since the toolbar blocklisting, correlations with these toolbars dropped down:
* @0x0 | datamngr.dll@0x1b661|EXCEPTION_ACCESS_VIOLATION_EXEC (266 crashes)
29% (76/266) vs. 1% (866/99477) ffox@bandoo.com (5.1)
14% (38/266) vs. 7% (6763/99477) {1E73965B-8B48-48be-9C8D-68B920ABC1C4}
* @0x0 | datamngr.dll@0x1b661|EXCEPTION_ACCESS_VIOLATION_READ (49 crashes)
18% (9/49) vs. 1% (866/99477) ffox@bandoo.com (5.1)
14% (7/49) vs. 6% (6114/99477) ffxtlbr@babylon.com
29% (14/49) vs. 22% (22244/99477) {CAFEEFAC-0016-0000-0026-ABCDEFFEDCBA} (6.0.26)
6% (3/49) vs. 0% (129/99477) {99079a25-328f-4bd4-be04-00955acaa0a7}
6% (3/49) vs. 1% (926/99477) {51a86bb3-6602-4c85-92a5-130ee4864f13}
Can we have a relationship between crashy datamngr dll versions and crashy toolbar versions so that bad toolbar versions are blocklisted?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 27•13 years ago
|
||
The toolbars are not causing crashes
The component which caused a crash is the dll
We are working to figure out if the fix we released solves the problem and to update the dll version number
In any way, I suggest you remove the toolbars blocklisting as this is not preventing crashes
Comment 28•13 years ago
|
||
(In reply to roi from comment #23)
> This is not malware
Searchqu toolbar ({99079a25-328f-4bd4-be04-00955acaa0a7})
http://www.spywareremove.com/removeSearchqu.html
Firefox protects against malware in websites:
http://www.mozilla.com/en-US/firefox/phishing-protection/
Right now, the add-on blocklisting is only used against crashes caused by add-ons, not against malware in add-ons. I think it should.
Comment 29•13 years ago
|
||
I agree that we should remove the blocking for the add-ons and instead block a version range of the DLL. Which versions should we apply this to, roi?
Reporter | ||
Comment 30•13 years ago
|
||
I did some quick math and the combined signatures for the last week across all Firefox versions eclipse 10K. If we are going to pursue the DLL version range we need versions - Roi can you help? In Comment 25 you said you were going to update the file version, but lots of the crash reports I see still have version 1.0.0.1.
Comment 31•13 years ago
|
||
(In reply to Marcia Knous [:marcia] from comment #30)
> In Comment 25 you said you were going to update the file version, but lots of the crash
> reports I see still have version 1.0.0.1.
According to crash correlations, datamngr.dll versions below 3.0.0.46593 must be blocked:
@0x0 | datamngr.dll@0x1b661|EXCEPTION_ACCESS_VIOLATION_EXEC (283 crashes)
100% (283/283) vs. 4% (3842/103991) datamngr.dll
80% (227/283) vs. 3% (3280/103991) 1.0.0.1
18% (50/283) vs. 0% (287/103991) 3.0.0.42011
0% (1/283) vs. 0% (18/103991) 3.0.0.46362
1% (3/283) vs. 0% (133/103991) 3.0.0.46577
1% (2/283) vs. 0% (124/103991) 3.0.0.46593
@0x0 | datamngr.dll@0x1b661|EXCEPTION_ACCESS_VIOLATION_READ (35 crashes)
100% (35/35) vs. 4% (3842/103991) datamngr.dll
77% (27/35) vs. 3% (3280/103991) 1.0.0.1
20% (7/35) vs. 0% (287/103991) 3.0.0.42011
3% (1/35) vs. 0% (18/103991) 3.0.0.46362
0% (0/35) vs. 0% (133/103991) 3.0.0.46577
0% (0/35) vs. 0% (124/103991) 3.0.0.46593
Comment 32•13 years ago
|
||
So whatever we have done is not working. We still get a ton of these crashes and it's significant when we add up all the signatures. The bandoo guy confirmed that the toolbars are not causing crashes so blocking those does nothing. We need to block the dlls, correct?
Can someone make a call on this? I know that blocking dlls is something that don't want to do. It's been sitting around for a long time and causing lots of crashes for our users. Who is the right person to own making this call?
Over 9000 crashes in the past week - combining all signatures across all versions.
Comment 33•13 years ago
|
||
I think Johnath has the call on DLL blocking. Note that DLL blocks are code-based, not server-based.
Assignee: fligtar → johnath
Comment 34•13 years ago
|
||
I can r+ a patch here (which basically anyone can write - c.f. http://mxr.mozilla.org/mozilla-central/source/toolkit/xre/nsWindowsDllBlocklist.h), we just need clarity on:
- Should we blocklist particular version ranges or all versions?
- Are there legitimate DLLs using the same name that we risk killing in the process?
Reporter | ||
Comment 35•13 years ago
|
||
One thing I noticed is (and I am not sure if it makes a difference) is that the debug identifier picked up in crash stats is not the same particular versions, for example
Version 1.0.0.1
Debug Indentifier: 19ADB0ADE5BC4EDBACDC5E5E1E42D39A1 in one report and D47143A82BCD4315B8CDDA354BC410471 in another
I am rolling up the versions that have the highest number of crashes right now.
Reporter | ||
Comment 36•13 years ago
|
||
I looked at a sample let of data from chofmann's latest report: https://crash-analysis.mozilla.com/crash_analysis/20110926/20110926_Firefox_7.0-interesting-modules-with-versions.txt.gz. From that it looks as if what Scoobidiver noted in Comment 31 stands. The only version that appears in this set of data that did appear in Comment 31 was 3.0.0.49236
10% (1/10) vs. 5% (1307/27381) datamngr.dll
0% (0/10) vs. 4% (1076/27381) 1.0.0.1
0% (0/10) vs. 0% (46/27381) 3.0.0.42011
0% (0/10) vs. 0% (3/27381) 3.0.0.46362
0% (0/10) vs. 0% (94/27381) 3.0.0.46577
10% (1/10) vs. 0% (66/27381) 3.0.0.46593
0% (0/10) vs. 0% (22/27381) 3.0.0.49236
@0x0 | datamngr.dll@0x1b661|EXCEPTION_ACCESS_VIOLATION_EXEC (69 crashes)
100% (69/69) vs. 5% (1307/27381) datamngr.dll
83% (57/69) vs. 4% (1076/27381) 1.0.0.1
14% (10/69) vs. 0% (46/27381) 3.0.0.42011
1% (1/69) vs. 0% (3/27381) 3.0.0.46362
0% (0/69) vs. 0% (94/27381) 3.0.0.46577
1% (1/69) vs. 0% (66/27381) 3.0.0.46593
0% (0/69) vs. 0% (22/27381) 3.0.0.49236
I think we still need to get clarity on Jonathan's questions in Comment 34 in regard to the question of blocklisting all versions or particular versions ranges and whether we are sure they aren't dlls using the same ID. I guess in thinking about it more there would be more risk in blocking version ranges in that case.
Reporter | ||
Comment 37•13 years ago
|
||
I asked chofmann his thoughts regarding this and he mentioned maybe just blocking on the name and 1.0.0.1 will catch the right stuff and avoid anything legitimate.
Comment 38•13 years ago
|
||
Did we ever do anything about blocking the DLL? Do these crashes still occur?
Comment 39•13 years ago
|
||
(In reply to Randell Jesup [:jesup] from comment #38)
> Did we ever do anything about blocking the DLL?
An answer to comment 34 is expected.
> Do these crashes still occur?
There are now only 4200 crashes per week while the blocklisting bar is 10.000 crashes per week.
Comment 40•13 years ago
|
||
So we need a patch for jonath to review. I assume the 4200 number includes all the addons using datamngr.
Comment 41•13 years ago
|
||
(In reply to Johnathan Nightingale [:johnath] from comment #34)
> - Are there legitimate DLLs using the same name that we risk killing in the
> process?
I don't believe so - here's what I could come up with.
Imesh datamngr.dll - http://www.fix-dllerrors.com/how-to-fix-datamngr-dll-error.htm
Bandoo Media (SearchQu) datamngr.dll - http://systemexplorer.net/filereviews.php?fid=6744394
"Datamngr.dll is related to Windows Searchqu Toolbar(another name is BearShare Mediabar" - https://encrypted.google.com/url?q=http://www.spywareremovalhelp.org/spyware-removal-help/what-is-datamngr-dll-how-to-fix-datamngr-dll-error.html&sa=U&ei=ypZOT-zlH9PaiQKkn5W0Cw&ved=0CA8QFjAA&sig2=3liQJUqfFuSkO8XdA603iA&usg=AFQjCNEGTIPDfNlo_iIHDOs9_1xTJK8aeQ
"BearShare MediaBar", "SearchQu Toolbar", "iMesh Toolbar". Given how many people are trying to uninstall these across the internet, I'd even be OK with blocking all versions outright.
Remaining tasks:
1) Create a blocklist patch for datamngr.dll
2) Have QA test a try build with the toolbars above to make sure we don't cause new crashes when blocking the DLL
3) Go for it
Comment 42•13 years ago
|
||
I agree: go for it! The web is full of people trying (and failing) to remove these, and virtually none of them appear to know where they got them (surprise).
From the top 100 addon Etherpad (no particular order):
- DataMngr (???) - http://www.google.com/search?q=%7B1FD91A9C-410C-4090-BBCC-55D3450EF433%7D
-----------------------------------------------------------------------------
- Notes: jZip Toolbar - it and the searchqu addons all use DataMngr dll.
Silently installed adware: http://forums.spybot.info/showthread.php?t=62634
? MediaBar - {28387537-e3f9-4ed7-860c-11e69af4a8a0} - http://www.google.com/search?q=%7B28387537-e3f9-4ed7-860c-11e69af4a8a0%7D
-----------------------------------------------------------------------------
- Notes: Closely related if not identical to {99079a25-328f-4bd4-be04-00955acaa0a7} (searchqu.net, see below)
? searchqu.net - {99079a25-328f-4bd4-be04-00955acaa0a7} - http://www.google.com/search?q=%7B99079a25-328f-4bd4-be04-00955acaa0a7%7D
-----------------------------------------------------------------------------
- Notes: This is a virus-like toolbar that resists removal (see Bug 665775)
? {c2d64ff7-0ab8-4263-89c9-ea3b0f8f050c} - http://www.google.com/search?q=%7Bc2d64ff7-0ab8-4263-89c9-ea3b0f8f050c%7D
-----------------------------------------------------------------------------
- Notes: This is BearShare MediaBar, closely related if not identical to {99079a25-328f-4bd4-be04-00955acaa0a7} (searchqu.net, see above)
Comment 43•13 years ago
|
||
Johnathan - would you happen to know who puts together blocklist patches these days? I know Kev put together our last DLL blocklist patch, but I doubt it should be his responsibility to patch and create try builds. Thanks in advance.
Comment 44•13 years ago
|
||
Comment 45•13 years ago
|
||
Updated•13 years ago
|
OS: Windows 2000 → Windows 7
Whiteboard: [extension][softblock] → [extension][softblock][dll]
Comment 46•13 years ago
|
||
The following extension blocklist description should be updated accordingly:
https://addons.mozilla.org/firefox/blocked/i39
https://addons.mozilla.org/firefox/blocked/i40
https://addons.mozilla.org/firefox/blocked/i41
Updated•13 years ago
|
Attachment #602379 -
Flags: review?(benjamin) → review+
Comment 47•13 years ago
|
||
(In reply to Ehsan Akhgari [:ehsan] from comment #45)
> Try build: https://tbpl.mozilla.org/?tree=Try&rev=a1bd00172de6
Thanks Ehsan and bsmedberg. Adding qawanted to do exploratory testing around the software in
https://bugzilla.mozilla.org/show_bug.cgi?id=665775#c41
https://bugzilla.mozilla.org/show_bug.cgi?id=665775#c42
with this try build. We want figure out whether we need to blocklist any associated add-ons and make sure we're not leaving users in a worse position than before the blocklist.
Keywords: qawanted
Comment 48•13 years ago
|
||
Using Fx11b5: When I look at the loaded dlls associated with the firefox.exe process (using Process Explorer) I see a datamngr.dll loaded. The toolbars are also loaded.
Using try-build: The datamngr.dll is still loaded as well as the other toolbars. The only add-on not loaded is the DataMngr 1.0 because it's not compatible with the nightly.
Both builds seem stable with all those toolbars, though.
Comment 49•13 years ago
|
||
(In reply to juan becerra [:juanb] from comment #48)
> Using try-build: The datamngr.dll is still loaded as well as the other
> toolbars. The only add-on not loaded is the DataMngr 1.0 because it's not
> compatible with the nightly.
Ehsan/Benjamin - any ideas why the blocklist didn't seem to have had an effect on whether datamngr.dll was loaded?
Comment 50•13 years ago
|
||
Juan, can you please try to see if that DLL is listed under this registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs
We are not yet capable of blocking DLL loads which are listed in that registry path. If the DLL is not listed there, I don't know why the blocklisting has not worked. Can you please verify that the DLL file on the disk has the exact same name?
Comment 51•13 years ago
|
||
(In reply to Ehsan Akhgari [:ehsan] from comment #50)
Only the datamgr.dll was listed in the registry (on WinXP) associated with the BearShare directory. On Win7 there were no entries in the registry.
Comment 52•13 years ago
|
||
(In reply to juan becerra [:juanb] from comment #51)
> (In reply to Ehsan Akhgari [:ehsan] from comment #50)
>
> Only the datamgr.dll was listed in the registry (on WinXP) associated with
> the BearShare directory.
If the DLL is listed in that registry key, we will not be able to blocklist it.
> On Win7 there were no entries in the registry.
Does Firefox still load that DLL in Windows 7 with the try build in this bug?
Comment 53•13 years ago
|
||
On Win7 the dll is not in the registry, and the dll is not loaded in neither Fx11b5 nor the try build.
Comment #48 was using XP, where the dll is in the registry and it is loaded in both Fx11b5 and the try build.
Comment 54•13 years ago
|
||
(In reply to juan becerra [:juanb] from comment #53)
> On Win7 the dll is not in the registry, and the dll is not loaded in neither
> Fx11b5 nor the try build.
>
> Comment #48 was using XP, where the dll is in the registry and it is loaded
> in both Fx11b5 and the try build.
OK, in that case, this is not a problem which we can solve by blocklisting.
Comment 55•12 years ago
|
||
(In reply to Ehsan Akhgari [:ehsan] from comment #54)
> (In reply to juan becerra [:juanb] from comment #53)
> > On Win7 the dll is not in the registry, and the dll is not loaded in neither
> > Fx11b5 nor the try build.
> >
> > Comment #48 was using XP, where the dll is in the registry and it is loaded
> > in both Fx11b5 and the try build.
>
> OK, in that case, this is not a problem which we can solve by blocklisting.
Should we just drop this bug and pursue another approach? Is there a way to patch Firefox to prevent this DLL from loading?
Comment 57•12 years ago
|
||
We're looking into this again on bug 812456, but things aren't looking very promising. I don't think there's more we can on this bug.
Status: ASSIGNED → RESOLVED
Closed: 13 years ago → 12 years ago
Resolution: --- → WONTFIX
Assignee | ||
Updated•9 years ago
|
Product: addons.mozilla.org → Toolkit
You need to log in
before you can comment on or make changes to this bug.
Description
•