29

I'm getting an InvalidOperationException thrown (which should be easy to fix). However when the exception is thrown, I can't view any of the current values in the Locals debug window. They all have the same message:

Local variables and arguments are not available in '[Exception]' call stack frames. To obtain these, configure the debugger to stop when the exception is thrown and rerun the scenario.

Not sure why this is happening (maybe something to do with async?) but this is relatively simple code and I should be able to see the value of these variables.

Calanus
  • 25,619
  • 25
  • 85
  • 120
  • So, have you tried to `configure the debugger to stop when the exception is thrown and rerun the scenario.` ? – KompjoeFriek Sep 05 '22 at 11:09
  • Maybe you can create a Minimal, Reproducible Example to help use to reproduce the issue. – Jingmiao Xu-MSFT Sep 06 '22 at 06:05
  • 2
    I haven't tried to configure the debugger to stop as I have no idea how to do that. I have reset all exceptions to default but I'm guessing that this means something else.... – Calanus Sep 06 '22 at 19:11
  • 1
    Did you try to go to Debug>Windows>Exception Setting and choose "System.InvalidOperationException". – Jingmiao Xu-MSFT Sep 15 '22 at 02:03
  • 20
    This is a serious regression. I'm not sure if it's a VS2022 issue or a .NET 6 issue, but it seriously decreases the usability of the debugger. It's not always feasible to "configure the debugger to stop when the exception is thrown and re-run the scenario". In my experience, that is rarely a workable solution. (I see an issue in Github from 2019 - apparently this is yet another serious limitation of the CoreClr that they've chosen to not address). – CarlDaniel Oct 06 '22 at 23:52
  • 3
    @JingmiaoXu-MSFT Just take a default install of VS2022 and run any code that will throw an exception, like a code path in which a Linq method is called on a NullReference. It's not particularly hard to run into this dumb issue, which makes it so annoying. – Tom Lint Mar 01 '23 at 16:37

3 Answers3

19

You can go to Debug>Windows>Exception Setting and choose "System.InvalidOperationException" to solve the issue. enter image description here

Jingmiao Xu-MSFT
  • 2,076
  • 1
  • 3
  • 10
1

After some time of searching I stumbled also over your question.

Yes, the accepted answer is a workaround for your problem -> you can go to Debug>Windows>Exception Setting and choose "System.InvalidOperationException" as described in the answer above.

However, this will then break always any "System.InvalidOperationException" even if the exception is handled in a try and catch block.

Alternatively, I suggest you open the "Call Stack window" (Debug > Windows > Call stack).

Here (not sure if this is a new feature in Visual Studio 2022 because in Visual Studio 2019 I don't have this problem) you will see two nearly identical call stacks:

  • One starting with [Exception] like "[Exception] ... call stack data ..."
  • and another identical but without [Exception] like "... call stack data ..."

If you double click on the second one your local variables are filled - while in the first one with [Exception] your local variables are not filled (which is the default one in case of an exception.

Indirectly this behavior is also described in your error message:

Local variables and arguments are not available in '[Exception]' call stack frames.

Unfortunately, I've no idea why Visual Studio 2022 now creates two similar call stacks in case of an exception while Visual Studio 2019 doesn't.

Twinnie
  • 131
  • 4
  • 1
    This is the only thing that 'works' for me, and I am also certain that this behavior was not happening previously as I have never had to do this before... – Christopher King May 25 '23 at 15:01
0

In Visual Studio 2022 on a .NET 6 application, I noticed this behavior when the debugger stopped execution during an exception rethrow:

try
{
     // some code that throws an exception
}
catch (Exception e)
{
     // some custom exception handling
     throw; // *** This is where the debugger is stopped ***
}

My solution, which may not be practical in all cases, was to use preprocessor directives to not catch and rethrow the exception during debugging:

#if DEBUG
#else
    try
    {
#end
         // some code that throws an exception
         // *** debugger now stops here, and locals/watch expressions work as expected ***
#if DEBUG
#else
    }
    catch (Exception e)
    {
        // some custom exception handling
        throw;
    }
#end
Dan
  • 10,480
  • 23
  • 49