Best regards.
Best answer by Rakanisheu Retired
View originalWebroot vs Firefox/Tor network
When trying to start the Tor network I get an error message from Firefox, "Couldn't load XPCOM". This happens only when Webroot is installed on my pc. I told the Tor guys about this, and they immediately asked me if I have Webroot on my pc which I confirmed. They told med yo contact you. Have you heard of this problem, and what can I do to deal with it?
Best regards.
Best regards.
Userlevel 7
We have had two tickets into our support system about this. I run TOR on my home PC along with 3 Test PC's without any issue from WSA. I am yet to figure out why certain people are getting this XPCom error.
Check the following setting and allow any TOR files;
1) Click on the little cog icon beside "Identity Protection" option
2) Click on "Application Protection" option
3) In that list look for the following file and set it to allow.
Check the following setting and allow any TOR files;
1) Click on the little cog icon beside "Identity Protection" option
2) Click on "Application Protection" option
3) In that list look for the following file and set it to allow.
That worked! :-) Thank you very much!
I've struggled with this issue, along with similar ones concerning both Mozilla Firefox as well as Google Chrome, and "derivative" browsers that utilize them (TOR for former, SRWare's Iron for latter). The standard approach I've typically used is to whitelist .dll's (sometimes in masse), and that previously sufficed.
It can be a bit of a pain in my case, as the box in question (a W7 Home Premium, HP OEM, Compaq CQ500Y) has 3 separate user accounts (Built-in Administrator, Creator/Administrator, and a daily-use standard acct.), each of which has its own individual instances of these browsers - portable (deployed from a .zip or .paf file) rather than installed (deployed from an .exe file's Install Wizard). Given that each also has @ least one backup copy on another drive, and given that I am unable to exclude complete drives (AFAIK), and given that WSA has a peculiar tendency to display one or another of these instances in the Application Protection whitelist, I've become used to seeing the whitelisted file registered as one of the backup locations rather than the actual run location I've manually or via-popup allowed. I've even got some referring to the Creator/Admin acct., which is reserved as an "emergency" acct., and so far logged into only a few times since the day W7 was installed in 2k10 - and never used to deploy any of the whitelisted files. I have no ready explanatin for why WSA displays these "alternate" locations in some instance and not in others, but since it has not noticeably decreased performance, I've done little investigation or troubleshooting (beyond submitting a long-ago support ticket that still languishes somewhere, unanswered). Considering what a fine AV suite WSA is, I simply consider the peculiarities of operation for this particular 'puter a small price to pay for Webroot's wonderful functionality, efficiency, and small footprint.
I mention all of the above in the long-winded 2nd ¶ because I suspect it might offer a clue to someone smarter than I, and because it was in consideration of the somewhat-convoluted nature of the various browser instances that I found a method to resolve a new "Could Not Load XPCOM.dll" error encountered after deploying the TOR browser's newest iteration, 4.0.2.
Nothing I tried in terms of removing and re-adding the various .dll's associated with TOR (mainly located in the C:users.. or browserrowser and C:users.. or browserTor for those with std installations, and under the same two folders with a different path for portable versions such as I use) worked to elude the error. My final, successful approach involved removing all the .dll's from the whitelist, then adding both C:users.. or browserrowserfirefox.exe and C:users.. or browserTor or.exe. Voila!
>To recap: adding tor.exe in "x":[Your computer's Path]Tor BrowserTor and firefox.exe in "x":[Your computer's Path]Tor BrowserBrowser to WSA's Application Protection whitelist got TOR 4.0.2 working for me.
It can be a bit of a pain in my case, as the box in question (a W7 Home Premium, HP OEM, Compaq CQ500Y) has 3 separate user accounts (Built-in Administrator, Creator/Administrator, and a daily-use standard acct.), each of which has its own individual instances of these browsers - portable (deployed from a .zip or .paf file) rather than installed (deployed from an .exe file's Install Wizard). Given that each also has @ least one backup copy on another drive, and given that I am unable to exclude complete drives (AFAIK), and given that WSA has a peculiar tendency to display one or another of these instances in the Application Protection whitelist, I've become used to seeing the whitelisted file registered as one of the backup locations rather than the actual run location I've manually or via-popup allowed. I've even got some referring to the Creator/Admin acct., which is reserved as an "emergency" acct., and so far logged into only a few times since the day W7 was installed in 2k10 - and never used to deploy any of the whitelisted files. I have no ready explanatin for why WSA displays these "alternate" locations in some instance and not in others, but since it has not noticeably decreased performance, I've done little investigation or troubleshooting (beyond submitting a long-ago support ticket that still languishes somewhere, unanswered). Considering what a fine AV suite WSA is, I simply consider the peculiarities of operation for this particular 'puter a small price to pay for Webroot's wonderful functionality, efficiency, and small footprint.
I mention all of the above in the long-winded 2nd ¶ because I suspect it might offer a clue to someone smarter than I, and because it was in consideration of the somewhat-convoluted nature of the various browser instances that I found a method to resolve a new "Could Not Load XPCOM.dll" error encountered after deploying the TOR browser's newest iteration, 4.0.2.
Nothing I tried in terms of removing and re-adding the various .dll's associated with TOR (mainly located in the C:users.. or browserrowser and C:users.. or browserTor for those with std installations, and under the same two folders with a different path for portable versions such as I use) worked to elude the error. My final, successful approach involved removing all the .dll's from the whitelist, then adding both C:users.. or browserrowserfirefox.exe and C:users.. or browserTor or.exe. Voila!
>To recap: adding tor.exe in "x":[Your computer's Path]Tor BrowserTor and firefox.exe in "x":[Your computer's Path]Tor BrowserBrowser to WSA's Application Protection whitelist got TOR 4.0.2 working for me.
Reply
Login to the community
No account yet? Create an account
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.