Hi, thanks for posting!
This is by design. It is due to the mechanics through which the await construction is implemented.
When the .NET runtime hits the await, it actually runs the thread through to completion and sets up a continuation pointed back at the await. When the awaited call completes, a new thread picks up the code from the point where the calling method was interrupted.
These mechanics happen above the level at which NCrunch operates, so the coverage tracking is completely unaware of them.
'await' was implemented by Microsoft in the same manner as 'yield'; all the complexity is in the compiler rather than in the runtime. This means that if you look at the MSIL generated from class using await, you'll see an extensive set of compiler generated methods and classes that have little to do with your own code and much more to do with the piping around await itself. It is theoretically possible for NCrunch to be upgraded to identify the 'await' by closely inspecting and analysing this structure, but this will come at a serious cost in terms of lost performance and significant complexity - it likely wouldn't be worth it.
