VS2012 - Why is my main UI thread showing green debugging statements?

Question

Edit : If you're seeing this same problem (and you're accustomed to NOT seeing this under VS2010) please comment below so I know it's not just me - but be sure to check Han's answer to make sure none of those scenarios appear...

---

I've been updating my app to run with .NET 4.5 in VS2012 RTM and noticing something that I don't quite understand and that is unexpectedly green highlighted statements (instead of yellow).

Now I'm well aware of what this is supposed to mean, and the IDE is even showing me a little explanation tooltip.

This is the next statement to execute when this thread returns from the current function

However there's absolutely nothing asynchronous or thread based about this code. In this simple example I'm sure you'll agree that string.ToUpper() won't be off in another thread. I can step through the code no issue.

There's nothing else going on and I am on the main thread as you can see here.

I am using async and await and MVVM-Light (the above method is the result of a RelayCommand) but I still get this behavior even when the code path is directly off an event handler such as PreviewKeyDown.

If I create a new app I cannot duplicate this - the coloring is yellow as expected - even when using await.

Anybody got any idea? It's starting to drive me crazy!!

Answer 1

It is green when the current instruction pointer is not exactly at the start of the statement. Some common causes:

• Common in threaded code, setting a breakpoint in one thread and switching context to another. The other thread will have been interrupted by the debugger at an entirely random location. Often in code that you don't have source code or debugging info for, like String.ToUpper(), the debugger can only show the "closest" source code
• Using Debugger + Break All to break into the debugger. Same idea as above, the instruction pointer will be at a random address
• Getting an exception in code you don't have debugging info for. The editor shows the last entry in the Call Stack that it does have source code for. You need the call stack window to see where the actual exception was raised. Or the Exception Assistant, its reason for being
• Debugging optimized code. The jitter optimizer scrambles the code pretty heavily, making it likely that the debugger can't show the current location accurately
• Having out-dated debugging info or editing the code while debugging
• Debugging code generated by the x64 jitter, happens when the project's Target Platform setting is AnyCPU. The x64 jitter has a number of chronic bugs that are not getting fixed, generating incorrect debugging info is one of them. Problems that were not addressed until it was completely rewritten, done by the RyuJIT project and first available in .NET version 4.6. Targeting x86 in your EXE project is the workaround.

Answer 2

I understand that this is old post yet I would like to answer the question with my experience. I have encountered same issue recently in one of my WCF application. After debugging and closely looking service logs and I find out that my code was giving this error because service was hitting max allowed limit for code execution and once the service hit max allowed time limit it was trying to offload the current debugging session.

ERROR IN GREEN STATEMENT: this is the next statement to execute when thread return

So avoiding this issue you can try to look any potential code(Code/Service Timeout or any other code block) which is trying to offload your currently executing code context and try to fix it, furthermore original explanation given by @Hans is still very much relevant for trouble shooting this issue.