Debugging Monad Scripts, Part 6: Trace-Expression, Breakpoint Script

Debugging Monad Scripts, Part 6: Trace-Expression, Breakpoint Script

Rate This
  • Comments 3

Did your command or script fail and/or report an error?  We hope to have a proper script debugger in a future version, but until then, MSH has some handy features to help you figure out what went wrong.  In this series of blog entries, I will present some of those features.  Thanks to Jim Truher [MSFT], Bruce Payette [MSFT], and Jeff Jones [MSFT] for their help in putting this together.

See the Windows "Monad" Shell Beta 2 Documentation Pack ( for general information about Monad.

Part 1: (Terminating vs. Non-Terminating Errors, ErrorRecord)
Part 2: ($error)
Part 3: (write-host)
Part 4: (set-mshdebug)
Part 5: (Preferences and Commandline Options)

Jon Newman [MSFT]


Trace-Expression: Using Tracing

Monad contains built-in tracing which you can enable using the trace-expression cmdlet. We use this for detailed debugging of our own code, and when bugs come in from our customers, we often ask that they turn on specific tracing categories and send us the expanded output. You can also use this to understand what is happening in your own scenarios, although you should expect that the tracing output will be highly technical, and will not be translated to other languages. The Windows "Monad" Shell Beta 2 Documentation Pack ( already contains excellent information in "TracingQuickStart.doc", so I won't elaborate on it here.


Breakpoint Script

Jeff Jones [MSFT] proposes the following scriptlet for creating breakpoints in Monad scripts:

function start-debug
   $scriptName = $MyInvocation.ScriptName
   function prompt
      "Debugging [{0}]>" -f $(if ([String]::IsNullOrEmpty($scriptName)) { "globalscope" } else { $scriptName } )
set-alias bp start-debug

You can dot-source these in your profile or add them directly to your script, then set a breakpoint by inserting "bp" in the script. When this line is hit it puts you into a nested prompt with a modified prompt that tells you what you are debugging. You can examine variables, functions, etc, and when you are done you type "exit" and the script starts running again. This is great when you have a long script and you don't want to step through the whole thing using set-mshdebug -Step.

[Edit: Monad has now been renamed to Windows PowerShell. This script or discussion may require slight adjustments before it applies directly to newer builds.]

Leave a Comment
  • Please add 4 and 2 and type the answer here:
  • Post
  • Hi, guys, any idea of timescales on a Visual Studio based PowerShell debugger and PowerShell aware editor ? Intellisense, code snippets, colour highlighting. Mmmm

    How about some kind of static checking of the scripts eg syntax checking, variable names etc. Just to reduce errors, and speed up development.

    C# to powershell translator ? Eg you find a cool piece of C# you need to use in PowerSHell, past it into the Visual Studio and it translates into powershell synax, again saving a bit of time.

    All the above would help with writing those scripts which must be production quality.

    Love PowerShell. Why did it take Microsoft so long to come up with it ?

  • Thanks, BambooWave.

    There are several IDEs coming around that are starting to offer PowerShell support, with more on their way:

    We plan to improve on this in the future, as well.


  • I still did not found a good debugging environment for my PowerShell development. The thing I use most

Page 1 of 1 (3 items)