ls is a PowerShell alias for Get-ChildItem, so it emits objects rather than text. Before findstr.exe receives those objects, PowerShell formats them as text and encodes that text for a native program. The mojibake indicates that the encoding PowerShell writes and the code page findstr reads do not agree.

The most reliable fix is to keep this operation in PowerShell and filter the file-name property directly:

Get-ChildItem | Where-Object Name -match 'win32'

# Include a PowerShell-generated sequence number if needed
$line = 0
Get-ChildItem | Where-Object Name -match 'win32' | ForEach-Object {
    $line++
    '{0}:{1}' -f $line, $_
}

If the intent is specifically to test native findstr, make the encoding used for native stdin match the console input encoding for that session:

$OutputEncoding = [Console]::InputEncoding
Get-ChildItem | findstr.exe /N /L "win32"

That session-wide setting can affect other native tools, so property-based PowerShell filtering is preferable here. Microsoft documents that $OutputEncoding controls how PowerShell communicates with native applications and recommends aligning it with [Console]::InputEncoding: https://learn.microsoft.com/powershell/module/microsoft.powershell.core/about/about_preference_variables#outputencoding