Here’s Your Game Changer: Debug Visualizer in CodeRush for Visual Studio

One of the goals of team CodeRush is to release something revolutionary, something with the power to change the way developers work, at least once a year. CodeRush 11.2 was the first tool on any platform to offer duplicate code consolidation. This year CodeRush 12.2 comes out of the gate with another powerful game changer: the Debug Visualizer.

The Debug Visualizer attempts to eliminate a number of productivity barriers inherent with today’s debugging experience. You may have noticed:

  1. The debugging experience can be slow
  2. Your hands reaching for the mouse to add a watch or inspect a value
  3. Your eyes moving back and forth between code and watched values

Sometimes when stepping through code you encounter unexpected results. Unexpected results are frequently interesting because they can reveal details about the code that were previously unknown, and they are a smell indicating a logic error or bad data. Unfortunately the time from the moment you see the unexpected result to the moment you understand why is frequently measured in minutes, not seconds. Drilling down into a complex expression or reviewing historical data leading to a potential issue involves way too many mouse clicks and keyboard shortcuts, and may even require a restart in an attempt to catch the problem where it happens. Unraveling complexity is often tedious and may require intense focus.

The Debug Visualizer is here to dramatically reduce the time between unexpected data and complete understanding.

Here’s how it works.

Historic Visual Record

As you step into a method the Debug Visualizer immediately gets to work, revealing values for any arguments passed into the method.

Figure 1: The Debug Visualizer acting like a Locals window, but without the messy window.

Those local values you see just below the arguments persist as you step through this method, serving as a sort of historical document on the original values on entry or assignment, which may be useful if those later change inside the method.

See Changes Right Where They Occur

When values change as you step through the code, you’ll see those changes immediately. For example, in the screenshot below we can see the value of surfaceAreaOfCylinder is 0.0.

Figure 2. An assignment statement before execution.

Stepping over this line of code updates the local variable’s value, shown in red on the left:

Figure 3. Now we can easily see which line of code changed a variable.

Showing Function Results

One debugging task that takes far too many steps and too much time is determining the value of a function that returns a calculation. There seems to be no easy way to get to this important information quickly.

Fortunately the Debug Visualizer makes this pain a thing of the past. Now when you step up to a return statement, you can see the value returned before you leave the function:

Figure 4: Easily see calculated values that functions return.


Revealing the Future

In addition to documenting the past, the Debug Visualizer can also reveal the future. Step through the code and you’ll see the values for expressions on the active line before they are executed. For example, in the code below, the Math.Sqrt() call has not been executed yet, however the future result, 42.0, can be seen right below the expression:

Figure 5:  The future revealed, and the answer is… 42?

If there is an unexpected value on the current line, many times it’s useful to know this before the line executes. It’s much easier to step into a method call or property getter before the line executes than after:

Stepping into a Method Call or Property Getter:

Before the Line Executes After the Line Executes
OrangeDot Press F11 or Ctrl+Shift+F11

OrangeDot Move the caret back to the problem line which might be far away if an exception occurred

  OrangeDot Press Ctrl+Shift+F10 to set the active line
  OrangeDot Wait for the line to become active
  OrangeDot Press F11 or Ctrl+Shift+F11

The future previews are here to save all those extra steps and waiting.

Values of expressions involving potential side-effects that may impact program behavior are not predicted; you’ll see a Refresh button instead. Click the button or press Ctrl+R to see the values.

Expression Explorer

So, what happens when you encounter an unexpected value while debugging? For this section, we’ll use a simple code example, however you might want to imagine this working on an expression with greater complexity.

Figure 6: An unexpected value.

With the caret anywhere on the active statement, press Alt+Down to bring up the Expression Explorer.

Figure 7: Drilling into the expression.

The Expression Explorer lets you drill into individual expression parts and see their corresponding values. In the screenshot above we can see the result of the call to Math.Sqrt() is 4.58 (we were expecting 5), and that the value of the expression passed into the Sqrt call is 21.0 (expecting 25).

Once the Expression Explorer is up, you can move around and drill into expression parts with the arrow keys. For example, pressing the Down arrow (using the example code above) reveals the children of the active expression:

Figure 8. Drilling further...  aSide * aSide == 9.0

The Node Map to the right shows a hierarchical representation of the expression.  You can click and drag this window to reposition it if necessary.

Figure 9. The Node Map reveals the active node (emphasized with high-contrast), parent nodes in purple, other nodes in blue, and hidden child nodes in gray.

Notice the high-contrast active node on the left contains two hidden children (in gray). Sometimes you just want to take a peek at the child node values without actually changing the active expression. We can toggle child expression visibility by pressing the spacebar. Doing so in our example code produces the following:

Figure 10. Spacebar toggles child expression visibility.

In the screenshot above, we can see the 9.0 comes from 3.0 * 3.0.

We can collapse all child expressions with the spacebar as well. Pressing spacebar again produces this:

Figure 11. Collapsing the child expressions with the spacebar.

The “9.0” value shown above for the “aSide * aSide” expression is expected, and the child expression values look good. Our problem must be elsewhere. Let’s move right.

Figure 12. Continuing to explore…

Expressions and their corresponding values are always left-aligned.

Figure 13. Values are displayed below a horizontal line that matches the length of the corresponding expression.

Let’s move down into the child expressions with the Down arrow.

And to the right with the Right arrow:


And now we can see our problem. This reference to “aSide” should have been a reference to “bSide”. Now we just need to fix the code. You can close the Expression Explorer by pressing Escape, or by clicking anywhere else in the editor. When the Expression Explorer closes, the code looks like this:

Figure 16. The Expression Explorer has closed, and we can still see the last values explored.

With Edit and Continue enabled we can fix the code. As soon as we make any change to the code the Debug Visualizer clears the historical data in the method we’re modifying.

Figure 17. After editing.

Of course, after editing, you can show the Expression Explorer again by pressing Alt+Down.

Figure 18. Results are now as expected.

Here’s the Expression Explorer in action:


And here’s the Expression Explorer scaling up to a more complex expression:

Figure 19. The Expression Explorer scales to handle complex code.

Why is this Expression False (or True)?

Sometimes when stepping through code with Boolean expressions an unexpected result appears. For example, you expected the expression to be true, but it is false. Or maybe you expected it to be false, but it is true. When this happens, the Expression Explorer can help you quickly understand why. For example, in this method we want to rent/hire a car. However the Debug Visualizer tells us this won’t happen:

Figure 20. The Debug Visualizer optionally adorns Boolean expressions with “DebuggerVisualizerTrue” (true) or “DebuggerVisualizerFalse” (false) icons.

So the question is “why is this expression false?” To find out, press Alt+Down to bring up the Expression Explorer:

Figure 21. Conclusive Boolean expressions are highlighted (in green) in the code and the Node Map (as squares)

Now we can immediately see the problem. It’s here, highlighted in green:

Figure 22. Conclusive Boolean expressions determine the value of their parent expressions

A parent Boolean expression might contain one or more conclusive Boolean child expressions. In this example there is only one. Let’s navigate into it to get more detail. Press the Right arrow to move right and select the conclusive Boolean expression:

Figure 23. The conclusive Boolean expression, shown as a square in the Node Map, is selected.

And now press the Down arrow (or spacebar) to see the children of this expression:

Figure 24. And now we see why we can’t rent/hire the car.

Highlighting conclusive expressions is useful for understanding why Boolean expressions are true or false.

Evaluating Expressions with Side Effects

Sometimes an expression might contain a method call or property getter access with potential side-effects. If CodeRush is unable to verify that the call is free of side-effects, the Debug Visualizer will display a Refresh button. As long as the line of code is active you can click this button (or Press Ctrl+R) to call into the method and get the result.

Figure 25. Calls with potential side-effects (e.g., the call to “Exists()”) are highlighted.

Note that even though an expression preview may be marked with a Refresh button, it may still be possible to drill down into its children to see their values without refreshing. For example, in the screenshot above, the Exists call prevents evaluation of the parent expression, however you can still see an evaluation of the “drive + path” expression.

The Debug Visualizer is Here Now

So there’s your game-changer for 2012, kids. Faster expression evaluation, historical record of changes, future reveal, function return preview, expression drill down, conclusive Boolean highlighting and important data always right where you need it – right in the source code. It works in C# and Visual Basic and is available right now in CodeRush 12.2 for Visual Studio. JavaScript support is expected in the next minor update. Give it a try and let us know what you think.



A file lock issue experienced by some developers has been fixed since the 12.2 release. You can get the update here.

Free DevExpress Products – Get Your Copy Today

The following free DevExpress product offers remain available. Should you have any questions about the free offers below, please submit a ticket via the DevExpress Support Center at your convenience. We’ll be happy to follow-up.
Alex Rezhko
Alex Rezhko

Mark, this is very useful functionality. I'm using DevExpress for ~8 years and happy to see new features!

4 December 2012
Preetham Chamakura
Preetham Chamakura

Wow.. Wow.. Just Wow...

I Love DevExpress tools...

Thank you!

4 December 2012
Gustavo Marzioni
Gustavo Marzioni


4 December 2012
Boris Bosnjak
Boris Bosnjak

Incredible!  How do you guys keep doing it? :)

Very much looking forward to the JavaScript support.

4 December 2012
Orhan ÖCAL
Orhan ÖCAL

A truly wonderful.

4 December 2012
Oleg Mironov (dbc)
Oleg Mironov (dbc)

I was slightly disappointed about new 2012.2 release because not too much new functionality (better to say almost nothing) was added to existing technologies (especially to WPF). However these new features for CodeRush are great and it will improve the whole picture of the release.

4 December 2012
Peter Thorpe
Peter Thorpe

This is an awesome, you really have helped relieve some of the pain of debugging.

4 December 2012
Abu Uddin
Abu Uddin

Man, can't wait to put my hand on this. Installing it as I speak.

5 December 2012
B User
B User

Simply amazing!

Does it work with Visual Studio 2010?

5 December 2012
Mark Miller (DevExpress)
Mark Miller (DevExpress)

The Debug Visualizer feature works in Visual Studio 2010 and 2012. Note: we are working on an issue where DV does not appear in some instances of VS 2010 - this seems like a VS version issue and we expect to have it resolved in the next 72 hours. So if you don't see it in VS 2010, contact with details of your VS version.

5 December 2012

This looks fantastic, cannot wait to use it!!!

5 December 2012
Eric Vaughan
Eric Vaughan

DevExpress has always taken ease of development to the next level. This is truly awesome.  

The only problem I have is how my adjacent lines of code move around as I'm debugging.  It's pretty disorienting.  I guess I'll get used to it. DevExpress has always prided itself on not getting in the way of the developer, but here is a case where the tool, while (tremendously) helpful sometimes, is distracting most of the time.

6 December 2012
Brien King
Brien King

I like the idea, but the implementation is a bit annoying.  It's more intrusive then I would like.

As I'm stepping through my code it keeps shifting code down as it inserts the debug information.  It also appears to keep the previous lines information visible, so it adds a lot of noise to the code.

A couple suggestions...

1) If I'm past the line and it's not in scope, it's probably no longer relevant to me, so I don't want to see it any more.

2) would much rather have the information as a ToolTip rather then pushing my code down as it inserts the debug information.

3) Long information is truncated, and thus unreadable, so it's not useful to me to even see it.  #2 would solve this issue as well.

If you don't want to go the ToolTip route, then maybe an option to have it at the end of the line, or semi-transparent over the actual line.  i.e. Don't change the formatting of my code when I'm debugging.

7 December 2012
Mark Miller (DevExpress)
Mark Miller (DevExpress)

Brian & Eric, thank you both for your comments. We have not stopped development on the Debug Visualizer and we intend to introduce a number of usability advances that will address these issues in future releases.

9 December 2012
Lester Henderson
Lester Henderson

Can you fix this so it looks properly with the 2 default 2012 themes better?  If one uses the dark theme, they have to go in and adjust a lot of the color settings.  It should support the dark theme out of the box since that is a visual studio option built in (dark/light theme)

Thank You

11 December 2012
Mark Miller (DevExpress)
Mark Miller (DevExpress)

Hi Lester,

This should already be working. Click the [Defaults...] button on the Debug Visualizer options page when the dark theme is selected in Visual Studio, and that should load up the default colors for the dark theme (no need to individually adjust a lot of colors). If you are still having issues, please contact

11 December 2012
Lester Henderson
Lester Henderson


I forgot to say - way cool, thanks for this ability!  I will have to open a support ticket.  I am using the default dark theme, if i am on a line and use the ALT DOWN, i cannot see half of the items.  Figures 13-16, i cannot see the SQRT item, the + signs, etc.  I will follup up with a ticket.

Again thanks for the great value add.


11 December 2012
Mark Miller (DevExpress)
Mark Miller (DevExpress)

Lester, try this:

Follow these steps to get to the Debug Visualizer options page:

1. From the DevExpress menu, select "Options...".

2. In the tree view on the left, navigate to this folder:


3. Select the "Debug Visualizer" options page.

This page level is Expert, and will only be visible if the Level combo on the lower-left of the Options dialog is set to Expert. Reason for making it Expert: We're going to simplify the UI on this page in a future release, and change the User Level so it's accessible by new users as well.

4. Click the "Default Settings..." button.

If you have the dark theme enabled, this should load in the default color settings.

5. Click OK.

If this fails, open a support ticket. I'm wondering if there's something different about your color settings that caused us to fail to identify it on install.

11 December 2012
Lorenzo Statie
Lorenzo Statie

Will this Debug Visualizer be extended to support lambda expressions and linq? This would be wonderful if possible.

1 February 2013
Mark Miller (DevExpress)
Mark Miller (DevExpress)

Hi Lorenzo,

There are two ways to support linq:

1. Evaluating the value of the *entire* linq expression.

2. Evaluating nested parts of a linq expression.

The first case is constrained by the Visual Studio debugger - Visual Studio is currently unable to evaluate the entire linq expression and the Debug Visualizer currently doesn't display anything that VS cannot calculate. It may be possible to circumvent this limitation in the future.

The second case is already supported. The CodeRush Debug Visualizer displays values for expressions you visit. To see values for expressions used together with "where" keyboard or for the lambda body, just step into (F11) that particular linq expression. Visualizing this automatically without the need for stepping into is a feature we may introduce in a future product update.

4 February 2013
Kevin McFarlane
Kevin McFarlane

I was aware of the Visualizer but not the Expression Explorer until now! So much tech to learn. Superb! CR just gets better and better. :)

9 August 2013

Please login or register to post comments.