Unrequested debugging Info in Powershell console

Question

I'm having a nuisance issue I'd like to eliminate where I get debugging info I am not asking for in a Powershell console and ISE. It's a nuisance in that it gets in the way of my desired debugging info.

I'm not clear if this is specific to the tool I am scripting (WinSCP), or a more generic PowerShell behavior.

In a nutshell, WinSCP.Session.Open events don't write out anything out (good!), but the Close() and Dispose() methods are quite chatty, with the below appearing in my console on each invocation.

At first I thought this might be the consequence of including the statements in a finally block, but moving them to the try block yields the same nuisance behavior.

Based on a similar, but not identical issue, I checked out the "preference variables". My stock values are listed at the very end, the only one I tried to change to no avail was the "Warning Preference" to "Silently COntinue", which had no effect

Run-Example:

PS F:\> getFirewallContents "AAA" 255.255.227.254
Attempting Session.Open  AAA  |  255.255.227.254
Completed  Session.Open  AAA  |  255.255.227.254
/var/db/commits exists, last write: 5/8/2015 11:33:22 AM
Closing Session  AAA

... two stanzas that follow are the undesired output ......    

MemberType          : Method
OverloadDefinitions : {System.Void Close()}
TypeNameOfValue     : System.Management.Automation.PSMethod
Value               : System.Void Close()
Name                : Close
IsInstance          : True

MemberType          : Method
OverloadDefinitions : {System.Void Dispose()}
TypeNameOfValue     : System.Management.Automation.PSMethod
Value               : System.Void Dispose()
Name                : Dispose
IsInstance          : True

Closed  Session  AAA

function getFirewallContents ([string] $fw_name, [string] $fw_ip) {
    $session = New-Object WinSCP.Session
    $sessionOptions = New-Object WinSCP.SessionOptions
    $xferOptions = New-Object WinSCP.TransferOptions

    $sessionOptions.HostName = $fw_ip
    $sessionOptions.UserName = "NOPE"
    $sessionOptions.Password = "NOT TELLING"
    $sessionOptions.Protocol = [WinSCP.Protocol]::Sftp
    $sessionOptions.GiveUpSecurityAndAcceptAnySshHostKey = $TRUE

    $remotefile = "/var/db/commits"

    Try {
        Write-Host  "Attempting Session.Open " $fw_name " | " $sessionOptions.HostName 

        $session.Open($sessionOptions)

        Write-Host  "Completed  Session.Open " $fw_name " | " $sessionOptions.HostName      

        if ($session.FileExists($remotefile)) {
            Write-Host "$remotefile exists, last write:" $session.GetFileInfo($remotefile).LastWriteTime
        } else {
            Write-Host "$remotefile NOT FOUND"
        }
    } Catch {
        Write-Host "Something bad happened"
    } Finally {
        Write-Host "Closing Session  $fw_name "
        $session.Close
        $session.Dispose
        Write-Host "Closed  Session  $fw_name "
    }
}

Name                           Value
----                           -----
ConfirmPreference              High
DebugPreference                SilentlyContinue
ErrorActionPreference          Continue
ProgressPreference             Continue
VerbosePreference              SilentlyContinue
WarningPreference              Continue     (Tried Silently Continue, no effect)
WhatIfPreference               False

Send the output to the bit-bucket. `$session.Close | Out-Null`, etc. — Etan Reisner, May 12 '15 at 18:56

score 3 · Accepted Answer · answered May 13 '15 at 08:27

3

You are missing brackets in call to .Close and .Dispose. So you are actually not calling the methods at all, but rather taking an address of the methods and not using it. PowerShell prints the "expression" results on a console as a last resort.

The correct syntax is:

$session.Close()
$session.Dispose()

answered May 13 '15 at 08:27

Martin Prikryl

188,800
56
490
992

1

This was a big learning moment for me, thank you,m thank you!!!! Of course, this is also why I had a couple hundred processes showing up in Process Monitor. (Didn't notice at the time). It's a weird response the way it presents the info, cause it doesn't really make it clear what you thought happened did not -- not clear that its a "WARNING" or "ERROR", not simply "INFO" or "DEBUG" info. Again, this will be a great learning moment. Glad the other poster deleted his response, although that was useful info, even if it was not correct after all. – dave_the_dev May 13 '15 at 15:29
Hey! I just realized why your name seemed familiar! Double thanks! – dave_the_dev May 13 '15 at 15:53

Unrequested debugging Info in Powershell console

1 Answers1