Bug with set-location/cd/pushd command

[p0W3RH311]

Bug with set-location/cd/pushd command

step to reproduce

PS C:\Windows\System32> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      7.0.0
PSEdition                      Core
GitCommitId                    7.0.0
OS                             Microsoft Windows 6.3.9600
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0


PS C:\Windows\System32> cd /
PS C:\Windows\System32> # work as expected
PS C:\> cd .\Windows\System32\

PS C:\Windows\System32> # ..but if i ran get-wmiobject...
PS C:\Windows\System32> get-wmiobject win32_Bios

SMBIOSBIOSVersion : xxxx
Manufacturer      : xxxx
Name              : xxxxx
SerialNumber      : xxxxx
Version           : xxxxx


PS C:\Windows\System32> # ... to work with Windows Powershell modules set-location/cd/pushd command's don't work as expected 
PS C:\Windows\System32> cd /
PS C:\Windows\System32> cd \
PS C:\Windows\System32> Set-Location c:
PS C:\Windows\System32> Set-Location /
PS C:\Windows\System32> Set-Location \
PS C:\Windows\System32> pushd \
PS C:\Windows\System32> pushd /
PS C:\Windows\System32>

[mklement0]

The fact that you ran get-wmiobject win32_Bios implies that you're using Windows PowerShell, so please report the issue in the Windows PowerShell UserVoice forum, as suggested in the issue template.

If something similar happened with Get-CimInstance in PS Core, that would be good to know, but I can't even reproduce your problem in Windows PowerShell.

Generally, please include details about your environment in your bug reports, and describe, specifically, how the observed behavior differs from what you expected, as suggested in the issue template.

[p0W3RH311]

The fact that you ran get-wmiobject win32_Bios implies that you're using Windows PowerShell, so please report the issue in the Windows PowerShell UserVoice forum, as suggested in the issue template.

If something similar happened with Get-CimInstance in PS Core, that would be good to know, but I can't even reproduce your problem in Windows PowerShell.

Generally, please include details about your environment in your bug reports, and describe, specifically, how the observed behavior differs from what you expected, as suggested in the issue template.

with windows 8.1 and
i using powershell7.0 and when i use get-wmiobject . set-location/cd/pushd dont work as expected...

[mklement0]

I apologize, @p0W3RH311: I missed that environment information was indeed present in your report - the fact that it wasn't where I expected it to be - in the "Environment data " section at the bottom - made me miss that.
That is one good reason to follow the guidance of the issue template.

[mklement0]

So now that we know that you're indeed on PowerShell 7, tell us:

• What did you have to do to make Get-WmiObject available in your session? Even if I explicitly import the WMI cmdlets via the compatibility layer (Import-Module Microsoft.PowerShell.Management -UseWindowsPowerShell, which is probably not a good idea, given PS Core has its own version of that module), I can't invoke it.

  • For context, please explain why you need to use a cmdlet that was superseded by Get-CimInstance in Windows PowerShell 3.0 (2012). (Of course, if it can be invoked, it shouldn't cause subsequent commands to malfunction; but perhaps the answer is to simply disallow use of Get-WmiObject).

  • Does it also happen with Get-CimInstance win32_Bios (I don't see a problem)?

• How do set-location/cd/pushd not work as expected?

[vexx32]

@mklement0 we've seen this before. Essentially it seems like if you call Get-WmiObject in PS7, currently it uses the Windows PowerShell compatibility remoting session to load the relevant Windows PowerShell module.

It also (erroneously) clobbers the already imported or otherwise available cmdlets from the PS7 module like Get-Location / Get-ChildItem / etc which are shadowed by the auto-generated functions that operate with the compatibility remoting.

As a result, we get some rather broken behaviour. I think @PaulHigin was notified and may be working on a fix.

Functionally speaking, this is a duplicate of #12014 🙂

[mklement0]

I appreciate the clarification and the pointers, @vexx32.

For my own edification:

Even though I do not have implicit WinPS compatibility turned off in my $PSHOME/powershellconfig.json, my sessions do not see the Get-WmiObject command on my PowerShell 7.0, Microsoft Windows 10 Pro (64-bit; Version 1909, OS Build: 18363.720) machines.

(By contrast, commands from other implicitly compatibility-loaded modules to seem to work, however, such as Get-TlsEccCurve from the TLS module).

Is this a separate issue, or am I missing something?

[vexx32]

I'm not clear on the exact conditions required to make this happen; I don't typically see it in my own win10 environment either. But it does seem to be happening from time to time, so some quirk of configuration seems to be letting the old winPS modules get loaded when they shouldn't be.

[mklement0]

@vexx32, I dug a little deeper:

As of (at least) Window 10 version 1909, (OS Build: 18363.720), the WinPS C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules\Microsoft.PowerShell.Management module is unexpectedly tagged as Core-compatible (CompatiblePSEditions = @('Desktop','Core')).

Therefore, when you try to run Get-WmiObject, it triggers direct import into a PS Core session, in addition to the PS Core-native Microsoft.PowerShell.Management module.

Ironically, even though the WMI cmdlets are listed in the module's exports, they are seemingly filtered out on import, which is why the Get-WmiObject call then fails, despite the (quiet and automatic) import of its module.

It seems to me that tagging the WinPS Microsoft.PowerShell.Management as PS Core-compatible is a bug - or am I missing something?

[mklement0]

See also: #12043 (comment)

[PaulHigin]

• @anmenaga

[anmenaga]

It seems to me that tagging the WinPS Microsoft.PowerShell.Management as PS Core-compatible is a bug

Yes, it is. It was fixed in Windows code base several weeks ago.