Thursday, 01 March 2018 10:07

Fixing 'Windows cannot install package Microsoft.Windows.Photos'

Written by
Rate this item
(4 votes)


While I sometimes long for the day when I no longer have to deal with unexpected Windows 10 behavior, there’s something rewarding about quickly finding a solution. In the process, I often end up with an idea for a blog post I can share with thousands three regular readers. Yesterday I successfully solved an interesting case that opened when a customer contacted me a month ago and reported that the Photo app was no longer working on their 1709 reference image.

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.

Read 32407 times Last modified on Friday, 02 March 2018 13:33

Recent Posts

  • Windows 10 21H2 Built-In Apps: What to Keep
    The development of the Windows 10, version 21H2 is finished and the update will soon be available for download from…
    Written on Wednesday, 20 October 2021 11:41
  • Group Policy Changes in Windows 10 21H2
    As Windows 10, version 21H2 update development winds down, Microsoft is now preparing for the final release of the Windows…
    Written on Wednesday, 20 October 2021 07:20
  • Group Policy Changes in Windows 10 20H1 Preview
    As Windows 10 Vibranium Update (20H1) development winds down, Microsoft is now beginning the phase of checking in the final…
    Written on Tuesday, 14 January 2020 04:51
  • An alternative ESU MAK Activation Solution
    This blog post was shared with me by a colleague of mine, Daniel Dorner, a Microsoft Premier Field Engineer. It’s…
    Written on Wednesday, 04 December 2019 21:04
  • The Case of Missing UE-V Templates
    My customers often deal with unexpected Windows behavior and this case is no different. This particular one is especially interesting…
    Written on Tuesday, 03 September 2019 12:20
  • The Case of Changing Default Printer
    While I sometimes long for the day when I no longer have to deal with unexpected Windows 10 behavior, there’s…
    Written on Wednesday, 14 August 2019 20:36