[release/6.0] Fix in-process decoding of DateTime in EventSource

[github-actions]

Backport of #67557 to release/6.0

/cc @josalem

Customer Impact

@MihaZupan root caused this issue succinctly in this comment: #61563 (comment)

@tommcdon it is a bug introduced by #52092 in .NET 6.0, but only affects in-process EventListeners.

The difference is in how the serialized value (long) is de-serialized by DecodeObjects:

• In 5.0, the DateTime would be converted from a long back to a DateTime via DateTime.FromFileTimeUtc
• In 6.0, the value is interpreted as a DateTime directly (i.e. exact number of ticks)

Sadly this was not caught by tests since none of them uses DateTime with WriteEventCore - we are only testing the varargs overload.

The fix here would be to change

runtime/src/libraries/System.Private.CoreLib/src/System/Diagnostics/Tracing/EventSource.cs

Line 1844 in a25aa66

decoded = *(DateTime*)dataPointer;

to

decoded = DateTime.FromFileTimeUtc(*(long*)dataPointer);

-- MihaZupan

Testing

Test added with this PR and is running in main.

Risk

Low risk. The functional change is <1 LOC. The remainder are a test of the change.

[ghost]

Tagging subscribers to this area: @tarekgh, @tommcdon, @pjanotti
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Backport of #67557 to release/6.0

/cc @josalem

Customer Impact

Testing

Risk

IMPORTANT: If this change touches code that ships in a NuGet package, please make certain that you have added any necessary package authoring and gotten it explicitly reviewed.

Author:	github-actions[bot]
Assignees:	-
Labels:	area-System.Diagnostics.Tracing
Milestone:	-

[jeffschwMSFT]

Approved. We will take for consideration in 6.0.x. Please ensure to get another code review.

[noahfalk]

LGTM

[josalem]

@jeffschwMSFT should I add the servicing-consider tag or will that be done by tactics?

[jeffschwMSFT]

Added. Are the PR failures understood?

[tommcdon]

Added. Are the PR failures understood?

The failures look related to TLS 1.0/1.1 disablement. I believe the test fixes have not yet been merged: #68332.

[josalem]

Corroborating Tom's assertion. Nearly all the test failures look like:

System.ComponentModel.Win32Exception : The client and server cannot communicate, because they do not possess a common algorithm.

[carlossanlop]

/azp run runtime

[carlossanlop]

Running the tests again now that I merged #68332 .

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[carlossanlop]

Test failures unrelated, they will get disabled in this PR: #68867