Votes from Connect: 3

Original Date Submitted: 5/27/2015 9:24:37 PM

Description:

Contact Information
Handle: _TimPringle
Site Name: PowerShell
Feedback ID: 1373413

Frequency: PowerShell

Regression: Reproduction Steps Example 1

1) Start PowerShell (either as normal or run as administrator)
2) Type Start-Job -VMName, and use tab to parse through other parameters. These are only the common parameters.

Reproduction Steps Example 2

1) Start PowerShell (either as normal or run as administrator)
2) Type get-command start-job -Syntax
3) The output should be similar to below, but the last four lines, which detail the use with the VM parameters, only indicate that the VMName/VMGUID can be used.

Start-Job [-ScriptBlock] <scriptblock> [[-InitializationScript] <scriptblock>] [-Name <string>] [-Credential <pscredential>] [-Authentication <AuthenticationMechanism>] [-RunAs32] [-PSVersion <version>] [-InputObject <psobject>] [-
ArgumentList <Object[]>] [<CommonParameters>]

Start-Job [-DefinitionName] <string> [[-DefinitionPath] <string>] [[-Type] <string>] [<CommonParameters>]

Start-Job [[-InitializationScript] <scriptblock>] -LiteralPath <string> [-Name <string>] [-Credential <pscredential>] [-Authentication <AuthenticationMechanism>] [-RunAs32] [-PSVersion <version>] [-InputObject <psobject>] [-Argumen
tList <Object[]>] [<CommonParameters>]

Start-Job [-FilePath] <string> [[-InitializationScript] <scriptblock>] [-Name <string>] [-Credential <pscredential>] [-Authentication <AuthenticationMechanism>] [-RunAs32] [-PSVersion <version>] [-InputObject <psobject>] [-Argument
List <Object[]>] [<CommonParameters>]

Start-Job [-VMGuid] <guid[]> [<CommonParameters>]

Start-Job [-VMGuid] <guid[]> [<CommonParameters>]

Start-Job -VMName <string[]> [<CommonParameters>]

Start-Job -VMName <string[]> [<CommonParameters>]

Problem Description:
The Start-Job cmdlet when used with either VMName or VMGUID does not work successfully. It only allows you to specify the VMname/VMGUID, but nothing (other than common parameters) after this. A check of the syntax confirms that this is the case.

Product Studio item created by Connect Synchronizer due to creation of feedback ID 1373413 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=1373413).

Repro Steps:

Reproduction Steps Example 1

1) Start PowerShell (either as normal or run as administrator)
2) Type Start-Job -VMName, and use tab to parse through other parameters. These are only the common parameters.

Reproduction Steps Example 2

1) Start PowerShell (either as normal or run as administrator)
2) Type get-command start-job -Syntax
3) The output should be similar to below, but the last four lines, which detail the use with the VM parameters, only indicate that the VMName/VMGUID can be used.

Start-Job [-ScriptBlock] <scriptblock> [[-InitializationScript] <scriptblock>] [-Name <string>] [-Credential <pscredential>] [-Authentication <AuthenticationMechanism>] [-RunAs32] [-PSVersion <version>] [-InputObject <psobject>] [-
ArgumentList <Object[]>] [<CommonParameters>]

Start-Job [-DefinitionName] <string> [[-DefinitionPath] <string>] [[-Type] <string>] [<CommonParameters>]

Start-Job [[-InitializationScript] <scriptblock>] -LiteralPath <string> [-Name <string>] [-Credential <pscredential>] [-Authentication <AuthenticationMechanism>] [-RunAs32] [-PSVersion <version>] [-InputObject <psobject>] [-Argumen
tList <Object[]>] [<CommonParameters>]

Start-Job [-FilePath] <string> [[-InitializationScript] <scriptblock>] [-Name <string>] [-Credential <pscredential>] [-Authentication <AuthenticationMechanism>] [-RunAs32] [-PSVersion <version>] [-InputObject <psobject>] [-Argument
List <Object[]>] [<CommonParameters>]

Start-Job [-VMGuid] <guid[]> [<CommonParameters>]

Start-Job [-VMGuid] <guid[]> [<CommonParameters>]

Start-Job -VMName <string[]> [<CommonParameters>]

Start-Job -VMName <string[]> [<CommonParameters>]

Expected Results:
Would expect similar parameters as the other parameter sets, such as Credential, File, ScriptBlock.
At present the vm options for start-job cannot do anything.

Internal BugId: 14518

Votes from Connect: 66

Original Date Submitted: 5/27/2015 8:46:16 AM

Description:
Contact Information
Handle: Frank E Lesniak
Site Name: PowerShell
Feedback ID: 1371736

Frequency: PowerShell
Regression: 1. Visit: https://gist.github.com/anonymous/572f42ba0ea7eec4f721#file-psclassreproreduced11-ps1
2. Click the "Raw" button. Copy the code to the clipboard
3. Open Notepad and paste the code from the clipboard. Save the file somewhere with file name: animal.ps1
(don't forget to change the file type to "All Files")
4. Execute the script using PowerShell.

Problem Description:
I have a stock PowerShell template that I use as a starting point for many scripts; its code is used throughout my organization. After patching a number of systems, I discovered that this known-good code has stopped working. A script that would normally take a brief moment to execute now hangs / freezes the PowerShell window with high CPU utilization.

After doing extensive testing, I have determined that installing KB3000850 consistently causes this bug to appear in Windows 8.1 or Windows Server 2012 R2.

I have taken the time to reduce the thousands of lines of template code down to simple code to reproduce the problem. The code to reproduce is still ~50 lines, but cutting out any additional code seems to break the ability to reproduce the problem.

Repro code:
https://gist.github.com/anonymous/572f42ba0ea7eec4f721#file-psclassreproreduced11-ps1

Impact of this is high; our automation is essentially dead in the water.

FYI: this issue is also occurring on Windows 10. See privately submitted Connect bug with ID 1122637.

Product Studio item created by Connect Synchronizer due to creation of feedback ID 1371736 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=1371736).

Repro Steps:
1. Visit: https://gist.github.com/anonymous/572f42ba0ea7eec4f721#file-psclassreproreduced11-ps1
2. Click the "Raw" button. Copy the code to the clipboard
3. Open Notepad and paste the code from the clipboard. Save the file somewhere with file name: animal.ps1
(don't forget to change the file type to "All Files")
4. Execute the script using PowerShell.

Expected Results:
The script should complete instantly with no output

Internal BugId: 14516

Votes from Connect: 4

Original Date Submitted: 5/21/2015 8:59:29 PM

Description:
Contact Information
Handle: Thomas Lee
Site Name: PowerShell
Feedback ID: 1353410

Problem Description:
-? is a great parameter for all cmdlets as it does a basic get-help. That's fine, but it would be nice to extend it as follows:

Switch What it does
-?F Equivalent of Get-Help -FULL
-?D Equivalent of Get-Help -Detailed
-?E Equivalent of Get-Help -Example
-?o Equivalent of Get-Help -Online

The idea is to make it simlpler to get help for a cmdlet/function.

Product Studio item created by Connect Synchronizer due to creation of feedback ID 1353410 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=1353410).

Repro Steps:

Internal BugId: 14503

Votes from Connect: 9

Original Date Submitted: 5/20/2015 3:14:12 PM

Description:
Contact Information
Handle: Joachim Meyer
Site Name: PowerShell
Feedback ID: 1349420

Frequency: PowerShell
Regression:

Problem Description:
I guess that classifies more as a design flaw than a bug. Netstat.exe has the option -o that displays the owning Process ID for each connection. Get-NetTCPConnection should also add a property for the Process ID. Without the Process ID the Cmdlet is pretty useless (at least for me) and does not replace netstat.exe. (The underlying WMI class MSFT_NetTCPConnection does not include that property, too, so in this case additional code and a synthetic property probably needs to be added.)

Product Studio item created by Connect Synchronizer due to creation of feedback ID 1349420 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=1349420).

Repro Steps:
Expected Results:

Internal BugId: 14496

Votes from Connect: 7

Original Date Submitted: 5/19/2015 2:43:00 AM

Description:
Contact Information
Handle: Trevor Sullivan [MVP]
Site Name: PowerShell
Feedback ID: 1345058

Frequency: PowerShell
Regression: class BaconStrip {

[string] $Length;

[string] $Width;


[ValidateSet('Cooked', 'Raw')]

[string] $Status;

[ValidateSet('Regular', 'Applewood', 'Smoked')]

[string] $Type;

BaconStrip([string] $Type) {

    $this.Type = $Type;

}

[void] Cook() {

    $this.Status = 'Cooked';

}

}

Create a new BaconStrip instance with an invalid type

$MyBaconStrip = [BaconStrip]::new('Regular2');

This variable should be $null if an exception is thrown in the constructor

$MyBaconStrip;

Problem Description:
In April 2015 Preview of WMF 5.0 (version: 5.0.10105.0), when you construct a PowerShell class, and attempt to instantiate it using the New() constructor method, if an exception is thrown, the object is returned in an inconsistent state.

Product Studio item created by Connect Synchronizer due to creation of feedback ID 1345058 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=1345058).

Repro Steps:
class BaconStrip {

[string] $Length;

[string] $Width;


[ValidateSet('Cooked', 'Raw')]

[string] $Status;

[ValidateSet('Regular', 'Applewood', 'Smoked')]

[string] $Type;

BaconStrip([string] $Type) {

    $this.Type = $Type;

}

[void] Cook() {

    $this.Status = 'Cooked';

}

}

Create a new BaconStrip instance with an invalid type

$MyBaconStrip = [BaconStrip]::new('Regular2');

This variable should be $null if an exception is thrown in the constructor

$MyBaconStrip;

Expected Results:
If an exception is thrown in a PowerShell class constructor, the object should not be instantiated.

Internal BugId: 14483

Votes from Connect: 3

Original Date Submitted: 5/18/2015 2:02:46 AM

Description:
Contact Information
Handle: Sergey Teplyakov
Site Name: PowerShell
Feedback ID: 1341920

Frequency: PowerShell
Regression:

Problem Description:
PowerShell uses copy-on-write semantic for inner scopes.

This means that if you'll change outer variable in the inner scope then inner scope would deal with it's own copy. Here is an example:

$list = @(1, 2)

Function Foo
{
"Foo: initial value - $list"
$list = $list + 3
"Foo: $list: $list,$global:list: $global:list"

}
The output would be:

Foo: initial value - 1 2
Foo: $list: 1 2 3, $global:list: 1 2
Ok, this behavior is by design. But lets change Foo function a bit:

Function Foo
{
"Foo: initial value - $list"
$list += 3
"Foo: $list: $list,$global:list: $global:list"

}
The output would be:

Foo: initial value - 1 2
Foo: $list: 3, $global:list: 1 2

Hm... I can assume that x += y operator is not exactly the same that x = x + y. But that is not exacted. Let's change the code once more:

Function Foo
{
New-Variable -Name z -Value 42
"Foo: initial value - $list"
$list += 3
"Foo: $list: $list,$global:list: $global:list"

}

And now the output would be:

Foo: initial value - 1 2
Foo: $list: 1 2 3, $global:list: 1 2

It seems like a bug. The only question is where exactly? I assume behavior of += in second case is incorrect. But maybe I missing something...

Link to stackoverflow post: http://stackoverflow.com/questions/30290555/powershell-copy-on-write-behavior-depends-on-operator-type

Product Studio item created by Connect Synchronizer due to creation of feedback ID 1341920 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=1341920).

Repro Steps:
Expected Results:

Internal BugId: 14479

Votes from Connect: 3

Original Date Submitted: 5/4/2015 1:20:27 AM

Description:
Contact Information
Handle: David I McIntosh
Site Name: PowerShell
Feedback ID: 1300430

Frequency: PowerShell
Regression: >function emptyArray() { @() }
>$lt = @() ; $lt.Count
0
>$lt1 = @(); $lt1 -eq $null; $lt1.count; $lt1.gettype()
0
IsPublic IsSerial Name BaseType

True True Object[] System.Array

>$lt += $lt1; $lt.Count
0
>$lt += emptyArray; $lt.Count
0
>$lt2 = emptyArray; $lt2 -eq $null; $lt2.Count; $lt2.gettype()
True
0
You cannot call a method on a null-valued expression.
At line:1 char:38
+ $lt2 = emptyArray; $lt2 -eq $null; $lt2.Count; $lt2.gettype()
+ ~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (:) [], RuntimeException
+ FullyQualifiedErrorId : InvokeMethodOnNull
>$lt += $lt2; $lt.Count
0
>$lt3 = $null; $lt3 -eq $null;$lt3.gettype()
True
You cannot call a method on a null-valued expression.
At line:1 char:32
+ $lt3 = $null; $lt3 -eq $null;$lt3.gettype()
+ ~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (:) [], RuntimeException
+ FullyQualifiedErrorId : InvokeMethodOnNull
>$lt += $lt3; $lt.count
1
>function addToArray($la, $lb) { $la += $lb; $la.count }
>$lt = @(); $lt.Count
0
>addToArray $lt $lt1
0
>addToArray $lt $lt2
1

SerializationVersion 1.1.0.1

BuildVersion 6.2.9200.16481

PSVersion 3.0

Problem Description:
When a function returns an empty array (in the pipe) and this is assigned to a variable, it is changed into something that is not quite $null and not quite an empty array. If this variable is subsequently passed in as a parameter to a function, it is further changed into what seems to be truly a $null

Product Studio item created by Connect Synchronizer due to creation of feedback ID 1300430 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=1300430).

Repro Steps:
>function emptyArray() { @() }
>$lt = @() ; $lt.Count
0
>$lt1 = @(); $lt1 -eq $null; $lt1.count; $lt1.gettype()
0
IsPublic IsSerial Name BaseType

True True Object[] System.Array

>$lt += $lt1; $lt.Count
0
>$lt += emptyArray; $lt.Count
0
>$lt2 = emptyArray; $lt2 -eq $null; $lt2.Count; $lt2.gettype()
True
0
You cannot call a method on a null-valued expression.
At line:1 char:38
+ $lt2 = emptyArray; $lt2 -eq $null; $lt2.Count; $lt2.gettype()
+ ~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (:) [], RuntimeException
+ FullyQualifiedErrorId : InvokeMethodOnNull
>$lt += $lt2; $lt.Count
0
>$lt3 = $null; $lt3 -eq $null;$lt3.gettype()
True
You cannot call a method on a null-valued expression.
At line:1 char:32
+ $lt3 = $null; $lt3 -eq $null;$lt3.gettype()
+ ~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (:) [], RuntimeException
+ FullyQualifiedErrorId : InvokeMethodOnNull
>$lt += $lt3; $lt.count
1
>function addToArray($la, $lb) { $la += $lb; $la.count }
>$lt = @(); $lt.Count
0
>addToArray $lt $lt1
0
>addToArray $lt $lt2
1

SerializationVersion 1.1.0.1

BuildVersion 6.2.9200.16481

PSVersion 3.0

Expected Results:
$l_t2 should behave as null or @(), not somewhere inbetween!

Internal BugId: 14438

Votes from Connect: 3

Original Date Submitted: 4/30/2015 2:06:48 PM

Description:
Contact Information
Handle: Holger Froebe
Site Name: PowerShell
Feedback ID: 1290413

Frequency: PowerShell
Regression: Windows 7 SP1 X64 - German
Following release notes:
Checked for all the updates - OK
Powershell 4.0 was installed - OK
Selecting package from MS Download Center:
Windows6.1-KB2908075-x64
Starting the Update-Package gives me the above error.

Maybe a Problem with UI Culture - I work with a german Windows and maybe the Preview is
only applicable to english Windows ?

Problem Description:
Installing Powershell 5.0 on Windows 7 gives me error:
This update is not applicable to your Computer.

Followed release notes:
Checked for all the updates - OK
Powershell 4.0 was installed - OK

Selected the right package from download Center:
Windows6.1-KB2908075-x64

Product Studio item created by Connect Synchronizer due to creation of feedback ID 1290413 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=1290413).

Repro Steps:
Windows 7 SP1 X64 - German
Following release notes:
Checked for all the updates - OK
Powershell 4.0 was installed - OK
Selecting package from MS Download Center:
Windows6.1-KB2908075-x64
Starting the Update-Package gives me the above error.

Maybe a Problem with UI Culture - I work with a german Windows and maybe the Preview is
only applicable to english Windows ?

Expected Results:

Internal BugId: 14422

Votes from Connect: 4

Original Date Submitted: 4/14/2015 8:18:28 AM

Description:
Contact Information
Handle: JasonHorner
Site Name: PowerShell
Feedback ID: 1246396

Problem Description:
often we need to parse a file and not rely on its extension, while magic number parsing is imperfect it can provide some value.
this could be used for general file parsing as well as some security scenarios

Here is a script that implements this feature though I don't think it is completely robust:
http://powershell.com/cs/blogs/tips/archive/2010/08/09/reading-file-quot-magic-number-quot.aspx

unix support a similar capability via the file utility:
http://en.wikipedia.org/wiki/File_%28command%29

More info on magic number parsing:
http://en.wikipedia.org/wiki/Listoffile_signatures

Product Studio item created by Connect Synchronizer due to creation of feedback ID 1246396 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=1246396).

Repro Steps:

Internal BugId: 14377

Votes from Connect: 3

Original Date Submitted: 2/19/2015 11:08:09 PM

Description:

Contact Information
Handle: Rohn Edwards
Site Name: PowerShell
Feedback ID: 1138469

Frequency: Always Happens
Regression: No, this is new to the most recent version

Problem Description:
In the December 2014 and February 2015 WMF 5.0 previews, flags enumerations that have byte, sbyte, short, or ushort underlying types have to be cast or coerced to a numeric type before -band, -bor, or -bxor bitwise operations will work.

int, uint, long, and ulong underlying types still work as expected.

Product Studio item created by Connect Synchronizer due to creation of feedback ID 1138469 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=1138469).

Repro Steps:
First, ensure $PSVersionTable.PSVersion is 5.0.10018.0

To see the error, run this command:
PS> [System.Windows.Input.KeyStates]::Down -band [System.Windows.Input.KeyStates]::Down

KeyStates has an underlying type of 'Byte'. The command works if you modify it like this:
PS> [System.Windows.Input.KeyStates]::Down.value__ -band [System.Windows.Input.KeyStates]::Down

Expected Results:
No errors are expected, like running this command:
It appears that version 5 returns an instance of the enumeration instead of a numeric value (which it looks like previous versions return).

Internal BugId: 13250

Votes from Connect: 5

Original Date Submitted: 2/6/2015 3:54:49 PM

Description:
Contact Information
Handle: edi89
Site Name: PowerShell
Feedback ID: 1117495

Frequency: Always Happens
Regression: I don't know if this issue existed previously

Problem Description:
Using paramter validation in functions works just find - something like this:
function test{

Param (

    [ValidateRange(3,8)]

    [Int] $mytest )


write-host $mytest

}
test 4
test 9
The problem is, that it seems, that parameter validation is in fact just a special case of variable validation which leads to the circumstance, that the variable used (in this case $mytest) is beeing validated every time you use it. Try this:
function test{

Param    (

    [ValidateRange(3,8)]

    [Int] $mytest)


$mytest = $mytest+5

write-host $mytest

}

test 4

It seems to be by design, but the documentation about parameter validation is misleading if not completly wrong, because it says something like:"parameters are validated when you call the function/cmdlet", which simply is not the way it works - the variable is validated everytime you use it.

Product Studio item created by Connect Synchronizer due to creation of feedback ID 1117495 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=1117495).

Repro Steps:
function test{

Param    (

    [ValidateRange(3,8)]

    [Int] $mytest)


$mytest = $mytest+5

write-host $mytest

}

test 4

Expected Results:
test 4
The variable cannot be validated because the value 9 is not a valid value for the mytest variable.
At line:6 char:5
+ $mytest = $mytest+5
+ ~~~~~~~~~~~~~~~~~~~

+ CategoryInfo          : MetadataError: (:) [], ValidationMetadataException

+ FullyQualifiedErrorId : ValidateSetFailure

4

Internal BugId: 13225

Votes from Connect: 3

Original Date Submitted: 1/30/2015 5:06:50 AM

Description:
Contact Information
Handle: Stephen Owen
Site Name: PowerShell
Feedback ID: 1107509

Frequency: Always Happens
Regression: I don

Problem Description:
Now that I've gotten used to ISE-Snippets, I love them and I have a huge selection of them to help me with calculated properties, custom objects, and things like that. I'd love to be able to use ISE-Snippets in the PowerShell console as well.

We can already hit F7 to see a list of the last 40 or so commands in our window. How about adding a similar window for ISE style snippets for our coding reference while in the console?

Product Studio item created by Connect Synchronizer due to creation of feedback ID 1107509 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=1107509).

Repro Steps:
Expected Results:

Internal BugId: 13210

Votes from Connect: 3

Original Date Submitted: 11/7/2014 10:07:44 PM

Description:

Contact Information
Handle: sba
Site Name: PowerShell
Feedback ID: 1023770

Frequency: Always Happens
Regression: No, this is new to the most recent version

Problem Description:
I have a script that contains the following code:

--------------8<----------------
function Get-ScriptDirectory{

$Invocation = (Get-Variable MyInvocation -Scope 1).Value

try {

    Split-Path $Invocation.MyCommand.Path -ea 0

}

catch {

    Write-Warning 'You need to call this function from within a saved script.'

}

}

$scriptdir = Get-ScriptDirectory

Set-Location $scriptdir -ErrorAction Stop
--------------8<----------------

(this originates from PS2.0 days)

The script runs fine, except if it's run from MSBuild using:

<Target Name="AfterClean">

<Message Text="Cleaning old generated files" Importance="normal" />

<Exec Command="powershell -noprofile -executionpolicy unrestricted -file $(ProjectDir)RemoveOldGeneratedFiles.ps1 ... />

</Target>

When run this way, I get:

Cleaning old generated files
powershell -noprofile -executionpolicy unrestricted -file ...\RemoveOldGeneratedFiles.ps1 ...
The property 'Value' cannot be found on this object. Verify that the property exists.At ....\RemoveOldGeneratedFiles.ps1:34 char:2
+ $Invocation = (Get-Variable MyInvocation -Scope 1).Value
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  + CategoryInfo          : NotSpecified: (:) [], PropertyNotFoundException

  + FullyQualifiedErrorId : PropertyNotFoundStrict

EXEC : warning : You need to call this function from within a saved script. [...foo.csproj]

If I add a Write-Host command to the Get-ScriptDirectory function before the "$Invocation = ..." line, the problem very mysteriously disappears.

Product Studio item created by Connect Synchronizer due to creation of feedback ID 1023770 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=1023770).

Repro Steps:
Run a script with the aforementioned code via MSBuild

Expected Results:
No exception raised by Get-Variable MyInvocation -Scope 1).Value

Internal BugId: 13091

Votes from Connect: 11

Original Date Submitted: 5/29/2013 2:52:43 AM

Description:
Contact Information
Handle: deadlydog
Site Name: PowerShell
Feedback ID: 788806

Frequency: Always Happens
Regression: Yes, this happens in all previous versions

Problem Description:

If you try and run a PowerShell script from File Explorer (e.g. Windows Explorer) by double clicking on it, or from the context menu using Open With -> Windows PowerShell the script will not run; instead the PowerShell console will display an error that the given file path is not valid, since only the first portion (up to the first space) of the script file path is passed to powershell.exe. The solution is a simple registry tweak to enclose the path passed to the powershell executable in double quotes.

Essentially you just need to change the key:
HKEYCLASSESROOT\Applications\powershell.exe\shell\open\command

from this:
"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" "%1"

to this:
"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" "& &quot;%1&quot;"

I explain this problem and the registry workaround in more detail on my blog at http://blog.danskingdom.com/fix-problem-where-windows-powershell-cannot-run-script-whose-path-contains-spaces/.

I found a related bug report (https://connect.microsoft.com/PowerShell/feedback/details/718060/power-shell-scripts-fail-at-startup-if-file-path-has-a-space-in-it) which seems to be a specific instance of this more general problem.

Product Studio item created by Connect Synchronizer due to creation of feedback ID 788806 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=788806).

Repro Steps:
1 - Create a powershell script with spaces in the file name or the directory that the script is in.
2 - Try running the powershell script by double clicking on it, or right-clicking it and choosing Open With -> Windows PowerShell.

Expected Results:

The script should run, but instead an error is thrown that it cannot find the script.

Internal BugId: 4225

Votes from Connect: 114

Original Date Submitted: 1/11/2013 5:50:47 PM

Description:
Contact Information
Handle: Arnaud Petitjean
Site Name: PowerShell
Feedback ID: 776313

Frequency: Always Happens
Regression: No, this is new to the most recent version

Problem Description:
* Unlike the previous versions (1.0 and 2.0) *, in PowerShell 3.0 there are no help files available in French language.

I would consider missing help as top priority here. Even for peoples who can read English, there is a big danger to misunderstood something. Reading documentation in a foreign language can be very challenging.

Calling the -online Help every time I need verbose English Help, is no solution. Because I am sitting in a corporate Network with Proxy and no Internet Access!

I have downloaded the English HelpFiles with Save-Help -UICulture 'en-US' but I can't access this Helpfiles. Because the Help depends on the UI Culture of my current Windows setting.
I can't display them without changind my UI Culture in Windows!
Should I switch my Windows settings allways if I need verbose English help?

I'd like the Help system to AUTOMATICALLY display French help by default but if not available then to "failover" to the English version if installed.

Please also consider to add the -Culture parameter to Get-Help, in order to:

Get-Help Get-Comand -Culture "en-US" -Full # should display the English verbose Help
Get-Help Get-Comand -Culture "fr-FR" -Full # should display the French verbose Help

Product Studio item created by Connect Synchronizer due to creation of feedback ID 776313 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=776313).

Repro Steps:
Expected Results:

Internal BugId: 4073

Votes from Connect: 11

Original Date Submitted: 9/29/2012 1:53:59 AM

Description:

Contact Information
Handle: Trevor Sullivan
Site Name: PowerShell
Feedback ID: 765261

Frequency: Always Happens
Regression: No, this is new to the most recent version

Problem Description:
The Invoke-RestMethod cmdlet in PowerShell v3 is truncating the results that come back from the Windows Azure REST API (querying for a list of ServiceBus queues), formatted as a XML AtomPub document. Within the results of the AtomPub document, only every other AtomPub "title" is returned from Invoke-RestMethod, rather than a complete result set.

This behavior can be confirmed by using the parameters -PassThru -OutFile to export the AtomPub document to a file. After this, you can cast the file contents to a XML document using the [XML] type accelerator, which then has the correct number of "titles."

Product Studio item created by Connect Synchronizer due to creation of feedback ID 765261 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=765261).

Repro Steps:
1. Call the Windows Azure ListQueues API using Invoke-RestMethod.

http://msdn.microsoft.com/en-us/library/windowsazure/hh780759.aspx

1. Examine output from Invoke-RestMethod. Only every other queue will be returned, rather than a complete listing.

Expected Results:
The Invoke-RestMethod cmdlet should return a complete array of all AtomPub "titles" instead of truncating them.

Internal BugId: 3846

Votes from Connect: 10

Original Date Submitted: 4/21/2012 9:43:26 PM

Description:
Contact Information
Handle: PowerShellDon
Site Name: PowerShell
Feedback ID: 738071

Frequency: Always Happens
Regression: No, this is new to the most recent version

Problem Description:
I suggest a Register-Module cmdlet, which can be used to register a given module, on a given machine, optionally within a given AD site, as being publicly available. Registration would be in DNS, likely as SRV records (much like an AD domain controller).

"Get-Module -List" would then list local modules as well as modules advertised in DNS for the user's current site (or modules advertised with no site preference). Module auto discovery would not be expected to work with these DNS-registered modules. However, Import-Module, when given just a module name (vs a path), would implicitly remote DNS-registered modules if the specified module was not installed locally.

Because this would probably expose the remoting "second hop" problem more frequently, remoting error messages should ideally be changed to identify situations where the second hop has not worked, and to suggest reading up on CredSSP.

The intent is to let senior administrators designate machines from which specified modules should be implicitly remoted - rather than having to locally install modules, and rather than letting other administrators decide for themselves where to remote modules from.

The SRV records used to advertise a module could also, potentially, advertise a specific port for Remoting, specify whether SSL was required, specify an endpoint (session configuration) name, etc - everything Import-Module would need to implicitly spin up a PSSession and import the module.

Product Studio item created by Connect Synchronizer due to creation of feedback ID 738071 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=738071).

Repro Steps:
n/a

Expected Results:
n/a

Internal BugId: 3540

Votes from Connect: 17

Original Date Submitted: 3/26/2012 6:09:59 PM

Description:
Contact Information
Handle: Peter Kriegel
Site Name: PowerShell
Feedback ID: 733298

Frequency: Sometimes Happens
Regression: I don't know if this issue existed previously

Problem Description:
Make it Possible to save PowerShell scripts in a compiled format (binary byte-code).

Since PowerShell V 3.0 uses the DLR, every PowerShell V 3.0 script has to be compiled during the first run of the script. This may have a speed disadvantage. To speed up the execution of scripts, it may be useful to store scripts in a compiled binary format and run them without an additional compilation step.

This may be useful in the following scenarios:

*  Logonscripts

* calling large amounts of scripts

With the possibility to store PowerShell Scripts in a compiled form, even Administrators are able to produce binary files, without forcing them to use .Net developer Tools like Visual Studio or equal. (producing .dll Assemblys !?)

As side effect, the source code of a script is not direct and easy readable.
Some PowerShell script developers may have the need to protect their knowledge and not give away, easy to read, plain text scripts. Scripts that are stored in a binary format, having the advantage that they are not readable, without an additional re-engineering step.

Product Studio item created by Connect Synchronizer due to creation of feedback ID 733298 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=733298).

Repro Steps:
Expected Results:
Higher Runtime Speed,
Administrators can create assemblys which can be used by other Programs.
Lightweight script read-protection.

Internal BugId: 3467

Votes from Connect: 13

Original Date Submitted: 3/5/2012 6:41:31 PM

Description:
Contact Information
Handle: Shay Levi
Site Name: PowerShell
Feedback ID: 728747

Frequency: Always Happens
Regression: Yes, this happens in all previous versions

Problem Description:
In PowerShell 3.0, the Test-Path cmdlet supports two new parameters: NewerThan and OlderThan. Both parameters accepts a DateTime object and return $true if the object's LastWriteTime is less/greater than the specified date.

One of the tasks IT admins need to perform often is getting old files. It would be great if Get-ChildItem could support those parameters as well, allowing us to filter objects based on a datetime value without the need to use the Where-Object cmdlet.

Product Studio item created by Connect Synchronizer due to creation of feedback ID 728747 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=728747).

Repro Steps:
Expected Results:

Internal BugId: 3393