User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:53.0) Gecko/20100101 Firefox/53.0 Build ID: 20170413192749 Steps to reproduce: 1. Install Windows Server 2012 R2 (64-bit german) 2. Install Firefox 53 (64-bit german) 3. Create override.ini under %InstallDirFirefox%\browser with correct settings [XRE] EnableProfileMigrator=false 4. ??? 5. PROFIT! :-P Actual results: Firefox starts, but does not load any page and does not respond to certain commands (like closing firefox). Expected results: Firefox should start and load the "Whats new page" and any other page i might want to open. I just tested this with new users, so this might be only an issue when Firefox has to create a new user-profile (%APPDATA%\Mozilla) I could reproduce this problem with different configuration files (override.ini, autoconfig.js, mozilla.cfg, userchrome.css) and not only with override.ini

alex, this symptom disappears if you use none of the configuration files? Does this still happen if you launch in safe mode? The symptoms you describe don't really match any error that could be caused by the EnableProfileMigrator=false setting. Does this happen if you have a completely empty override.init file?

Hello Benjamin, yes, this symptom disappears if i use none of the configuration files. No, this does not happen if you have a completely empty override.ini file. I have to test this in safe mode. I'll add this info later, as i need to test it first.

I tried in safe mode and in safe mode i do not have this problem. i'll try with a fresh Windows 10 VM next.

Works also in a Windows 10 VM... i'll have to analyze this further... maybe process explorer has some answers... The strange thing is, if i use a 32bit Firefox on those servers everything works fine... it just doesn't work with the 64bit Firefox... strange...

Alright, i think i could isolate the problem to Citrix itself. I can reproduce this bug a 100% of the time if following this exact steps: 1. Install Windows Server 2012 R2 (64-bit german) 2. Install Citrix XenApp & XenDesktop Virtual Delivery Agent 7.13 (you can install it without having a Citrix infrastructure) 2. Install Firefox 53 (64-bit german) 3. Create override.ini in %InstallDirFirefox%\browser with correct settings [XRE] EnableProfileMigrator=false So it seems the problem is caused by Citrix itself. Citrix also uses the Terminal Server role of Windows, but when removing Citrix and letting the Terminal Server role on the Windows Server, Firefox behaves as it should. So the problem has to be Citrix itself. Although i have no idea what they possibly could change to break Firefox 64-bit configuration files.

Gah. Unfortunately I don't think we have the engineering time to diagnose this, so I suggest you report it to Citrix. I am going to leave this report open and if the Citrix team has questions they can use this report to contact me.

I can't report a bug to Citrix, as Citrix requires you to have a support contract to report bugs and problems. We bought the product licenses without support. Altough Citrix is in the process of forcing everyone into support, so i might have support in a few months. I opened a thread in the official forum: http://discussions.citrix.com/topic/386686-citrix-xenapp-713-vda-breaks-firefox-64-bit-configuration-files/ Someone else might report this bug to Citrix or i'll do it as soon as our company has support with them. This may take a while though...

Alex, it looks like 64-bit Chrome users are reporting similar problems with Citrix XenApp. Can you please check whether the "Disable Citrix API hooks for Chrome" instructions in the following Chrome KB article fix your 64-bit Firefox crash? For step #3, set the ExcludedImageNames registry key to "firefox.exe,plugin-container.exe" instead of "chrome.exe,nacl64.exe". https://support.google.com/chrome/a/answer/7380899

Hello Chris, thanks for your help! I can confirm, that Firefox stops crashing when using this workaround. Here is an articel that describes the hooks on Citrix side: https://support.citrix.com/article/CTX107825 Helge Klein explained it a lot better: https://helgeklein.com/blog/2015/10/citrix-xenappxendesktop-api-hooking-explained/ Although removing those hooks probably will remove functionality from Citrix and / or make Firefox less performant in Citrix. So this really is just a workaround and no permanent solution.

Does it also stop crashing if you disable Electrolysis/e10S?

yep, i can confirm, that by deactivating Electrolysis / e10S / Multi-Process, Firefox stops crashing on Citrix. So, if i see this correctly we have concluded, that it must be a incompatibility between Citrix XenApp / XenDesktop Hooks and the Multi-Process spawning of Firefox. FYI: Citrix XA/XD also has Problems with Multi-Processes on Internet Explorer, but nothing critical. It just prevents a session from closing, because Internet Explorer doesn't close its child processes.

ok now that i am testing it again with Firefox 53.0.2 i can no longer replicate it with the config files... it just seems to be between e10s and Citrix Hooks. Maybe the config files changed when and how electrolysis was activated on Firefox? Citrix XA 7.13 has no problems with electrolysis on 32-bit Firefox (we are currently using this and electrolysis is activated). i'll change the title accordingly.

OK thank you for confirming. Disabling the hooking is the only option. Citrix will be releasing versions that will automatically disable hooking for Firefox 64b processes. When released you can reference fixed issue ID LC6982.

(In reply to ed.zimny from comment #13) > OK thank you for confirming. Disabling the hooking is the only option. > Citrix will be releasing versions that will automatically disable hooking > for Firefox 64b processes. When released you can reference fixed issue ID > LC6982. Thanks, Ed! We'll note this in a Mozilla KB article.

(In reply to ed.zimny from comment #13) > OK thank you for confirming. Disabling the hooking is the only option. > Citrix will be releasing versions that will automatically disable hooking > for Firefox 64b processes. When released you can reference fixed issue ID > LC6982. Thanks Ed, can you please confirm what limitations this brings for Citrix/Firefox 64 bit users, I.e does this have any effect on end users (like Firefox is not accessible through XenApp/XenDesktop) or does it imply more IT complexity? We're planning on rolling-out 64 bit Firefox more widely this year so you should expect more of these instances, the current 64bit user share is very low.

This issue should only impact XenApp servers, not XenDesktop. Disabling hooking for Firefox 64b processes will result in one limitation - Special Folder Redirection will also be disabled.

XenApp 7.14 solves this issue. Here is the changelog (search for #LC6982). http://docs.citrix.com/en-us/xenapp-and-xendesktop/7-14/whats-new/fixed-issues.html Quote: ------------------ When you launch the 64-bit version of Mozilla Firefox in a remote session and the Electrolysis (e10s) feature is enabled, the second firefox.exe process might exit unexpectedly, leaving the first firefox.exe process running in a diminished state. [#LC6982] ------------------ I think we can mark this bug as solved (users need to update to XenApp 7.14). Thx again for resolving this issue! :)

(In reply to alex.marocchi from comment #17) > XenApp 7.14 solves this issue. > Here is the changelog (search for #LC6982). > > http://docs.citrix.com/en-us/xenapp-and-xendesktop/7-14/whats-new/fixed- > issues.html Thanks for the heads up, Alex! We are preparing a Mozilla support article about this XenApp crash. I'll add a note about the fix in XenApp 7.14.

Here is the SUMO KB article about 64-bit Firefox problems with Citrix's XenApp VM: https://support.mozilla.org/kb/64-bit-firefox-crashes-citrixs-xenapp-vm

XenApp 7.6 LTSR CU4 also includes the same change referenced as LC6982. http://docs.citrix.com/en-us/xenapp-and-xendesktop/7-6-long-term-service-release/xad-whats-new/cumulative-update-4/fixed-issues.html