Search Support

Avoid support scams. We will never ask you to call or text a phone number or share personal information. Please report suspicious activity using the “Report Abuse” option.

Learn More

FF60 ESR with VMware Horizon, AppVolumes, UEM

more options

With the latest Firefox release last week I began piloting the ESR 60 it on my organization's VMware Horizon, AppVolumes, UEM platform. We've been using ESR 52 for the past year, updating it as usual and experiencing no issues. I changed nothing about my setup going from ESR 52 to ESR 60 and found that Firefox ESR 60 won't open at all when it's deployed the exact same way as 52 was. I've tried fresh installs and installing 60 over the top of 52 with no luck. I also upgraded 52 ESR to the latest 52.8 release with no issue.

In short, Firefox doesn't open up at all. It crashes immediately. I deleted my UEM Archives, Backups, and the %appdata%\Mozilla folder from my profile and FF 60 finally opened. But once I closed and opened it a few times, it is back to not opening again--and this time deleting my profile doesn't seem to help.

I've disabled UEM DirectFlex and that has not helped either.

Looking for any guidance for deploying into a virtual desktop environment. I presume this is an issue with ESR 60 rather than VMware products since I have no such issue with 52.

Also Using Win7 x64 Enterprise FWIW


Here's what my logs are looking like: crash.main.2 1526330757 455d87f3-b927-4f52-84f3-29fd44211392 ServerURL=https://crash-reports.mozilla.com/submit?id={ec8030f7-c20a-464f-9b0e-13a3a9e97384}&version=60.0&buildid=20180503164101 StartupTime=1526330756 SafeMode=0 ProductName=Firefox Vendor=Mozilla InstallTime=1526330708 CPUMicrocodeVersion=0x42c ReleaseChannel=esr Version=60.0 StartupCrash=1 BuildID=20180503164101 ProductID={ec8030f7-c20a-464f-9b0e-13a3a9e97384} CrashTime=1526330757 UptimeTS=16.51687 SecondsSinceLastCrash=48 BlockedDllList= User32BeforeBlocklist=1 SystemMemoryUsePercentage=28 TotalVirtualMemory=8796092891136 AvailableVirtualMemory=8794780155904 TotalPageFile=10735030272 AvailablePageFile=8725798912 TotalPhysicalMemory=6441984000 AvailablePhysicalMemory=4628758528 MozCrashReason=MOZ_RELEASE_ASSERT(globalObj) ThreadIdNameMapping=6764:"Gecko_IOThread",5628:"Timer",8156:"Link Monitor",1816:"Socket Thread",3432:"JS Watchdog",

With the latest Firefox release last week I began piloting the ESR 60 it on my organization's VMware Horizon, AppVolumes, UEM platform. We've been using ESR 52 for the past year, updating it as usual and experiencing no issues. I changed nothing about my setup going from ESR 52 to ESR 60 and found that Firefox ESR 60 won't open at all when it's deployed the exact same way as 52 was. I've tried fresh installs and installing 60 over the top of 52 with no luck. I also upgraded 52 ESR to the latest 52.8 release with no issue. In short, Firefox doesn't open up at all. It crashes immediately. I deleted my UEM Archives, Backups, and the %appdata%\Mozilla folder from my profile and FF 60 finally opened. But once I closed and opened it a few times, it is back to not opening again--and this time deleting my profile doesn't seem to help. I've disabled UEM DirectFlex and that has not helped either. Looking for any guidance for deploying into a virtual desktop environment. I presume this is an issue with ESR 60 rather than VMware products since I have no such issue with 52. Also Using Win7 x64 Enterprise FWIW Here's what my logs are looking like: crash.main.2 1526330757 455d87f3-b927-4f52-84f3-29fd44211392 ServerURL=https://crash-reports.mozilla.com/submit?id={ec8030f7-c20a-464f-9b0e-13a3a9e97384}&version=60.0&buildid=20180503164101 StartupTime=1526330756 SafeMode=0 ProductName=Firefox Vendor=Mozilla InstallTime=1526330708 CPUMicrocodeVersion=0x42c ReleaseChannel=esr Version=60.0 StartupCrash=1 BuildID=20180503164101 ProductID={ec8030f7-c20a-464f-9b0e-13a3a9e97384} CrashTime=1526330757 UptimeTS=16.51687 SecondsSinceLastCrash=48 BlockedDllList= User32BeforeBlocklist=1 SystemMemoryUsePercentage=28 TotalVirtualMemory=8796092891136 AvailableVirtualMemory=8794780155904 TotalPageFile=10735030272 AvailablePageFile=8725798912 TotalPhysicalMemory=6441984000 AvailablePhysicalMemory=4628758528 MozCrashReason=MOZ_RELEASE_ASSERT(globalObj) ThreadIdNameMapping=6764:"Gecko_IOThread",5628:"Timer",8156:"Link Monitor",1816:"Socket Thread",3432:"JS Watchdog",

All Replies (5)

more options

Are you using any mechanism for enterprise customization like AutoConfig or CCK2?

Can you go to about:crashes and see if there is a link to the crash report on our crash server?

more options

We certainly don't use CCK2. I do have a local-settings.js file (rather than an autoconfig.js file) pointing to a mozilla.cfg file containing a dozen or so settings including the use of the MSIE certificate store.

My organization has also used PolicyPak for Firefox configuration thus far, but I've removed it from our test systems in anticipation of using the official official ADMX/ADML files from Mozilla.

I'll remove the mozilla.cfg file and local-settings.js from my configuration and see if I run into further trouble.

I'll also look into the crash page and see what I can find.

more options

Somehow I got FF 60.0.0 to work properly in a VMware AppVolume. I don't know how, but it eventually worked fairly consistently. Some of my testers had to delete their profiles to get it to work but it did. I saw that Mozilla released 60.0.2 today. I installed it over the top of 60.0.0--lo and behold, Firefox returned to its instant crash behavior. I rolled back to the AppVolume with 60.0.0. Surprisingly, it has begun crashing again. I seriously give up. Far more complicated programs seem to work perfectly fine while FF fails to work. Why does this application just not work in a virtualized environment? I'm open to any advice one could offer. Thanks

more options

Are you able to get any of the actual crash links from about:crashes?

If I can get the URL, I can see what the actual crash stack looks like.

more options

I've tried going to the crash links, each time it says the page can't be found. I was able to get FF to open again, I had to re-provision virtual desktops and delete all Mozilla folders from %appdata% and %localappdata% over and over until it finally began opening as normal again, hence--the crash links were in those profiles. I'll try to reproduce one of them and post it if possible.