Debugging support for .NET Native Preview apps

Debugging support for .NET Native Preview apps

Rate This
  • Comments 4

This post has been updated to reflect debugging support available in Visual Studio 2015

By now you will heard about .NET Native, but if not read about it first.

With a new tool chain and runtime you also have a debug engine designed to debug .NET Native binaries. That means that when you switch to compile your .NET code with the .NET Native tool chain, under the covers you have also switched to the debug engine for .NET Native. The debugging experience you get includes (but certainly is not limited to):

F5, Attach, Output window, Exceptions, Breakpoints, Step Into/Over/Out, Run To Cursor, Call Stack, Data and Variable windows, Just My Code (filtering stacks, exceptions, and private fields in variable inspection), Modules window, Address level debugging (Disassembly, Memory, Registers windows), Threads window, Parallel Stacks Parallel Watch windows, Process Lifecycle Management for Store apps (background tasks, suspend, resume, suspend and shutdown), triggering prefetch, and debugging dump files.

In addition to bringing that level of parity, with .NET Native you also get very cool interop debugging between your managed and native code on ARM (something only possible on x86 and x64 for your regular .NET apps).

So have fun debugging, and you'll know you are using the new debug engine for .NET Native when you see in the Processes window under the Debugging column the name of the new engine “Managed (Native compilation)” (in contrast with what you'd see when you debug your other .NET apps “Managed (v4.5, v4.0)”):


It is also important to note that there are some features that we have not implemented yet (let us know which ones are impactful to you):

  1. Set Next Statement
  2. Editing values in the variable windows
  3. Tasks window (incl. the new async support)
  4. Async debugging support in the Call Stack window
  5. Support for Return Values
  6. Edit and Continue
  7. Just My Code -- works correctly for showing call stacks but is not supported when stepping

Please try debugging your .NET Native code and let us know if you find anything not working that is not on the list above Visual Studio’s Send a Smile tool, or via Twitter.

Leave a Comment
  • Please add 6 and 3 and type the answer here:
  • Post

  • You mentioned "a new debugging engine". Does that mean .NET Native debugging won't be using CorDebug? Will CorDebug be enhanced or is there a new API replacing it? If there's a new API will it be public? I'm using CorDebug to inspect dumps so keen to know what it's future is :-)

  • @THIS IS NONSENSE: Thank you for the feedback. VB.NET is definitely on our radar. We've started with C# but we intend to bring up VB.NET as well.

    @Greg: .Net Native will still use ICorDebug for managed debugging.  However, .Net Native has a new engine under the hood driving it which has some behavioral differences from the CLR's implementation of ICorDebug.  

    In general, your CorDebug dump inspection tool will work on .Net Native apps but it will need some modifications to work on the new runtime. The ICorDebug API surface will look very familiar to anyone who's written inspection tools but there will be some porting as it isn't identical.

    We need to document exactly what you'll need to modify in your debugger to support .Net Native. We haven't done that for the preview release but we intend to document the API.

  • Awesome, thanks for the feedback Andrew! Looking forward to trying it out.

Page 1 of 1 (4 items)