New blog location!

I’ve purchased some webspace so I figured I would move my blog onto to it as well. I’m currently working with some Android development and need a space in the cloud to host my data. Please update your bookmarks and visit often!

http://csharpening.net/blog

Surprise! PowerGUI VSX 1.1 – Beta 2

It’s been almost a month since I’ve posted anything about PowerGUI VSX (well…anything). I was on vacation, was pretty swamped at work and moved. But now that I’m a bit more settled I’ve found some time to work on a new  beta of PowerGUI VSX 1.1. Great surprises in this one! PowerGUI 2.2 Beta was recently released; which added native PowerShell debugging. I had to rework some of the PowerGUI VSX debugger to get this going correctly. I also fixed a slew of bugs and added some cool new additions. Here’s a list:

• Fixed a debug installation issue requiring Visual Studio to be run as Administrator the first time it is executed after installation of the VSX
• Added better Property window support to allow for examination of variable properties (and properties of properties, etc…)
• Added Comment\Uncomment\Indent\Unindent toolbar support
• Fixed a bug where renaming an open script file would continue to save to the old file location
• Fixed an issue where multiple tabs of the same script could be opened
• Tabs are now changed when debugging multiple scripts
• Found out that Express editions are not supported (they only support extensions with templates)
• Any cool things inherited from PowerGUI 2.2

Hopefully this drop is a lot easier to install. If you have any issues please let me know ASAP so I can get them handled (Issue tracker, blog messages, twitter, carrier pigeon…whatever). If you don’t have it already you will need PowerGUI 2.2 Beta for this release.

I hope to release a stable version pretty soon here. I’ll see what I can do about the remaining bugs in the backlog. Until then, grab this:

http://powerguivsx.codeplex.com/releases/view/51998

Stay tuned!

PowerGUI VSX Beta 1.1 Status

So Beta 1.1 has been out for about 2 weeks and I’ve received a few issues and the PowerGUI 2.2 Beta has been released. The changes to the debugger are really exciting. They should really help with the breakpoint management I was hoping to implement into the extension. I haven’t had much time to work on the VSX lately due to a busy schedule at work and the fact that I’ve been packing up and getting ready to move this coming weekend. Additionally, next week I will be out of town on vacation. The current build of the VSX is not compatible with Beta 2.2 of PowerGUI. The changes to the debugger are pretty substantial so I will need some time to rework some of the debugging components.  Once I’m a bit more settled in the coming weeks I hope to get a lot more traction on the issues that have been risen and add support for PowerGUI 2.2.

Here is a list of what is currently outstanding:

• No printing support from PowerGUI VSX (28535)
• No support for PowerGUI 2.2 Beta (28533)
• Bug with renaming script files (28532)
• Find and replace is still buggy (28499)
• Multiple tabs of the same script can be opened (28402)
• No automatic checkout (28169)

I apologize for the lack of updates regarding this project but once I have my free time back I will be working on correcting these issues. If anyone is willing to take a look at the code and possibly fix some of these issues feel free to email me directly or upload a patch.

Thanks for all the feedback and support! It is really awesome to have people checking this out.

PowerGUI VSX – Debugging a Debugger – Part 3

Well now that I officially released the PowerGUI VSX Beta 1.1 (twice) with the newly added debug 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 hurtle: breaking and stepping. These features are arguably the most crucial components of any modern debugger.  The Visual Studio debugging API has a ton of interfaces to allow for creating a really versatile engine with all the goodness that comes with debug engines that are baked into the IDE.

Interfaces of Interest

• IDebugPendingBreakpoint2, IDebugBoundBreakpoint2 - Pending and bound breakpoints notify the SDM when to cause the user interface to break
• IDebugThread2 - Retrieved from the IDebugProgramNode2 and break point events, this interface is used to denote a thread within a process.
• IDebugStackFrame2 - An enumeration of stack frames are returned by the thread to describe where in the call stack the current code is executing
• IDebugCodeContext2\IDebugDocumentContext2 - The code and document contexts describe to the editor where within a source file to position the debug cursor

When the user clicks the breakpoint margin in Visual Studio a break point is posted to the SDM in a pending state (as a IDebugPendingBreakpoint2). After the debug engine is loaded, it can enumerate the pending breakpoints to determine which breakpoints can be successfully bound; creating a IDebugBoundBreakpoint2 for each successful binding. When the PowerGUI debugger hits a break point, it sends an event to the VSX which then raises an IDebugBreakpointeEvent2. This debug event provides a IDebugThread2 to the SDM for further examination.

In the PowerGUI VSX debug engine I defined IDebugThread2 on the same class that I defined IDebugProgramNode2 and a host of other interfaces. I haven’t included the ability to debug multiple threads. It would be cool to debug asynchronous jobs this way but this is definitely something for version 2.

The debug thread provides a enumeration of stack frames. Each stack frame then provides the document and code contexts and any IDebugProperty2s that are valid at that scope.

That doesn’t sound hard, why’d it take you a month to do this?

Debugging a debugger proved trying. It was hard to discern what Visual Studio was expecting when something was amiss.  My only recourse was to include trace logging for every implemented method. This way I could trace exactly where my chain of calls was ending. Typically, with some messin around, I could move onto the next necessary call. I didn’t implement the debug engine like a typical language provider because all the user interface management is taken care of by PowerGUI.

If you open the breakpoints window within Visual Studio you will see that only 1 breakpoint exists.  Prior to starting my debug engine I call IVsDebugger.InsertBreakpointByName. This ensures that the SDM will allow my debug engine to bind this pending breakpoint and eventually notify it that the breakpoint has been hit.  This is another version 1 hack. It would be nice to expose breakpoint management through the Breakpoints window but for the time being this will suffice for enabling breakpoints to be hit.

Another reason for the delay was that once I implemented stack frame and context support it seemed that the engine would run off into the weeds and present the “No source code available window.” I grew to hate that thing. I debugged and debugged the debugger but could not identify why this kept happening. Eventually I realized the problem was with the editor not the debugger. Due to the fact that I’m letting PowerGUI run the show, I neglected implementing several key methods in the editor. Once these were complete debugging finally worked.

What next?

The fun stuff! Since the release of Beta 1.1 I’ve added better property support:

Locals window with expandable variables

I’ve also fixed an issue where the tabs would not change correctly when debugging multiple scripts. My next few items I’d like to see added are real stack frames, true breakpoint management, and Visual Studio exception dialogs on script failure. My final objective is to enable seamless .NET to PowerShell and PowerShell to .NET debugging.

I’d like to hear some feedback on how this engine is working for everyone out there and also what you’d like to see.

I’ll keep everyone posted on my progress so stay tuned!

PowerGUI VSX – Beta 1.1 Update

I’ve posted an update to Beta 1.1 due to issues surrounding installation of the debug engine. The engine needs to be copied into the PowerGUI installation folder because I can’t load the assembly myself. It relies on the PowerGUI assemblies so this is the only way it will be able to find them. It also needs to be registered with Visual Studio from that location. This installation will take place the first time the extension is initialized. Because of this installation and registration Visual Studio will need to be run as Administrator the first time after the extension is installed. Launching a PS1 file initializes the extension and the file will be copied and registered. From then on there should be no need to run Visual Studio as Administrator.

I know this is a bit hacky and is calling out for an installer. Due to the complexity of this release’s  functionality I foresee releasing another, more stable and complete, beta. Stay tuned for more information.

PowerGUI VSX – Beta 1.1 Release

After about a month of hard work on the PowerGUI VSX I’m releasing Beta 1.1. The download is available here, at the CodePlex site. Here are a few screen shots to get you excited:

The debugger honors breakpoints set into source files.

Basic variable values are presented in the locals window.

Output is written to the output window.

Getting the debugging working proved to be pretty difficult. Visual Studio loved to go off into the weeds with little information about why it was doing so. I’ll delve into the down and dirty in a later post so stay tuned for more information on that. In addition to getting debugging to work here is a list of some other bug fixes and features included in this release:

• Can now search for text
• Can now goto line
• The VSX now honors font settings
• The VSX now honors line numbering settings
• User prompts are presented during debugging
• A PS1 file template is included for CSharp and VB.NET project types to create new script files
• The script editor is now tied to PSM1 and PSD1 files as well as PS1 files
• The VSX can now be installed in all version of Visual Studio 2010

In addition to some fixes there are also some known issues:

• When debugging multi-script sessions the debugger does not switch tabs automatically (annoying I know…)
• The locals variables rely on ToString() to present values so complex objects may yield little information

I know more issues will crop up so please let me know as soon as you run into something either on the discussion forum, by adding an issue to the issue tracker or by leaving a comment on this blog. I’m a bit concerned about installation issues because the VSX requires a COM registration and some kind of complex registry work to get the debug engine installed correctly so I’d especially like to hear feedback about that.

To launch the debugger, select the desired script and press Shift+F5 while in the window. From there all the normal debugging keys will work (F5, F10, F11).

Stay Tuned!

EDIT:

You will need to copy the file PowerGUIVSX.Core.DebugEngine.dll from (C:\users\<user name>\AppData\Local\Microsoft\VisualSTudio\10\Extensions\Adam Driscoll\Power GUI Visual Studio Extension\1.0) to the PowerGUI installation folder (C:\Program Files (x86)\PowerGUI).

Unfortunately this may not be the only installation issue. I’ll keep you posted…

PowerGUI VSX Beta 1.1 – Bad News

I know I promised a beta release this week but the programming gods have worked against me. I didn’t accomplish everything I wanted for the beta so I’ve decided to hold off until I have a chance to produce a more complete product. As always you can still grab the latest source change set and build it yourself. Just to keep you interested here is what will be included in Beta 1.1:

• Support for all versions of Visual Studio 2010 (Item #27928)
• Item templates for PS1 files (Changeset 72433)
• Support for PSD1 and PSM1 files (Changeset 73496)
• Fixed a bug where searching would not work (Changeset  72343)
• Fixed a bug where font settings were not honored in the VSX editor (Changeset 73598)

What I’m trying to accomplish before Beta 1.1 is to get the debug engine functional. Currently I have the engine launching, running scripts and writing output to the VS output window. I’m on the verge of implementing breakpoints and stepping. Once this is complete I will release Beta 1.1.

Stay tuned!

Fixing a 10644 error in SCVMM R2

For the last few days I have been wrastlin’ with an error that cropped up while trying to create new virtual machines from a template within our SCVMM library. Every time I would go to deploy a new virtual the process would get 85% done and then fail on the sysprep. The error I was receiving was:

Error (10644) Virtual Machine Manager cannot access the WAIK (Windows Automated Installation Kit) Image Manager DLLs. Recommended Action Install WAIK and ensure that the Image Manager DLLs are installed in the GAC (Global Assembly Cache).

I tried reinstalling the WAIK (version 1.1 and 2.0) and SCVMM. Unfortunately the error still persisted.  I decided to copy the files right from the WAIK installation folder for the Image Manager (C:\Program Files\Windows AIK\Tools\Image Manager by default) into the SCVMM R2 installation folder (C:\Program Files\Microsoft System Center Virtual Machine Manager 2008 R2\bin by default). Badaboom! I can no roll out new VMs. I had to use the v1.1 of the WAIK. Copying the files from the v2.0 version caused the VMM service to crash. I can successfully roll out Win7 and 2008 R2 VMs no problem.

If anyone has a more elegant solution please let me know!

PowerGUI VSX – Debugging a Debugger – Part 2

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:

1. LaunchSuspended
   1. Return your implementation of IDebugProcess2
   2. Make sure to store the IDebugPort2 supplied by the method call into the process
2. ResumeProcess
   1. Get the port from the provided process
   2. Cast it to a IDebugDefaultPort2
   3. Get the IDebugPortNotify2
   4. Call AddProgramNode; supplying your implementation of IDebugProgramNode2
3. IDebugEngine2.Attach
   1. Get the program Id from the supplied array (should only be 1 program in the array) and keep track of that Id
   2. Create an instance of IDebugProgramPublisher2 and publish the IDebugProgramNode2 with the Id received in the previous step
   3. Call IDebugEngineCreateEvent2, IDebugProgramCreateEvent2, IDebugLoadCompleteEvent2, and IDebugEntryPointEvent2
   4. 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!

PowerGUI VSX – Debugging a Debugger – Part 1

I know I promised a talk on the architecture of the PowerGUI VSX Debug Engine but I’ve come to the realization that I don’t know what that is. I’ve learned a lot about how Visual Studio debug engines work but creating one is an entirely different animal. In this post I’ll give you some information I’ve learned through this process.

How an entity is debugged in Visual Studio

When a user clicks the Debug button in Visual Studio a call is made to IVsDebuggableProjectCfg.DebugLaunch which launches the Session Debug Manager (SDM). The SDM keeps track of which debug engines are running and their current state. Debug engines communicate through the SDM to cause user visible results such as local variables, exceptions and breaks. Each debug engine runs on a particular port. The default port is the native local port which is defined within Visual Studio.  The port abstraction layer allows for remote debugging to be possible.  One or more debug engines can be running at the same time.

What a Visual Studio Debug Engine Is Made Of

A Visual Studio debug engine is compromised of the engine itself, typically a single debug process, one to many debug programs, and the various other components that define a debugging session. The class that describes the debug engine needs to implement several key interfaces to function correctly.

Debug Engine Class Interfaces

• IDebugEngine2 - Requires several key debug engine functions such as attaching, creating breakpoints and setting exceptions
• IDebugEngineLaunch2 - Requires methods for launching and terminating a debug process
• IDebugProgram3 - Exposes methods for dealing with debugged programs
• IDebugEngineProgram2 - Methods for cooperating with other debug engines and multithreading

Another key ingredient to a debug engine is the IDebugProgram2 implementation. A debug program is a single entity within a IDebugProcess2 that is being debugged. I haven’t found a much better definition than that in my reading. The debug program actually orchestrates the running, stepping and breaking of the debugger during a debug session.

Debug Program Class Interfaces

• IDebugProgram2 - Defines the program in its entirety
• IDebugProgramNode2 - A light-weight pointer to the IDebugProgram2 interface

Program nodes are created and supplied to the SDM via the IDebugProgramPublisher2 interface. A IDebugProgramProvider2 interface, which has already been registered with Visual Studio, supplies information about the published nodes.

The debugger communicates back and forth with the SDM and the UI via the IDebugEventCallback2 interface. Event interfaces are used to instruct the SDM what the debug engine is currently doing. The Debug Engine Sample has some great classes in this department.

The debug engine can also supply breakpoints, stack frame information, threads and properties. The number of extension points is somewhat bewildering.

How does PowerShell fit in?

The PowerShell Debug Engine will be compromised of many of the above pieces. Unlike some debug engines, PowerShell is not actually a “process” so it will be launched via the LaunchDebugTargets method to allow for the engine itself to handle launching of its “process.” At first I hope to have a single program node take care of all the debugging.  Scripts will be executed, the debug engine will launch and each of the debug events will be tied into the PowerGUI debugger. Information that is radiated from the PowerGUI debugger will be wrapped in the various debug engine interfaces.

My end goal is to have both the managed and PowerShell debug engines running in tandem to allow for debugging from one end of a binary PowerShell module to the other. It would be great to jump right from a script executing into the source code the makes up the module that is running.

The actual design is pending because I’m still learning how all the pieces fit together.

How is it going?

• I’ve got the debug engine registered with Visual Studio which in turn makes it visibly evident
• Pressing Shift+F5 in a PowerShell script window will launch the debug engine; which starts and then stops
• The entry point for the debug engine is executed but the next step in the process fails to execute; If you have an hints reply to list post

Note: If you want more information on how to register a debug engine look here and here.