You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We would like to get a stack of an event using the real-time (non-file) based support of TraceLog. The event is published using an EventSource in the same (.net 8) process as the process which is hosting the TraceEventSession.
We where looking at the "41_TraceLogMonitor.cs" sample to implement this.
We have the basic sample running (and included) this sample does capture the event, but it only translated a very small part of the stack
This might be caused because we disabled the EnableKernelProvider and ClrRundownTraceEventParser.ProviderGuid, but if we enable it the custom event is not captured anymore. Does anybody know where are can start to fix this.
Background
First of all thank you for this great library and tools. We use EventSource in our .net 8 applications everywhere to detect all kinds of issues. Recently we are removing old (depreciated) functions. We use an event so we can detect when this happens and report it to the appropriate teams for fixing.
We are looking to make this process even more developer friendly. We have added an option in our WPF application so it display some UI elements when we detect a "DepreciatedFunctionCall" event. The developer can click on it and get some details about the "DepreciatedFunctionCall" event, such as the method name. This is all working fine.
Now we want to add the stack when the event occurs. A simple solution would be to add the stack trace as data to the event. However we noticed that perfview (with the @StacksEnabled=true) and "dotnet-trace collect" is able to get stack information without having to add it as data to the event. So we would like to add it that way to keep our events cleaner.
What you're trying to do is supported. You will need some kernel and rundown events in order to resolve all symbols. Your current issue is likely that you're just getting events for methods that are jitted during the trace, but no native code or pre-compiled managed code.
For native and pre-compiled managed code, you will need to enable some kernel events. For jitted code that was jitted before the trace started, you will need rundown.
Hi,
We would like to get a stack of an event using the real-time (non-file) based support of TraceLog. The event is published using an EventSource in the same (.net 8) process as the process which is hosting the TraceEventSession.
We where looking at the "41_TraceLogMonitor.cs" sample to implement this.
We have the basic sample running (and included) this sample does capture the event, but it only translated a very small part of the stack
This might be caused because we disabled the EnableKernelProvider and ClrRundownTraceEventParser.ProviderGuid, but if we enable it the custom event is not captured anymore. Does anybody know where are can start to fix this.
Background
First of all thank you for this great library and tools. We use EventSource in our .net 8 applications everywhere to detect all kinds of issues. Recently we are removing old (depreciated) functions. We use an event so we can detect when this happens and report it to the appropriate teams for fixing.
We are looking to make this process even more developer friendly. We have added an option in our WPF application so it display some UI elements when we detect a "DepreciatedFunctionCall" event. The developer can click on it and get some details about the "DepreciatedFunctionCall" event, such as the method name. This is all working fine.
Now we want to add the stack when the event occurs. A simple solution would be to add the stack trace as data to the event. However we noticed that perfview (with the @StacksEnabled=true) and "dotnet-trace collect" is able to get stack information without having to add it as data to the event. So we would like to add it that way to keep our events cleaner.
Thanks in advance,
Bart Vries
TestCs.zip
The text was updated successfully, but these errors were encountered: