Further information. Starting Firefox with a new profile and it seemed to fix the problem. Needed to kill the process using task manager before starting the profile manager. Was able to start and use Firefox, close it restart it, all good with the new profile. However after a reboot it wont start. At least before the new profile it would start once. Now it just does the partial load.

Repeat with yet another new profile (after killing process in Task manager) and it will start and run but only the once.

I wonder if its not closing properly. In the new profile folder is there a file called lock or .lock file? This used to be caused by a corruption.

Or are there any crash reports in the crashes folder? Move them to the submitted folder and try to start Firefox.

• Profiles - Where Firefox stores your bookmarks, passwords and other user data

There are no lock files or crashes. It appears that at some point in the development chain, Firefox was loaded as a background process with a "stub" as the foreground process. Much more efficient this way as it could then be treated like a service and opening multiple copies of Firefox (or perhaps tabs?) just hook into the background process. Much faster this way as Windows does the processing in the background and takes care of the overheads, all in the background.

The virus scanner seems to be the culprit and is obviously blocking one of the processes. Trouble is the virus scan logs do not show any blocking.

HOWEVER, the firewall log shows a multicast with protocol 2 (?) to 224.0.0.1 & 224.0.0.22. I reckon Firefox is trying to pass information somewhere via multicast and I bet this is being blocked by the firewall (probably rightly so). Trouble is Firefox has no method for timing this function.

So it appears Firefox is trying to set up some sort of "auto monitoring" probably to keep track of health issues but it seems to be a REALLY REALLY bad idea. I can just imagine the new wave of malaware using this sort of thing as a hook, and reeks of the way Microsoft operate.

Further testing. OK the multicast may not be what it seems. Perhaps its just a faster way of being able to setup & load a packet from wherever available. I would think this is part of a "torrent like" upgrade?

I uninstalled and installed the previous version. Worked fine. This version does not load as a background process.

I guess I need to be able to load the version 42 without the multicast setup to be sure that is the only problem.

One thing I note is that my firewall has Firefox as being allowed to make & receive connections, so I wonder if it is the maintenance service that is the problem.

I think it may be a program/concept problem which my virus scanner is specifically designed not to like.

I am reasonably happy with my existing virus scanner (& no its not a freeby) and am not about to abandon it just to fix a Firefox problem until I am sure what the problem is

EDIT: NOT SOLVED. As soon as I set my homepage to about:newtab it reverted back to the old problem.

Solved. Microsoft did an update to Windows 10 and now Firefox loads as a background service.

Interestingly after the update, Chrome loads the same way as Firefox.

What is really annoying is that I have no control of Windows update under Windows 10. I cannot easily find out the specifics of what is changed. I am starting to feel like an Apple user (just get on with it, pay us lots of money for what is basically a free operating system and let us do the understanding. Macs don't crash they just freeze up....).

It is possible that Firefox tries to check the server for an update of web pages that are present in a tile on the about:newtab page. If tiles are empty then Firefox can load sponsored links.

• https://support.mozilla.org/kb/how-do-tiles-work-firefox
• https://support.mozilla.org/kb/Firefox+makes+unrequested+connections

You can try to set browser.newtab.preload to false on the about:config page. You can open the about:config page via the location/address bar. You can accept the warning and click "I'll be careful" to continue.

• http://kb.mozillazine.org/about:config

Thanks cor-el said

It is possible that Firefox tries to check the server for an update of web pages that are present in a tile on the about:newtab page. If tiles are empty then Firefox can load sponsored links.

• https://support.mozilla.org/kb/how-do-tiles-work-firefox
• https://support.mozilla.org/kb/Firefox+makes+unrequested+connections

You can try to set browser.newtab.preload to false on the about:config page. You can open the about:config page via the location/address bar. You can accept the warning and click "I'll be careful" to continue.

• http://kb.mozillazine.org/about:config

Thanks for the suggestion. I should have updated a little earlier. After update 42, during the load, Firefox does a "sanity-test" for a video card. This is I assume for the programmers, nothing else. However they do it they seem to send results to a website, though I can't tell for sure. My virus scanner prevents some action within the test and Firefox fails to continue to load.

This is actually achieved by writing to the prefs.js file which contains any changes made by the user to the config.

I cannot find where this is loaded from. It is nor a user.Js file but it is part of the config and can be reset using about:config. Putting the necessary preferences in a user.js file (or better a test.js file) would seem to me to be a much more elegant approach.

On startup however the config (as seen by about config) is modified EVERY time to include this test, so it is then written to the prefs.js and the next time Firefox tries to load it fails.

What ever the failure actually is it is caused by my virus scanner not allowing this test to complete. It will work fine without the virus scanner, but that is not really an option

This "sanity test" I assume is meant to be only done once, but because it cant complete it is repeated at each load. Even by allowing it to complete by stopping the virus scanner, the test still is initiated at EVERY load.

There are no logs within the virus scanner to say what is actually happening.

The programming of the test in this way seems to me to be a pretty sloppy bit of programming. If it fails (for whatever reason) it should either send an error message or log the fault somewhere.

If it is a fault with the virus scanner software, I want to know what the specifics are before I condemn it, this test seems unnecessary and not coded very well.

I have submitted a bug report, the reason being if it is the virus scanner at fault (which I suspect it is not) the inclusion of this type of test without either a timeout or error warning is not desirable. Also, it seems the way to enable or disable this test should be straight forward, (using about config) but it is not. The test can be disabled by about:config but at the next startup it is automatically re enabled which is about as useful as a pocket in a jock strap. Effectively, control is fully removed from the normal config arrangement. This sort of scenario seems to me to be a might big hole in the configuration just waiting for a hacker to take advantage of.

I need to go back to Firefox version 41 and see if this test is in it. I suspect it is not, or it is initiated in a different way.

See also:

• https://wiki.mozilla.org/Blocklisting/Graphics
• https://support.mozilla.org/kb/add-ons-cause-issues-are-on-blocklist

Well the sanity- test is in version 41.02 and it succeeds. Some other change in version 42 causes this test to fail when it interacts with the virus scanner.

cor-el said

See also:

• https://wiki.mozilla.org/Blocklisting/Graphics
• https://support.mozilla.org/kb/add-ons-cause-issues-are-on-blocklist

Thanks for the link Had a look here but pretty sure it is not relevant. The fact that it works on version 41 and this failure in some way relates to the virus scanner (which is exactly the same for both 41 & 42) suggests its a change within 42. The graphics card & driver is not mentioned in the link as being block listed. The driver version is well above the 257.21 required (mine is 381+) Since block listing came into force a fair time ago, I would think a GPU hardware or software fault would have shown up well before now.

I don't now have any add ons and any I did have I disabled to test and finally removed them. No improvement

Worked out a temporary solution. Just avoids the issue rather than solves it. Made a copy prefs.js Renamed the copy to user.js Edited user.js to remover everything except the "Sanity-test" preferences. Set all the sanity test preferences to nul ("").

user_pref("sanity-test.device-id", ""); user_pref("sanity-test.driver-version", ""); user_pref("sanity-test.running", ""); user_pref("sanity-test.version", "");

user.js is not modified by Firefox, unlike the prefs.js, but Firefox loads and processes after the prefs.js. So... the prefs.js sets these preferences to run the sanity test but the user.js overwrites them. Not sure what setting these preferences to null has any other effect, I assume that the process "sanity-test" checks for valid preferences and aborts if they are not valid.

I will not mark this as solved, because of the nature of the fix, I assume I will eventually find a real solution which would be preferable.

See also:

• http://mxr.mozilla.org/mozilla-release/source/toolkit/components/gfx/SanityTest.js

Gave up in trying to actually find what is actually happening. Have eventually changed the virus scanner software. My guess (and its only a guess) is that the change to integrate with windows update at update 42 changes the method of output to the telemetry file that the virus scanner does not allow. It maybe the virus scanner cannot handle that file or the ownership but it does not log the fact, a failing of the virus scanner. There is an inkling of doubt in my mind when an upgrade causes a working system to fail in a non traceable method.