Empty 'Allocated' Column After Updating to Windows 10 v1903

[luckerby]

After updating to Windows 10 v1903, I get the following outcome:

Note the empty 'Allocated' column, which before the Windows update was showing the expected values. Contrast this with what's seen on another machine, running the same exact code, and still running Windows 10 v1803:

Upgrading to BDN v0.12 on the v1903 machine made no difference.

[luckerby]

Based on my understanding, the code that returns the number of allocated bytes - for a .NET Framework deployment - will use AppDomain.CurrentDomain.MonitoringTotalAllocatedMemorySize to extract this information (RuntimeInformation.IsFullFramework is just a string match against .NET Framework based on what's returned by RuntimeInformation.FrameworkDescription).

The trouble is that this value is 0 on the v1903 machines I've tested with. Some quick code was used to report basic info:

On a v1803 machine though, the value continues to be reported just fine:

Interestingly enough, if execution would have continued in the code as if this wasn't a "classic" .NET Framework", it would have reported the right value (at least down to a few KB), as GetAllocatedBytesForCurrentThread shows (on v1803 this crashes because I didn't fully copy the BDN code that uses the delegate, so it attempts to use a null reference).

As a side note, I'm targeting .NET Framework 4.7.2 for the project whose text output is seen above, on both machines tested, but somehow the version retrieved from the AppDomain on v1903 is 4.8, while on v1803 is 4.7. I don't quite get this one to be honest...

[adamsitnik]

Hello @luckerby

I know that there was a bug in a preview version of .NET 4.8 where this API was always returning 0: https://twitter.com/dotMorten/status/1110237429397479424

Could you please use Windows Updater and check if you are having any available .NET updates?

if execution would have continued in the code as if this wasn't a "classic" .NET Framework", it would have reported the right value

GetAllocatedBytesForCurrentThread returns memory allocated only for the current thread, so it would return invalid value for multi-threaded benchmarks and bring #723 back to live.

[luckerby]

Thanks @adamsitnik ! I've went ahead and installed the pending Windows updates, and once done everything works as expected:

The only .NET-related update that was in the set of those installed was this one, so I'm assuming this is the one that corrects the issue.

[adamsitnik]

Thanks @luckerby , I am glad that it helped! I am closing the issue since there is really nothing we can do on BDN side