-
Windows PowerShell script debugging
Windows Server 2016 introduced several improvements for script debugging introduced for Windows PowerShell:
Break All
Remote editing
Remote debugging
Job debugging
Runspace debugging
Remote Desired State Configuration debugging
Break All
Break All is a very useful function to stop a script as it’s running so that we can dive into the debugger to find out how the script is running and what the current state of the variables and other elements are. Support has been included for both the Windows PowerShell console and the ISE.
To use the debugger in a console session, press Ctrl+Break In the Windows PowerShell ISE, you can press Ctrl+B or, on the menu, click Debug and then click Break All.
Remote editing
With the current Windows PowerShell ISE, you can open and directly edit a file in a remote Windows
PowerShell session. Using a new command called PSEdit, we can directly edit files locally and in
remote sessions. The following code shows a sample in action:
[Cloud01]: PS C:\> PSEdit C:\WinDemo\Get-ComputerInfo.ps1
When you execute PSEdit, it will open the file in the ISE where you can make changes and save them
to the remote machine and reexecute the code.
Remote debugging
Extending on to the capabilities of remote editing, you can now debug a script running in a remote
session with the ISE.
The Set-PsBreakpoint cmdlet sets the breakpoint in the code and then you use the Write-Debug
cmdlet to output some information for use in your scripts when you encounter a break point. This
drops you into the debugger at that point to perform some additional work and look at the available
information. When a script encounters a breakpoint in a remote session, it will display a message indicating it has done so. Not all remote sessions will support a remote debug session, but when you connect to the remote session using the Connect-PSSession cmdlet, you will see the output. If remote debug is available, you can connect to the session by using the Enter-PSSession cmdlet, which connects you directly to the debugger.
Job debugging
One useful function in Windows PowerShell is the ability to execute scripts as background jobs. These jobs can run without clogging up the main console screen, letting you proceed with additional tasks.
This was fine, but these jobs could sometimes be difficult to troubleshoot and could require a lot of
trial and error in order to develop robust scripts that could truly be run as jobs.
Now, with Server 2016, Windows PowerShell introduces the Debug-Job cmdlet, which gives you the
ability to debug these background jobs more effectively. To get to this break state, the same cmdlet Set-PSBreakPoint or Wait-Debugger is used to “pause” the script and enter the debugger. You can type these cmdlets into your script and then verify the state of the job so that you can verify if it has encountered the breakpoint and is ready to debug.
Runspace debugging
Runspaces were introduced to solve a few problems that background jobs had introduced, such as
resources issues and performance problems. Runspaces are different from jobs in that they generate a
new thread of execution for the environment which doesn’t come with the same overhead as a
background job.
Desired State Configuration
Windows PowerShell Desired State Configuration (DSC) is a hot topic nowadays. DSC is a new
configuration management platform with which administrators can use Windows PowerShell for
deploying and managing software services and also for managing the environment in which these
services run. Windows Server 2016 introduces several improvements to DSC, and in this chapter, we
dive into two of these enhancements: the new Local Configuration Manager and a new partial
configuration feature.
Source of Information : Microsoft Introduction Windows Server 2016
Subscribe to:
Post Comments (Atom)
0 comments: