Debugging

The debugger is wired to PowerShell 7’s own debugging API rather than a re-implementation, which is why its behavior matches what your senior people expect from Visual Studio and the ISE. It’s also regression-tested end to end on every release, on video, in a clean Windows Sandbox — the same evidence chain the rest of the product runs through.

Breakpoints are file-and-line facts, so debugging an unsaved buffer prompts you to save first; there’s deliberately no debug-anyway option, because breakpoints against text that matches no file stop on lines you can’t see. At a stop, the Call Stack panel lists frames innermost first, and selecting a frame re-scopes the Watch panel to it. Watch expressions evaluate through the debugger channel in the paused frame, not through the console, so they can’t deadlock the paused pipeline. Break All (Ctrl+B) converts a running script into a stop at its next statement. Disabled breakpoints stay visible but dimmed, and Remove, Enable, and Disable All live on the Debug menu, greyed out when the set is empty.

A breakpoint is a bookmark that says “pause here.” Click in the margin to the left of a line number and a red dot appears. Press F5, and instead of running to the end, the script pauses at that line. Now you can look at your variables in the Watch panel, step one line at a time with F10, and watch what changes. When you’ve seen enough, F5 lets it finish. It’s the difference between reading about what your script did and watching it happen.

Debugging a file requires that the file on disk match the editor, by design, so what was executed under the debugger is always a saved, identifiable artifact.