How to diagnose immediate crash of x64 version with conventional suggestions not working?
I have one Windows computer that cannot start the x64 version of Firefox. Any x86 version works, this goes for pre and post version 57 Firefox installs. This goes for release, beta, and developer versions. The profile is not the cause and safe mode does not seem to work either. When I use a x64 executable, even the profile manager will not work. There is a crash in the Windows event log.
How should one debug such a situation? Neither safe mode, nor profile changes or new installs work, but the x86 versions all work anyway. I tried looking at the .dmp files, but I could not infer the problem, Visual Studio says something along the lines that invalid virtual memory was addressed in a thread. I also ran scans on the machine and believe that everything is in order and have no problems with any other applications.
Isisombululo esikhethiwe
I solved the problem and will try to explain the issue, but I still think that here probably should be a better way to handle this.
First I look at more information from the dump.
Exception code: 0xC0000005 Indicates a memory access violation.
By using the Visual Studio Debugger, I also found this information:
Access violation writing location 0x0000000000000000.
To me, this looked like a null pointer access from the Firefox process. From this point on, I thought and still do that it is an error in that occurs in the Firefox process, because it is not caused by another module. But I knew that it does not occurs in safe mode, so Firefox is still only arriving in this state because something external is guiding it to this state.
I had ruled out the webcam, I also looked at all sorts of other old drivers and pruned unused drivers with Uwe Sieber's "Device Cleanup Tool". This did not help, since I had no clue what was causing the problem. I looked at the used DLLs in the dump and I found one named guard64.dll that I could trace back to the Comodo Firewall I had installed a few years ago. Obviously, since I had uninstalled it, Firefox should have no business loading it. I could not get rid of it with regsvr32, so I just installed the newest version of Comodo and then uninstalled it and monitored the file, and it disappeared. After that, I could launch the profile manager.
I think it is strange that no other programs have had problems. Also, if the webcam driver was an issue, why do other programs such as Skype that use the webcam not crash? To me it seems that Firefox might have an issue here that should be looked into.
If I had not found this problem, I would have asked if there was a debug build of Firefox that one could use to get more information. There has to be some way to trace back the problem to a specific module that is causing a crash like the ones with the webcam or in my case. If the crash would point out the guard64.dll specifically, it would have been easy to fix. It is not tenable to try out all drivers and shared libraries to find the one that is causing problems with Firefox.
The null pointer information from the dump still suggests to me that Firefox is doing something bad when trying to load all modules together. Let's assume that Firefox does have some kind of bug that only occurs for a very low number of users in a special constellation of software and hardware. There has to be some way to diagnose the problem in these case where Firefox cannot start at all and resort to the built-in error reporting or safe-mode etc. I imagine that debugging it by building it from source with mixed C++ and Rust code is not really for the average user. Is there some kind of documentation how Firefox searches and loads DLLs?
Funda le mpendulo ngokuhambisana nalesi sihloko 👍 0All Replies (16)
Many have reported issues using the 64bit Firefox. Install the 32bit version from; Download Firefox For All languages And Systems {web link}
I have installed 32-bit versions and they run fine. But I want to switch to the 64-bit version. The 64-bit version has become the new default, so I think that it should be considered stable. But I cannot figure out what the problem is, since even fresh install with fresh profiles do not work.
It must be some kind of very low level crash, because even the profile manager cannot launch when supplying the -P switch with a x64 version.
Hi, you need to follow the clues that are given you : invalid virtual memory was addressed There is a crash in the Windows event log. Figure out the above problems 1st before trying to get to Firefox.
You could have bad Ram, forget Windows go for original stuff. 3 passes should be enough. take out all sticks except 1 , Hope know which is 1 then you skip a slot with 2, fill the slot with 3, full 4 https://www.memtest86.com/
Figure what the Windows Crash reports are about as this is sowing it is not a Firefox issue but your system OS Problems and maybe hardware.
If you have h/drive room :
Follow this to get rid of Ram eating junk :
- Use the Windows key + X keyboard shortcut to open the Power User menu and select Command Prompt (Admin).
- Copy/Paste the following command and press Enter:
- DISM /Online /Cleanup-Image /RestoreHealth
Reboot after. This goes up online for files, fixes registry and system files. Is like the SFC / Scannow command except gets new files.
Work on the issue that is causing Windows to Crash out so that Firefox will not work. If need help : https://www.tenforums.com/ https://www.bleepingcomputer.com/forums/f/229/windows-10-support/
I don't think it is a memory problem, I already tested the memory with memtest86+ and the scanned the computer for problems. I think the Windows install is OK, it was also upgraded to 1803 this year and I noticed this problem last year when Firefox 57 came out. Since then I have been unable to solve.
All other programs work and the x86 works. So there must be something special, I think it may be related to the DLLs loaded, but I don't know how one is supposed to proceed with debugging since all solutions like safe mode and reinstall and profile switching assume that Firefox loading works. It's also strange that the x86 works, I mostly use x64 binaries for everything and one would expect more problems with x86 with older stuff conflicting with it instead of the x64 version.
How do developers debug such a problem, for example if they really have a problem on there side or encounter something new and unknown that conflicts with something?
I would like to add that invalid virtual memory addressing is not indicating a memory problem, it rather means that there was an error in the program execution so that it was terminated. It has nothing to do with hardware.
Well, since it seems that it is Windows crashing Firefox as I mentioned please start with Windows.
Windows is not crashing. It's stable and I did not have any system crashes or other program crashes for longer than I remember. It's just the x64 version of Firefox that just does not start.
If I create a program that intentionally accesses memory it should not access, it would show the same symptoms. Or if I take away DLLs of a program and add wrong versions. So some library my cause a problem, but I would need to figure out what. I thought it might be an old plugin for Firefox, but I think those only were x86, and it should work with safe mode at least, right?
I did not start with this problem, I have monitored this problem since last October. I came forward now after I hoped that a newer Firefox version might start to work, but it did not. I tried finding problems with the Windows installation in regard to Firefox, but I am out of ideas and need some suggestions how to search in a specific direction. If there is a problem with my installation, I need some kind of more directed approach to see what parts with the Firefox launch crash. I have no other problems with any other programs.
This question is very similar to my problem and it seems there was no solution other than using the x86 version: https://support.mozilla.org/de/questions/1188055
Perhaps you're encountering this issue from about a year ago:
Device Driver Issues for 64-bit Windows Users with 64-bit Firefox
Before Firefox 56.0.1, users of 64-bit Windows generally were using the traditional 32-bit version of Firefox. However, newer versions may switch you to the 64-bit version.
We received a number of puzzling reports of Firefox either not starting or not loading any pages after this migration.
One user discovered that Windows was silently killing Firefox at startup and recording it in the Windows event logs (you can view event logs using the Event Viewer for application errors example). Based on one of the reports in the log, we were able to trace that to an out-of-date Logitech camera driver, of all things.
By Feb. 2018, at least seven other users reported that uninstalling or updating the Logitech camera software resolved their problem as well.
- https://support.mozilla.org/questions/1179822#answer-1019375
- https://support.mozilla.org/questions/1181740#answer-1021470
- https://support.mozilla.org/questions/1181405#answer-1022798
- https://support.mozilla.org/questions/1182572#answer-1023413
- https://support.mozilla.org/questions/1182847#answer-1024290
- With 57: https://support.mozilla.org/questions/1188971
- https://support.mozilla.org/questions/1191368#answer-1041814
Do you want some assistance in looking at event logs, or do you have such a webcam?
I think this is going in the right direction. I have the same Logitech webcam that was mentioned in the other posts.
I uninstalled two Logitech webcam related items from the control panel. I also uninstalled an old Logitech Setpoint version. Then I uninstalled the driver and selected delete driver in the uninstall. Then I unplugged the device and restarted. However, the problem still persists.
But if I boot to safe mode, I can see the profile manager window would appear if I supply the -P switch, so I think Firefox x64 would work if all drivers are disabled in safe mode. So I think a driver is the issue, but it seems that the webcam was not my main or only issue.
In other posts, the event log sometimes indicated a DLL related to the Logitech driver as faulty module (e.g. LVPrcInj01.dll in https://support.mozilla.org/en-US/questions/1179822#answer-1018725), but for it shows only "unknown" as name of the faulty module in the event log. In the same post, this was also shown in P4 of the problem signature, but for me P4 shows StackHash_11bc.
So I think that some other driver or similar is causing problems for Firefox when it tries to load, but I do not know how to pinpoint it. Other applications work fine, I used my webcam regularly without having any issues. Also the x64 version of Chrome works without problems, and it is probably using a similar features regarding hardware.
I also tried a portable version of Firefox 64-bit, it's also the same. Is there any other way to dump more meaningful information to analyze what is causing the problems while loading and to isolate it?
Hi willj, I think you've made progress. I have a limited understanding of how to read Windows event logs, but I can often find a few clues by combining different indicates in a web search. Unfortunately, "StackHash_11bc" gives me zero results on Google, so we'll need to find something additional clues or direct you to a Windows-oriented forum.
Are there any other events related to Windows shutting down Firefox at startup?
StackHash crashes seem to be connected to DEP (Data Execution Prevention).
See e.g.:
Isisombululo Esikhethiwe
I solved the problem and will try to explain the issue, but I still think that here probably should be a better way to handle this.
First I look at more information from the dump.
Exception code: 0xC0000005 Indicates a memory access violation.
By using the Visual Studio Debugger, I also found this information:
Access violation writing location 0x0000000000000000.
To me, this looked like a null pointer access from the Firefox process. From this point on, I thought and still do that it is an error in that occurs in the Firefox process, because it is not caused by another module. But I knew that it does not occurs in safe mode, so Firefox is still only arriving in this state because something external is guiding it to this state.
I had ruled out the webcam, I also looked at all sorts of other old drivers and pruned unused drivers with Uwe Sieber's "Device Cleanup Tool". This did not help, since I had no clue what was causing the problem. I looked at the used DLLs in the dump and I found one named guard64.dll that I could trace back to the Comodo Firewall I had installed a few years ago. Obviously, since I had uninstalled it, Firefox should have no business loading it. I could not get rid of it with regsvr32, so I just installed the newest version of Comodo and then uninstalled it and monitored the file, and it disappeared. After that, I could launch the profile manager.
I think it is strange that no other programs have had problems. Also, if the webcam driver was an issue, why do other programs such as Skype that use the webcam not crash? To me it seems that Firefox might have an issue here that should be looked into.
If I had not found this problem, I would have asked if there was a debug build of Firefox that one could use to get more information. There has to be some way to trace back the problem to a specific module that is causing a crash like the ones with the webcam or in my case. If the crash would point out the guard64.dll specifically, it would have been easy to fix. It is not tenable to try out all drivers and shared libraries to find the one that is causing problems with Firefox.
The null pointer information from the dump still suggests to me that Firefox is doing something bad when trying to load all modules together. Let's assume that Firefox does have some kind of bug that only occurs for a very low number of users in a special constellation of software and hardware. There has to be some way to diagnose the problem in these case where Firefox cannot start at all and resort to the built-in error reporting or safe-mode etc. I imagine that debugging it by building it from source with mixed C++ and Rust code is not really for the average user. Is there some kind of documentation how Firefox searches and loads DLLs?
BTW, this seems to be the problem: https://bugzilla.mozilla.org/show_bug.cgi?id=1140397
Hi willj, congratulations on tracking that down. I don't know why that DLL was running after you uninstalled Comodo.
The Mozilla Crash Reporter process seems not to be able to gather information in certain cases, probably where the crash happens too early in the startup process. I don't know whether it would be possible to start it independently to resolve that issue, but it could be helpful if it could make more sense of the Windows data than the event viewer. I suspect there will always be cases like this one where a "process of elimination" is necessary.
BTW, this seems to be the problem: bug 1140397
I updated that bug with a link to this thread.
Thank you, I felt very lucky to find the problem. I think your tips and links to the issues lead me to the right path, after hearing that drivers could be a problem, I saw that it was working in Windows safe mode, which motivated me to chase down the DLLs. Thank you very much!