This project has moved. For the latest updates, please go here.

Enable Unmanaged Debugging IronPython



While debugging, with an IronPython startup project, I'm trying to step from IronPython to C# code to unmanaged C/C++ code. Is this possible?

I am currently able to step from IronPython to C# when the startup project is IronPython. I'm also currently able to step from C# to unmanaged C/C++ code when the startup project is C#. However, I am not able to step from IronPython to C# to C++ when the startup project is IronPython.

Even though there was no relevant gui option I could find, I tried editing the .pyproj file, changing the EnableUnmanagedDebugging field from "false" to "true", but this did not have any noticeable impact.

I'm using Visual Studio 2010 (Version 10.0.40219.1 SP1Rel), Microsoft .NET Framework Version 4.5.50709 SP1Rel, and Python Tools for Visual Studio 2.1.20620.00.

I would greatly appreciate any help in this, even if just to confirm it is not possible so that I stop trying.


file attachments


jj995 wrote Jul 25, 2014 at 5:41 PM

I posted this question on the mailing list and got the following response (copied from

From: Jeff Hardy
Date: Wed, Jul 9, 2014 at 6:14 AM
Subject: Re: [Ironpython-users] Enable Unmanaged Debugging IronPython
To: John DiMatteo
Cc: "", Dino Viehland

Adding DinoV because this sounds more like a PTVS issue than an IronPython issue - from the IronPython side there's nothing that should prevent it from working AFAIK. IronPython in VS uses the normal managed debugger.
  • Jeff

jj995 wrote Aug 11, 2014 at 7:02 PM

Is there any other information I can provide to get a response for this issue? Thanks for your time.

jj995 wrote Aug 18, 2014 at 8:38 PM

After reviewing the mixed mode debugging documentation, I don't think it is possible to step from IronPython to C++ in an IronPython project. says "Mixed-mode only supported for CPython 2.7 and 3.3+"

This seems to significantly reduce productivity with IronPython, so if anyone knows of a way to do this I'd appreciate it. For example, if I have to debug a C++ integration issue with my IronPython code, I often end up writing the equivalent call in C# so that I can step into the C++ code and find the problem. This seems to be a shame, since "from the IronPython side there's nothing that should prevent it from working".

Zooba wrote Aug 18, 2014 at 9:23 PM

If you attach to a running instance of ipy.exe using Managed and Native debugging then you'll get the usual experience for IronPython - there's no need to select Python here. It isn't as good on the Python side as our mixed-mode debugger is, but that's because the developers didn't have an interest in supporting IronPython, so what's there is largely because IronPython is based on the CLR.

IronPython is supposed to emit debugging information that makes sure the normal CLR debugger can find the correct lines of source code. If it is no longer doing that, then it's an IronPython issue. (Sorry to pass the problem back to them, though as Jeff said, DinoV is exactly the right person to look at it - he used to work on IronPython - so I'll make sure he's aware of this issue.)

jj995 wrote Aug 19, 2014 at 12:54 AM

Thanks Zooba for the information!

I just tried Debug > Attach to Process with both "Managed (v4.0) code, Native code" selected, and attached to my ipy64.exe process. In the call stack I see my C# functions along with my C++ functions, but none of my python functions are present in the call stack.

Instead of showing IronPython function calls, there is stuff like the following in the call stack:
Microsoft.Dynamic.dll!Microsoft.Scripting.Interpreter.FuncCallInstruction<MyL,MyLI>.Run(Microsoft.Scripting.Interpreter.InterpretedFrame frame) + 0x54 bytes
Full call stack is attached. Note that I've replaced some proprietary dll/function/type names with variations of "My*" and "Foo".

So I guess this is an IronPython issue. I'll email the list under the "Enable Unmanaged Debugging IronPython" thread.

jj995 wrote Aug 19, 2014 at 12:55 AM

Please find attached the stack referenced in the prior post.