6 Replies Latest reply on Dec 28, 2018 11:38 AM by LukaszDziwisz

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

    jgemcs Novice

      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&buildid=20180605201706
      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/80000003/00e1439f.htm?Retriage=1 Followup: MachineOwner --------- 
      
        • 1. Re: Reproducible FireFox 60.0.2 Crash after working 1-3 times per session
          LukaszDziwisz Novice

          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.

          • 2. Re: Reproducible FireFox 60.0.2 Crash after working 1-3 times per session
            jmatz135 Enthusiast

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

            • 3. Re: Reproducible FireFox 60.0.2 Crash after working 1-3 times per session
              jordanht Novice

              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!

              • 4. Re: Reproducible FireFox 60.0.2 Crash after working 1-3 times per session
                Tomas_Iskra Lurker

                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.

                • 5. Re: Reproducible FireFox 60.0.2 Crash after working 1-3 times per session
                  alejandrovmw Novice

                  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

                  • 6. Re: Reproducible FireFox 60.0.2 Crash after working 1-3 times per session
                    LukaszDziwisz Novice

                    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?