Closed xiaomi7732 closed 6 years ago
Can you describe the repro a bit more? The version number you are describing is a version number for an ETLX file.
The output above looks like a PerfView log, but PerfView shoudl not respond in the way the log above indicates. It generates the ETLX file from the netperf file right on the spot and thus 'can't be wrong' (and if there was an exception, it throws the ETLX file away an tries again.
THus I can't reconcile what you show it how PerfView works. I also just tried opening a variety of version of *.netperf Files with PerfVIew and they opened fine (which is what I would have expected).
I WOULD expect the behavior you got if you were trying to open ETLX files that were generated earlier by some earlier version of PerfView/TraceEvent. Is this what is happening?
@vancem You are correct, I had an old version of the etlx on the box. Sorry for the confusion.
However, I was trying to open a netperf file, it seems it does NOT throw away the deprecated etlx file in the temp folder. The issue reproed until I had the temp folder cleared by using menu 'File|Clear Temp Files' in the PerfViewer.
So, this is a way smaller issue that shall be able to be fixed in #606 .
@vancem @brianrob In this commit, we bumped up the min-version for TraceLog to 69: https://github.com/Microsoft/perfview/commit/216108b7c27eea7526fb35d99337d7a54f5f04fe This breaks the scenario for PerfView to read EventPipe traces, which on CLR 2.0.4 is of version 68. Could you please take a look?
Here's the log when trying to open the netperf file
The trace is caught by using the runtime container: aspnetcore:2.0.5 https://hub.docker.com/r/microsoft/aspnetcore/