Bugzilla

Our current understanding of this problem is as follows. Our code contained paths where it will try to load non-Microsoft-signed libraries with the ProcessSignaturePolicy process mitigation policy being active. On regular installs and in our CI, failures with this mitigation are silent, they just generate an ETW event and make LoadLibrary return NULL -- and our code was relying on this behavior. But given our current config for the MSIX package, these failures seem doubly fatal, meaning they provoke the two things described below.

1. They set the package status to 2, which implies that next time we try to launch the app we will not even try to start Firefox and just fail.
    Here is a part of the corresponding kernel call stack caught in procmon and manually annotated:

```
    0xfffff80763d78dd3 0x1c0008dd3 CI.dll KappxpSetPackageStatus
    0xfffff80763d79481 0x1c0009481 CI.dll KappxpNotifyPackagedFile
    0xfffff80763df1e2c 0x1c0081e2c CI.dll KappxNotifyIntegrityFailureInPackagedProcess
    0xfffff80763dc7a17 0x1c0057a17 CI.dll CipReportAndReprieveUMCIFailure
    0xfffff80763dc2daa 0x1c0052daa CI.dll CiValidateImageHeader
    (... 00000034`cf3fd5a0 ntdll.dll LdrLoadDll)
```

2. They report an exception -- which maybe crashes our process although we are not 100% sure of the flow of that exception.
    Here is a part of the corresponding userland call stack caught in WinDbg:

```
    00 00000034`cf3fc868 00007fff`0b637c19 ntdll!NtRaiseException+0x14
    01 00000034`cf3fc870 00007fff`0b636cc8 ntdll!WerpBreakIntoDebuggerIfPresent+0x2d
    02 00000034`cf3fc8a0 00007fff`0b6267b5 ntdll!RtlReportException+0x38
    03 00000034`cf3fc920 00007fff`0b5f9f15 ntdll!LdrAppxHandleIntegrityFailure+0x1b5
    04 00000034`cf3fd060 00007fff`0b561770 ntdll!LdrpMapDllNtFileName+0x99321
    05 00000034`cf3fd160 00007fff`0b56153f ntdll!LdrpMapDllFullPath+0xe0
    06 00000034`cf3fd2f0 00007fff`0b578fd4 ntdll!LdrpProcessWork+0x77
    07 00000034`cf3fd340 00007fff`0b56932c ntdll!LdrpLoadDllInternal+0x1a0
    08 00000034`cf3fd3e0 00007fff`0b57a95a ntdll!LdrpLoadDll+0xb0
    09 00000034`cf3fd5a0 00007ff6`5bdf6e8e ntdll!LdrLoadDll+0xfa
```

Just for archiving -- our current understanding of this problem is as follows. Our code contained paths where it will try to load non-Microsoft-signed libraries with the ProcessSignaturePolicy process mitigation policy being active. On regular installs and in our CI, failures with this mitigation are silent, they just generate an ETW event and make LoadLibrary return NULL -- and our code was relying on this behavior. But given our current config for the MSIX package, these failures seem doubly fatal, meaning they provoke the two things described below.

1. They set the package status to 2, which implies that next time we try to launch the app we will not even try to start Firefox and just fail.
    Here is a part of the corresponding kernel call stack caught in procmon and manually annotated:

```
    0xfffff80763d78dd3 0x1c0008dd3 CI.dll KappxpSetPackageStatus
    0xfffff80763d79481 0x1c0009481 CI.dll KappxpNotifyPackagedFile
    0xfffff80763df1e2c 0x1c0081e2c CI.dll KappxNotifyIntegrityFailureInPackagedProcess
    0xfffff80763dc7a17 0x1c0057a17 CI.dll CipReportAndReprieveUMCIFailure
    0xfffff80763dc2daa 0x1c0052daa CI.dll CiValidateImageHeader
    (... 00000034`cf3fd5a0 ntdll.dll LdrLoadDll)
```

2. They report an exception -- which maybe crashes our process although we are not 100% sure of the flow of that exception.
    Here is a part of the corresponding userland call stack caught in WinDbg:

```
    00 00000034`cf3fc868 00007fff`0b637c19 ntdll!NtRaiseException+0x14
    01 00000034`cf3fc870 00007fff`0b636cc8 ntdll!WerpBreakIntoDebuggerIfPresent+0x2d
    02 00000034`cf3fc8a0 00007fff`0b6267b5 ntdll!RtlReportException+0x38
    03 00000034`cf3fc920 00007fff`0b5f9f15 ntdll!LdrAppxHandleIntegrityFailure+0x1b5
    04 00000034`cf3fd060 00007fff`0b561770 ntdll!LdrpMapDllNtFileName+0x99321
    05 00000034`cf3fd160 00007fff`0b56153f ntdll!LdrpMapDllFullPath+0xe0
    06 00000034`cf3fd2f0 00007fff`0b578fd4 ntdll!LdrpProcessWork+0x77
    07 00000034`cf3fd340 00007fff`0b56932c ntdll!LdrpLoadDllInternal+0x1a0
    08 00000034`cf3fd3e0 00007fff`0b57a95a ntdll!LdrpLoadDll+0xb0
    09 00000034`cf3fd5a0 00007ff6`5bdf6e8e ntdll!LdrLoadDll+0xfa
```

The proposed patches appear to have fixed the problem.