Hello, I have noticed some strange behavior with Powershell when run in a remote session, it seems as if there is a memory leak with write-progress when run in a remote session.

Take the following code for example:

$MaxVal = 10000000

for ($x=1;$x -le $MaxVal;$x++)
{
Write-Progress -Activity "Writing a progress event" -PercentComplete ($x / $MaxVal * 100) -Status "$($x / $MaxVal * 100)% complete"
}

If I run this locally, powershell.exe runs normally and does not take up much memory.

However, if I run it on the same computer from a remote session (as in, I do an enter-psesssion -computername computer).

The memory on powershell.exe keeps going up until it eventually crashes the process.

Is there something I am doing wrong or is this a bug within powershell? I noticed it because I have a long running script that I use write-progress in and it was running fine whenever it runs locally, but calling it in a powershell session kept hanging the script and it would never complete. If I just remove all the calls to write-progress from the script, it runs fine in a remote session.

Hi there

I've never used the powershell very much. Today I discovered this graphical bug in the rendering of the console text output:
https://i.imgur.com/H40F15W.png
This bug was very confusing at first. Then it just kept getting more irritating.
The bug appears when I scroll up and down, at the bottom of the window. Sometimes text gets cut off at the sides too, but only if I change the window width.
I think I remember I had similiar issues years ago on a different computer.

I couldn't find anything related on google. Maybe I used the wrong search terms?

Although totally unrelated: Please unblock icw-mss setting in tcp for atleast one profile. (Doesn't hurt to keep pressing this)

I've tried putting my commands in an exe module, but could not get this module loaded in PowerShell.

1) If I try to load my module as-is, e.g. an .exe file I get "The extension '.exe' is not a valid module extension. "

2) If I create a .psd1 manifest and put RootModule = 'MyModule.exe' there I get Object reference not set to an instance of an object.
at Microsoft.PowerShell.Commands.ModuleCmdletBase.LoadModuleNamedInManifest(PSModuleInfo parentModule, ModuleSpecification moduleSpecification, String moduleBase, Boolean searchModulePath, String prefix, SessionState ss, ImportModuleOptions options, ManifestProcessingFlags manifestProcessingFlags, Boolean loadTypesFiles, Boolean loadFormatFiles, Object privateData, Boolean& found, String shortModuleName, Nullable`1 manifestLanguageMode)
at Microsoft.PowerShell.Commands.ModuleCmdletBase.LoadModuleManifest(String moduleManifestPath, ExternalScriptInfo manifestScriptInfo, Hashtable data, Hashtable localizedData, ManifestProcessingFlags manifestProcessingFlags, Version minimumVersion, Version maximumVersion, Version requiredVersion, Nullable`1 requiredModuleGuid, ImportModuleOptions& options, Boolean& containedErrors)
at Microsoft.PowerShell.Commands.ModuleCmdletBase.LoadModule(PSModuleInfo parentModule, String fileName, String moduleBase, String prefix, SessionState ss, Object privateData, ImportModuleOptions& options, ManifestProcessingFlags manifestProcessingFlags, Boolean& found, Boolean& moduleFileFound)
at Microsoft.PowerShell.Commands.ImportModuleCommand.ImportModule_LocallyViaName(ImportModuleOptions importModuleOptions, String name)
at Microsoft.PowerShell.Commands.ImportModuleCommand.ProcessRecord()
at System.Management.Automation.CommandProcessor.ProcessRecord()

Only Parallel, Queue, and IgnoreNew are supported right now. One would expect that the option available from the Task Scheduler GUI would be available in the powershell interface.

Steps to reproduce

$a = New-ScheduledTaskSettingsSet -MultipleInstances StopExisting

Expected behavior

The task's multiple instances policy is set to kill existing tasks before starting another instance.
Actual behavior

value "StopExisting" to type "Microsoft.PowerShell.Cmdletization.GeneratedTypes.ScheduledTask.MultipleInstancesEnum".
Error: "Unable to match the identifier name StopExisting to a valid enumerator name. Specify one of the following
enumerator names and try again:
Parallel, Queue, IgnoreNew"
At line:1 char:131
+ ... ngOnBatteries -ExecutionTimeLimit $b -MultipleInstances StopExisting
+ ~~~~~~~~~~~~
+ CategoryInfo : InvalidData: (:) [New-ScheduledTaskSettingsSet], ParameterBindingArgumentTransformationE
xception
+ FullyQualifiedErrorId : ParameterArgumentTransformationError,New-ScheduledTaskSettingsSet

According to this question on stackoverflow, it has been reported, but Microsoft Connect no longer is alive, so I couldn't follow the bug. Google searching powershell bug report brought me here, not sure if it's the right place though.

When passing a hashtable to a function parameter that expects a PSCustomObject, PowerShell does not fully convert the hashtable to a PSCustomObject type.

function Test-1 {
param(
[PSCustomObject] $Foo
)

Write-Host "`$Foo's type is: $( $Foo.GetType().Name )" -Fore Green
Write-Host "`$Foo is a PSCustomObject: $( $Foo -is [PSCustomObject] )" -Fore Green
Write-Host "`$Foo has these properties:" -Fore Green

foreach ($prop in ($Foo | Get-Member -MemberType NoteProperty| Select -ExpandProperty Name))
{
Write-Host "`t$prop" -Fore Green
}
}

PS C:\Users\dabelc> Test-1 -Foo ( @{ "CustomProp" = "Value" } )
$Foo's type is: Hashtable
$Foo is a PSCustomObject: True
$Foo has these properties:

PS C:\Users\dabelc> Test-1 -Foo ( [PSCustomObject] @{ "CustomProp" = "Value" } )
$Foo's type is: PSCustomObject
$Foo is a PSCustomObject: True
$Foo has these properties:
CustomProp

[Environment]

Name Value
---- -----
PSVersion 5.1.16299.15
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.16299.15
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1

[Bug]

Consider this code:

[int]$end = 100
[double]$Increment = 0.1

1..$End | Foreach-Object {[double]$t += $Increment ; "$_ $t"}

I'd expect the output always to give the line number and the current total, but look what happens at lines 60 and 101:

>54 5.4
>55 5.5
>56 5.6
>57 5.7
>58 5.8
>59 5.9
>60 5.99999999999999
>61 6.09999999999999
>62 6.19999999999999
>63 6.29999999999999
>64 6.39999999999999
>65 6.49999999999999
....
96 9.59999999999998
97 9.69999999999998
98 9.79999999999998
99 9.89999999999998
100 9.99999999999998
101 10.1
102 10.2
103 10.3
104 10.4
105 10.5

This behaviour seems to repeat over larger ranges and for different values of $Increment. The lines on which the problems occur vary according to the $Increment.

A colleague can repro this in the same environment (PSVersion 5.1.16299.15). Anyone else?

SCENARIO
On Machine1:
SCHTASKS /Create /RU SYSTEM /SC ONSTART /TN "Map I drive" /TR "net use I: \\someServer\someShare somePassword /user:someDomain\someUser"

On Machine2 run:
$Script = { Write-Output "Hello world!" }
Invoke-Command -ComputerName Machine1 -ScriptBlock $Script

As a result you get "Hello world!" but also an error
"Attempting to perform the InitializeDefaultDrives operation on the 'FileSystem' provider failed."

The error belongs to I drive which should have been returned as a warning and not error. The invoke does not even use the I drive so why fail on it (we in this case dont even want the invoke to have access to the I drive why using credssp is not a solution)

OUR REQUEST
Dont return FileSystem errors (for at least network drives) as errors, but warning/Information.

COMMENT
The command runs perfect locally on Machine1 and can list drives with [System.IO.DriveInfo]::getdrives() which shows the I drive is not ready from remote (and we dont want it to be either).