[RESOLVED] Failure to Debug

In a dynamically loaded dll I have this little snippet of code:

Code:

---

If trts.Length > 1 Then
    mErrors.AddString("Something here")
End If

---

In this case, trts.Length is 1. That's all it should be, and by looking at the value in trts it is 1, and the value of trts.Length = 1, and trts.Length > 1 is False. However, if I put a breakpoint on the If statement, code execution goes to the mErrors.AddString....or maybe it doesn't.

If the mErrors.AddString were actually executed, then a string would be added to mErrors, which would raise an event that is caught elsewhere. That event is clearly not caught, so it appears not to be raised, which suggests that the mErrors.AddString never happens.

Also, the line immediately after the If block is not reached, nor does it appear to be reachable, because if I attempt to put a breakpoint on the line immediately after the If block, VS pauses for a second then reports that it was unable to bind a breakpoint at that point.

Interestingly, while the debugger steps into the If block (even though it should not), then the next step is out of the method entirely and back to the caller, the code after the If block is being called. That code builds a string that ends up in a tooltip, and since the tooltip is (mostly) right, the code must be getting called.

So, debugging is going the wrong way at a condition, then skipping over the rest of the method, but execution is NOT going the wrong way at the condition and is NOT skipping over the rest of the method. The debugger is just doing the wrong thing.

This was an issue with VB6, but I have never before seen it in VS. I have a few more tests to perform to study the situation in greater detail, so I suppose this is more or less just a rant, but if anybody has anything to say on the topic, or tests I could try, I'd like to hear about them.

The first test seemed obvious: I was using the release build of the dynamic dll, so I thought that some optimizations might have gotten the source and the executed code out of sync. Therefore, the first test was to switch to using the debug build, without optimizations.

At first, I just switched to the debug build. This did have some impact, as I was able to set a breakpoint on the line after the if statement, but the breakpoint was never reached, even though the code it was on had clearly run (the tooltip would be nearly empty had it not run, and it was nowhere near empty).

That was a bit of an improvement, but not much, since my real objective was to step through the code that was building the tooltip, and while the tooltip WAS being built, and I now COULD set a breakpoint, those breakpoints were ignored, which meant that debugging was impossible.

I then started writing this post, and realized that what I said in the first line I had not confirmed: I knew I had switched to the debug build, but I didn't know the state of the Enable Optimizations flag on the Compile tab of Project | Properties. Normally, that flag is clear for debug builds...but I thought I'd go check. Sure enough, it was checked for the debug build in this dll. Not sure why, not sure how, but I unchecked it and rebuilt.

Now everything is working the way I expect it to.

So, from this little sequence: Enable Optimizations MAY cause debugging to behave incorrectly. Execution MAY appear to take the wrong path at conditionals, and MAY appear to exit methods early, thereby skipping code that is actually run. This won't normally happen, so the debugger is normally reliable, but as long as optimizations are enabled, the debugger is not necessarily showing an accurate and correct representation of what the execution is actually doing.

Ultimately, this is probably a visible manifestation of something that is otherwise a good thing. The source says one thing, the debugger follows something which ideally is the source, but optimizations can mean that the execution path no longer lines up with the source all that well. At that point, the path that the debugger takes may not match the source very well at all. You want the optimizations, ultimately, but while debugging you really want the debugger to match the source perfectly, so you need to have the optimizations off.

This was never a thing in VS2010 (and I have no relevant experience with the versions between 2010 and 2019), which may indicate a change in the debugger, but more likely means that the optimizations that take place in 2019 are considerable, while the optimizations that took place in 2010...may not have been much of anything.

On my last project (vs2017) I goes from debug version to release to debug and the break point didn't work anymore in the last debug version. I had to deselect manually "activate only my code" and everything came back to normal. I really If I understand that the passage to release toggle it automatically, I don't understand why to come back to the debug version don't untoggle it automatically. Maybe it is the same here?

by the ways, Sometimes, instead of a break point, I put a stop or messagebox (or console.write or debug.write) with the value I want to check or just "test" to check if it goes there.

Just to follow up on this, the setting "Suppress JIT optimization on module load" will cause the debugger to work the way I expect whether in Release or Debug builds as far as stepping through the dll. Just My code has to be disabled, as well.

Hey shaggy, happy new year and all. Hope you are all good.

I recently have been having lots of bizarre debugging issues with 2019 and was putting it down to a new released version of resharper that messed up my install to which jetbrains logged the bug but now not so sure. This might not be related or even close but very much so am getting skipped breakpoints and also points stopped on that should not even be reached regardless of debug or released.

I put it down initially to all the medication I am on but maybe I cant so much now after seeing your issues.

Yeah, I was seeing some very strange code stepping, but that option I mentioned is an interesting one to look into. The documentation on it from MS says up front that if you don't have that one checked, the debugger can do some bizarre and unpredictable things. I'm a bit surprised that it defaults to unchecked.