PowerShell 7.X.X Backward Compatibility Issues (Windows 10!)

Prerequisites

• [x] Write a descriptive title.
• [x] Make sure you are able to repro it on the latest released version
• [x] Search the existing issues.
• [x] Refer to the FAQ.
• [x] Refer to Differences between Windows PowerShell 5.1 and PowerShell.

Steps to reproduce

I waited for a long time to write this feedback. It's about the functionality of PowerShell 7.5.0 on a WIN10 Laptop! On my WIN11 24H2 Desktop, everything works perfect.

Last year, in PowerShell 7.4.3 I was busy with importing Modules. from the older PowerShell Versions. Windows Compatibility: importing cmdlets, .psd1 & .psm1 files etcetera. Efforts were 'hopeless'! I was like; "Yeah... Whatever... Nevermind!" A year later, after installing 7.5.0 I thought this issue would be fixed, but unfortunately it wasn't! I could share an audiofile/youtube video with 20+ minutes of troubleshooting, frustration and chat advice by Copilot.

Anyway... This .png file. A screenshot, from yesterday, of the PowerShell History... Recreated in Paint with all the lines and colors will let you capture the essence of this struggle much faster... I also captured the solution to this issue. I believe you're interested. Let me know.

Expected behavior

PS Import-Module -Name Microsoft.PowerShell.Management -PSSession $PSSession -Verbose
Error

Actual behavior

PS $PS Session = New-PSSession -UseWindowsPowerShell

Error details

PS $PSSession (Argument Is Null. Provide a valid value, retry command again.

Environment data

PS

Visuals

No response

Hopefully, this explains this in the shortest way possible. I created my account here Saturday, I'm new to the environment. Ignore the "Expected Behavior," "Actual Behavior," "Error Details," "Environment Data" I created that in a hurry!!!

It's unclear to me what problem you're facing, but I have two observations:

• You should no longer install the now obsolete WindowsCompatibility module in PowerShell 7, because its functionality is now built into PowerShell itself - see the about_Windows_PowerShell_Compatibility help topic (New-PSSession -UseWindowsPowerShell uses the now built-in feature, for instance).

• You shouldn't try to load the built-in Microsoft.PowerShell.Management module via the compatibility feature; the purpose of the feature is to allow you to load external modules that ship with Windows that aren't declared as PowerShell 7-compatible (either because they haven't yet been declared as such, or because they are inherently incompatible).

Installing PowerShell 7.5.0 (ON WINDOWS 10!!!!) does not automatically load all the modules correctly... The same way that my Windows 11 device does!!

• My previous comment implies that it is ill-advised to try to load all modules via the Windows PowerShell Compatibility feature.

• That things change between PowerShell versions (possibly in relation to specific supported platform version) is not in and of itself indication of a problem that needs to be fixed.

Therefore:

• Please explain, specifically, what particular use of the Windows PowerShell Compatibility feature you feel isn't working as intended on your W10 device in PowerShell 7.5.0

That information is all in the .png file. I said it ALL! in my first feedback comment! But it works now with a detour. I wanted to address this issue to developers.

I understand that you think you've provided all the necessary information.

My comments were meant to point out that you didn't.

What your screenshot shows is:

• An ill-advised attempt to import an obsolete module.

• A conceptually broken attempt to bind a parameter via both the pipeline and by argument.

• An unnecessary attempt to use the Windows PowerShell Compatibility feature explicitly:

  • In order to call CheckPoint-Computer, no preparation is needed at all: PowerShell 7 will find this Windows PowerShell-only command by default and implicitly load it via the Windows PowerShell Compatibility feature. In other words: just invoke it.
  • While the Windows PowerShell Compatibility feature in v7.1+ now prevents "clobbering" (overriding) built-in PowerShell 7 cmdlets, Windows PowerShell-only cmdlets such as CheckPoint-Computer - even if stemming from a module that is also a built-in one in PowerShell 7 - are still implicitly imported via the feature.

---

All that said:

• If somebody sees something actionable in your post that I missed, I hope they'll chime in.

• Otherwise, don't be surprised if you'll receive no further responses here.

Certain sources strongly encouraged me to do so... Ain't something incorrect about it.

P.S., @Simon79-626: While GitHub seemingly doesn't prevent promoting one's own posts via emoji, I encourage you to abstain from doing so.

Hey. TBH I'm tired of your comments. But thanks anyway for thinking with me. If these modules were PowerShell 7 built-in cmdlets, I wouldn't have to go through all of this, on Windows 10. Windows 11 installed it correctly. I hoped that they would fix it, so that it works on Windows 10 all the same! In the next PowerShell 7 upgrade! 7.5,1 or whatever! A win-win for all, that's my goal!!! Let them tell me I'm wrong. Can you remove your comments?

TBH I'm tired of your comments.

Unless you have counterarguments, please abstain from such gratuitous comments. If you do have counterarguments (and I know you think you do, but I don't see any), state only them.

But thanks anyway for thinking with me.

Please abstain from - inherently gratuitous - sarcastic comments: they only serve to antagonize, without contributing anything meaningful to the discussion.

so that it works on Windows 10 all the same!

You say it works on Windows 11 but not on Windows 10. That is good.

Windows 10 will soon be out of support in October 2025. Should this project spend effort on supporting an operating system at the end of it's lifespan?

It's not in their interests to accomplish that. Actually, that was a possible scenario, in my mind. Fair enough. Thanks @rhubarb-geek-nz

BUT... (Even though more and more people spent money on Windows 11, Windows 10 STILL is a valid Operating System! And later on... When Windows 12 or later versions will be released on the consumer market, we'll have the same issues for Windows 11?!)

@rhubarb-geek-nz:

Since this issue lacks a clear problem definition, discussing Windows 10 vs. Windows 11 may be premature.

What is clear, however, is that the issue exhibits misconceptions and ill-advised practices; to summarize:

• Use of the obsolete WindowsCompatibility module

• An attempt to load all commands from the built-in Microsoft.PowerShell.Management module via the compatibility feature (which changes the behavior of fundamental cmdlets such as Get-Location).

  • The proper approach is to use Import-Module -UseWindowsPowerShell Microsoft.PowerShell.Management, which by default isn't even necessary, as this command is implicitly performed on first call to a Windows PowerShell-only cmdlet from this module, such as Checkpoint-Computer

  • This sensibly only imports those cmdlets that aren't also present in PowerShell 7 - unlike Import-Module -Name Microsoft.PowerShell.Management -PSSession (New-PSSession -UseWindowsPowerShell), as (in effect) shown in the issue

• The mistaken expectation that you can pipe a session object to Import-Module

• Trying to pass $null to the -PSSession parameter of Import-Module, which predictably fails.

@rhubarb-geek-nz

Now, I'm not here to criticize the codes from databases that mklement0 referred to. At all. They might be functional for other users who troubleshoot it for the first time. But since my PowerShell configuration works perfectly now, with another workaround... I won't have to use those codes, as they can misconfigure/mess up my current configuration for 7.5.0. I can't let that happen!

Fixing the backward compatibility issue for files in C:\Windows\System32\WindowsPowerShell\v1.0\Modules and other folders... That were designed for version 5.1 or earlier. Are not "obsolete" and were worth my time. I don't want to open version 1, ISE or 5.1 to run those commands. No. I wanted them to be functional in 7.5.0 as well. "It's a known limitation due to the architectural differences between .NET Framework and .NET Core (7), .NET Framework relies on APIs or features that are no longer supported in PowerShell 7.x.x," That's why the system didn't recognize them, at first in Windows 10. The last sentence, may sound like a "paradox" saying this. But it makes sense!

• Your screenshot shows only expected behaviors (while doing ill-advised things / using broken commands, as noted).

• As noted, your issue lacks a clear problem description and the screenshot doesn't help. If you expect any action to be taken, you'll have to demonstrate in a reproducible manner that there is a problem.

It is possible that I'm missing something that others won't, but, as a general tip, pushing back against those giving specific feedback and asking for clarification will not help your cause, and your problem - if indeed there is one - may slip through the cracks.

My workaround WORKS! Your workaround (with the compatibility layer) WORKS! [“import-module -UseWindowsPowerShell Microsoft.PowerShell.Management”] @mklement0 I uploaded this feedback to show that it does NOT automatically load those modules in that particular Windows 10 system. It's about the fact that YOU DO HAVE TO USE ONE of the two approaches there. IT DOESN’T MATTER HOW OR WHY!!!

If they, (based on what they analyze) say: “No!! That certain Windows 10 case is NOT in our interests to fix in 7.5.1 or later!” Then that’s my problem, and I will be okay with that! But I don’t think that’s the case here…

Is it true that PowerShell 7.2.24 is the latest version running on Windows 7?

Is it true that PowerShell 7.2.24 is the latest version running on Windows 7?

.NET support for Windows 7 and 8.1 will end in January 2023

They will not be supported with .NET 7+.

PowerShell 7.2.24 was built on .NET SDK 6.0.427.

@rhubarb-geek-nz Sorry, but I don't know how to process your answer. The expected answer here would be "yes" or "no". At present I use PowerShell 7.2.24 on Windows 7 x64, and my question was about whether it was the latest for that platform, not about the support, dates, or SDK with which it was built.

.NET 7+ is not supported on Windows 7 (which itself is no longer supported).

PowerShell 7.2.x is the latest version (itself now no longer supported) that is built on a pre-.NET 7 version, namely .NET 6.

In short: Given that 7.2.24 is the latest and last 7.2.x version, the answer to your question is YES.

Finally, there is a way to run the latest Pwsh on Windows 7.

$ $PSVersionTable
Name                           Value
----                           -----
PSVersion                      7.5.1
PSEdition                      Core
GitCommitId                    7.5.1
OS                             Microsoft Windows 6.1.7601 Service Pack 1
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

Changes to modules that ship in Windows are typically done by their respective teams. Even when we're involved we generally don't have much say in how far back those changes are backported.

The feedback hub is your best bet for reaching the folks who would make that decision. That said, it would be a tough sell given the impending end of support, especially given how long it's been as it is currently.

This issue has been marked as answered and has not had any activity for 1 day. It has been closed for housekeeping purposes.

📣 Hey @@Simon79-626, how did we do? We would love to hear your feedback with the link below! 🗣️

🔗 https://aka.ms/PSRepoFeedback

Microsoft Forms

Changes to modules that ship in Windows are typically done by their respective teams. Even when we're involved we generally don't have much say in how far back those changes are backported.

The feedback hub is your best bet for reaching the folks who would make that decision. That said, it would be a tough sell given the impending end of support, especially given how long it's been as it is currently.

Hi Dude @SeeminglyScience It's not 100% the result I expected. I know it can be exhausting for Microsoft, to read every entry everywhere. But... I won't have to put all the effort in again, to upload it to the Feedback Hub... For this case! I already learned that they are working on newer PowerShell modules, for future software of PowerShell. CimCmdlets will sooner or later replace all the older cmdlets/modules that are outdated/not compatible anymore.

Have a good rest of your day!