Hello Everyone,
I was wondering if someone might have run into an issue with Mozilla Firefox on AppStack not working. What is happening is that after I created an appstack with Firefox on it everything seem to work great for a day or two however then all of the sudden it won't launch at all. It happens to multiple users including myself. I'm using UEM to capture user information using the UEM template available here on VMware site. Besides that there are no other alterations to the program. If I install Firefox on master image it works flawlessly but I don't really want that on my image. The Firefox versions I tried is regular Firefox 62 and Firefox 60.2 ESR. The OS I'm on is Windows 10 1607 LTSB . THere not a single Event in the event viewer that could point to what is happening here.
Any help would be much appreciated
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)
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.
Hi everyone.
I'm facing the exact same problem (and not using Writable Volume either). Using version 60.4.0 ESR (I tried with other 6x.x.x versions).
When I open a new session on a desktop, Firefox launches normally, but as soon as I close it, I'm unable to open it again using the normal shortcut.
If anyone manage to find a solution, it would be nice to share
I've been following this issue for a little while and I saw this possible solution pop up in a different thread. I have not tested it myself yet.
Re: Reproducible FireFox 60.0.2 Crash after working 1-3 times per session
*************************************************************************************************
* Please do not change the subject line of this email if you wish to respond. **
Hello,
Emailing in regards to the issue with App volumes and Firefox. Can you attempt the following test for me:
1. Login to the Parent VM
2. Open regedit and navigate to the location : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\svdriver\Parameters
3. There is Multi-String value there called "HookInjectionWhitelist"
4. Add *firefox.exe||* to the list
5. Create a new snapshot and test if it resolves the issue in a test pool
Some information on Hook Injection:
App Volumes driver uses reparse technique to redirect every file access request to their respective appstack/writable. There are few applications which perform integrity checks on the opened file handle. Integrity check means, an application opens a file and gets the handle and then it queries for the path from the handle and compares them. In case of AppVolumes, both the paths are different and integrity check fails. This is where hook was introduced to fake paths returned to satisfy the Integrity check.
*************************************************************************************************
Wow! I just ran a quick and dirty test (had to create the whitelist key) but it seems to be working. I have found that accessing sites using Flash (Horizon View, etc.) seem to cause Firefox to crash more quickly with this "feature" and they have remained stable compared to a VM that does not have this applied. Will keep testing and report back. THANK YOU!