Seeing function return values in the Visual Studio 2013 debugger

Seeing function return values in the Visual Studio 2013 debugger

Rate This
  • Comments 20

You asked, and we have listened. Seeing return values for functions is something that many .NET developers wanted, and voted heavily for on the Visual Studio uservoice site. This feature exists already for C++ code and the good news is that with the latest version of Visual Studio, it’s here and you’ll be able to use it for your .NET code too.

This new feature allows you to examine the return value of a function when the developer steps over or out of a function during your debugging session. This is especially useful when the returned value is not stored in a local variable. Consider the following nested function example Foo(Bar()); in this example you can now examine the return value(s) from Bar and Foo, when you step over that line.

The return value(s) get displayed in the “Autos Windows” (Debug->Windows->Autos) and you can also use the pseudo variable “$ReturnValue” in the Watch and/or Immediate window to fetch the last function’s return value.


Here are some steps for you to try it out in action:

1) Create a new C# Console Application

2) Copy the following code to your program.cs

01	class Program
02	    {
03	        static void Main()
04	        {
05	            int result = Multiply(Five(), Six());
06	        }
08	        private static int Multiply(int num1, int num2)
09	        {
10	            return (num1 * num2);
11	        }
13	        private static int Five()
14	        {
15	            return(5);
16	        }
18	        private static int Six()
19	        {
20	            return (6);
21	        }
22	    }


3) Put a breakpoint in line # 05 – [int result =Multiply(Five(), Six());] and run it

4) Run the program (F5)


5) When the program breaks step-over the function (F10)


6) As this example was nested functions, you are able to see all the return values in the autos window

7)  You can also use the last returned value in your immediate window


Note that if a function returns a struct, it will not be displayed in the Autos window with the exceptions of enums and structs that have exactly one field which is the size of a pointer (i.e. structs with the same characteristics as enums).

In closing, we are really happy to bring this capability to you and as always your feedback is welcome in the diagnostics forum.

Leave a Comment
  • Please add 8 and 8 and type the answer here:
  • Post
  • Yaniv, your code sample isn't formatted correctly. It looks to have double spacing at the moment.

  • That's awesome! Can we also change the return value?

  • @ Dave Shaw - thank you for pointing it out. Fixed now.

    @Christoph: You can’t change the return value directly. However, if it is setting a variable you can update it or if it’s something that get passed into a function you can put a break point in the function and update it there.

  • Why is variable name is not consistent? In Autos it's called result, in Immediate - $ReturnValue?!

    For instance, $exception in simplified catch{} block has consistent name across.

  • @abatishchev: The Autos window has a "result" because of the local variable "int result" that is declared in the code sample - it's a real variable, not a pseudo-variable like $ReturnValue or $exception

  • Hi Yaniv, thanks for the great blog post!

    Say, is there a way to programmatically obtain all the return values and the names of the associated method from a Visual Studio extension?


  • Excellent. Thanks VS team for this feature.

    MS Rocks!

  • It just displays primitives and not classes, so this feature is not as exciting as I thought.

  • @VahidND

    Thanks for the feedback!

    Would you mind voting or opening new suggestion items on for the support you feel this feature is lacking? For example, we already have:

    -support structs:

    -on hover:


    Maria Ghiondea

    Visual Studio Debugger

  • @VahidND

    Also - while there is a known limitation that the feature can't support structs with more than one field, it should support classes! If you are not seeing it work - would you mind letting me know when you are seeing that fail?

    If you prefer - you can email us at vsdbgfb at


    Maria Ghiondea

    Visual Studio Debugger

  • @Omer Raviv

    You can write an extension listening to IDebugReturnValueEvent2 and call IDebugReturnValueEvent2::GetReturnValue() to get the return value. This should work for both native and managed:

  • This doesn't work for me in Visual Studio 2013 Update 2, .NET 4.5.1.

    Test project [console app] :

    namespace ConsoleApplication9


       class Program


           static void Main()


               var data = GetData();


           private static int GetData()


               return 5;

           } //place breakpoint here



    Upon hitting the breakpoint $returnValue, $ReturnValue are not recognized neither in a Watch tool window, nor in the Immediate window. In the Autos window it doesn't appear either.

    Is this shipped and working?

  • I can't seem to find this feature in update 2 either, is there a switch to turn it on somewhere?

  • That's great if you can wait until the Function exits and you're using 2013+.  What if you want to examine the return value *before* you exit the function (i.e. so that maybe you could Set Next Statement to earlier in the Function and change some code and/or modify some Variable(s) values to alter the Function result)?

    If you're using VB.NET, your in luck because for as long as I can remember (from VB through all versions of VB.NET), you can simply query the Function Name.  You *should* already know that it "functions" like a Local Variable that's implicitly declared at the start of the Function and that its current value is also used as the Return value whenever the Function exits via non-Return Statement means (i.e. Exit Function or just falling through) and of course, when the Return Statement is used, it is also set to the Return Statement's expression.  Just like a Local Variable, its value can be inspected at any point of execution inside the Function (including after the Return Statement is executed).  C# doesn't have this and should.

  • That little VB.NET feature (plus the Exit Function Statement which it enables - another feature C# doesn't have and should) is very useful in a from of Defensive Programming I practice where I always initialize the Function Name to the failure/default value as the 1st Statement.  Then, at any failure point (which normally occurs much more often than success points), I can simply call the Exit Function Statement (i.e. without having duplicate the failure / default expression or even Variable name).

Page 1 of 2 (20 items) 12