Open mjsabby opened 4 years ago
I'm thinking of the following:
Process Start -> Process Id, Filename, Command Line Args Process End -> Process Id Module Load -> ModuleLoadAddress, ModuleSize, ModuleDebugGuid, ModuleDebugAge, ModuleFilename, ModuleDebugFilename Module Unload -> LoadAddress, Size
Thoughts?
Thanks Mukul! A few thoughts came to mind, not sure where it all leads yet but just dumping it here as part of our brainstorming : )
I've got yet some other thoughts about improvements it might be worth making if we are to make a breaking change but I'm trying to keep this thread just on the abstract events : ) We'll probably need to create an issue that is a general purpose v.next format wishlist. Let me know if you think I am getting carried away but breaking changes have same adoption challenges whether we do a little or a lot - so I want to at least get a lot out of it : )
First, let me say that nothing you've mentioned is bad, and I want ALL of it :) That said, I'm tempering this with the reality of me wanting at least something fairly quickly. Whether that means some of it is a format change and some of it is merely a library change is for us to decide.
That said, I'm tempering this with the reality of me wanting at least something fairly quickly
Sure, we can chat a little tomorrow about timelines and options for staging the work. There probably is some natural tension for you to deliver increments of work quickly vs. my desire to make breaking changes fairly substantive. I also have relatively limited time since this is concurrent with planning .NET 6 + trying to finish .NET 5. Hopefully we can still find a path that delivers what we need : )
Today
TraceLog
depends onProcessStart
,ProcessStop
(and their DCStart/DCStop equivalents),ImageLoad
,Image Unload
(and their DCStart/Stop equivalents) andImageID
events to be able to do useful event viewing and analysis of data.As we add the ability to add multiple processes inside NetTrace files, it becomes important to represent these events. After discussion with @noahfalk and @brianrob it seems like having them not depend on the Windows Kernel events per-se seems useful and doesn't encumber the NetTrace format with these OS-specific concepts.
So, effectively these events will inform equivalent data but using different events. In fact, they will be like any other EventSource events, except their parsers will be part of the TraceEvent package and we will hook them up by default in the parser hook up for NetTrace and are "enlightened" to be acted up on when serializing TraceProcess/TraceModule, etc.