Profiler

[lowleveldesign]

@secabstraction, I've scanned through the code and have few questions. The Get-ProcessTrace does not parse correctly right now - is everything committed? I would also like to put the PSReflect module as a dependency module (as it's done in PowershellArsenal) and remove it from the project code. Also, I think it would be nice to split the code of Get-StackTrace and Get-ProcessTrace among several files - > 1000 lines of code is extremely hard to support and develop. What do you think? I could start working on that in my fork, but would like to first discuss the changes with you. Also, what is your plan for the profiler? I guess the current goal is to make Get-ProcessTrace work, parsing both managed and native stacks, am I right?

[secabstraction]

Man I hadn't looked at this repo in quite a long time. I tried importing the module and running Trace-ProcessThreads and it worked just fine for me. I will try to go through the repo and clean things up today. As there are different use cases, I would prefer to have a branch with PSReflect as a dependency and another that doesn't. I need to do more research on the profiler piece, as I haven't looked far enough into it (was brought up to me by Lee Holmes).

[lowleveldesign]

I've seen the dates of the last commits and did not assume in any way that you will quickly respond :) I will make a research on my own regarding the mixed-mode stacks (I have planned to do so for my other project anyway). I will write back with any findings and ideas. Profiling API is one way to go (might be easiest) but on the other hand is also quite invasive. Maybe parsing internal CLR structures will be an interesting way too (although more risky as they may change between .NET versions).

Some time ago I was looking for a way to list app domains in a process and ended up with ETW rundown events (Process Hacker for instance is using structures extracted from the CoreCLR repository).