6

EDIT: When I run this code in Visual Studio 2013, the debugger is showing Utc, not Local. It's a bug in Visual Studio 2015 Debugger.

EDIT: Have taken the code and put in stand-alone console app, but cannot reproduce in either version of VS. Bummer.

Can someone explain to me how what you see in this screenshot is possible?!

  1. On line 298, endingTimePeriodStartDate is redefined as its Date value but set to DateTimeKind.Utc.
  2. On Line 300, if endingTimePeriodStartDate is not actually DateTimeKind.Utc, an exception is thrown.
  3. The debugger breakpoint on line 305 is hit, meaning the exception on line 302 was not thrown, meaning endingTimePeriodStartDate.Kind == DateTimeKind.Utc
  4. (I also did a System.Diagnostic.Debug.WriteLine(endingTimePeriodStartDate.Kind) before line 305 and it prints “Utc” in the Output window).
  5. When I look at endingTimePeriodStartDate in the Locals and Watch debugger windows, and when I mouse hover over the variable, the Kind property shows DateTimeKind.Local

enter image description here

Improve this question
11
  • 4
    Can you reproduce this in a short but complete app we could all try for ourselves? Commented Oct 2, 2015 at 13:48
  • 3
    As you are returning a Task I guess you use async programming -> is it possible another thread changes endingTimePeriodStartDate in the small gap between Ln 300 and 305? Commented Oct 2, 2015 at 13:58
  • Can you reproduce that? Could be a nasty soft error Commented Oct 2, 2015 at 14:00
  • As a side note: You are using VS 2015 and so C# 6 -> why not use new ArgumentNullException(nameof(date)) in Ln 295 to eliminate "magic strings"? Commented Oct 2, 2015 at 14:00
  • 1
    The issue isn't whether you're using async, but whether there's any parallelism going on. If the function is still returning a Task, this could still be chalked up to multi thread issues Commented Oct 16, 2015 at 14:22

1 Answer 1

Reset to default
2

Usually the debugger will show wrong line numbers, and go into old code if it is running a different version of the dll (a former version) than the one that your code is showing. This happens

  • when there is some kind of caching
  • when the former running version wasn't closed correctly, or is still running in another process.
  • when the Visual Studio is not pointing to the correct code

Usually to fix this, you should:

(Start by trying only a "clean" and "rebuild")

  1. Stop all running or debugging Visual Studio projects.
  2. Close all your Visual Studio solutions and windows, so that Visual Studio is not running.
  3. (If next step doesn't do the trick, then the next time around reboot your computer as well before going on to next step)
  4. Re-open only the solution you need to run. Hit "Clean solution". Then "Rebuild solution".

Check if this fixed the problem.

  1. Manually delete the bin folders: (if the clean/rebuild didn't work)

5.1 If your afraid, backup your whole source directory. After everything works, delete the backup...

5.2 manually go into the dependent projects (that are referenced in your "wrong code showing" project) and in each one of them, go into the obj and into the bin folder and delete everything that was automatically created from there - in other words, everything that you did not put there manually. Usually that's everything. Don't worry, visual studio will re-create the Debug and Release directories and fill them up.

Delete the obj and bin of your project as well.

Rebuild everything.

Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.