FF8.0 NoScript 2.1.9 -> Can't restart Firefox

[Hoib3rgA]

Hello,
i use this AddOn for long time, but since a few weeks i've got the problem, that i can't restart my ff, after i closed it anytime before.
In the taskmanager is still the ff running, i've to kill the instance there, just after this i can start firefox again.

When i disable this noscript, i can restart firefox, if noscript is running it isn't possible to do this.


kr Chris

[Guest]

me again, forgot to tell something:
If i disable all the other AddOns, the problem is still there! When i got only NoScript running, i also can't restart firefox.

My pc is running WinXP Pro.

kr Chris

[dhouwn]

Maybe some Firefox bug triggered by NoScript.
Not that I am entirely sure if this might reveal the problem but could you please install Process Explorer and have a look with it (running with admin rights) at the Firefox process when it refuses to shutdown, e.g. at the performance graph and maybe what threads are running and the stacks of the threads running code from firefox.exe and xul.dll.

[therube]

Kind of doesn't make sense? NoScript being only JavaScript.

Other then extensions, what plugins do you have?
If you disable those ...?

As a test, If you were to create a new Profile, install NoScript, does the problem persist?

Browser will not start up

Profile in use

[Hoib3rgA]

Hello,
@ therube:
in my second post i wrote, that it doesn't make a difference which other addon runs in ff. To find out which AddOn causes this problem, i deinstalled all addons and plugins and installed evryone in single time. When i install NoScript - NO OTHER addon installed in the same time, just NoScript - i can't restart ff.
And yes, this problem exist also with a new profile

@ dhouwn:
I installed this tool and made some screenshots.
At this shot, ff is running:
http://img37.imageshack.us/img37/3198/ffrunning.jpg

At this time, i've closed my ff:
http://img403.imageshack.us/img403/314/ffoff.jpg

and this is a screenshot when i try to restart ff:
http://img39.imageshack.us/img39/1356/ffrestart.jpg

[Tom T.]

According to this anti-virus forum, that Spigot toolbar is malware -- one user called it a "backdoor Trojan". This means that a remote hacker has established a secret path into your machine, and could easily keep the browser running if it suited his evil purpose.

Many hackers are aware of NoScript; a popular topic at black-hat (evil) hacker sites is, "How do I get my malware past NoScript?" Which is proof of its effectiveness -- they fear it.

Your anti-virus provider should be able to help you remove it, or the Web will provide other tools. Look for MalwareBytes Anti-Malware, for example.
Or take it to a trusted shop for professional removal, and detection of other possible malware.

For safety's sake, they may recommend that you wipe the hard drive completely and reinstall your operating system.
Some malware can reside even lower in the hierarchy than the operating system.
In any event, expert advice is needed to clean this machine.

NoScript is not causing your problem.

[Tom T.]

Not that I am entirely sure if this might reveal the problem but could you please install Process Explorer and have a look with it (running with admin rights) at the Firefox process when it refuses to shutdown

And thanks to dhouwn for that insightful suggestion. Even if the problem wasn't within firefox.exe or xul.dll itself, it revealed the probable source.

Which is another good reason to ask users to list not only Firefox extensions, but any toolbars or products from other sources that are visible. ... come to think of it, just a screenshot or printed list of processes in Windows Task Manger would probably have revealed this malicious process running. But PE indeed will reveal a lot more than TM overall.

[GµårÐïåñ]

Just to add for sake of completeness. Fx since late 3.x branch has been having this problem for a while now that it won't close and it is not "ALWAYS" an addon or malware that causes it, just that Fx doesn't always exit clean or release memory in some cases causing it to linger or keep the process thread alive.

[Tom T.]

Just to add for sake of completeness. Fx since late 3.x branch has been having this problem for a while now that it won't close and it is not "ALWAYS" an addon or malware that causes it, just that Fx doesn't always exit clean or release memory in some cases causing it to linger or keep the process thread alive.

You are right as usual, my friend, and thank you. However, OP seemed to be able to correlate the issue directly to whether NS was running. Malware fighting with NS seems plausible; without NS, it shuts down, and the backdoor opens on next browser start.

FWIW, the advice from MZ used to be that the most certain way to close Fx was by File > Exit, rather than merely the X box in the upper right. Never tested it, as it's never been a problem. Wonder if it would make a difference for OP? -- but the malware needs to go, anyway. Cheers.

[dhouwn]

FWIW, the advice from MZ used to be that the most certain way to close Fx was by File > Exit, rather than merely the X box in the upper right. Never tested it, as it's never been a problem. Wonder if it would make a difference for OP? -- but the malware needs to go, anyway. Cheers.

Former always closes the whole application while latter just closes a window and the whole application also shuts down when the last main window (e.g. not the downloads window) is closed.

[GµårÐïåñ]

Oh yeah, absolutely the addons and malware can screw with it, I wasn't arguing that. That's why I said for sake of completeness, sometimes its just the app itself. That's why I put "ALWAYS" in the quotations trying to imply that it CAN be something else, like the core itself. In this case it was malware-ish and it has been my experience that it flows in this order: addons (majority of cases), core (second largest cases) and malware (actually quite a small group of cases). In this case the OP got hit by the last one, which sucks but toolbars although in my eyes are all malware (not really but just my feeling of disliking them) even when not malicious have some lazy hooks that don't release properly because usually they are there to "integrate" with something in your system and/or a website that requires them to "stay alive" causing problems when you don't want them anymore to stay alive. It just means the developers didn't account for a clean exit of the core and releasing memory, which is in itself a sign of a bad product.

[Tom T.]

FWIW, the advice from MZ used to be that the most certain way to close Fx was by File > Exit, rather than merely the X box in the upper right. Never tested it, as it's never been a problem. Wonder if it would make a difference for OP? -- but the malware needs to go, anyway. Cheers.

Former always closes the whole application while latter just closes a window and the whole application also shuts down when the last main window (e.g. not the downloads window) is closed.

True, but If we're using all tabs instead of separate windows, hitting the X gives a prompt, "You are trying to close 4 tabs. R U sure?" - if "yes', the entire app shuts down. (I wouldn't close until any d/l's are complete anyway.) Was just reciting the MZ advice, that's all. No worries!

@ GµårÐïåñ: Agree 100%, esp. regarding toolbars.

[GµårÐïåñ]

I don't want to go off topic but just a quick clarification from a programmer's perspective on why the X is not always the same behavior as the File/Exit is the following. Usually the File/Exit corresponds to some block of code or a clean exit module that its triggered. However, the X is actually an OS/Platform level item which actually launches in a different process and unless the developer accounted for that by having it point to the same code as the File/Exit, you will get different results.

Now, let me use a bit of pseudo code without a particular language in mind to try and visualize it.

File/Exit menu has a Click event, which will contain some code like:
1. unload this form, that form,
2. save the settings here and reset this or that,
3. make sure we have wrapped everything up,
4. unload the form/end and program is closed.

Now the X on the top right, which is a system hook usually, triggers a different event such as Query_Unload and is often not coded, so if you clicked on it, you could get something like:
1. application says, I am being queried to close (almost like a process kill)
2. i have nothing to do, so lets end and program is "closed"
BUT: if there are database links, active TCP connections, or anything that is not done yet, it has a process its holding and it won't let go in this manner, hence why sometimes you have to use "Kill process TREE" to end something completely than just "Kill process".

Now a simple fix would be for a developer, something I do all the time, and that is to include a call back to the formal close procedure and it fixes the issue. So next time X is clicked, the goes to the query and then is says: aha, Call form_unload or Call file_menu_click or whatever event that normally handles the clean exit, it could even be a self contained module and it will do the same thing.

To avoid having to find out if the developers were good or lazy, you best just close using File/Exit to make sure whatever they intended to be done, got done. that's all, hopefully the inner workings of the WHY helps people understand it better, or not. Take it for what's it worth.

[Tom T.]

GµårÐïåñ, my friend, please never apologize for sharing with us your very deep, low-level knowledge of these things. You have explained the difference very clearly.

As said, I have never had a problem with the X method, bu now I understand *why* MZ gave the File > Exit as "Best Practice".
Yes, it is always better to know the "why*, so that one can understand the "what".

[GµårÐïåñ]

Thank you my friend and you are too kind to me and I appreciate the praise. I am but a humble means to an end but I do what I can when I can to make things easier for others. Sometimes successful, sometimes not You know what I mean.