Problems debugging a PowerShell cmdlet

Question

I'm using Visual Studio 2010 on Windows 7 64-bit Professional. I'm having trouble debugging a custom PowerShell cmdlet.

Configuration

• Language: C#, targeting .NET Framework 3.5 SP1.
• Platform target: Any CPU
• Start Action: C:\Windows\system32\WindowsPowerShell\v1.0\powershell.exe
• Command line arguments: -noexit -command Add-PSSnapIn MyCustomSnapIn

Problem 1: Failure to attach when I press F5 (Debug → Start Debugging)

• PowerShell opens, and Task Manager indicates that powershell.exe is running as a 64-bit process. The Image Path Name column shows the same executable specified in the Start Action.
• If I choose Debug → Break All in Visual Studio, I receive a message "Unable to break execution. This process is not currently executing the type of code that you selected to debug."

Problem 2: Unexpectedly launches as a 32-bit process when I press Ctrl+F5 (Debug → Start Without Debugging)

• PowerShell opens. Task Manager indicates that powershell.exe is running as a 32-bit process - this time the Image Path Name shows a SysWOW64 redirection.

The annoying way to debug right now: The only way I've found to debug my cmdlet is to press F5, then select Debug→Detach All, then select Debug→Attach To Process and reattach Visual Studio.

Answer 1

Problem 1:

Seems to me like a bug in VS2010 reported here: https://connect.microsoft.com/VisualStudio/feedback/details/539389/debugging-powershell-cmdlet-from-vs-2010-does-not-stop-at-breakpoints?wa=wsignin1.0

Using VS2008 should help.

Update: I found more convenient way to debug powershell cmdlets. In the solution explorer right click on solution node -> Add -> New project -> Select powershell.exe file (C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe). Set newly added project as start up project (right click and select "Set As Startup Project"). Then go to project properties (right click on project node and select "Properties") and set the "Debugger Type" property to "Managed (v2.0, v1.1, v1.0)". Don't forget to register your Provider or CmdLet (by running post build events, see http://msdn.microsoft.com/en-us/library/ms714644%28v=vs.85%29.aspx). Now, the program should stop at the breakpoint.

Answer 2

On problem #2, since Visual Studio is a 32-bit process running on WOW64, the path C:\Windows\system32\WindowsPowerShell\v1.0\powershell.exe is redirected to C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe. Which is where the 32-bit version of PowerShell lives.

Answer 3

I know that this posting is about a year old at this point, but it may help someone else struggling with this anyway.

I have found that the following scenario works for me with PowerShell 2.0. I am also using VS2010 SP1 on Windows 7 64-bit.

With PS 2.0 you no longer have to install cmdlets using installutil. Instead you can use Import-Module instead (which does not require Admin rights). I will not go into full detail on how that is done as a web search will reveal most details, but in short, you will need to create a folder (if it does not already exist) at:

md (Join-Path (Split-Path $profile) modules)

Under the modules folder, create another folder with the same name as your cmdlet DLL (minus “.DLL”). This folder will contain your binary and a psd1 file that describes your DLL (see Module Manifests). For my convenience I created this folder as a folder symbolic link to my project’s bin\debug folder.

You still need to run PowerShell (or PowerShell ISE) from Visual Studio as describe elsewhere in the “Start Action” section of the Debug tab of your project properties.

Set your breakpoints and go. Once PowerShell starts, type:

Import-Module <ModuleName>

Then run your cmdlet.

---

Sample

C:\Users\<me>\Documents\WindowsPowerShell\modules\MyCmdlet\MyCmdlet.dll 
C:\Users\<me>\Documents\WindowsPowerShell\modules\MyCmdlet\MyCmdlet.pdb
C:\Users\<me>\Documents\WindowsPowerShell\modules\MyCmdlet\MyCmdlet.psd1
C:\Users\<me>\Documents\WindowsPowerShell\modules\MyCmdlet\MyCmdlet.Types.ps1xml (etc.)

In PowerShell type (can be put in your profile too):

Import-Module MyCmdlet

For me, this hits all my breakpoints and also stops on exceptions. All without having to attach to a process, etc.

Answer 4

Problem 1: powershell.exe is not actually a managed executable. It hosts the CLR itself, so you need to enable native code debugging alongside managed for this to work.

As for problem 2, I'm not sure about this. Obviously VS itself is a 32bit process so perhaps it's interfering here.

Answer 5

I was able to solve problem #2 by creating the folder C:\dev\PowerShell\x64 and copying everything from C:\Windows\System32\WindowsPowerShell\v1.0 into it. I created a similar folder C:\dev\PowerShell\x86. The intended version of PowerShell always launches when I specify these paths, so the shortest way to start debugging is now Start Without Debugging followed by Attach To Process.

Answer 6

You don't mention how you're installing the plugin before calling Add-PSSnapin to make it usable in your debugging session.

Make sure that you are installing the plugin using C:\Windows\Microsoft.NET\Framework64\v2.0.50727\InstallUtil.exe, and not the one in ...\Framework... - this stumped me for a couple days.

Answer 7

I had this problem with VS2010, but it went away after installing SP1.