Powershell “Set-PSDebug -Trace 2” causes unexpecte

Question

I'm having a weird problem where I get different behavior when setting "Set-PSDebug -Trace 2".

I traced it down to a switch statement not executing properly and was able to reproduce it on Powershell V3 but not on Powershell V2 or Powershell V1 (works as expected)

Take the following simple function:

function DoTest {
$result = "Switch Case Not Executed"
$VendorName = "Microsoft"
switch ($VendorName)
{
    "Microsoft" { $result = "Switch Case Executed" }
}
Write-host "Switch: $($VendorName) -> $result"

}

Now run the following:

#Works as expected
Set-PSDebug -Off; DoTest;

#Doesn't work as expected
Set-PSDebug -Trace 2; DoTest;

Results on PosH V3 with PSDebug Trace

DEBUG:    3+ Set-PSDebug -Trace 2;  >>>> DoTest;
DEBUG:    1+ function DoTest  >>>> {
DEBUG:     ! CALL function 'DoTest'
DEBUG:    2+      >>>> $result = "Switch Case Not Executed"
DEBUG:     ! SET $result = 'Switch Case Not Executed'.
DEBUG:    3+      >>>> $VendorName = "Microsoft"
DEBUG:     ! SET $VendorName = 'Microsoft'.
DEBUG:     ! SET $switch = 'Microsoft'.
DEBUG:    4+     switch ( >>>> $VendorName)
DEBUG:     ! SET $switch = ''.
DEBUG:    9+      >>>> Write-host "Switch: $($VendorName) -> $result"
DEBUG:    9+     Write-host "Switch: $( >>>> $VendorName) -> $result"
Switch: Microsoft -> Switch Case Not Executed
DEBUG:   11+  >>>> }

In PoSH version 3, even the debug tracing indicates that the value is set, but it seems to skip the switch statement entirely. I even tried the Set-StrictMode and everything runs fine. It's only when I enable PSDebug tracing. Is this behavior intended?

Answer 1

After exhaustive investigation, it appears to be a bug in Powershell. The $switch variable is getting clobbered in debug mode, and ends up being some sort of array enumerator, on an empty array or something silly like that. I recommend filing an issue on http://connect.microsoft.com

Workaround 1:

# Pro: No scoping differences between if statement blocks and function
# Con: big piles of If ... else if ... else if ... can get really annoying to code and maintain
# Con: Statements are limited to single execution, pipeline is lifted to function level instead of statement level
... same code as before but using an if instead of switch ...
if($VendorName = 'Microsoft') { $result = "Switch Case Executed" }
else { $result = "FAIL!" }

Workaround 2:

# Pro: Each script block is self-contained and has private scope
# Pro: "cases" can be added without modifying DoIt function, and even passed into the function 
# Pro: "cases" can be used in a pipeline
# Con: Indirect script blocks can be difficult to understand at first
function DoTest {
    $result = "Switch Case Not Executed"
    $VendorName = "Microsoft"

    $SwitchHack = @{
        Microsoft = { "Microsoft Case Executed" }
        Default = { "Default Case Executed" }
    }

    if($SwitchHack.Keys -contains $VendorName) {
        $result = $SwitchHack."$VendorName".InvokeReturnAsIs()
    } else {
        $result = $SwitchHack.Default.InvokeReturnAsIs()
    }

    'Switch: {0} -> {1}' -f $VendorName, $result | Write-Host 
}

Set-PSDebug -Trace 2
DoTest

And because I was bored, I wrote Workaround 3 which is just 2 with the Switch moved to a function

function Switch-Object {
    param(
        [Parameter(Mandatory=$true)]
            [String]$In,
        [Parameter(Mandatory=$true)]
            [hashtable]$Actions
    )

    try {
        $Actions."$In".InvokeReturnAsIs()
    } 
    catch {
        throw "Unknown Action Label"
    }
}

function DoTest {
    $result = "Switch Case Not Executed"
    $VendorName = "Microsoft"

    $VendorActions = @{
        Microsoft = { "Microsoft Case Executed" }
    }

    $result = Switch-Object -On:$VendorName -Actions:$VendorActions
    'Switch: {0} -> {1}' -f $VendorName, $result | Write-Host 
}

Set-PSDebug -Trace 2
DoTest