At the time, I was not aware of the problem so I chalked it up to an isolated customer issue which could be fixed by rebuilding the reference image. In the meantime, I came across a TechNet forum thread casually mentioning the issue and then yesterday I ran into the exact same problem at a different customer, so I finally had the opportunity to investigate.

Whenever I experience unexpected behavior in an application, I always take a look at the event log. There’s no guarantee for success, but many times after spending just a few moments I find clues that point at the root cause or, at the very least, lead to the next clue. In most cases, when a UWP application fails to start, the cause is either a missing dependency or a corrupted / missing license.

Once I had a few spare moments, I opened the eventvwr and started going through the Administrative Events view, which lists all errors and warnings for all logs. I quickly came upon two AppReadiness events that correlated with my most recent attempts to launch the Photos app:

• EventID 10: The Appx operation 'RegisterPackageAsync' on 'Microsoft.Windows.Photos_2017.37071.16410.0_neutral_~_8wekyb3d8bbwe' failed for user 'Tolwyn' - Windows cannot install package Microsoft.Windows.Photos_2017.37071.16410.0_x64__8wekyb3d8bbwe because this package depends on a framework that could not be found. Provide the framework "Microsoft.NET.Native.Runtime.1.4" published by "CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US", with neutral or x64 processor architecture and minimum version 1.4.24201.0, along with this package to install. The frameworks with name "Microsoft.NET.Native.Runtime.1.4" currently installed are: {}. (Error: Package failed updates, dependency or conflict validation.)
• EventID 214: 'Microsoft.Windows.Photos_8wekyb3d8bbwe' install failed for Tolwyn. Error: 'Package failed updates, dependency or conflict validation.' (1.4849314 seconds)

Note: following modern in-box application appeared to be plagued by the same issue as well: Microsoft.StorePurchaseApp (which provides in-app purchase functionality) and Microsoft.Advertising.Xaml (probably somehow related to Microsoft Advertising Framework for XAML).

It appeared that the RegisterPackagesAsync operation, which registers a package (the main package) and its dependency packages for the current user, started when the user logged on but errored out because one of the dependencies - Microsoft.NET.Native.Runtime.1.4 to be precise - failed validation. The question was why?

One common denominator in all cases was that customers removed a choice selection of the in-box modern apps using Michael Niehaus' excellent RemoveApps PowerShell script.

Wondering if perhaps the sequence of app removals might do something with the unexpected behavior, I opened the build and capture task sequence in MDT and disabled the RemoveApps step, installed a reference computer and verified that the Photos app could be launched.

This came as a surprise. As I did not have time yet to investigate further which of the apps I am removing in Windows PE is causing this behavior, I came up with a fix (workaround to be precise) instead. I downloaded Microsoft.NET.Native.Runtime.1.4 x86/x64 packages from the Microsoft Store for Business (for details, see this post)...

... put together a small PowerShell wrapper (see below), placed both appx files in the same folder as the PS script and then added the script to my build and capture task sequence. Crossing my fingers, I installed another VM and verified that my workaround did indeed solve the issue.

# Determine where to do the logging 
$tsenv = New-Object -COMObject Microsoft.SMS.TSEnvironment 
$logPath = $tsenv.Value("LogPath") 
$logFile = "$logPath\$($myInvocation.MyCommand).log"
$ScriptName = $MyInvocation.MyCommand

# Create Log folder
$testPath = Test-Path $logPath
If (!$testPath)
{
    New-Item -ItemType Directory -Path $logPath
}
 
# Create Logfile
Write-Output "$ScriptName - Create Logfile" > $logFile
 
Function Logit($TextBlock1){
	$TimeDate = Get-Date
	$OutPut = "$ScriptName - $TextBlock1 - $TimeDate"
	Write-Output $OutPut >> $logFile
}

# Start main code here
. Logit "Make sure policy is set."
Set-ItemProperty -Path "HKLM:\Software\Policies\Microsoft\Windows\Appx" -Name "AllowAllTrustedApps" -Value "1" -Force | Out-Null

# Determine where to check
$AppxPath = $PSScriptRoot
$AppxList = (Get-ChildItem -Path $AppxPath -Recurse) | where-object {$_.FullName -like "*.appx"}

. Logit "Adding packages..."
ForEach ($Appx in $AppxList) {
    . Logit "Installing package $($Appx.Fullname)"
    Add-AppxProvisionedPackage -Online -SkipLicense -PackagePath "$($Appx.Fullname)"
}

I am yet to investigate the actual cause of the problem and also if it still occurs on Windows 10 1803 (Spring Creators Update) installs. The point of this post was to highlight this particular issue and to illustrate potential workaround.

Update: Anton Andres pointed out per mail, that removing Microsoft.Xbox.TCUI breaks .NET.Native.Runtime dependency in the first place. Thanks for the tip!

Tweet me if you fancy or have any questions.