Description

liushuang (shuangxue520)

opened on Jun 3, 2026

Issue body actions

Summary

The array-subexpression operator itself throws System.ArgumentException: Argument types do not match when it wraps a System.Collections.Generic.List[object] created by New-Object.

UI Automation, ConvertTo-Json, and the original $pair[1] access are not required. They only made the issue visible in the original application.

Minimal reproduction

$list = New-Object System.Collections.Generic.List[object]
@($list)

The list can be empty.

Actual output

OperationStopped: Argument types do not match

Expected output

@($list) should not throw and should behave consistently with the same public .NET type created with its constructor. In the tested environment, the constructor-created empty list produces an empty object[]:

$list = [System.Collections.Generic.List[object]]::new()
@($list) # succeeds

Comparison

function Test-Case($name, [scriptblock]$body) {
    try {
        & $body | Out-Null
        $name + ': OK'
    }
    catch {
        $name + ': FAIL - ' + $_.Exception.Message
    }
}

$newObjectList = New-Object System.Collections.Generic.List[object]
$constructorList = [System.Collections.Generic.List[object]]::new()

Test-Case 'New-Object + @()' { @($newObjectList) }
Test-Case 'constructor + @()' { @($constructorList) }
Test-Case 'New-Object + [array]' { [array]$newObjectList }
Test-Case 'New-Object + ToArray' { $newObjectList.ToArray() }

Observed:

New-Object + @(): FAIL - Argument types do not match
constructor + @(): OK
New-Object + [array]: OK
New-Object + ToArray: OK

Both values report the same public types:

GetType():                         System.Collections.Generic.List[System.Object]
PSObject.BaseObject type:          System.Collections.Generic.List[System.Object]
PSObject.ImmediateBaseObject type: System.Collections.Generic.List[System.Object]

The failure is specific in the tested matrix:

Construction/type	@(...)
New-Object List[object]	FAIL
[List[object]]::new()	OK
New-Object List[string]	OK
New-Object List[int]	OK
New-Object ArrayList	OK
New-Object Queue[object]	OK

Stack trace

The exception occurs while evaluating @($list), before any JSON serialization. The top stack frames are:

at System.Linq.Expressions.Expression.Condition(...)
at System.Management.Automation.Language.PSEnumerableBinder.MaybeDebase(...)
at System.Management.Automation.Language.PSToObjectArrayBinder.Bind(...)

Workarounds

$list = [System.Collections.Generic.List[object]]::new()
[array]$list
$list.ToArray()

In the original application, removing the unnecessary array-subexpression also avoids the failure:

- controls = @($pair[1])
+ controls = $pair[1]

Environment

Reproduced on:

• PowerShell 7.6.3 on Windows 11 10.0.26200
• Windows PowerShell 5.1.26100.8655 on the same machine

The original report attributed the failure to UI Automation-derived hashtables and ConvertTo-Json. Further reduction after reviewer feedback shows that neither is required.

Related issues

• PowerShell #5579: implicit PSObject wrapping and serialization behavior
• PowerShell #4280 and PR #4296: earlier work on array-subexpression behavior and List[object]

Activity

1. SeeminglyScience commented on Jun 3, 2026

   

   Patrick Meinecke (SeeminglyScience)

   on Jun 3, 2026

   Contributor

   More actions

   A minimal reproduction script is attached below.

   I don't see one, but please provide repro steps inline, and ideally the minimum required to repro
2. iRon7 commented on Jun 5, 2026

   

   iRon7

   on Jun 5, 2026

   More actions

   Or show us what exactly is in the $pair object:

   Install-Module -Name ObjectGraphTools
   $pair | ConvertTo-Expression -LanguageMode full
3. TAO92996my commented on Jun 7, 2026

   

   Cheah Poh Yuen (TAO92996my)

   on Jun 7, 2026

   More actions

   Null / TAO92996MY
4. liushuang (shuangxue520)

   changed the title [-]ConvertTo-Json throws "Argument types do not match" for @() wrapping List[object] containing UIA-derived hashtables[/-] [+]Array subexpression @($list) throws "Argument types do not match" for List[object] created by New-Object[/+] on Jul 12, 2026
5. shuangxue520 commented on Jul 12, 2026

   

   liushuang (shuangxue520)

   on Jul 12, 2026

   Author

   More actions

   Thanks Patrick Meinecke (@SeeminglyScience) and iRon7, and sorry that the original report was unclear. I went back and tried to reduce it further.

   It turns out that $pair, UI Automation, and ConvertTo-Json are not needed. This reproduces the error by itself, even though the list is empty:

   $list = New-Object System.Collections.Generic.List[object]
   @($list)

   Creating the same public type with [System.Collections.Generic.List[object]]::new() does not throw. I updated the issue body with the exact output, a few comparison cases, and the top of the stack trace.

   I am still learning PowerShell and I am not sure what internal difference New-Object introduces here. Please let me know if there is any other information I should collect, or if I have misunderstood something.

   Reacted by Michael Klement and Patrick Meinecke
6. mklement0 commented on Jul 12, 2026

   

   Michael Klement (mklement0)

   on Jul 12, 2026

   Contributor

   More actions

   It comes down to binary cmdlets such as New-Object emitting [psobject]-wrapped objects (verify with $list -is [psobject]; by contrast, calling the ::new() method does not do that).

   It is yet another example of such meant-to-be-invisible [psobject] wrappers causing problems; see:

   • Objects are situationally invisibly [psobject]-wrapped, sometimes causing unexpected behavior. #5579

   A simple way to demonstrate the problem:

   # OK - no [psobject] wrapper
   $list = [System.Collections.Generic.List[object]]::new(); @($list)
   
   # BROKEN - [psobject] wrapper, as implicitly emitted by New-Object
   $list = [System.Collections.Generic.List[object]]::new(); @([psobject] $list)

   Reacted by liushuang, iRon7 and Patrick Meinecke
7. liushuang (shuangxue520)

   closed this as completedon Jul 13, 2026
8. mklement0 commented on Jul 13, 2026

   

   Michael Klement (mklement0)

   on Jul 13, 2026

   Contributor

   More actions

   liushuang (@shuangxue520), I recommend keeping this issue open, as it calls for a fix to a specific scenario; #5579 is just a meta issue that tries to keep track of the various specific issues.
9. liushuang (shuangxue520)

   reopened this on Jul 13, 2026
10. shuangxue520 commented on Jul 13, 2026

    

    liushuang (shuangxue520)

    on Jul 13, 2026

    Author

    More actions

    @shuangxue520, I recommend keeping this issue open, as it calls for a fix to a specific scenario; #5579 is just a meta issue that tries to keep track of the various specific issues.

    Reopened — thanks for the suggestion! I wasn't sure whether to keep it open since it's related to #5579.

    Reacted by Michael Klement

Issue actions