PowerShell 7.6.10 LTS Fixes MSIX PATH Issues as 7.4 and 7.5 Reach End of Support

Where 7.6.10 fits​

PowerShell 7.6 is the current LTS line. Microsoft's PowerShell team, which announced general availability in March, said PowerShell 7.6 is built on .NET 10 (LTS), continuing the alignment between PowerShell and the modern .NET platform. Microsoft's lifecycle table lists PowerShell 7.6 (LTS) with a release date of 18-Mar-2026 and end-of-support of 14-Nov-2028, on .NET 10.0.

Microsoft's lifecycle policy also defines what an LTS point release can contain: updates to an LTS release only contain critical security updates and servicing fixes that are designed to minimize impact on existing workloads. One rule in the same document applies directly here: Microsoft only supports the latest update version of a release. Once 7.6.10 is out, anyone still on 7.6.9 is one step behind the supported version, even though this is a quiet patch.

The previous build is a useful comparison. endoflife.date listed 7.6.9 (25 Oct 2026) as the latest 7.6 release, and WindowsForum's coverage of that version noted it moved to .NET SDK 10.0.403. The 7.6.10 notes move the build to .NET SDK 10.0.404. That is the SDK used to build PowerShell. The runtime PowerShell 7.6 targets is still .NET 10.

Section summary: 7.6.10 is the newest supported 7.6 LTS build. It arrived about two weeks after 7.6.9 and is the supported landing spot for anyone leaving 7.4 or 7.5.

The deadline: 7.4 and 7.5 end support today​

Microsoft's lifecycle table lists both PowerShell 7.5 (.NET 9.0) and PowerShell 7.4 (LTS) (.NET 8.0) with an end-of-support date of 10-Nov-2026. Both branches still run after that date, but they no longer get serviced. Microsoft's lifecycle documentation says that after a version reaches end of life, no further updates are provided, including security updates.

Windows PowerShell 5.1 is a separate product. It ships with Windows and follows the Windows support lifecycle, so this deadline does not affect it. As StarWind's upgrade guide points out, PowerShell 7 installs side-by-side with Windows PowerShell 5.1 (you still launch the old one with powershell.exe and the new with pwsh).

What changed in 7.6.10​

1. MSIX installs are detected with a Windows API​

Before this release, PowerShell decided whether it was running as an MSIX package by looking at its installation path. In 7.6.10 it calls the native GetCurrentPackageFamilyNameNative API instead.

The backport pull request (#28313) gives the reason. It says the change improves handling of a customer-reported MSIX/PATH issue. PowerShell now uses the package identity to choose the stable execution-alias directory for PATH. It also compares Windows process names case-insensitively, so launch paths with mixed capitalization are handled correctly. The PR says Unix behavior is unchanged.

The PR rates the risk as low but notes that the change touches startup PATH handling and adds Windows native interop. Testing was limited:

• The original upstream change was validated with an MSIX bundle.
• Local tests were not run on the release-branch backport. It relied on continuous integration (CI), and 36 checks passed before the merge.
• An automated Copilot review flagged that the backport had no release-branch validation of three cases: MSIX execution-alias resolution, startup outside a package, and fallback when the native API isn't available. A maintainer then approved it as a faithful backport with no blocking issues.

What this means for you: If you installed PowerShell from the Store or MSIX bundle and have had PATH or execution-alias problems at startup, this fix is aimed at your setup. It does not claim to fix every PATH problem. If you use the MSI or ZIP packages, it probably won't change anything for you.

2. A warning for SHA-1 file catalogs​

New-FileCatalog and Test-FileCatalog now warn you when you create or validate a legacy SHA-1 catalog. The backport PR (#28311) says the warning recommends regenerating the catalog with -CatalogVersion 2. It also says generation and validation of old catalogs remain supported for compatibility, and hashing and validation behavior are unchanged.

So SHA-1 catalogs have not been removed, and your existing catalogs are not upgraded automatically. You'll just see a warning that you should migrate them.

The warning text itself went through a correction. A reviewer pointed out that the draft message wrongly mentioned "SHA0." The same release includes a separate fix to the WeakCatalogHashAlgorithm resource string (#28334). Because the wording changed, scripts shouldn't match on the exact message text. Treat the warning as advice, not as a stable string to test against.

To regenerate a catalog with the stronger format (SHA-256-based):

1. Check that you're on 7.6.10 by running $PSVersionTable.PSVersion.
2. Regenerate the catalog: New-FileCatalog -Path <folder> -CatalogFilePath <file.cat> -CatalogVersion 2.
3. Validate it with Test-FileCatalog -Path <folder> -CatalogFilePath <file.cat>. You should get a Valid result and no SHA-1 warning.
4. If a signing process uses that catalog, re-sign the new file.

3. Test-Json with List output returns all errors​

The release notes say Test-Json now returns all errors when you use the List output format (#28273). The notes don't describe exactly how the old output differed. If your scripts or pipelines read validation errors from Test-Json -OutputFormat List, check them after upgrading, because they may now receive errors they never saw before.

4. MSIX won't update while PowerShell 7 is running​

The packaging changes update the Appx manifest so the package can't be updated while PowerShell 7 is running (#28319). This applies only to the Store/MSIX package. The notes don't say how a running session is handled, so don't assume either way. On machines that rely on Store updates, an always-open pwsh session could delay the update until you close it.

Build and pipeline changes​

The rest of the changelog is mostly internal:

• CI tests now run on a pinned Ubuntu 24.04 image. This affects testing only, not the list of supported operating systems.
• Fixed feed credentials for module-only vPack builds, added the ability to consume PowerShell modules from an internal feed, and installed Az.Storage for release-publishing jobs.
• Several localization check-ins, plus Store version metadata moved to the English description.
• GitHub Actions dependency updates, including CodeQL components to 4.39.1, actions/upload-artifact 7.0.1 → 7.0.2, and OSSF Scorecard 2.4.4 → 2.5.0.

None of these is a user-facing feature. The release notes list no CVE (security advisory number), so this should not be treated as an emergency security update.

Downloads and checksum verification​

The release has 39 assets:

The release page publishes a SHA-256 hash for every file. On Windows, run Get-FileHash .\PowerShell-7.6.10-win-x64.msi -Algorithm SHA256 and compare the result with the hash listed for that exact file. Files marked "fxdependent" need a matching .NET runtime already installed, so most people should use the self-contained packages.

Bottom line​

PowerShell 7.6.10 is a small update with good timing:

• On 7.4 or 7.5? Today is the last day of support. Move to 7.6.10.
• On 7.6.9 or earlier 7.6? Upgrade so you stay on the one supported 7.6 build. Most changes are internal, but the MSIX and Test-Json fixes are real.
• Using the MSIX/Store package? You get the PATH detection fix and the new rule against updating while pwsh is running.
• Signing modules with file catalogs? Expect the SHA-1 warning, and plan to regenerate catalogs with -CatalogVersion 2.

LTS updates are meant to be uneventful, and this one mostly is, aside from the deadline for older versions landing on the same day.