We had a similar issue with Mozilla not launching. We found it was because of the writable volume capturing the "auto-updates" of Firefox. Our fix was to disable updates using the new Firefox group policy object, and delete the writable. Since then, we haven't had any issues. The same goes for Chrome. We are using version 63 of Firefox on Windows 10 1803. Hope that helps.
We already had auto-updates disabled but this issue was still happening for us too.
Firefox would run for a while but eventually whenever a user launched Firefox it didn't open. Nothing in the event logs either. Oddly, I found that I could a user could launch Firefox if they executed it from an AppStack directly.
After some digging around here's what I was seeing.
If Firefox was launched from an AppStack directly, it was executing the process from:
\Device\HarddiskVolume22\SVROOT\Program Files\Mozilla Firefox\firefox.exe
If Firefox was launched from a shortcut in the Start Menu, it was executing the process from:
E:\SVROOT\Program Files\Mozilla Firefox\firefox.exe
Note: We give our writable volumes a drive letter (and hide it from Explorer) because Chrome can't install extensions without it.
If you look at snapvol.cfg in a writeable volume, you'll notice at the bottom there's a section for "Reverse Replicate File Entries". After adding the following line into snapvol.cfg Firefox was able to open for our users.
reverse_replicate_file=Program Files\Mozilla Firefox\firefox.exe
This is due to App Volumes tricking firefox.exe to run as "C:\Program Files\Mozilla Firefox\firefox.exe" but is being mapped to "\Device\HarddiskVolume22\SVROOT\Program Files\Mozilla Firefox\firefox.exe" instead of the location on the E: drive.
I see. We are not using Writable volumes at all so none of those solutions would work for us. It appears that something changed between version 59 ESR of Firefox and 60. Once I rolled back Mozilla to version 59 everything works great.
I'm seeing the same thing and am preparing to just install Firefox on our base image versus deploying via AppVol. However, I've done some additional digging and observed the following behavior on our non-writable app volume/stack:
(Using 64-bit Firefox on Win10)
- User logs in
- c:\svroot\Program Files is NOT browsable
- User starts Firefox to do stuff
- c:\svroot\Program Files IS browsable- Firefox folder has the same size and number of files as c:\program files\mozilla...
- After a while, user closes Firefox and launching via normal shortcuts does not work anymore
- c:\svroot\Program Files\Mozilla Firefox (where I believe the shortcuts actually point to?) is now down about 30 files compared to c:\program files\... and Firefox does not work when launched from here
- However, launching Firefox from the actual AppStack (per another post above- accessed via c:\snapvolumestemp\Mounpoints\SOMEGUID\svroot\program files\mozilla firefox\firefox.exe) DOES work.
So the big question appears to be: What is deleting these files and why? I'm reluctant to open up a case with Mozilla and/or VMware as I fully expect each one to blame the other.