search

google / UIforETW

User interface for recording and managing ETW traces
https://randomascii.wordpress.com/2015/04/14/uiforetw-windows-performance-made-easier/
Apache License 2.0
1.55k stars 201 forks source link

UIforETW can't get symbols for old Chrome when profiling an upgrade #97

Closed randomascii closed 7 years ago

randomascii commented 7 years ago

ETW latches the module information for executables during the trace rundown, when tracing is stopping or being flushed to disk. This means that any modules which are deleted in the middle of the trace will get blank/zero columns for timedatestamp, version, etc., and therefore symbols cannot be loaded for these. The terrifically obvious fix to this is to record a brief pre-trace that contains the information, like this:

xperf.exe -start "NT Kernel Logger" -on PROC_THREAD+LOADER -f "%temp%\pretrace.etl xperf.exe -stop xperf.exe -merge "%temp%\pretrace.etl" "%temp%\inject.etl" -injectonly

and then add inject.etl to the list of traces that are merged in by the final "xperf -merge" step at the end. This has been tested and seems to work.

This is not applicable to tracing to circular-memory-buffers (when would you do this step?) but it is easily applicable to the other two modes. If the cost is not too great then this should just routinely be done.

This problem is particularly irksome when profiling a Chrome upgrade process. The old version of Chrome is deleted and no symbols can be loaded.

randomascii commented 7 years ago

This was fixed by c042f43b9db7bb824d475ba7fbbc4347af1d5fb3 (will be in the 1.45 release) - I just verified the fix on a canary upgrade and I was able to see symbolized stacks for both the old and new versions.

Symbols were shown for the old and new chrome.exe, even though I don't think WPA can actually distinguish between them, but in practice this should not be a problem.