Get-WinUserLanguageList cmdlet fails

Now that I’m using a Windows 10 laptop for working from home, I decided to try using PowerShell Core and discovered the following error when attempting to run the Get-WinUserLanguageList cmdlet. I’m not a programmer (mostly a GNU/Linux sysadmin) and I was never particularly proficient at PowerShell but this looks like C#/.NET error.

The Get-WinUserLanguageList cmdlet is provided by the International module which is listed as being compatible with Core, Desktop. The cmdlet works in Windows PowerShell 5.1 and not in PowerShell Core 7.1 so I hope I’m reporting this bug to the right place. If not, let me know where I should report this and if so, I hope I’ve provided enough relevant information.

Steps to reproduce

Invoke the following cmdlet:

Get-WinUserLanguageList

Expected behaviour

Windows PowerShell 5.1 on the same machine returns details of the language list for the current user account:

> Get-WinUserLanguageList -Verbose

LanguageTag     : en-IE
Autonym         : English (Ireland)
EnglishName     : English
LocalizedName   : English (Ireland)
ScriptName      : Latin
InputMethodTips : {1809:00000809, 1809:00001809}
Spellchecking   : True
Handwriting     : False

Actual behaviour

> Get-WinUserLanguageList -Debug
Get-WinUserLanguageList: Cannot marshal 'parameter #2': Invalid managed/unmanaged type combination.

Environment data

> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      7.1.0-rc.2
PSEdition                      Core
GitCommitId                    7.1.0-rc.2
OS                             Microsoft Windows 10.0.18363
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0


> Get-Command Get-WinUserLanguageList

CommandType     Name                                               Version    Source
-----------     ----                                               -------    ------
Cmdlet          Get-WinUserLanguageList                            2.0.0.0    International


> (Get-Command Get-WinUserLanguageList).Source | Get-Module | Format-List -Property *

LogPipelineExecutionDetails : False
Name                        : International
Path                        : C:\Windows\system32\WindowsPowerShell\v1.0\Modules\International\International.psd1
ImplementingAssembly        :
Definition                  :
Description                 :
Guid                        : 561544e6-3a83-4d24-b140-78ad771eaf10
HelpInfoUri                 : https://go.microsoft.com/fwlink/?linkid=285548
ModuleBase                  : C:\Windows\system32\WindowsPowerShell\v1.0\Modules\International
PrivateData                 :
ExperimentalFeatures        : {}
Tags                        : {}
ProjectUri                  :
IconUri                     :
LicenseUri                  :
ReleaseNotes                :
RepositorySourceLocation    :
Version                     : 2.0.0.0
ModuleType                  : Manifest
Author                      : Microsoft Corporation
AccessMode                  : ReadWrite
ClrVersion                  : 4.0
CompanyName                 : Microsoft Corporation
Copyright                   : © Microsoft Corporation. All rights reserved.
DotNetFrameworkVersion      :
ExportedFunctions           : {}
Prefix                      :
ExportedCmdlets             : {[Get-WinAcceptLanguageFromLanguageListOptOut, Get-WinAcceptLanguageFromLanguageListOptOut], [Get-WinCultureFromLanguageListOptOut, Get-WinCultureFromLanguageListOptOut],
                              [Get-WinDefaultInputMethodOverride, Get-WinDefaultInputMethodOverride], [Get-WinHomeLocation, Get-WinHomeLocation]…}
ExportedCommands            : {[Get-WinAcceptLanguageFromLanguageListOptOut, Get-WinAcceptLanguageFromLanguageListOptOut], [Get-WinCultureFromLanguageListOptOut, Get-WinCultureFromLanguageListOptOut],
                              [Get-WinDefaultInputMethodOverride, Get-WinDefaultInputMethodOverride], [Get-WinHomeLocation, Get-WinHomeLocation]…}
FileList                    : {}
CompatiblePSEditions        : {Core, Desktop}
ModuleList                  : {}
NestedModules               : {Microsoft.InternationalSettings.Commands}
PowerShellHostName          :
PowerShellHostVersion       :
PowerShellVersion           : 5.1
ProcessorArchitecture       : None
Scripts                     : {}
RequiredAssemblies          : {}
RequiredModules             : {}
RootModule                  :
ExportedVariables           : {}
ExportedAliases             : {}
ExportedDscResources        : {}
SessionState                : System.Management.Automation.SessionState
OnRemove                    :
ExportedFormatFiles         : {}
ExportedTypeFiles           : {}

[anmenaga]

Pwsh 7 is seeing this as Core compatible (i.e. it is Not using compatibility solution to load it) because the module is incorrectly declares itself as Core-compatible. It has CompatiblePSEditions=@("Core","Desktop") in psd1 file. It is wrong. It should be CompatiblePSEditions=@("Desktop") if the module is known to be Not working in PS Core. Please note Unless the module manifest indicates that module is compatible with PowerShell Core... in this quote from About Windows PowerShell compatibility:

LONG DESCRIPTION
Unless the module manifest indicates that module is compatible with PowerShell Core,
modules in the %windir%\system32\WindowsPowerShell\v1.0\Modules folder
are loaded in a background Windows PowerShell 5.1 process
by Windows PowerShell Compatibility feature.

So at high level the process is: When -UseWindowsPowerShell parameter is used - user’s intent is perfectly clear, so compatibility solution is used immediately to load the module (regardless of what module manifest says about module compatibility). When -UseWindowsPowerShell parameter is Not specified, PS will first check module manifest. If it finds Core value in CompatiblePSEditions then PS will load the module directly, if the value is not there - it will use compatibility solution to load it.

[anthony-geoghegan]

Thanks, @kvprasoon I wasn’t aware of the -UseWindowsPowerShell option or Windows PowerShell Compatibility

@iSazonov I’ve used the Feedback Hub (that comes with Windows 10) to report this problem, under the Input and Language category, including a link to this GitHub issue.