To use PowerDbg you must first establish a ‘session’. This establishes PowerDbg’s internal connection between a local debugger and either a memory dump, live process or remote debugger.
Sessions are established using the New-DbgSession
cmdlet, and can be instantiated in one of four ways:
- attach to a running process by name (-process
- launch a process under the debugger (-command
- opening a memory dump in the debugger (-dump
- connecting to an existing debugger configured as a server (-remote
Additionally PowerDbg can be instructed to auto-load SOS (if possible), using the
parameter. This can only be performed if the process in question has already loaded the CLR, and so is not applicable to the -command method.
The PowerDbg 'unhandled exception' demo can be run under the debugger as follows (note the quotes which allow us to pass an argument to the process being launched):
PS > New-DbgSession -command '.\blah\ManagedScenarios.exe UnhandledExceptionScenario'
PS > Send-DbgGo
(1104.730): CLR exception - code e0434f4d (first chance)
(1104.730): CLR exception - code e0434f4d (!!! second chance !!!)
000007fe`fdedaa7d 4881c4c8000000 add rsp,0C8h
Since the the debugger immediately
breaks into the launched process, we have to use
to allow the process to continue on (and subsiquently fail). When creating a session to a memory dump or a remote debugger already halted at the point of interest, this would be unnecessary.
Once a PowerDbg session exists you can interact with it using any of the Get-Dbg* cmdlets, or by using
to send commands directly.
- Each PowerShell window running PowerDbg can only support one such session at a time
- The session is automatically terminated when the PowerDbg module is unloaded (Remove-Module PowerDbg)
- The debugger is attached invasively, and so the debuggee will terminate when the session is ended