0

I can't figure out how to catch the moment when Visual Studio debugger is evaluating my property value in C# code. Breakpoints only work if my code is accessing the property, not Visual Studio debugger (when this property is watched).

My question is: does Visual Studio have a setting or feature which changes the behavior of breakpoints so they become hit (if such breakpoint is located in getter of a property) when Visual Studio debugger shows the value of this property in Watch window (and somehow executing this getter for that)?

I need this for solving my issue (but the issue is NOT my question, it's just to provide some background why I ever needed the feature I'm asking for): for some reason, somehow reading some property of my object by the debugger makes unwanted side effects (causing another property to change). When I do the same in the code (read the properties of the object), nothing like that happens. To locate which property (as I have many dozens of them) causes this effect, I would like to be make breakpoints being hit when debugger evaluates expressions causing my code with these breakpoints to execute.

I couldn't find any feature to enable this in Visual Studio. Am I missing something? Or, maybe, it was added later? I'm on Visual Studio 2008 now.

EDIT: I got downvotes so I need to clarify it again. I'm not seeking assistance with finding the problem in my code (that's why no code here). I'm asking for a very concrete thing. Can I make Visual Studio stop on breakpoints when execution occurred due to evaluating some expression in the debugger. Just that.

public int MyProp1
{
    get
    {
      DoSomething1(); // I want VS debugger stop here on evaluating expression in Watch window
      return _value1;
    }
}
...
public int MyProp99
{
    get
    {
      DoSomething99(); // I want VS debugger stop here on evaluating expression in Watch window
      return _value99;
    }
}
Alex
  • 2,469
  • 3
  • 28
  • 61
  • 1
    can you provide an example of how this change is occurring? –  Jul 12 '17 at 16:33
  • I guess you have to provide a [mvce] to explain how reading one property will modify another property. – Filburt Jul 12 '17 at 16:34
  • Do any of your getters have side effects? Have you tried narrowing this down by watching the properties one by one instead of all at once? Can you describe *exactly*, precisely, in great detail, what you are observing? – 15ee8f99-57ff-4f92-890c-b56153 Jul 12 '17 at 16:48
  • Well, it's easy if getter of SomeContent makes some actions which cause this content to be built (lazy model, building document body from some kind of DOM model only when it's requested). Another property (like SomeContentSize) will now return diff. value. But in this question I wasn't seeking assistance on my exact programming problem (the code is very complex to show it and explain, etc). I'm rather after finding the solution to locate the problematic place by finding the codepath which occurs only in the debugger evaluating the property. And for that I need breakpoints being hit. – Alex Jul 12 '17 at 16:49
  • @EdPlunkett I tried that but couldn't succeed yet. I tried to read many properties of my object in the code but nothing bad occurs. When I use Watch on my object, it sometimes shows diff. value of the problematic property on next Step Over operation. I tried to scroll down Watch window to locate the very property which (while being read by the debugger) causes another property to change. But it didn't help, looks like Visual Studio reads more properties than fits on the screen. So I still couldn't locate the right one. Or, maybe, even the order is important (as I have many calculated props). – Alex Jul 12 '17 at 16:54
  • 1
    Yes, you can. Put a breakpoint on the line/step immediately after where you think it failed, along with the same line. Check the values before, and after. Without code (despite the clarification), it's impossible to point you in the right direction though. – gravity Jul 12 '17 at 17:01
  • I added the code where I want to have breakpoints which would be hit by expression evaluation when in Watch I open the object having all these properties. I'm actually looking for some, like, an option in Visual Studio deeply buried in settings "Enable breakpoints hit on expression evaluation". Nothing else.. – Alex Jul 12 '17 at 17:27
  • 1
    @gravity This guy isn't here to listen. He's here to tell *you* what the answer is, and you're wearing out his patience. There is exactly one very small piece of information about programming that he doesn't already know, and your job is to provide it, without any nonsense. – 15ee8f99-57ff-4f92-890c-b56153 Jul 12 '17 at 17:40
  • @gravity Perhaps I'm not getting the idea. What do you mean of "before" and "after"? Breakpoint is not being hit (when the getter is executed by expression evaluation). So there is no "before" and "after". It's just executed non-stop. If I made it stop on breakpoint, I'd check values before and after. But I need to understand how to do that.. – Alex Jul 12 '17 at 17:50
  • Your question then, quite literally, is *"How do I use breakpoints?"* https://msdn.microsoft.com/en-us/library/5557y8b4.aspx – gravity Jul 12 '17 at 17:51
  • @gravity Thank you but I don't see in the mentioned article any mention of how to make this breakpoint being hit when no code is being executed by the program at this moment (we're already staying at some breakpoint in the program flow) and now I want to examine some object values in Watch. And reading some property value by this Watch window executes a getter which has its own breakpoint. I want execution be stopped again (like Breakpoint within Breakpoint) in this second-level breakpoint. – Alex Jul 12 '17 at 17:56
  • Then put a breakpoint AFTER the last breakpoint you need to validate values. It's very simple. Breakpoints occur BEFORE the execution of said line, so the line(s) before have effected your properties. Step backwards. That is all. – gravity Jul 12 '17 at 17:57
  • @gravity The problem with property suddenly changing its value does not occur with the code flow in the program. If I set any number of breakpoints anywhere (or no breakpoints at all), everything will be fine. The only problem is opening an object in Watch window. Like under Watch the code of getters is executed differently than accessing these getters in the program flow. That's why I need breakpoint being active in Watch process. You explained where to better insert breakpoints but my issue is that they cannot executed at all when getter was accessed not by the code but by Watch evaluator. – Alex Jul 12 '17 at 18:09
  • Just hit F9 on the line that you think is causing the problem. This creates a breakpoint. Move your mouse over the object in question, see the value. Hit F10 or F11 to move through the program after the breakpoint stops the program flow. Repeat as necessary. –  Jul 12 '17 at 18:10
  • 1
    *"property... changing value... does not occur with the code flow..."* - ?!? I'm not sure you have a basic understanding of what happens during program compile time in different environments. – gravity Jul 12 '17 at 18:13
  • @Nick I have a breakpoint B1 (I know how to set them). The code stops at it. Now I open Watch window for my object. For that, Watch window (debugger, not my program!) reads the properties of object properties by calling their getters. If my getter has a breakpoint B2, it won't be hit now. It can only be hit when the code of my program reaches it. Not when debugger reads this property to display it in Watch window. Watch window like spawns another thread of my program to evaluate properties, but with breakpoints disabled. I want this B2 being hit despite the fact the program is stopped at B1. – Alex Jul 12 '17 at 18:25
  • @gravity Maybe. At least I don't know how Watch mechanism in the debugger works (when we're staying at some breakpoint and examing objects in Watch window). Is execution of a getter by Watch mechanism different from the same process by of executing the program code. Is it another thread (because the program's own thread is stopped by some higher-level breakpoint), is it possible to hit breakpoints in this Watch thread, etc. – Alex Jul 12 '17 at 18:35

5 Answers5

4

You can't enable breakpoints during debugger property evaluation. What you can do, if the evaluation side effects are causing you debugging issues, is turn off property evaluation and other implicit calls (like calls by the debugger to ToString())

Disable it under Debug->Options->General->Enable property evaluation and other implicit function calls.

participant
  • 2,923
  • 2
  • 23
  • 40
A Friend
  • 41
  • 2
  • This answer shows understanding of the question.... unfortunately the answer of "you can't" is a problem, not just for the OP, but for others. Being able to invoke code dynamically from the debugger (in this case evaluate a property in a watch or immediate window) and have it hit all breakpoints is a feature common in other debuggers..... PITY that it is not supported by VS... – David V. Corbin Jan 10 '23 at 14:15
1

While you can't hit a breakpoint when an expression is typed into the Watch panel, you can achieve this functionality by typing the expression into Visual Studio's immediate window. Any set breakpoint will be hit. This is applicable to Visual Studio 2022.

Aaa
  • 900
  • 3
  • 9
  • 22
0

You can set up conditional breakpoints in VS. Set the breakpoint on the line you wish, right click and hit condition.

This link can help you out with breakpoint conditions: https://blogs.msdn.microsoft.com/zainnab/2010/05/03/set-a-simple-breakpoint-condition/

Brian Reynolds
  • 25
  • 1
  • 6
  • I'm aware of conditional breakpoints. But what is the condition "hit on expression evaluation"? The article doesn't state that.. – Alex Jul 12 '17 at 17:09
  • You can disable the option in Debugging -> General -> Enable property evaluation and other implicit function calls. – Brian Reynolds Jul 12 '17 at 17:41
  • No, if I do this, properties won't be evaluated by the debugger at all. I need them evaluated but breakpoints in getters of these properties being hit (like in the normal program flow under the debugger). – Alex Jul 12 '17 at 17:44
  • 1
    I said that because you mentioned that some property being read by the debugger was causing side effects and you don't know what property that is. Turning it off will eliminate the problem and you can manually evaluate the properties you need to look at. From my understanding: you start the code, hit a breakpoint, you add a class to the watch list, expand it to examine the properties and somewhere in this step you have another property unexpectedly changing, despite you having the breakpoint on your getter line. You won't be able to hit a breakpoint from executing a function within the watch. – Brian Reynolds Jul 12 '17 at 18:05
  • No, changing the property value by Watch is the only my concern. I.e. it's not an annoying issue which prevents me from debugging other things. This is the very core of the issue. What's so special in Watch evaluator which cannot be reproduced normally. Maybe it's just a bug of Watch mechanism of Visual Studio but I suspect something is not right with my code. That's why I want to debug the debugger. See how exactly Watch window evaluates my getters, being able to insert breakpoints in them (provided that we're already staying at some breakpoint, otherwise we woudn't have Watch window at all). – Alex Jul 12 '17 at 18:15
  • 1
    Can you replicate the issue by instantiating the object you have in the watch right after your current breakpoint, and then removing it from your watch, then stepping through the init of the class/properties, while having a watch on the property that is changing? – Brian Reynolds Jul 12 '17 at 18:26
  • Yes, and I can actually make my debugging even without "breakpoint when stopped at another breakpoint". If I add Console.WriteLine in the getters, it gets executed by Watch evaluator so if I add many of them, I can trace the execution under Watch. My question was if I can use breakpoints there directly (but looks like not). I was just interested if I can interrupt the process of evaluating a property by Watch. If not, I have other options, no problem with that it will just take a little longer. Thanks! – Alex Jul 12 '17 at 18:50
  • @Alex, Is it like the Data Breakpoint even if it just supports the VC++ Native code? https://msdn.microsoft.com/en-us/library/350dyxd0(v=vs.100).aspx – Jack Zhai Jul 13 '17 at 10:11
  • @JackZhai-MSFT Maybe. I was not able to find anywhere any info on how Watch property value evaluator works internally. What kind of breakpoints can it honor (if any). Does it start any new thread, etc. – Alex Jul 13 '17 at 11:20
-1

Like the document which share us how we could use the breakpoint in VS IDE:

https://msdn.microsoft.com/en-us/library/5557y8b4(v=vs.110).aspx

My understanding is that the data breakpoint could achieve the function you want o get, but this feature really has a limitation now, it just supports the VC++ native now.

So I agree with Brian Reynolds, the workaround is that you could try to break on or intercept Add and Remove from the debugging watch window.

Of course, for the data breakpoint issue, other community members also submitted this feature question to the product team here:

https://visualstudio.uservoice.com/forums/121579-visual-studio-ide/suggestions/6097301-support-data-breakpoints-for-c

You could also vote it or submit your feature request if you have any good suggestion for the VS product.

Jack Zhai
  • 6,230
  • 1
  • 12
  • 20
  • Thank you. However, just wanted to double-check. Will data breakpoint break in case if the reason of why data value has changed was an action caused by Watch window (to evaluate some property), not by the code of the program being debugged. The article never mentions that. Currently, I'm under impression than any evaluations caused by debug windows (be it Watch, Auto, Locals) never trigger any breakpoints.. – Alex Jul 14 '17 at 09:35
  • @Alex, no, just when the specified number of Bytes are modified starting at the specified Address: https://stackoverflow.com/questions/4794646/vb-net-add-watch-stop-when-value-changes. It seems that it also doesn't really meet all your requirements, am I right? – Jack Zhai Jul 14 '17 at 10:00
  • It's hard to tell without the actual testing. If these bytes are modified by the process/thread different from the thread of the app's being debugged but by the debugger's own thread, will it trigger the breakpoint? Turns out it would require a completely new concept of multiple breakpoints being hit at the same time. We're already staying at some breakpoint of the app being debugged (that's the only case when Watch window is there). And now, we want to execute something else (code started by Watch evaluator) and hit another BP while the app's own code is still stopped at the original BP.. – Alex Jul 14 '17 at 10:47
  • @Alex, Sorry for that I didn't find other possible solution, like my previous suggestion, if possible, you could submit a feature request to the product team directly. – Jack Zhai Jul 17 '17 at 10:58
  • Thanks anyway. The feature is not a must-have for me as I could debug my issue even without it, I was more like curious if it exists but I can live without it easily. From the discussion, it doesn't look like anyone but me would ever need it.. – Alex Jul 18 '17 at 12:00
-1

Right click on your break point for example in a for loop then click Condoitions , then type your condition for example i>5 or i==5 then click Close button. enter image description here

M Komaei
  • 7,006
  • 2
  • 28
  • 34
  • And how does this answer my question? – Alex Sep 07 '22 at 15:20
  • Cant seem to post image in comment... Look at a watch window where a method with side-effects is selected... See the little circular arrow that will invoke the method and update the value? The goal is to hit breakpoints that are encountered while THAT evaluation is occuring. – David V. Corbin Jan 10 '23 at 14:18