VMware Horizon Community
jgemcs
Enthusiast
Enthusiast
Jump to solution

Reproducible FireFox 60.0.2 Crash after working 1-3 times per session

Hi,

we discovered an error in a customer environment which is reproducable in our LAB which is completely fresh installed.

We use a clean Windows7 x64 VM, fully patched with Horizon View 7.4 Agent and AppVolumes 2.14.

Single Appstack, only Firefox 60.0.2 64bit German Version.

Clean User Profile, no Profile Management solution for testing

Starting Firefox works fine - open, browse, close.

Open again/browse/close works fine for several times. But if you open some tabs, stop using firefox for some minutes and close it, it won't open again.

Firefox is on the newest Version, so no update in the background.

-Safe-mode :not working

-deleting FireFox Profile :not working

-same behavior with View Agent 7.3.2, AppVolumes Agent 2.13.3, old AppVolumes Template.

-Copying the FireFox program directory to c:\temp and start FireFox from there works fine

Any Idea how to find out whats going on here ?

Is there a possibility to debug the AppVolumes driver ?

Jens

Firefox Crash error:

crash.main.2

1529515938

255c0e7f-d871-4029-a520-81c8c5274a82

ServerURL=https://crash-reports.mozilla.com/submit?id={ec8030f7-c20a-464f-9b0e-13a3a9e97384}&version=60.0.2&bu...

StartupTime=1529515938

SafeMode=0

ProductName=Firefox

Vendor=Mozilla

InstallTime=1529515554

CPUMicrocodeVersion=0x42a

ReleaseChannel=esr

Version=60.0.2

StartupCrash=1

BuildID=20180605201706

ProductID={ec8030f7-c20a-464f-9b0e-13a3a9e97384}

CrashTime=1529515938

UptimeTS=7.105649

BlockedDllList=

SystemMemoryUsePercentage=31

TotalVirtualMemory=8796092891136

AvailableVirtualMemory=8794795450368

TotalPageFile=6439596032

AvailablePageFile=5348102144

TotalPhysicalMemory=3220758528

AvailablePhysicalMemory=2209562624

MozCrashReason=MOZ_RELEASE_ASSERT(globalObj)

ThreadIdNameMapping=4112:"Gecko_IOThread",3000:"Timer",3904:"Link Monitor",3568:"Socket Thread",4160:"JS Watchdog",

minidump Analysis:

Windows 7 Version 7601 (Service Pack 1) MP (2 procs) Free x64

Product: WinNt, suite: SingleUserTS

kernel32.dll version: 6.1.7601.24094 (win7sp1_ldr_escrow.180330-1600)

Machine Name:

Debug session time: Wed Jun 20 13:42:29.000 2018 (UTC - 4:00)

System Uptime: not available

Process Uptime: 0 days 0:00:01.000

  Kernel time: 0 days 0:00:00.000

  User time: 0 days 0:00:00.000

TRIAGER: Could not open triage file : e:\dump_analysis\program\triage\oca.ini, error 2

TRIAGER: Could not open triage file : e:\dump_analysis\program\winxp\triage.ini, error 2

TRIAGER: Could not open triage file : e:\dump_analysis\program\triage\user.ini, error 2

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

*                                                                             *

*                        Exception Analysis                                   *

*                                                                             *

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

TRIAGER: Could not open triage file : e:\dump_analysis\program\triage\guids.ini, error 2

*** WARNING: Unable to verify timestamp for firefox.exe

*** ERROR: Module load completed but symbols could not be loaded for firefox.exe

*** WARNING: Unable to verify timestamp for mozglue.dll

*** ERROR: Module load completed but symbols could not be loaded for mozglue.dll

*** WARNING: Unable to verify timestamp for nss3.dll

*** ERROR: Module load completed but symbols could not be loaded for nss3.dll

TRIAGER: Could not open triage file : e:\dump_analysis\program\triage\modclass.ini, error 2

GetUrlPageData2 (WinHttp) failed: 12029.

FAULTING_IP:

xul+e1439f

000007fe`e957439f cc              int     3

EXCEPTION_RECORD:  ffffffffffffffff -- (.exr 0xffffffffffffffff)

ExceptionAddress: 000007fee957439f (xul+0x0000000000e1439f)

   ExceptionCode: 80000003 (Break instruction exception)

  ExceptionFlags: 00000000

NumberParameters: 1

   Parameter[0]: 0000000000000000

DEFAULT_BUCKET_ID:  STATUS_BREAKPOINT

PROCESS_NAME:  firefox.exe

ERROR_CODE: (NTSTATUS) 0x80000003 - {EXCEPTION}  Breakpoint  A breakpoint has been reached.

EXCEPTION_CODE: (HRESULT) 0x80000003 (2147483651) - One or more arguments are invalid

EXCEPTION_PARAMETER1:  0000000000000000

FAULTING_THREAD:  000000000000035c

PRIMARY_PROBLEM_CLASS:  STATUS_BREAKPOINT

BUGCHECK_STR:  APPLICATION_FAULT_STATUS_BREAKPOINT

IP_ON_HEAP:  00000000008fd500

The fault address in not in any loaded module, please check your build's rebase

log at \bin\build_logs\timebuild\ntrebase.log for module which may contain the address if it were loaded. FRAME_ONE_INVALID: 1 LAST_CONTROL_TRANSFER: from 00000000008fd500 to 000007fee957439f STACK_TEXT: 00000000`0022f160 00000000`008fd500 : 00000000`0022f878 00000000`0afae240 00000000`00000003 00000000`0022f1a0 : xul+0xe1439f 00000000`0022f168 00000000`0022f878 : 00000000`0afae240 00000000`00000003 00000000`0022f1a0 00000000`0080a9a0 : 0x8fd500 00000000`0022f170 00000000`0afae240 : 00000000`00000003 00000000`0022f1a0 00000000`0080a9a0 00000000`0a424020 : 0x22f878 00000000`0022f178 00000000`00000003 : 00000000`0022f1a0 00000000`0080a9a0 00000000`0a424020 00000000`00000000 : 0xafae240 00000000`0022f180 00000000`0022f1a0 : 00000000`0080a9a0 00000000`0a424020 00000000`00000000 00000000`00000000 : 0x3 00000000`0022f188 00000000`0080a9a0 : 00000000`0a424020 00000000`00000000 00000000`00000000 000007fe`eb568f18 : 0x22f1a0 00000000`0022f190 00000000`0a424020 : 00000000`00000000 00000000`00000000 000007fe`eb568f18 00020021`00000011 : 0x80a9a0 00000000`0022f198 00000000`00000000 : 00000000`00000000 000007fe`eb568f18 00020021`00000011 01d408be`0f3a99d3 : 0xa424020 STACK_COMMAND: ~0s; .ecxr ; kb FOLLOWUP_IP: xul+e1439f 000007fe`e957439f cc int 3 SYMBOL_STACK_INDEX: 0 SYMBOL_NAME: xul+e1439f FOLLOWUP_NAME: MachineOwner MODULE_NAME: xul IMAGE_NAME: xul.dll DEBUG_FLR_IMAGE_TIMESTAMP: 5b171132 FAILURE_BUCKET_ID: STATUS_BREAKPOINT_80000003_xul.dll!Unknown BUCKET_ID: X64_APPLICATION_FAULT_STATUS_BREAKPOINT_xul+e1439f WATSON_STAGEONE_URL: http://watson.microsoft.com/StageOne/firefox_exe/60_0_2_6730/5b170b9f/xul_dll/60_0_2_6730/5b171132/8... Followup: MachineOwner ---------

Tags (3)
Reply
0 Kudos
1 Solution

Accepted Solutions
jmatz135
Hot Shot
Hot Shot
Jump to solution

This fix also works for me with App volumes 2.15 and Firefox 60.4.0 ESR.

View solution in original post

Reply
0 Kudos
14 Replies
LukaszDziwisz
Hot Shot
Hot Shot
Jump to solution

We are seeing exactly the same behavior but with WIndows 10. Firefox would open fine after AppStack is freshly attached and then it will never open again. It works fine on packaging machine.

Reply
0 Kudos
jmatz135
Hot Shot
Hot Shot
Jump to solution

Has anyone heard from VMware on this?  Firefox is not working for us on Windows 10, Appvols 2.14.0 either.

Reply
0 Kudos
jordanht
Enthusiast
Enthusiast
Jump to solution

I'm seeing the same issue since upgrading to app volumes 2.14, so I'm guessing that's where something broke. At first I thought it was due to Firefox auto-updating itself, but I am running the ESR version and also disabled any updating through policy.

EDIT: After some testing it seems like it might just be an issue with Firefox 60. I went back to ESR 52.9 and haven't seen the issue again. Disappointing because I really like 60!

Reply
0 Kudos
Tomas_Iskra
Contributor
Contributor
Jump to solution

Hi,

we are experiencing similar problem.

When Firefox 60.x is launched from appstack, firefox.exe process closes immediately (we cannot event get to see app crashing).

Previous version 52.x doesnt have this problem.

I've copied Firefox folder (C:\Program Files (x86)\Mozilla Firefox) to C:\temp, launched from there and it works.

Seems like it's working because virtualization/filtering is not in place for such case.

Based on that, i believe the issue is in the App Vol agent (we are on 2.13.2.13).

Any ideas are more than welcomed.

Tom.

Reply
0 Kudos
alejandrovmw
Contributor
Contributor
Jump to solution

Hello,

Just to let you know that we had the same issue.

We updated Firefox to version ESR 60.X and same symptoms.

We treated this case with VMware Support.

They suggested to do the following:

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

* 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.
 
 

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

Hopefully this corrected my issue and we are using Firefox ESR 60.X, with AppVolumes 2.14 and View 7.5

Regards

Alejandro

LukaszDziwisz
Hot Shot
Hot Shot
Jump to solution

Did you get it implemented? Did it work?

Where would change need to be done? On master image or in the appstack where Mozilla lives?

Reply
0 Kudos
bwong32
Contributor
Contributor
Jump to solution

I applied the registry addition to the master image and it worked. 

I tested it with both the standard version of firefox 64.0.2 and the ESR edition (60.4) and both appstacks worked.

Reply
0 Kudos
alejandrovmw
Contributor
Contributor
Jump to solution

Hello Lukasz,

We have Firefox installed on an AppStack and AppVolumes 2.14.

You have to perform the change on the master image, under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\svdriver\Parameters

There is an entry called HookInjectionWhitelist. Just add *firefox.exe||* to the end of the line

Regards

pastedImage_2.png

jmatz135
Hot Shot
Hot Shot
Jump to solution

This fix also works for me with App volumes 2.15 and Firefox 60.4.0 ESR.

Reply
0 Kudos
LukaszDziwisz
Hot Shot
Hot Shot
Jump to solution

It worked for me as well on 60.5.0 ESR. Thank you very much for your help

Reply
0 Kudos
sjesse
Leadership
Leadership
Jump to solution

Has anyone heard from support if this is being added in a future version?

Reply
0 Kudos
RanHar
Contributor
Contributor
Jump to solution

This solution works.  AppVol 2.17.0.49, Firefox 74.0 (64-bit)

Reply
0 Kudos
Mickeybyte
Hot Shot
Hot Shot
Jump to solution

I'm seeing the same issue on a brand new Horizon 2006 setup with AppVol 2012 and latest Firefox version. So this is still an issue today?

Was able to solve it with HookInjectionWhiteList registry key.

 

Regards,

Mickeybyte


Regards,
Mickeybyte (ITPro blog)

If you found this comment useful or an answer to your question, please mark as 'Solved' and/or click the 'Kudos' button, please ask follow-up questions if you have any.
Reply
0 Kudos
alex17pat
Contributor
Contributor
Jump to solution

My problem is fixed by testing the firefox version.

Reply
0 Kudos