FF60 ESR with VMware Horizon, AppVolumes, UEM
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",
Tutte le risposte (5)
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?
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.
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
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.
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.