VMware Horizon Community
LukaszDziwisz
Hot Shot
Hot Shot

Mozilla on Appstack

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

Reply
0 Kudos
7 Replies
jsinclair
Enthusiast
Enthusiast

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.

Reply
0 Kudos
hermanc01
Enthusiast
Enthusiast

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.

Reply
0 Kudos
LukaszDziwisz
Hot Shot
Hot Shot

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.

Reply
0 Kudos
MrCheesecake
Enthusiast
Enthusiast

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.

Reply
0 Kudos
Scarlito
Contributor
Contributor

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 Smiley Happy

Reply
0 Kudos
jordanht
Enthusiast
Enthusiast

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.
 
 

*************************************************************************************************

Reply
0 Kudos
MrCheesecake
Enthusiast
Enthusiast

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!

Reply
0 Kudos