Brian Robbins

@kirsan31, you will also need to enable the TPL events. These are not enabled by default as they are quite verbose and can impact CPU sampling results.

Interesting. Are you by chance able to share the trace? It looks like this view should show up as long as you specify /ThreadTime and TPL events.

Yes, I will need the full trace. Feel free to post it to a site such as OneDrive and then send a link to me at brianrob [at] microsoft.

Got it. Thanks. The issue is that you are capturing the TPL events, but it appears that stacks are not being collected, and this view requires stacks on these events...

That's a good question - I don't know, and I'm not even quite sure where to get a copy to check.

Yes, if you're able, it would be awesome to see what happens [here](https://github.com/microsoft/perfview/blob/main/src/PerfView/CommandProcessor.cs#L711) in a debugger. This line ends up opening `kernel32.dll` and that's where I think things are going...

Interesting. That one I can't explain...

I don't believe that there is anything tracking long path support, so this issue can be used to do so. https://github.com/microsoft/perfview/commit/5f738b85d44f43240ec00e45a81a1a1576224fa5 is actually for reaching into Windows process isolation containers...

@alois-xx, I need to do a bit of research on your proposed change to understand the details, especially around the manifest file. Let me look into this and report back.

@yang-er, there aren't any current plans to do something specific around Packet Monitor, but it looks like Packet Monitor produces an [ETL file](https://docs.microsoft.com/en-us/windows-server/networking/technologies/pktmon/pktmon-netmon-support) that is consumable via NetMon, and PerfView...