Debug Engine Runs Get-Process
We have lift off!
I’ve gotten the debug engine to execute PowerShell scripts! Right now it isn’t much of a debugger because it doesn’t honor breakpoints or halt at all. It will run through to completion each time the script is run. I did manage to get script output to display in the Visual Studio Output window. Attacking some of the fun aspects of the engine will be next in the line up. It will be great to get breakpoints, variable information and stack frames exposed. If you feel like playing with the latest engine go and grab this changeset. I will be releasing a beta 1.1 as soon as I get a few more debugging features complete.
If you’re interested in learning how I got it goin’ read on, otherwise check back for more updates next week sometime.
Turning the Key
The secret sauce to a debug engine is not to over think it. When I started out I used the Debug Sample Engine as a shell for my engine. I wouldn’t recommend this. Unless you are implementing some sort of native debugger it may be better to use the sample as merely reference material and implement only the necessary interfaces. I started out with like 30 different classes and boiled it down to three primary implementations: the engine the process, and the program.
The Engine
I implemented IDebugEngine2 and IDebugEngineLaunch2 on my debug engine implementation. IDebugEngineLaunch2 is necessary to allow the debugger to “launch” the process to be debugged. Here is the sequence to get a successful launch:
- LaunchSuspended
- Return your implementation of IDebugProcess2
- Make sure to store the IDebugPort2 supplied by the method call into the process
- ResumeProcess
- Get the port from the provided process
- Cast it to a IDebugDefaultPort2
- Get the IDebugPortNotify2
- Call AddProgramNode; supplying your implementation of IDebugProgramNode2
- IDebugEngine2.Attach
- Get the program Id from the supplied array (should only be 1 program in the array) and keep track of that Id
- Create an instance of IDebugProgramPublisher2 and publish the IDebugProgramNode2 with the Id received in the previous step
- Call IDebugEngineCreateEvent2, IDebugProgramCreateEvent2, IDebugLoadCompleteEvent2, and IDebugEntryPointEvent2
- Go on your merry way
The Process
The process does little more than hold onto an Id and the program node. The SDM will request both these items periodically. Make sure you return the same GUID in GetPhysicalProcessId and GetProcessId.
The Program
Right now the program seems like the most important implementation and also, for me, the least complete. The interfaces I’ve implementation are IDebugProgramNode2, IDebugProgram2, IDebugProgramNodeAttach2, IDebugEngineProgram2. Not quite sure if they are all necessary at this point but here are a few tips.
- Make sure to return the correct engine Id from GetEngineInfo
- Make sure to return the correct process Id from GetHostPid
- The program Id should be set to the one supplied by IDebugEngine2.Attach, NOT a self-created one
Hopefully this can get someone off the ground a bit faster. There is a lot of good information here as well.
Feel free to shoot me any questions!
Posted by PowerShell Hacker #10 on July 24, 2010 at 8:20 am
[...] PowerGUI VSX – Debugging a Debugger – Part 2 – Another post and turn of the handle for Visual Studio 2010 PowerShell integration [...]
Posted by PowerGUI VSX – Debugging a Debugger – Part 3 « Adam Driscoll's Blog on August 2, 2010 at 10:10 pm
[...] engine I thought I would share how I accomplished the final stages of integration. In my last segment of this series I talked about launching the engine. Once the engine was launched I faced my next [...]
Posted by PowerGUI VSX – Debugging a Debugger – Part 3 on January 17, 2011 at 3:33 pm
[...] engine I thought I would share how I accomplished the final stages of integration. In my last segment of this series I talked about launching the engine. Once the engine was launched I faced my next [...]