Powershell вывод в консоль ошибок - ErrorsMaster.ru - большая энциклопедия ошибок и их решений

В Powershell существует несколько уровней ошибок и несколько способов их обработать. Проблемы одного уровня (Non-Terminating Errors) можно решить с помощью привычных для Powershell команд. Другой уровень ошибок (Terminating Errors) решается с помощью исключений (Exceptions) стандартного, для большинства языков, блока в виде Try, Catch и Finally.

Как Powershell обрабатывает ошибки

До рассмотрения основных методов посмотрим на теоретическую часть.

Автоматические переменные $Error

В Powershell существует множество переменных, которые создаются автоматически. Одна из таких переменных — $Error хранит в себе все ошибки за текущий сеанс PS. Например так я выведу количество ошибок и их сообщение за весь сеанс:

Get-TestTest
$Error
$Error.Count

При отсутствии каких либо ошибок мы бы получили пустой ответ, а счетчик будет равняться 0:

Переменная $Error являет массивом и мы можем по нему пройтись или обратиться по индексу что бы найти нужную ошибку:

$Error[0]

foreach ($item in $Error){$item}

Свойства объекта $Error

Так же как и все что создается в Powershell переменная $Error так же имеет свойства (дополнительную информацию) и методы. Названия свойств и методов можно увидеть через команду Get-Member:

$Error | Get-Member

Например, с помощью свойства InvocationInfo, мы можем вывести более структурный отчет об ошибки:

$Error[0].InvocationInfo

Методы объекта $Error

Например мы можем очистить логи ошибок используя clear:

$Error.clear()

Критические ошибки (Terminating Errors)

Критические (завершающие) ошибки останавливают работу скрипта. Например это может быть ошибка в названии командлета или параметра. В следующем примере команда должна была бы вернуть процессы «svchost» дважды, но из-за использования несуществующего параметра ‘—Error’ не выполнится вообще:

'svchost','svchost' | % {Get-Process -Name $PSItem} --Error

Не критические ошибки (Non-Terminating Errors)

Не критические (не завершающие) ошибки не остановят работу скрипта полностью, но могут вывести сообщение об этом. Это могут быть ошибки не в самих командлетах Powershell, а в значениях, которые вы используете. На предыдущем примере мы можем допустить опечатку в названии процессов, но команда все равно продолжит работу:

'svchost111','svchost' | % {Get-Process -Name $PSItem}

Как видно у нас появилась информация о проблеме с первым процессом ‘svchost111’, так как его не существует. Обычный процесс ‘svchost’ он у нас вывелся корректно.

Параметр ErrorVariable

Если вы не хотите использовать автоматическую переменную $Error, то сможете определять свою переменную индивидуально для каждой команды. Эта переменная определяется в параметре ErrorVariable:

'svchost111','svchost' | % {Get-Process -Name $PSItem } -ErrorVariable my_err_var
$my_err_var

Переменная будет иметь те же свойства, что и автоматическая:

$my_err_var.InvocationInfo

Обработка некритических ошибок

У нас есть два способа определения последующих действий при ‘Non-Terminating Errors’. Это правило можно задать локально и глобально (в рамках сессии). Мы сможем полностью остановить работу скрипта или вообще отменить вывод ошибок.

Приоритет ошибок с $ErrorActionPreference

Еще одна встроенная переменная в Powershell $ErrorActionPreference глобально определяет что должно случится, если у нас появится обычная ошибка. По умолчанию это значение равно ‘Continue’, что значит «вывести информацию об ошибке и продолжить работу»:

$ErrorActionPreference

Если мы поменяем значение этой переменной на ‘Stop’, то поведение скриптов и команд будет аналогично критичным ошибкам. Вы можете убедиться в этом на прошлом скрипте с неверным именем процесса:

$ErrorActionPreference = 'Stop'
'svchost111','svchost' | % {Get-Process -Name $PSItem}

Т.е. скрипт был остановлен в самом начале. Значение переменной будет храниться до момента завершения сессии Powershell. При перезагрузке компьютера, например, вернется значение по умолчанию.

Ниже значение, которые мы можем установить в переменной $ErrorActionPreference:

Continue — вывод ошибки и продолжение работы;
Inquire — приостановит работу скрипта и спросит о дальнейших действиях;
SilentlyContinue — скрипт продолжит свою работу без вывода ошибок;
Stop — остановка скрипта при первой ошибке.

Самый частый параметр, который мне приходится использовать — SilentlyContinue:

$ErrorActionPreference = 'SilentlyContinue'
'svchost111','svchost' | % {Get-Process -Name $PSItem}

Использование параметра ErrorAction

Переменная $ErrorActionPreference указывает глобальный приоритет, но мы можем определить такую логику в рамках команды с параметром ErrorAction. Этот параметр имеет больший приоритет чем $ErrorActionPreference. В следующем примере, глобальная переменная определяет полную остановку скрипта, а в параметр ErrorAction говорит «не выводить ошибок и продолжить работу»:

$ErrorActionPreference = 'Stop'
'svchost111','svchost' | % {Get-Process -Name $PSItem -ErrorAction 'SilentlyContinue'}

Кроме ‘SilentlyContinue’ мы можем указывать те же параметры, что и в переменной $ErrorActionPreference.

Значение Stop, в обоих случаях, делает ошибку критической.

Обработка критических ошибок и исключений с Try, Catch и Finally

Когда мы ожидаем получить какую-то ошибку и добавить логику нужно использовать Try и Catch. Например, если в вариантах выше мы определяли нужно ли нам отображать ошибку или останавливать скрипт, то теперь сможем изменить выполнение скрипта или команды вообще. Блок Try и Catch работает только с критическими ошибками и в случаях если $ErrorActionPreference или ErrorAction имеют значение Stop.

Например, если с помощью Powershell мы пытаемся подключиться к множеству компьютеров один из них может быть выключен — это приведет к ошибке. Так как эту ситуацию мы можем предвидеть, то мы можем обработать ее. Процесс обработки ошибок называется исключением (Exception).

Синтаксис и логика работы команды следующая:

try {
    # Пытаемся подключиться к компьютеру
}
catch [Имя исключения 1],[Имя исключения 2]{
    # Раз компьютер не доступен, сделать то-то
}
finally {
    # Блок, который выполняется в любом случае последним
}

Блок try мониторит ошибки и если она произойдет, то она добавится в переменную $Error и скрипт перейдет к блоку Catch. Так как ошибки могут быть разные (нет доступа, нет сети, блокирует правило фаервола и т.д.) то мы можем прописывать один блок Try и несколько Catch:

try {
    # Пытаемся подключится
}
catch ['Нет сети']['Блокирует фаервол']{
    # Записываем в файл
}
catch ['Нет прав на подключение']{
    # Подключаемся под другим пользователем
}

Сам блок finally — не обязательный и используется редко. Он выполняется самым последним, после try и catch и не имеет каких-то условий.

Catch для всех типов исключений

Как и было показано выше мы можем использовать блок Catch для конкретного типа ошибок, например при проблемах с доступом. Если в этом месте ничего не указывать — в этом блоке будут обрабатываться все варианты ошибок:

try {
   'svchost111','svchost' | % {Get-Process -Name $PSItem -ErrorAction 'Stop'}
}
catch {
   Write-Host "Какая-то неисправность" -ForegroundColor RED
}

Такой подход не рекомендуется использовать часто, так как вы можете пропустить что-то важное.

Мы можем вывести в блоке catch текст ошибки используя $PSItem.Exception:

try {
   'svchost111','svchost' | % {Get-Process -Name $PSItem -ErrorAction 'Stop'}
}
catch {
   Write-Host "Какая-то неисправность" -ForegroundColor RED
   $PSItem.Exception
}

Переменная $PSItem хранит информацию о текущей ошибке, а глобальная переменная $Error будет хранит информацию обо всех ошибках. Так, например, я выведу одну и ту же информацию:

$Error[0].Exception

Создание отдельных исключений

Что бы обработать отдельную ошибку сначала нужно найти ее имя. Это имя можно увидеть при получении свойств и методов у значения переменной $Error:

$Error[0].Exception | Get-Member

Так же сработает и в блоке Catch с $PSItem:

Для вывода только имени можно использовать свойство FullName:

$Error[0].Exception.GetType().FullName

Далее, это имя, мы вставляем в блок Catch:

try {
   'svchost111','svchost' | % {Get-Process -Name $PSItem -ErrorAction 'Stop'}
}
catch [Microsoft.PowerShell.Commands.ProcessCommandException]{
   Write-Host "Произошла ошибка" -ForegroundColor RED
   $PSItem.Exception
}

Так же, как и было описано выше мы можем усложнять эти блоки как угодно указывая множество исключений в одном catch.

Выброс своих исключений

Иногда нужно создать свои собственные исключения. Например мы можем запретить добавлять через какой-то скрипт названия содержащие маленькие буквы или сотрудников без указания возраста и т.д. Способов создать такие ошибки — два и они тоже делятся на критические и обычные.

Выброс с throw

Throw — выбрасывает ошибку, которая останавливает работу скрипта. Этот тип ошибок относится к критическим. Например мы можем указать только текст для дополнительной информации:

$name = 'AD.1'

if ($name -match '.'){
   throw 'Запрещено использовать точки в названиях'
}

Если нужно, то мы можем использовать исключения, которые уже были созданы в Powershell:

$name = 'AD.1'

if ($name -like '*.*'){
   throw [System.IO.FileNotFoundException]'Запрещено использовать точки в названиях'
}

Использование Write-Error

Команда Write-Error работает так же, как и ключ ErrorAction. Мы можем просто отобразить какую-то ошибку и продолжить выполнение скрипта:

$names = @('CL1', 'AD.1', 'CL3')

foreach ($name in $names){
   if ($name -like '*.*'){
      Write-Error -Message 'Обычная ошибка'
   }
   else{
      $name
   }
}

При необходимости мы можем использовать параметр ErrorAction. Значения этого параметра были описаны выше. Мы можем указать значение ‘Stop’, что полностью остановит выполнение скрипта:

$names = @('CL1', 'AD.1', 'CL3')

foreach ($name in $names){
   if ($name -like '*.*'){
      Write-Error -Message 'Обычная ошибка' -ErrorAction 'Stop'
   }
   else{
      $name
   }
}

Отличие команды Write-Error с ключом ErrorAction от обычных команд в том, что мы можем указывать исключения в параметре Exception:

Write-Error -Message 'Обычная ошибка' -ErrorAction 'Stop'

Write-Error -Message 'Исключение' -Exception [System.IO.FileNotFoundException] -ErrorAction 'Stop'

В Exception мы так же можем указывать сообщение. При этом оно будет отображаться в переменной $Error:

Write-Error -Exception [System.IO.FileNotFoundException]'Моё сообщение'

…

Теги:

#powershell

#ошибки

Источник

Error Handling is a very important concept in every programming language including PowerShell which gives us several possibilities to manage errors in code.

In this article, I will try to cover as many as possible error handling concepts with examples from my practice and one of the important concepts is writing errors in external Error Log text file.

Why Should We Bother Handling Errors In PowerShell
How To Handle And Log PowerShell Errors
Example Of PowerShell Error Handling
Chain Of Events When PowerShell Error Occurs
How To Write PowerShell Errors Into The External Log File
Errors In PowerShell
ErrorAction Common Parameter
$ErrorActionPreference Preference Variable Explained
Error Handling With Try/Catch/Finally Blocks
Getting Error Information With $Error Automatic Variable
Write-Error CmdLet
Handling Errors from non-PowerShell processes
Useful PowerShell Error Handling Articles

Why Should We Bother Handling Errors In PowerShell

It is no fun to run any code or application full of errors and bugs as the matter a fact it is quite annoying so in order for users to have a pleasant experience handling the errors is one of the essentials in programming.

PowerShell is no exception to that way of thinking and programming ethics although it can take some additional coding and effort but trust me it is always worth it.

I would be more than happy to share my experience with error handling and even more satisfied if I can hear your tips from the field so we can all enrich our knowledge on this very important subject.

Here is a general approach to error handling and logging errors into the external text file. I have an example in the next subheading that further explain each step so everything is much more understandable.

Identify which Commands need Error Handling in your Function, CmdLet or Script.
Set the ErrorAction parameter to value Stop for the command that needs Error Handling. This will stop executing the command when an error occurs and it will show the error message. Basically, we are making non-terminating errors into terminating in order to be able to handle the error in the catch block.
Command that has ErrorAction parameter set to value Stop is wrapped in Try { } block. So when Error occurs handling of the code will jump from the Try block to Catch block.
In Catch { } block that immediately follows after Try {} block, the error is handled by writing to the error log file on the disk.
We use our own Write-ErrorLog CmdLet inside Catch{ } block to write the error in a text file on the disk. (See the explanation and code here)
We have an additional switch error parameter to decide whether we want to write an error in the log file or not. This is totally optional.
Use the Finally { } block if needed.
Test the whole setup by intentionally breaking the code while in the development phase.
Since some of the CmdLets calls are Scheduled we have routine to check external Error Log text file at least once a week and investigate errors that are caught. This step is part of improving the overall quality of the written code.

Example Of PowerShell Error Handling

To show you Error Handling and implement previously defined steps I will use my own Get-CPUInfo CmdLet which is in the Common module of the Efficiency Booster PowerShell Project. Efficiency Booster PowerShell Project is a library of CmdLets that help us IT experts in day to day IT tasks.

In order to follow me along, I highly encourage you to download the zip file with the source code used in this example.

Here is the location of Get-CPUInfo script:
…[My] DocumentsWindowsPowerShellModules3common

Get-CPUInfo CmdLet script location

Let’s use steps defined in the previous subheading to this example.

Step 1. I have identified the command that needs Error Handling in Get-CPUInfo CmdLet and that is a call to Get-CimInstance CmdLet.

Get-CimInstance @params

Step 2. So I have set up the ErrorAction parameter to the value ‘Stop‘ for Get-CimInstance CmdLet in order to force non-terminating errors into terminating and then to be able to handle such errors.

INFO: I use parameter splatting when running CmdLet. If you want to know more about parameter splating please read this article.

            $params = @{ 'ComputerName'=$computer;
                         'Class'='Win32_Processor';
                         'ErrorAction'='Stop'}
            $CPUInfos = Get-CimInstance @params | 
                            Select-Object   @{label="ServerName"; Expression={$_.SystemName}}, 
                                            @{label="CPU"; Expression={$_.Name}}, 
                                            @{label="CPUid"; Expression={$_.DeviceID}}, 
                                            NumberOfCores, 
                                            AddressWidth

Step 3. Wrap up the call to Get-CimInstance CmdLet into the Try Block in order to be able to handle the error in a catch block that follows.

         try {
            Write-Verbose "Start processing: $computer - $env - $logicalname"
            Write-Verbose "Start Win32_Processor processing..."
            $CPUInfos = $null
            $params = @{ 'ComputerName'=$computer;
                         'Class'='Win32_Processor';
                         'ErrorAction'='Stop'}
            $CPUInfos = Get-CimInstance @params | 
                            Select-Object   @{label="ServerName"; Expression={$_.SystemName}}, 
                                            @{label="CPU"; Expression={$_.Name}}, 
                                            @{label="CPUid"; Expression={$_.DeviceID}}, 
                                            NumberOfCores, 
                                            AddressWidth           
            Write-Verbose "Finish Win32_Processor processing..."                    
            foreach ($CPUInfo in $CPUInfos) {
                Write-Verbose "Start processing CPU: $CPUInfo"
                $properties = @{ 'Environment'=$env;
                                 'Logical name'=$logicalname;
                                 'Server name'=$CPUInfo.ServerName;
            	                 'CPU'=$CPUInfo.CPU;
            	                 'CPU ID'=$CPUInfo.CPUid;
            	                 'Number of CPU cores'=$CPUInfo.NumberOfCores; 
                                 '64 or 32 bits'=$CPUInfo.AddressWidth;
                                 'IP'=$ip;
                                 'Collected'=(Get-Date -UFormat %Y.%m.%d' '%H:%M:%S)}
                $obj = New-Object -TypeName PSObject -Property $properties
                $obj.PSObject.TypeNames.Insert(0,'Report.CPUInfo')
                Write-Output $obj
                Write-Verbose "Finish processing CPU: $CPUInfo"
            }
 Write-Verbose "Finish processing: $computer - $env - $logicalname"                       
        }

Step 4. When the error occurs in the try block it is handled in the Catch Block.
It is important to notice following in the catch block of code:

Get-CPUInfo CmdLet switch parameter $errorlog has been used to decide whether to log the errors in an external text file or not. This is completely optional.
Certain Error properties are collected using an automatic variable $_ ($PSItem is another name for the same variable). If you want to know more about which properties we collect please read here.
Collected data about the error that will be handled has been passed to another CmdLet Write-ErrorLog that will write the data in an external text log file. Please read here about Write-ErrorLog CmdLet.

catch {
            Write-Warning "Computer failed: $computer - $env - $logicalname CPU failed: $CPUInfos"
            Write-Warning "Error message: $_"
            if ( $errorlog ) {
                $errormsg = $_.ToString()
                $exception = $_.Exception
                $stacktrace = $_.ScriptStackTrace
                $failingline = $_.InvocationInfo.Line
                $positionmsg = $_.InvocationInfo.PositionMessage
                $pscommandpath = $_.InvocationInfo.PSCommandPath
                $failinglinenumber = $_.InvocationInfo.ScriptLineNumber
                $scriptname = $_.InvocationInfo.ScriptName
                Write-Verbose "Start writing to Error log."
                Write-ErrorLog -hostname $computer -env $env -logicalname $logicalname -errormsg $errormsg -exception $exception -scriptname $scriptname -failinglinenumber $failinglinenumber -failingline $failingline -pscommandpath $pscommandpath -positionmsg $pscommandpath -stacktrace $stacktrace
                Write-Verbose "Finish writing to Error log."
            }
        }

Step 5. I have already mentioned that Write-ErrorLog CmdLet has been used to write the error data into an external text log file. Read more about this CmdLet here.

Step 6. I did not need Finally { } block for this example.

Step 7. In the development phase, I was intentionally breaking Get-CPUInfo CmdLet to test my error handling code.

Step 8. If Get-CPUInfo CmdLet is part of the scheduled code I would look regularly Error log file and work on correcting all the bugs in the code produced by Get-CPUInfo CmdLet.

Chain Of Events When PowerShell Error Occurs

Let’s talk a little bit about what is happening when an error occurs in PowerShell and which events are triggered one after another.

Call to CmdLet is failing and error has just occurred.
Since we have ErrorAction parameter set to value Stop our non-terminating error has forced into terminating error so the execution of code stops.
The error that is failing in the CmdLet is written in the $Error automatic variable by the PowerShell.
We have forced the error to be terminating in order to be able to handle with try catch finally block of error handling.
Since our CmdLet call is wrapped in Try block and error is terminating PowerShell can trigger error handling looking for a Catch block.
We can have several Catch blocks for one try block. If we have a Catch block that handles the actual error number that block is executed.
Otherwise, PowerShell will look Catch block that handles all error numbers.
Optionally in the Catch block, we can have code that will write the error in the external text Error log file.
We can use the automatic variable $Error or $_ object to read Error data and write them in the external file.
If there is no Catch block PowerShell will look for Catch block in parent call if we have nested calls.
If there are no further Catch block or no Catch block at all that will handle error then PowerShell looks for Finally block to execute which is used to clean up resources as needed.
After executing Finally block error message will be sent to the error stream for further processing.

In further sections of this article, you can read in more detail about the many terms mentioned (ErrorAction, $Error, Try Catch Finally, Terminating, Non-Terminating, etc ) in this bulleted list in order to better understand them.

How To Write PowerShell Errors Into The External Log File

Here I will explain the code of Write-ErrorLog CmdLet that writes error data that occurs in CmdLets and handle the error data into an external text file.

Error data are written in the file named Error_Log.txt in folder PSlogs.

Location and name of external error text log file

Example of error logged in an external text file

Write-ErrorLog CmdLet is part of the Efficiency Booster PowerShell Project and if you want to download the source code of this CmdLet please click here.

Here is the location of Write-ErrorLog script which is part of the Utils module:
…[My] DocumentsWindowsPowerShellModules2utils

Write-ErrorLog CmdLet script location

Write-ErrorLog CmdLet Code

Here is the code of the whole Write-ErrorLog CmdLet.

<#
.SYNOPSIS
Writes errors that occur in powershell scripts into error log file.
.DESCRIPTION
Writes errors that occur in powershell scripts into error log file.
Error log file and error log folder will be created if doesn't exist.
Error log file name is Error_Log.txt and it has been saved into ..DocumentsPSlogs

.PARAMETER hostname
Name of the computer that is failing.

.PARAMETER env
Environment where computer is located. For example: Production, Acceptance, Test, Course etc.

.PARAMETER logicalname
Type of the server that is failing. For example: Application, Web, Integration, FTP, Scan, etc. 

.PARAMETER errormsg
Error message.

.PARAMETER exception
Error number.

.PARAMETER scriptname
Name of the powershell script that is failing.

.PARAMETER failinglinenumber
Line number in the script that is failing.

.PARAMETER failingline
Content of failing line.

.PARAMETER pscommandpath
Path to the powershell command.

.PARAMETER positionmsg
Error message position.

.PARAMETER stacktrace
Stack trace of the error.

.EXAMPLE
Write-ErrorLog -hostname "Server1" -env "PROD" -logicalname "APP1" -errormsg "Error Message" -exception "HResult 0789343" -scriptname "Test.ps1" -failinglinenumber "25" -failingline "Get-Service" -pscommandpath "Command pathc." -positionmsg "Position message" -stacktrace "Stack trace" 

.EXAMPLE
Help Write-ErrorLog -Full

.LINK 
Out-File
#>
Function Write-ErrorLog {
[CmdletBinding()]
param (

    [Parameter(Mandatory=$false,
                HelpMessage="Error from computer.")] 
    [string]$hostname,

    [Parameter(Mandatory=$false,
                HelpMessage="Environment that failed. (Test, Production, Course, Acceptance...)")] 
    [string]$env,

    [Parameter(Mandatory=$false,
                HelpMessage="Type of server that failed. (Application, Web, Integration...)")] 
    [string]$logicalname,
    
    [Parameter(Mandatory=$false,
                HelpMessage="Error message.")] 
    [string]$errormsg,
    
    [Parameter( Mandatory=$false,
                HelpMessage="Exception.")]
    [string]$exception,
    
    [Parameter(Mandatory=$false, 
                HelpMessage="Name of the script that is failing.")]
    [string]$scriptname,
     
    [Parameter(Mandatory=$false,
                HelpMessage="Script fails at line number.")]
    [string]$failinglinenumber,

    [Parameter(Mandatory=$false,
                HelpMessage="Failing line looks like.")]
    [string]$failingline,
    
    [Parameter(Mandatory=$false,
                HelpMessage="Powershell command path.")]
    [string]$pscommandpath,    

    [Parameter(Mandatory=$false,
                HelpMessage="Position message.")]
    [string]$positionmsg, 

    [Parameter(Mandatory=$false,
                HelpMessage="Stack trace.")]
    [string]$stacktrace
)
BEGIN { 
        
        $errorlogfile = "$homeDocumentsPSlogsError_Log.txt"
        $errorlogfolder = "$homeDocumentsPSlogs"
        
        if  ( !( Test-Path -Path $errorlogfolder -PathType "Container" ) ) {
            
            Write-Verbose "Create error log folder in: $errorlogfolder"
            New-Item -Path $errorlogfolder -ItemType "Container" -ErrorAction Stop
        
            if ( !( Test-Path -Path $errorlogfile -PathType "Leaf" ) ) {
                Write-Verbose "Create error log file in folder $errorlogfolder with name Error_Log.txt"
                New-Item -Path $errorlogfile -ItemType "File" -ErrorAction Stop
            }
        }
}
PROCESS {  

            Write-Verbose "Start writing to Error log file. $errorlogfile"
            $timestamp = Get-Date 
            #IMPORTANT: Read just first value from collection not the whole collection.
            "   " | Out-File $errorlogfile -Append
            "************************************************************************************************************" | Out-File $errorlogfile -Append
            "Error happend at time: $timestamp on a computer: $hostname - $env - $logicalname" | Out-File $errorlogfile -Append
            "Error message: $errormsg" | Out-File $errorlogfile -Append
            "Error exception: $exception" | Out-File $errorlogfile -Append
            "Failing script: $scriptname" | Out-File $errorlogfile -Append
            "Failing at line number: $failinglinenumber" | Out-File $errorlogfile -Append
            "Failing at line: $failingline" | Out-File $errorlogfile -Append
            "Powershell command path: $pscommandpath" | Out-File $errorlogfile -Append
            "Position message: $positionmsg" | Out-File $errorlogfile -Append
            "Stack trace: $stacktrace" | Out-File $errorlogfile -Append
            "------------------------------------------------------------------------------------------------------------" | Out-File $errorlogfile -Append                   
            
            Write-Verbose "Finish writing to Error log file. $errorlogfile"
}        
END { 

}
}
#region Execution examples
#Write-ErrorLog -hostname "Server1" -env "PROD" -logicalname "APP1" -errormsg "Error Message" -exception "HResult 0789343" -scriptname "Test.ps1" -failinglinenumber "25" -failingline "Get-Service" -pscommandpath "Command pathc." -positionmsg "Position message" -stacktrace "Stack trace" -Verbose
#endregion

Write-ErrorLog CmdLet Explained

Let’s make our hand’s a little bit “dirty” and dive into PowerShell code.

In the BEGIN block we:

Check if folder PSlogs exist in the (My) Documents folder of the current user.
- If the PSlogs folder doesn’t exist then create the folder.
Check if file Error_Log.txt exists in the folder PSlogs.
- If Error_Log.txt doesn’t exist then create the file.
Now we can move on to PROCESS block code.

BEGIN { 
        
        $errorlogfile = "$homeDocumentsPSlogsError_Log.txt"
        $errorlogfolder = "$homeDocumentsPSlogs"
        
        if  ( !( Test-Path -Path $errorlogfolder -PathType "Container" ) ) {
            
            Write-Verbose "Create error log folder in: $errorlogfolder"
            New-Item -Path $errorlogfolder -ItemType "Container" -ErrorAction Stop
        
            if ( !( Test-Path -Path $errorlogfile -PathType "Leaf" ) ) {
                Write-Verbose "Create error log file in folder $errorlogfolder with name Error_Log.txt"
                New-Item -Path $errorlogfile -ItemType "File" -ErrorAction Stop
            }
        }
}

In the PROCESS block:

We format the line of text that we want to write into the log file.
Then we pipe formatted text to Out-File CmdLet with the Append parameter to write that line of text in the file.
We repeat the process of formatting the line of text and appending of that line to the Error log file.

PROCESS {  

            Write-Verbose "Start writing to Error log file. $errorlogfile"
            $timestamp = Get-Date 
            #IMPORTANT: Read just first value from collection not the whole collection.
            "   " | Out-File $errorlogfile -Append
            "************************************************************************************************************" | Out-File $errorlogfile -Append
            "Error happend at time: $timestamp on a computer: $hostname - $env - $logicalname" | Out-File $errorlogfile -Append
            "Error message: $errormsg" | Out-File $errorlogfile -Append
            "Error exception: $exception" | Out-File $errorlogfile -Append
            "Failing script: $scriptname" | Out-File $errorlogfile -Append
            "Failing at line number: $failinglinenumber" | Out-File $errorlogfile -Append
            "Failing at line: $failingline" | Out-File $errorlogfile -Append
            "Powershell command path: $pscommandpath" | Out-File $errorlogfile -Append
            "Position message: $positionmsg" | Out-File $errorlogfile -Append
            "Stack trace: $stacktrace" | Out-File $errorlogfile -Append
            "------------------------------------------------------------------------------------------------------------" | Out-File $errorlogfile -Append                   
            
            Write-Verbose "Finish writing to Error log file. $errorlogfile"
}

$PSItem or $_

$PSItem contains the current object in the pipeline object and we use it to read Error properties in this case.

Just a quick explanation of each Error property from the $_ ($PSItem) automatic variable that we collect and write in Logfile:

$_.ToString() – This is Error Message.
$_.Exception – This is Error Exception.
$_.InvocationInfo.ScriptName – This the PowerShell script name where Error occurred.
$_.InvocationInfo.ScriptLineNumber – This is line number within the PowerShell script where Error occurred.
$_.InvocationInfo.Line – This is the line of code within PowerShell script where Error occurred.
$_.InvocationInfo.PSCommandPath – This is the path to the PowerShell script file on the disk.
$_.InvocationInfo.PositionMessage – This is a formatted message indicating where the CmdLet appeared in the line.
$_.ScriptStackTrace – This is the Trace of the Stack.

As you can see on the screenshot below we collect really useful information about the Error that we handle in the Logfile. The pieces of information are presented in very neatly fashion so we can immediately see:

which error occurred,
what were the message and exception,
where the error occurred (script name, script location, line number and line of the code in the script)
even the call stack is shown if needed.

Here are the final result and an example of one formatted error logged in Error_Log.txt file.

************************************************************************************************************
Error happend at time: 09/11/2019 18:20:41 on a computer: APP01 -  - 
Error message: The WinRM client cannot process the request. If the authentication scheme is different from Kerberos, or if the client computer is not joined to a domain, then HTTPS transport must be used or the destination machine must be added to the TrustedHosts configuration setting. Use winrm.cmd to configure TrustedHosts. Note that computers in the TrustedHosts list might not be authenticated. You can get more information about that by running the following command: winrm help config.
Error exception: Microsoft.Management.Infrastructure.CimException: The WinRM client cannot process the request. If the authentication scheme is different from Kerberos, or if the client computer is not joined to a domain, then HTTPS transport must be used or the destination machine must be added to the TrustedHosts configuration setting. Use winrm.cmd to configure TrustedHosts. Note that computers in the TrustedHosts list might not be authenticated. You can get more information about that by running the following command: winrm help config.
   at Microsoft.Management.Infrastructure.Internal.Operations.CimAsyncObserverProxyBase`1.ProcessNativeCallback(OperationCallbackProcessingContext callbackProcessingContext, T currentItem, Boolean moreResults, MiResult operationResult, String errorMessage, InstanceHandle errorDetailsHandle)
Failing script: C:UsersdekibDocumentsWindowsPowerShellModules3commonGetCPUInfo.ps1
Failing at line number: 214
Failing at line:             $CPUInfos = Get-CimInstance @params | 

Powershell command path: C:UsersdekibDocumentsWindowsPowerShellModules3commonGetCPUInfo.ps1
Position message: C:UsersdekibDocumentsWindowsPowerShellModules3commonGetCPUInfo.ps1
Stack trace: at Get-CPUInfo, C:UsersdekibDocumentsWindowsPowerShellModules3commonGetCPUInfo.ps1: line 214
at , : line 1
------------------------------------------------------------------------------------------------------------

TIP: If your scripts are scheduled in Task Manager the best practice is to have a routine of regularly checking the Error Log file and investigate the errors that occurred since the last check. I am doing this once a week.

Errors In PowerShell

There are two types of Errors in PowerShell:

Terminating
Non-Terminating

Terminating Errors

Here are the important features of Terminating errors:

terminates execution of command or script
triggers Catch block and can be error handled by the Catch block.

Examples are syntax errors, non-existent CmdLets, or other fatal errors

Non-Terminating Errors

Here are important features of Non-Terminating Error:

A non-fatal error.
Allows execution to continue despite the failure that just occurred.
It doesn’t trigger the Catch block and cannot be Error Handled in the Catch block by default.

Examples are permission problems, file not found, etc.

How To Force Non-Terminating Errors Into Terminating

Use the ErrorAction parameter with value Stop to force non-terminating error into terminating as in the following example. The reason why we want to make non-termination error into terminating one is to be able to catch the error when occurs.

$AuthorizedUser = Get-Content .DocumentsWindowsPowerShellProfile.ps1 -ErrorAction Stop

Basically, the workflow is as follows.

When an error occurs,
a non-terminating error has changed into terminating one since we have Stop value on ErrrorAction parameter,
then since terminating error has occurred try block will send the error handling to catch block where error can be processed and
optionally written to the external log,
optionally error handling can continue in the final block.

NOTE: ErrorAction parameter overrides temporarily ErrorActionPreference variable while the call to CmdLet has been processed.

How To Treat All Errors As Terminating

We use the ErrorActionPreference variable to treat all errors as terminating by setting to the value Stop in the:

script
or session

Write the following line of code at the begging of the script to treat all errors as terminating.

$ErrorActionPreference = Stop

Type in Windows PowerShell Console the same command to setup terminating errors for the session.

ErrorAction Common Parameter

ErrorAction parameter belongs to the set of common parameters that we can use with any CmdLet. If we set CmdLetBinding on Advanced Functions than PowerShell automatically makes common parameters available for that command.

This is a parameter that I always use with CmdLets that need error handling since the ErrorAction Parameter determines how the CmdLet responds to a non-terminating error. It has several values that we will talk about in a minute but the value that I like to use is Stop and it is used to make non-terminating errors into terminating errors as written in previous sections.

The ErrorAction parameter overrides the value of the $ErrorActionPreference variable when applied to the specific command.

Here are valid values:

Continue (Default)
- This is the default setting. Display error then continues execution.
Stop
- Display error, and stop the execution.
Inquire
- Displays error message and the user is asked to continue with execution.
SilentlyContinue
- No error message is displayed and execution is continued. However, the error message is added to the $Error automatic variable.
Ignore
- The same as SilentlyContinue, No error message is displayed and execution is continued. However, Ignore does not add an error message to the $Error automatic variable.
Suspend
- This one is for workflows. A workflow job is suspended to investigate what happened, then the workflow can be resumed.

$ErrorActionPreference Preference Variable Explained

$ErrorActionPreference preference variable determines how Windows PowerShell responds to a non-terminating error (an error that does not stop the cmdlet processing) in a script, cmdlet or at the command line

If we want to override the value of the ErrorActionPreference preference variable for the specific command we use the ErrorAction common parameter as explained here.

The valid values for $ErrorActionPreference preference variable are:

Continue (Default)
- This is the default setting. Display error then continues execution.
Stop
- Display error message, and stop the execution.
Inquire
- Displays error message and the user is asked to continue with execution.
SilentlyContinue
- No error message is displayed and execution is continued. However, the error message is added to the $Error automatic variable.
Suspend
- This one is for workflows. A workflow job is suspended to investigate what happened, then the workflow can be resumed.

Error Handling With Try/Catch/Finally Blocks

Try, Catch, and Finally, blocks are used to handle terminating errors in the scripts, functions, and CmdLets. A non-terminating error does not trigger Try block and Windows PowerShell will not look for Catch block to handle the error. So we need to force a non-terminating error to become terminating error using ErrorAction parameter with value Stop whenever we call some CmdLet or Advanced function.

Try block is used as part of the code that PowerShell will monitor for errors. The workflow in the Try block is as follows:

Try block is the section of code that will be monitored for errors by Windows PowerShell.
When the error occurs within Try block the error is saved to $Error automatic variable first.
Windows PowerShell searches for a Catch block to handle the error if the error is terminating. If the Catch block has not been found in current scope Windows PowerShell will search for catch block in parent scopes for nested calls.
Then the Finally block is run if exists.
If there is no Catch block than the error is not handled and the error is written to the error stream.

One Try block can have several Catch Blocks that will handle different error types.

Catch block usually handles the error.

The Finally block is optional and can be only one. Usually, it is used to clean up and free the resources.

The syntax for Try, Catch, and Finally block:

try { } 
catch [],[]
   { } 
catch { } 
finally { }

Getting Error Information With $Error Automatic Variable

$Error automatic variable is an array of error objects (both terminating and the non-terminating) that occurred in the current PowerShell session. The most recent error that occurred is written with index 0 in the array as $Error[0]. If we have just opened the Windows PowerShell session the $Error variable is an empty array and ready to be used.

Check the number of Errors in $Error variable with the following code:

$Error.Count

To prevent the error from being written in $Error automatic variable set ErrorAction parameter to value Ignore.

$Error variable is a rich object that has many useful properties worth reading and helpful for further understanding of the error that just occurred.

Let’s see some useful properties and in section Write-ErrorLog CmdLet Explained I have explained to you some useful examples of properties that are interesting to be written in an external log file.

$error[0] | Get-Member

Methods and Properties of the Error object

$Error.CategoryInfo | Get-Member

Methods and Properties of CategoryInfo object

$Error[0].Exception

The exception of the error that occurred.

$Error.InvocationInfo | Get-Member

Methods and Properties of InvocationInfo object

Write-Error CmdLet

Write-Error CmdLet writes an object to the error stream.

Please read this article from Microsoft PowerShell documentation regarding this CmdLet.

Handling Errors from non-PowerShell processes

We can run applications from PowerShell script like for example, PsExec.exe or robocopy.exe and they are external processes for PowerShell. Since it is an external process, errors from it will not be caught by our try/catch blocks in PowerShell script. So how we will know whether our external process was successful or not.

Well, we can use the $LastExitCode PowerShell automatic variable.

PowerShell will write the exit code to the $LastExitCode automatic variable when the external process exits. Check the external tool’s documentation for exit code values but usually, 0 means success and 1 or greater values mean a failure.

Useful PowerShell Error Handling Articles

Here are some useful articles and resources:

Windows PowerShell Error Reporting
About Try Catch Finally
About CommonParameters
About Automatic Variables
About Preference Variables
Write-Error
About Throw
About Break
About Continue

Источник

В PowerShell не обязательно использовать echo или аналогичные команды, поскольку по умолчанию поведением для строк является их вывод.

К примеру если ввести число и нажать Enter, то оно будет выведено на экран:

12345
12345

Если ввести строку в двойных кавычках и нажать Enter, то она также будет выведена на экран:

"Just a string"
Just a string

Аналогично для строк в одинарных кавычках:

'Another string'
Another string

Тем не менее, если ввести строку без кавычек (как число), то это вызовет ошибку

The term '…...' is not recognized as a name of a cmdlet, function, script file, or executable program.

Check the spelling of the name, or if a path was included, verify that the path is correct and try again.

Аналогично со строками, которые начинаются на числа — их нужно заключать в кавычки. Разница в поведении, видимо, связана с тем, что имена функций и командлетов не могу составлять только из чисел, поэтому числа трактуются буквально, а все другие строки трактуются как имена командлетов, если они не заключены в кавычки.

Аналогично вывод содержимого переменных не требует echo или других командлетов:

$String = "Строка в переменной"
$String

И при этом в PowerShell имеется поддержка команды echo:

echo 'Just a string'

Ещё пример:

$String = "Строка в переменной";
echo $String

А также есть командлеты для вывода информации:

Write-Host
Write-Output
Write-Information

Можно запутаться, правда?

Для начала уясним, что echo является синонимом Write-Output.

Командлет Write-Information предназначен для вывода обработчиков потоков информации и является сложным по сравнению с обычной функцией echo — его мы рассматривать не будем.

Итак, изучим Write-Host и Write-Output.

Особенности echo в PowerShell

Прежде всего, обратите внимание на разницу в выводе строке, содержащей пробелы, в кавычках и без:

echo Just a string
Just
a
string

echo 'Just a string'
Just a string

Как уже было сказано, echo является псевдонимом для Write-Output, поэтому рассмотрим этот командлет подробнее, чтобы понять другие особенности echo в PowerShell.

Write-Output

Командлет Write-Output отправляет указанный объект по конвейеру следующей команде. Если команда является последней командой в конвейере, объект отображается в консоли.

Write-Output отправляет объекты по основному конвейеру, также известному как «выходной поток» или «конвейер SUCCESS». Чтобы отправить объекты ошибок по конвейеру ошибок, используйте Write-Error.

Этот командлет обычно используется в сценариях для отображения строк и других объектов на консоли. Однако, поскольку поведение по умолчанию заключается в отображении объектов в конце конвейера, обычно нет необходимости использовать командлет. Например,

Get-Process | Write-Output

эквивалентно

Get-Process

Итак, одной из особенностей echo и Write-Output является то, что эти команды не требуются.

Другая особенность — эти команды работают с объектами, поэтому простая строка с запятыми может быть выведена не так, как вы ожидаете.

К примеру, команда

Write-Output 1,2,3

Выведет:

1
2
3

Аналогично:

Write-Output Just a string
Just
a
string

Дело в том, что эти строки расцениваются как объекты, свойства которых перечислены через запятую и каждое новое свойство выводится на отдельной строке. Если вы хотите избежать такого поведения, то просто помещайте строку в одинарные или двойные кавычки.

Пример 1: Получение объекта и вывод его в консоль

$P = Get-Process
Write-Output $P

Первая команда получает список процессов, запущенных на компьютере, и сохраняет их в переменной $P.

Вторая команда отображает объекты процесса в $P на консоли.

Пример 2: Передача вывода другому командлету

Write-Output "test output" | Get-Member

Эта команда передаёт строку «test output» командлету Get-Member, который отображает члены класса System.String, демонстрируя, что строка была передана по конвейеру.

Пример 3: Подавление перечисления в выводе

Write-Output @(1,2,3) | Measure-Object

Вывод:

Count    : 3
...

Write-Output @(1,2,3) -NoEnumerate | Measure-Object

Вывод:

Count    : 1
...

Эта команда добавляет параметр -NoEnumerate для обработки коллекции или массива как одного объекта в конвейере.

Write-Host

Командлет Write-Host является продвинутым аналогом Write-Output.

Командлет Write-Host настраивает вывод. Вы можете указать цвет текста, используя параметр -ForegroundColor, и вы можете указать цвет фона, используя параметр -BackgroundColor. Параметр -Separator позволяет указать строку (символ или набор символов), которая будет использоваться для разделения отображаемых объектов. Конкретный результат зависит от программы, в которой размещается PowerShell.

Начиная с Windows PowerShell 5.0, «Write-Host» является оболочкой для «Write-Information». Это позволяет вам использовать «Write-Host» для отправки вывода в информационный поток. Это позволяет захват или подавление данных, записанных с помощью Write-Host, при сохранении обратной совместимости

Опции Write-Host

-BackgroundColor

Падает цвет фона. По умолчанию значение не установлено. Допустимые значения для этого параметра:

Black
DarkBlue
DarkGreen
DarkCyan
DarkRed
DarkMagenta
DarkYellow
Gray
DarkGray
Blue
Green
Cyan
Red
Magenta
Yellow
White

-ForegroundColor

Задает цвет текста. По умолчанию значение не установлено. Допустимые значения для этого параметра:

Black
DarkBlue
DarkGreen
DarkCyan
DarkRed
DarkMagenta
DarkYellow
Gray
DarkGray
Blue
Green
Cyan
Red
Magenta
Yellow
White

-NoNewline

Параметр делает так, что строковые представления входных объектов объединяются для формирования выходных данных. Между строками вывода не вставляются пробелы или символы новой строки. Новая строка не добавляется после последней выходной строки.

-Separator

Падает разделительную строку для вставки между объектами, отображаемыми хостом.

Write-Host отправляет объекты на хост. Сам командлет не возвращает никаких объектов. Однако хост может отображать объекты, которые посылает ему Write-Host.

Примеры Write-Host

Пример 1: Запись в консоль без добавления символа новой строки:

Write-Host "no newline test " -NoNewline; Write-Host "second string"

Эта команда отображает строку «no newline test» с параметром -NoNewline.

Затем записывается вторая строка, но она оказывается на той же строке, что и первая, из-за отсутствия символа новой строки, разделяющей строки.

Сравните с поведением по умолчанию:

Write-Host "no newline test "; Write-Host "second string"

Пример 2: Запись в консоль и замена стандартного разделителя

Write-Host (2,4,6,8,10,12) -Separator ", +2= "
2, +2= 4, +2= 6, +2= 8, +2= 10, +2= 12

Эта команда отображает чётные числа от двух до двенадцати. Параметр -Separator используется для добавления строки «, +2= » (запятая, пробел, +, 2, =, пробел)`.

Пример 3: Вывод с другим цветом текста и фона

Write-Host (2,4,6,8,10,12) -Separator ", -> " -ForegroundColor DarkGreen -BackgroundColor White

Эта команда отображает чётные числа от двух до двенадцати. Она использует параметр -ForegroundColor для вывода темно-зеленого текста и параметр -BackgroundColor для отображения белого фона.

Пример 4: Вывод с разными цветами текста и фона

Write-Host "Red on white text." -ForegroundColor red -BackgroundColor white

Эта команда отображает строку «Red on white text». Текст имеет красный цвет, как определено параметром -ForegroundColor. Фон является белым, как определено параметром -BackgroundColor.

Пример 5: Подавление вывода от Write-Host

# Следующие два оператора могут использоваться для эффективного подавления вывода от Write-Host
Write-Host "I won't print" -InformationAction Ignore
Write-Host "I won't print" 6>$null

Эти команды эффективно подавляют вывод командлета Write-Host. Первый использует параметр -InformationAction со значением «Ignore» для подавления вывода в информационный поток. Второй пример перенаправляет информационный поток команды в переменную «$null» и тем самым подавляет его.

Подавление вывода echo и Write-Output

Для подавления вывода echo и Write-Output используется одинаковая конструкция:

echo 'Эта строка не будет показана' > $null
Write-Output 'Эта строка не будет показана' > $null

Подавление стандартного вывода

Стандартный вывод могут показывать не только echo и Write-Output. Поэтому конструкция «> $null» может работать не всегда.

Как было показано выше, иногда информационный поток имеет другой номер, например:

Write-Host "I won't print" 6>$null

Тем не менее, в большинстве случаев для подавления вывода достаточно перенаправить поток в «$null»:

Get-ChildItem > $null

Заключение

Итак, для вывода в консоль можно использовать следующие команды:

Write-Output
echo (псевдоним Write-Output)
Write-Information (вывод с возможностью поменять текст цвета и фона).

Ещё парочка примеров применения вывода в консоль. Следующая команда покажет строку «Current user: », а затем на этой же строке выведет результат работы команды «whoami»:

Write-Host "Current user: " -NoNewline; Write-Host $(whoami)

В следующем пример содержимое файла записывается в переменную, затем значение переменной выводится в консоль:

$From = Get-Content -Path .CopyFromFile.txt
$From

Связанные статьи:

Как в PowerShell сохранить вывод в файл (аналоги > и >>) (100%)
Как в PowerShell менять набор выводимых по умолчанию данных (100%)
Как выводить данные без таблицы в PowerShell (100%)
В PowerShell таблица не помещается на экран — как исправить (РЕШЕНО) (100%)
Как вывод скрипта PowerShell записать в файлы журнала (100%)
Ошибки «Оператор «<» зарезервирован для использования в будущем» и «The ‘<‘ operator is reserved for future use.» (РЕШЕНО) (RANDOM — 100%)

Источник

Вы можете использовать простые текстовые лог файлы для контроля запуска и отслеживания всех действий, которые выполняются при запуске PowerShell скриптов. Это удобно при отладке ошибок, для аудита выполненных скриптом действий. В этой статье мы рассмотрим несколько способов ведения текстовых лог-файлов для ваших PowerShell скриптов.

В самом простом случае, если вам нужно записать вывод информационного сообщения или результатов определенной PowerShell команды в текстовый лог файл, вы можете использовать один из следующих форматов перенаправления вывода в txt файл:

Write-Output "Файлы созданы успешно на $env:computername" >> C:PSLogsTestLog.txt

Add-Content -Path C:PSLogsTestLog.txt -Value "Файлы созданы успешно на $env:computername"

"Файлы созданы успешно на $env:computername" | Out-File -FilePath C:PSLogsTestLog.txt –Append

Во всех случаях команды добавляют в указанный текстовый файл новую строку c указанным вами текстом.

Если вам нужно каждый раз перезатирать содержимое ло-файла, используйте Set-Content.

Тем не менее, если ввести строку без кавычек (как число), то это вызовет ошибку

The term '…...' is not recognized as a name of a cmdlet, function, script file, or executable program.

Check the spelling of the name, or if a path was included, verify that the path is correct and try again.

Аналогично вывод содержимого переменных не требует echo или других командлетов:

$String = "Строка в переменной"
$String

И при этом в PowerShell имеется поддержка команды echo:

echo 'Just a string'

Ещё пример:

$String = "Строка в переменной";
echo $String

А также есть командлеты для вывода информации:

Write-Host
Write-Output
Write-Information

Можно запутаться, правда?

Для начала уясним, что echo является синонимом Write-Output.

Итак, изучим Write-Host и Write-Output.

Особенности echo в PowerShell

Прежде всего, обратите внимание на разницу в выводе строке, содержащей пробелы, в кавычках и без:

echo Just a string
Just
a
string

echo 'Just a string'
Just a string

Write-Output

Get-Process | Write-Output

эквивалентно

Get-Process

Итак, одной из особенностей echo и Write-Output является то, что эти команды не требуются.

К примеру, команда

Write-Output 1,2,3

Выведет:

1
2
3

Аналогично:

Write-Output Just a string
Just
a
string

Пример 1: Получение объекта и вывод его в консоль

$P = Get-Process
Write-Output $P

Первая команда получает список процессов, запущенных на компьютере, и сохраняет их в переменной $P.

Вторая команда отображает объекты процесса в $P на консоли.

Пример 2: Передача вывода другому командлету

Write-Output "test output" | Get-Member

Пример 3: Подавление перечисления в выводе

Write-Output @(1,2,3) | Measure-Object

Вывод:

Count    : 3
...

Write-Output @(1,2,3) -NoEnumerate | Measure-Object

Вывод:

Count    : 1
...

Эта команда добавляет параметр -NoEnumerate для обработки коллекции или массива как одного объекта в конвейере.

Write-Host

Командлет Write-Host является продвинутым аналогом Write-Output.

Опции Write-Host

-BackgroundColor

Падает цвет фона. По умолчанию значение не установлено. Допустимые значения для этого параметра:

Black
DarkBlue
DarkGreen
DarkCyan
DarkRed
DarkMagenta
DarkYellow
Gray
DarkGray
Blue
Green
Cyan
Red
Magenta
Yellow
White

-ForegroundColor

Задает цвет текста. По умолчанию значение не установлено. Допустимые значения для этого параметра:

Black
DarkBlue
DarkGreen
DarkCyan
DarkRed
DarkMagenta
DarkYellow
Gray
DarkGray
Blue
Green
Cyan
Red
Magenta
Yellow
White

-NoNewline

-Separator

Падает разделительную строку для вставки между объектами, отображаемыми хостом.

Примеры Write-Host

Пример 1: Запись в консоль без добавления символа новой строки:

Write-Host "no newline test " -NoNewline; Write-Host "second string"

Эта команда отображает строку «no newline test» с параметром -NoNewline.

Сравните с поведением по умолчанию:

Write-Host "no newline test "; Write-Host "second string"

Пример 2: Запись в консоль и замена стандартного разделителя

Write-Host (2,4,6,8,10,12) -Separator ", +2= "
2, +2= 4, +2= 6, +2= 8, +2= 10, +2= 12

Пример 3: Вывод с другим цветом текста и фона

Write-Host (2,4,6,8,10,12) -Separator ", -> " -ForegroundColor DarkGreen -BackgroundColor White

Пример 4: Вывод с разными цветами текста и фона

Write-Host "Red on white text." -ForegroundColor red -BackgroundColor white

Пример 5: Подавление вывода от Write-Host

# Следующие два оператора могут использоваться для эффективного подавления вывода от Write-Host
Write-Host "I won't print" -InformationAction Ignore
Write-Host "I won't print" 6>$null

Подавление вывода echo и Write-Output

Для подавления вывода echo и Write-Output используется одинаковая конструкция:

echo 'Эта строка не будет показана' > $null
Write-Output 'Эта строка не будет показана' > $null

Подавление стандартного вывода

Как было показано выше, иногда информационный поток имеет другой номер, например:

Write-Host "I won't print" 6>$null

Тем не менее, в большинстве случаев для подавления вывода достаточно перенаправить поток в «$null»:

Get-ChildItem > $null

Заключение

Итак, для вывода в консоль можно использовать следующие команды:

Write-Output
echo (псевдоним Write-Output)
Write-Information (вывод с возможностью поменять текст цвета и фона).

Write-Host "Current user: " -NoNewline; Write-Host $(whoami)

$From = Get-Content -Path .CopyFromFile.txt
$From

Связанные статьи:

Как в PowerShell сохранить вывод в файл (аналоги > и >>) (100%)
Как в PowerShell менять набор выводимых по умолчанию данных (100%)
Как выводить данные без таблицы в PowerShell (100%)
В PowerShell таблица не помещается на экран — как исправить (РЕШЕНО) (100%)
Как вывод скрипта PowerShell записать в файлы журнала (100%)
Ошибки «Оператор «<» зарезервирован для использования в будущем» и «The ‘<‘ operator is reserved for future use.» (РЕШЕНО) (RANDOM — 100%)

Источник

Write-Output "Файлы созданы успешно на $env:computername" >> C:PSLogsTestLog.txt

Add-Content -Path C:PSLogsTestLog.txt -Value "Файлы созданы успешно на $env:computername"

"Файлы созданы успешно на $env:computername" | Out-File -FilePath C:PSLogsTestLog.txt –Append

Во всех случаях команды добавляют в указанный текстовый файл новую строку c указанным вами текстом.

Если вам нужно каждый раз перезатирать содержимое ло-файла, используйте Set-Content.

Главный недостаток такого метода – по такому лог файлу нельзя определить, когда была внесена та или иная запись в лог (произошло событие). Вы можете добавить в лог текущую метку даты, времени (timestamp). Это поможет легко идентифицировать время запуска скрипта и конкретного события в нем.

Для удобства можно создать в PowerShell скрипте отдельную функцию, которая будет сохранять переданные ей данные в лог файл и добавлять время записи информации.

Можно сделать функцию:

$Logfile = "C:PSLogsproc_$env:computername.log" function WriteLog { Param ([string]$LogString)

$Stamp = (Get-Date).toString("yyyy/MM/dd HH:mm:ss") $LogMessage = "$Stamp $LogString" Add-content $LogFile -value $LogMessage }

Теперь, чтобы записать что-то в лог файл, вам нужно вызвать функцию WriteLog.

WriteLog "Скрипт запущен” WriteLog "Выполняю вычисления…." Start-Sleep 20 WriteLog "Скрипт выполнен успешно"

Теперь в лог файле содержится время, когда была произведена запись.

Можете заменить в своем скрипте вызовы Write-host на LogWrite.

В PowerShell также есть встроенная возможность сохранять в текстовый лог файл все команды и результаты, которые выводятся в консоль PS.

Чтобы начать запись текущей PowerShell сессии, используется командлет Start-Transcript.

После запуска этой команды появляется сообщение, в котором указано, в какой файл сохраняются результаты всех команд. По умолчанию лог файл пишется в профиль текущего пользователя:

Transcript started, output file is C:UsersAdministratorDocumentsPowerShell_transcript.DC01.inhP7egx.20210315041442.txt

Можно указать путь к текстовому файлу так:

Start-Transcript -Append C:PSLogsPSScriptLog.txt

Параметр –Append указывает, что нужно дописывать новые сессию в конец лог файла (не перезатирать его).

Выполните несколько PowerShell команд, которые выводят результаты в консоль. Например, выведем список тяжелых запущенных процессов, запущенных служб и состояние репликации в AD:

Get-Process| where-object {$_.WorkingSet -GT 300000*1024}|select processname,@{l="Used RAM(MB)"; e={$_.workingset / 1mb}} |sort "Used RAM(MB)" –Descending Get-Service | Where-Object {$_.status -eq 'running'} Get-ADReplicationFailure -Target DC01

Завершите запись сессии для текущей сессии:

Stop-Transcript

Теперь откройте текстовый файл с логом.

Как вы видите, в текстовом логе отображаются вся история PowerShell команд, которые запускались в скрипте и весь вывод, который выводился в консоль.

В лог файл попадают в том числе все ошибки и предупреждения, что бывает крайне удобно при диагностике и отладке сложных PowerShell скриптов.

Вы можете использовать Start-Transcript/Stop-Transcript в своих PowerShell скриптах чтобы нативно логировать все действия и результаты.

С помощью групповой политики Turn on PowerShell Transcription в Computer Configuration –> Administrative Templates –> Windows Components –> Windows PowerShell можно включить автоматическое логирование всех запускаемых PowerShell команд и выводимых результатов на компьютере. После обновления настроек GPO на компьютере, для каждого запущенного процесса powershell.exe будет создаваться отдельный тектовый лог файл, куда будут записываться все PS команды и результаты результаты.

Источник

Вообще я редко вижу смысл в том чтобы отлавливать ошибки в скриптах, но недавно ко мне попалась задача, где необходимо было обработать ошибки в скрипте PowerShell. Дело в том что данный скрипт использовался как часть работы System Center Orchestrator. Для этого я использовал Try/Catch/Finaly . Но все по порядку.

Немного про ошибки

Ошибки можно условно разделить на две больших категории.

Прерывающие
Не прерывающие

Первые завершают выполнение конвейера с ошибкой. Т.е. дальнейшие команды в конвейере не выполняются. Например, вы не правильно указали имя команды. Вторая категория лишь генерирует ошибку, но конвейер продолжает выполняться далее. Например, вы запросили содержимое не существующего каталога.

В любом случае всю информацию о всех ошибках можно поглядеть в переменной $error. Последняя ошибка идет с индексом 0, т.е. $error[0] — покажет последнюю ошибку. А $error[0].Exception описание последней ошибки.

PS C:> Get-Command NoCommand,Dir

Get-Command : Имя «NoCommand» не распознано как имя командлета, функции, файла сценария или выполняемой программы. Пров

ерьте правильность написания имени, а также наличие и правильность пути, после чего повторите попытку.

строка:1 знак:1

+ Get-Command NoCommand,Dir

+ ~~~~~~~~~~~~~~~~~~~~~~~~~

+ CategoryInfo : ObjectNotFound: (NoCommand:String) [Get-Command], CommandNotFoundException

+ FullyQualifiedErrorId : CommandNotFoundException,Microsoft.PowerShell.Commands.GetCommandCommand

CommandType Name ModuleName

—————— —— —————

Alias dir -> Get-ChildItem

PS C:> $error[0]

Get-Command : Имя «NoCommand» не распознано как имя командлета, функции, файла сценария или выполняемой программы. Пров

ерьте правильность написания имени, а также наличие и правильность пути, после чего повторите попытку.

строка:1 знак:1

+ Get-Command NoCommand,Dir

+ ~~~~~~~~~~~~~~~~~~~~~~~~~

+ CategoryInfo : ObjectNotFound: (NoCommand:String) [Get-Command], CommandNotFoundException

+ FullyQualifiedErrorId : CommandNotFoundException,Microsoft.PowerShell.Commands.GetCommandCommand

PS C:> $error[0].Exception

Имя «NoCommand» не распознано как имя командлета, функции, файла сценария или выполняемой программы. Проверьте правильн

ость написания имени, а также наличие и правильность пути, после чего повторите попытку.

Этот же пример, но в виде рисунка для наглядности.

Для того чтобы выяснить была ли в какой-то части кода ошибка необходимо использовать Try. Это помогает избавиться от неожиданного и некорректного завершение вашего скрипта. Позволяя так же корректно завершить его работу.

Синтаксис выглядит в общем случае так.

Try

{

часть кода в которой ищем ошибку

}

Catch

{

[тип ошибки, которую ищем] код,

который будет выполнен когда ошибка будет найдена

}

Finally

{

код, который будет выполнен в любом случае

}

Однако использование Finally и определение типа ошибки — опционально и может не использоваться.

Для проверки напишем вот такой код где используем Try в PowerShell для того чтобы обработать ошибку деления на ноль и вывести информацию об ошибке.

try

{

[float](4/0)

}

catch

{

Write-Host «Error!!!»

Write-Host $error[0].Exception

}

Как видно я произвожу деление на ноль в блоке try, т.е. совершаю прерывающую ошибку. Только прерывающие ошибку будут отловлены. А далее в блоке catch произвожу уже необходимые отладочные действия, т.е. произвожу обработку ошибки.. В моей исходной задаче я в данном блоке заносил информацию об ошибках в специальный лог файл, но давайте попробуем запустить мой данный пример.

PS C:> .test.ps1

Error!!!

System.Management.Automation.RuntimeException: Попытка деления на нуль. —-> System.DivideByZeroException: Попытка делен

ия на нуль.

—— Конец трассировки внутреннего стека исключений ——

в System.Management.Automation.ExceptionHandlingOps.CheckActionPreference(FunctionContext funcContext, Exception exce

ption)

в System.Management.Automation.Interpreter.ActionCallInstruction`2.Run(InterpretedFrame frame)

в System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame)

Увы в блоке try в PowerShell должна присутствовать прерывающая ошибка.

Преобразуем не прерывающую ошибку в прерывающую

Существует общий параметр для всех командлетов в PowerShell -ErrorAction. Данный параметр может принимать четыре значения

Continue — выводит ошибку и продолжает выполнение
SilentlyContinue — не выводит ошибку и продолжает выполнение
Stop — завершает выполнение
Inquire — спрашивает у пользователя как поступить

В нашем случае подходит действие stop. Если использовать параметр со значением -ErrorAction Stop, то при возникновении ошибки при выполнении команды, данная ошибка прерывает выполнение команды. Ниже пример скрипта, использующего -ErrorAction Stop.

try

{

Dir NoFolder -ErrorAction Stop

}

catch

{

Write-Host «Error!!!»

Write-Host $error[0].Exception

}

Ниже результат выполнения данного скрипта

PS C:> .test.ps1

Error!!!

System.Management.Automation.ItemNotFoundException: Не удается найти путь «C:NoFolder»,

так как он не существует.

в System.Management.Automation.SessionStateInternal.GetChildItems(String path, Boolean recurse, C

mdletProviderContext context)

в Microsoft.PowerShell.Commands.GetChildItemCommand.ProcessRecord()

В моей исходной задаче try в PowerShell необходимо было использовать для всех команд в скрипте. Поскольку обработка ошибки была общей для любой ошибки в скрипте весь скрипт можно поместить в один Try, конечно это не совсем правильно, но зато просто. Чтобы каждый раз не писать -ErrorAction Stop. Можно воспользоваться переменной $ErrorActionPreference, которая имеет те же значения и сходна по действию, однако распространяет свое действие на все командлеты в скрипте.

$ErrorActionPreference = «stop»

try

{

Dir Folder

Get-Process -ComputerName TestPC

}

catch

{

Write-Host «Error!!!»

Write-Host $error[0].Exception

}

Вместо заключения

Конечно, по началу вы мало будете задумываться об поиске ошибок, используя множество условных конструкций вы их минимизируете. Однако использование try в PowerShell позволит минимизировать случаи неожиданного завершения скрипта.

Источник

Всем привет.

В предыдущих двух постах были подробно изложены методы отлова критических и некритических ошибок при работе с PowerShell. Но я решил что будет несправедливым не отметить самые основные моменты, которые возникают в работе если что-то пошло не так. Т.е. переменные и обьекты в PowerShell которые содержат первичную информацию о работе нашего скрипта. Речь пойдет об объекте ErrorRecord, о переменной $Error, о мониторинге возникновения ошибки c помощью переменной $? и кодов возврата, а также упомянем командлет Set-PSDebug и точки прерывания. Поможет нам в этом замечательная книга Попова А. В. «Введение в Windows PowerShell» — СПб.: БХВ-Петербург, 2009.

Поехали.

1. Объект ErrorRecord и поток ошибок.

В PowerShell информация о возникающих ошибках записывается в поток ошибок, который по умолчанию отображается на экране, например:
PS C:> dir «C:Folder doesn’t exist»
Get-ChildItem : Не удается найти путь «C:Folder doesn’t exist»,
так как он не существует.
В строка:1 знак:4
+ dir <<<< «C:Folder doesn’t exist»

Поток ошибок можно перенаправить в текстовый файл с помощью специального оператора 2>, например:
PS C:> dir «C:Folder doesn’t exist» 2>err.txt

Проверим теперь содержимое файла err.txt:
PS C:> Get-Content err.txt
Get-ChildItem : Не удается найти путь «C:Folder doesn’t exist»,
так как он не существует.
В строка:1 знак:4
+ dir <<<< «Folder doesn’t exist» 2> err.txt
Как видите, в файл err.txt полностью записалось сообщение об ошибке, однако никакой дополнительной информации не появилось.

Где произошла ошибка смотрим так
PS C:> $err.InvocationInfo
MyCommand : Get-ChildItem
ScriptLineNumber : 1
OffsetInLine : -2147483648
ScriptName :
Line : $err = dir «C:Folder doesn’t exist» 2>&1
PositionMessage :
В строка:1 знак:11
+ $err = dir <<<< «C:Folder doesn’t exist» 2>&1
InvocationName : dir
PipelineLength : 1
PipelinePosition : 1
Хотя этот вывод даст нам место скрипта(или непсредственного ввода)
где ошибку интепретирует сама PowerShell, истинное место проблемы надо будет
искать самим.

2. Специальная переменная $Error.

В PowerShell имеется специальная переменная $Error, которая содержит коллекцию (массив) объектов ErrorRecord, соответствующих ошибкам, возникавшим в текущем сеансе работы. Максимальное количество элементов в данной коллекции задается значением переменной $MaximumErrorCount (по умолчанию это 256):
PS C:> $MaximumErrorCount
256

После заполнения массива $Error объекты для вновь возникающих ошибок будут заменять объекты, соответствующие старым ошибкам. Возникновение каждой новой ошибки приводит к смещению элементов в массиве $Error: объект для последней ошибки хранится в первом элементе ($Error[0]), объект для предыдущей ошибки — во втором элементе ($Error[1]) и т. д.
Убедимся, что элемент $Error[0] имеет тип ErrorRecord, и выведем содержимое этого элемента:
PS C:> $Error[0].GetType().FullName
System.Management.Automation.ErrorRecord

PS C:> $Error[0]
Get-ChildItem : Не удается найти путь «C:Несуществующий каталог»,
так как он не существует.
В строка:1 знак:4
+ dir <<<< «Несуществующий каталог»
Естественно, мы можем обращаться ко всем свойствам объекта ErrorRecord:

PS C:> $Error[0].Exception
Не удается найти путь «C:Несуществующий каталог», так как он не существует.

Повторим вывод свойства InvocationInfo
PS C:> $Error[0].InvocationInfo
MyCommand : Get-ChildItem
ScriptLineNumber : 1
OffsetInLine : -2147483648
ScriptName :
Line : $err = dir «C:Folder doesn’t exist» 2>&1
PositionMessage :
В строка:1 знак:11
+ $err = dir <<<< «C:Folder doesn’t exist» 2>&1
InvocationName : dir
PipelineLength : 1
PipelinePosition : 1

3. Мониторинг возникновения ошибки переменной $?.

В PowerShell имеется логическая переменная $?, которая равна $True, если последняя выполняемая операция завершена успешно, и $False, если во время выполнения последней
операции возникла ошибка. Такая же существует и в Linux.) Например, если выполнить командлет Get-Item для заведомо существующего каталога, то значение переменной $? будет равно $True:
PS C:> Get-Item С:
Каталог:
Mode LastWriteTime Length Name
—- ————- —— —-
d—hs 21.03.2016 12:00 C:

PS C:> $?
True

Если же выполнить этот же командлет для несуществующего каталога, то значение переменной $? будет равно $False:
PS C:> Get-Item С:321
Get-Item : Не удается найти путь «C:321», так как он не существует.
В строка:1 знак:9
Глава 9. Обработка ошибок и отладка 183
+ Get-Item <<<< С:321
PS C:> $?
False

4. Мониторинг возникновения ошибки по коду возврата.

Для внешних команд Windows и сценариев PowerShell определено понятие кода возврата (напомним, что для сценариев PowerShell этот код можно установить с помощью инструкции Exit). В операционной системе код возврата последней команды доступен через переменную среды %ERRORLEVEL%; в оболочке PowerShell данный код возврата хранится в специальной переменной $LASTEXITCODE. При этом, если код возврата равен нулю, то переменной $? присваивается значение $True. Если же код возврата не равен нулю, то считается, что при выполнении данной команды произошла ошибка, и переменной $? присваивается значение $False.

В качестве примера выполним команду интерпретатора cmd.exe, которая устанавливает нулевой код возврата. Для этого можно запустить cmd.exe с ключом /c (выполнить команду и завершить работу интерпретатора) и указать для исполнения команду exit 0:
PS C:> cmd /c exit 0

Проверим значения переменных $LASTEXITCODE и $?:
PS C:> $LASTEXITCODE
0
PS C:> $?
True
Теперь выполним команду интерпретатора cmd.exe с ненулевым кодом возврата (пусть, например, код возврата равен 10):
PS C:> cmd /c exit 10
Вновь проверим переменные $LASTEXITCODE и $?:
PS C:> $?
False
PS C:> $LASTEXITCODE
10

5. Командлет Set-PSDebug и точки прерывания.

Процесс поиска ошибок в сценариях неразрывно связан с отладкой. Поэтому нам стоит упомянуть что основным встроенным инструментом для отладки сценариев является командлет Set-PSDebug. Параметры этого командлета позволяют включить режимы трассировки и пошагового выполнения команд, а также режим обязательного объявления переменных:
-Trace 0 Отключение трассировки
-Trace 1 Включение основного режима трассировки
-Trace 2 Включение полного режима трассировки
-Step Включение режима пошагового выполнения
-Strict Включение режима обязательного объявления переменных
-Off Отключение всех механизмов отладки.

Примеры приводить не буду, назначение ключей очевидно из их названия. Самым интересным является режим пошагового выполнения -Step, который позволяет в любой момент вызвать вложенную командную строку для анализа или изменения состояния интерпретатора. Однако отлаживать более-менее большие сценарии с помощью данного метода часто оказывается неудобно, так как для запуска вложенного сеанса в определенной строке сценария придется каждый раз добираться до этой строки с самого начала сценария (каждую команду при этом
нужно выполнять, нажимая клавишу <A>).

Гораздо удобнее было бы использовать точки прерывания, позволяющие запускать сценарий в автоматическом режиме и приостанавливать выполнение на нужной команде. В PowerShell аналогом установки точки прерывания можно считать вызов метода $Host.EnterNestedPrompt(), например:
PS C:> for ($i=0; $i -lt 10; $i++) {
>> «i = $i»
>> if ($i -eq 5) {
>> «Моя точка прерывания»
>> $Host.EnterNestedPrompt()
>> }
>> }
>>
i = 0
i = 1
i = 2
i = 3
i = 4
i = 5
Моя точка прерывания
PS C:>>>

В данном примере на пятой итерации цикла выводится строка «Моя точка прерывания» и вызывается метод $Host.EnterNestedPrompt(). В результате выполнение цикла приостанавливается, и мы попадаем во вложенную командную строку (вид приглашения изменяется на >>>).

Выход из вложенного сеанса с помощью инструкции Exit:
PS C:>>> Exit
PS C:>

Вот так вот.

Источник

Как Powershell обрабатывает ошибки

Автоматические переменные $Error

Свойства объекта $Error

Методы объекта $Error

<img decoding="async" alt="Очистка логов об ошибке в Powershell с $Error" src="https://fixmypc.ru/media/uploads/2020/10/02/19.jpg" title="Очистка логов об ошибке в Powershell с $Error" />

Критические ошибки (Terminating Errors)

Не критические ошибки (Non-Terminating Errors)

Параметр ErrorVariable

Обработка некритических ошибок

Приоритет ошибок с $ErrorActionPreference

Использование параметра ErrorAction

Обработка критических ошибок и исключений с Try, Catch и Finally

Catch для всех типов исключений

<img decoding="async" alt="Вывод сообщения об ошибке в блоке try и catch в Powershell" src="https://fixmypc.ru/media/uploads/2020/10/01/15.jpg" title="Вывод сообщения об ошибке в блоке try и catch в Powershell" />

Создание отдельных исключений

Выброс своих исключений

Выброс с throw

Использование Write-Error

Why Should We Bother Handling Errors In PowerShell

Example Of PowerShell Error Handling

Chain Of Events When PowerShell Error Occurs

How To Write PowerShell Errors Into The External Log File

Write-ErrorLog CmdLet Code

Write-ErrorLog CmdLet Explained

$PSItem or $_

Errors In PowerShell

Terminating Errors

Non-Terminating Errors

How To Force Non-Terminating Errors Into Terminating

How To Treat All Errors As Terminating

ErrorAction Common Parameter

$ErrorActionPreference Preference Variable Explained

Error Handling With Try/Catch/Finally Blocks

Getting Error Information With $Error Automatic Variable

Write-Error CmdLet

Handling Errors from non-PowerShell processes

Useful PowerShell Error Handling Articles

Особенности echo в PowerShell

Write-Output

Write-Host

Опции Write-Host

Примеры Write-Host

Подавление вывода echo и Write-Output

Подавление стандартного вывода

Заключение

Связанные статьи:

Особенности echo в PowerShell

Write-Output

Write-Host

Опции Write-Host

Примеры Write-Host

Подавление вывода echo и Write-Output

Подавление стандартного вывода

Заключение

Связанные статьи:

Немного про ошибки

Преобразуем не прерывающую ошибку в прерывающую

Вместо заключения