Problems debugging a PowerShell cmdlet

views:

112

answers:

+2 Q:

Problems debugging a PowerShell cmdlet

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.

x0n 2010-07-25 22:06:46

Regarding #1: Visual Studio (devenv.exe) is also not a managed executable, but you don't have to enable native code debugging for the debugger to correctly work with managed code add-ins. Regarding #2: Visual Studio has no trouble debugging other 64-bit binaries. This is the first issue I've run into.

280Z28 2010-07-26 01:45:57

@280z28, yes but are these 64bit binaries in %systemroot%?

x0n 2010-07-26 02:40:25

Try using the special %windir%\sysnative path to launch powershell, e.g. launch path of %windir%\sysnative\windowspowershell\1.0\powershell.exe to see if this supresses the redirect.

x0n 2010-07-26 02:43:13

@x0n: You can't use the sysnative special folder in the Start Action in Visual Studio. It gives a message that the system cannot find the path specified.

280Z28 2010-07-26 13:24:00

@280z28 That's a pity.

x0n 2010-07-26 21:24:12

+1 A:

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.

Keith Hill 2010-07-25 22:24:59

As I mentioned, the actual path launched was verified by Task Manager to be under `system32`, *not* under `SysWOW64`.

280Z28 2010-07-26 01:43:48

@280z28 i think you're missing the subtle point that yes, the launch path is system32 but windows (not powershell or vs) redirects the request to syswo64, silently and transparently.

x0n 2010-07-26 02:38:37

@280Z28 - Are you looking at the "Command Line" column or the "Image Path Name" column? Cuz when I try this experiment in VS 2010, Ctrl+F5 fires up command line `C:\Windows\system32\WindowsPowerShell\v1.0\powershell.exe` but Image Path Name says `C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe`.

Keith Hill 2010-07-26 07:48:00

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.

280Z28 2010-07-26 13:31:00

so you understand now that this is a windows system32 redirect, not some powershell quirk, right?

x0n 2010-07-26 16:54:46

@x0n: Yes, but it still doesn't allow me to debug the code through a direct launch. I have to use Attach To Process.

280Z28 2010-07-27 14:46:43

@280z28: You could also hoist the scripts into system.management.automation in a peer project as a debugging host. Creating runspaces and testing cmdlets like this can be a lot easier than tinkering with the full shell. I blogged the guts of what you'd need: http://www.nivot.org/2010/05/03/PowerShell20DeveloperEssentials1InitializingARunspaceWithAModule.aspx

x0n 2010-07-28 22:40:48

+2 A:

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.

josheee 2010-07-27 15:01:51

+1 - this is indeed exactly the issue, thanks for digging it up; unfortunately nobody seems to feel responsible there right now because they failed to understand the initial bug report (and subsequent comments). Maybe someone with a direct contact at Microsoft could bump this again?

Steffen Opel 2010-07-27 23:09:57

I added a comment, clarifying the repro case. It seems my question here should really clear up the confusion between whoever tested it at MS and the people experiencing it.

280Z28 2010-07-28 17:25:43

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.

Dan R 2010-08-20 19:34:17

ansaurus

tags:

views:

answers:

Problems debugging a PowerShell cmdlet

related questions