Improvements in Variable Visibility when Debugging

In Visual Studio 2022 17.10 Preview 2, we’re including a small quality-of-life improvement that results in the Watch/Locals window displaying local variables correctly for any arbitrary frames in the call stack in debug builds. To try it out, please install the recently released Preview. For more information, read on. 
The problem: missing variables in Watch Window
Have you ever been in this situation? We’re debugging some code, and have a breakpoint we hit in a function, foo. We need to inspect the values of some local variables a bit up the call stack, so we open up the call stack window and click to that frame.
In this case, we want to see the value of the variable y, which is an input to calculate the argument to the function foo we’re inspecting. Unfortunately, it’s not available:

The reason it isn’t available has to do with scoping, and how call stacks are walked. The variable y is scoped to just that one if statement; when you’re outside the if block, y no longer exists. And, the way call stacks work, the return address we use to determine the scope is actually the next instruction after the call, or in this case, the return statement.
Improvements to variable visibility
In Visual Studio 2022 17.10 Preview 2, we’ve addressed this 🙏 Community Suggestion. Now, in this toy example, you will see the value of the variable y:

The breakpoint is in the same location, but now when you click to the previous frame, you’ll see the “next statement” arrow still points to the call, so all the variables in that scope are now available.
How did we do this? Well, there are a ton of approaches we could have taken, but the one we went with was to change the code generation of debug builds to include nop instructions after every call which ends a lexical scope (and only calls which are the final instruction in a scope).

The extra nop instruction after the call to foo is what makes this work. It’s located in the same scope, so everything works as expected without having to modify the debugger or the stack walking algorithm. This has the advantage of also working on older debuggers.
This approach does increase the code size generated in Debug builds, so should something go wrong, we’ve added a switch to disable this behavior. Just add /d2EnsureCallScopeForDebugging- to the “Additional Options” under the Command Line for your project, and you’ll get the previous behavior of not generating extra nops:

This switch may be removed in the future.
Send us your feedback
That’s the feature, let us know if you find it helpful or find any issues. Please install Visual Studio 2022 17.10 Preview 2 and give it a try! We are very much interested in your feedback to continue to improve this experience. The comments below are open.
We appreciate the time you took to report issues and sharing suggestions like this one. We hope you will continue to give us feedback when using Visual Studio about what you like and what we can improve. Your feedback is critical to help us make Visual Studio the best tool it can be. Please share your feedback via Visual Studio Developer Community. You can also reach us on X (@VisualC), or via email at