Firefox 36.0 hanging and refusing to be killed in Win XP

[ravisunny2]

Hi,

I wasn’t sure whether to post this problem on Internet & Web or Apps & Software.

Anyway, the problem is that Firefox 35.0 occasionally hangs and refuses to be terminated.

I have tried the taskmanager and the Sysinternals Process Explorer v15.21.

Neither was able to kill Firefox.

The only option I had was to reboot.

Can someone help please?

Thanks,

Ravi

 

[ComputerGuy55]

If it's in fected with some type of virus that won't let the application go that could be a problem. I could suggest doing scans right away, but if you can disable any and all add-ons for the browser (or start it in safe mode) I suggest doing that as a test.

 

[DelJo63]

Update to 36.04 and to be 'brutal' about it, download the new installer, uninstall FF, reboot and install the new copy.

 

[ravisunny2]

Thanks guys.

Pretty sure there is no virus. I am using a paid antivirus.

Chrome functions smoothly. All other apps run perfectly.

Jobeard, I have 36.04 but that is an update. Will try a clean install.

 

[DelJo63]

Background Info: There's a long standing issue for processes stalling (ie not responsive).
FEW systems support fully asynchronous I/O as a default. Most I/O is preformed in BLOCKING mode, meaning the process gets no service until the I/O completes. When I/O is initiated, there are several layers of software to get into the kernel code where it actually gets initiated. As long as the process is not in the kernel, the process is easily killed. Once in the kernel however, the process stalls until the I/O completes.

For I/O to locally attached devices (hd, usb, video, kb, mouse, ...) this is seldom an issue unless you have a faulty device or have disconnected the device while it was active (a device that is offline/not ready will never get into the kernel).

For networked devices (eg mapped drives) you are at the mercy of the system which has that resource as a local device. If that system/user takes the resource offline, then you are exposed.

Network sockets work much like network devices, but have always had a timeout associated.

But you say "Hey, it's a browser and it is threaded" - - true enough and although the tread may be stalled in the kernel, the process SHOULD (in theory) never stall as all threads are controlled by the program that created them, and by now, *most* programers who can write threaded code, know enough to not access resources in the parent.

If the process window can not be minimized/maximized, then the process is not getting any CPU - - and the quest begins :sigh: