Allow user to mark regions in a trace

[ricnewton]

Don't know if you are interested in this but I found myself wanting to have an easy way to mark regions in a trace to quickly find significant events via a keyboard shortcut.

I've added new keyboard shortcuts Win+Ctrl+Alt+[0-9] to allow 10 separately marked things (probably overkill, I tend to use at most 2), repeatedly hitting them toggles on/off the marking.

I have a custom WPA preset based off your Multi Events with field1 and field2 moved above Opcode Name and filtered to Task Name = UserMark.

[ricnewton]

By the way, I did not update the bin/ETWProviders.dll since I'm on Visual Studio 2015 and they seem to be build on an older compiler.

[randomascii]

Sounds reasonable, but (just to clarify) can you explain the advantages of this over using the generic keyboard input recording. That is, all keyboard input is already recorded in the trace (obfuscated by default for many reasons) and I want to be clear on how this differs.

I should rebuild bin/ETWProviders.dll with VS 2015 for consistency - there's no reason to have it on an older version other than that I haven't gotten around to making the switch.

[ricnewton]

Obfuscation is one thing, but the main workflow I was after was to hit a hotkey, run some action over a fairly short time, hit the hotkey again, then in the trace in in WPA be able to select that user marked region and have the time period select so I can zoom to that time window (a bit like you can select the time period for a given window in focus)

If this is possible with just keyboard events that would be great, I just wasn't sure how to set up WPA to do it in a slick way.

[randomascii]

See image below. Note that alphabetic characters are all recorded as 'A' and numeric characters all recorded as (IIRC) '0' to avoid information disclosure. Function keys are recorded verbatim, and full recording is an option.

So, pretty easy to select the relevant key-up/key-down events and zoom to that region. Super useful. And, since it records incidental interaction (mouse moves/clicks as well) it usually automatically gives you time-context. Window in focus also very useful.

Note: I've been thinking of recording actual key codes for letters when Ctrl is held down. Ctrl+V versus Ctrl+C seems useful, without violating privacy. Thoughts?

[ricnewton]

I like the idea of recording the key codes, looks useful. I was using the key down view before and it was great, it just took a few seconds to find the right key event each time, now as I have it it's a single click to instantly highlight the marked region.

I guess if we had the full key code I could set up WPA to filter a view to just show key down for a specific key combination and have that select the time window in a single click, right?

[ricnewton]

So this is my initial setup:

So I can quickly select the marked region by selecting it in the top window, hopefully I could reproduce this workflow with the keycode being specified.

[randomascii]

Correct, and there should be full key codes for function keys. A change to the default startup profile to add a new view that filters for this may be all that is needed.

Also, look into regions of interest. I haven't explored them much but one such XML file does ship with UIforETW and it can automate the process of matching up events. Potentially very cool.

[ricnewton]

OK, sounds like it will work great, I'll wait for the keycode changes. Shall I close this pull request?

[randomascii]

I'll wait for the keycode changes.

Function key codes are already recorded fully. See this trace I just captured (columns reordered to put each key on a separate row and to filter out all non-function key events).

So, I think everything you need is available.

[ricnewton]

So is there a way to set up the filter to only show say Ctrl+Win+F1 (picking a hotkey at random), so I could highly the region between 2 presses of that combination? Though just using the function key on its own works, it would be even cooler if I could filter to a specific combination with modifiers.

[randomascii]

It looks like the state of the control key is not saved with each key event. That is a generically useful piece of data so maybe that is the real change that should be made. Would just need to modify the existing keyboard input ETW events to have an extra field (bit mask?) for that and then emit the extra information.

Preserving filters is also tricky. "Filter to selection" is not saved in startup profile. But View Editor-> Advanced has some options. This image shows me modifying the filter so that only rows where Field1 (key code in this case) starts with 11 show up. Crude, would need some work, but workable.

If emitting custom events for this one purpose is simpler I'm not opposed to it. It's not like it has any significant cost, and working with the existing events is looking increasingly complex.

[ricnewton]

I don't think we need a custom event now, I like your idea better.

You already save a string as part of the key down event (field2), could we extend that to append any control keys along with the key pressed in LowLevelKeyboardHook? Or add another string field, extended key name or something, would be a string like "Ctrl+Alt+F1"

[randomascii]

Yes, that would be entirely reasonable and appropriate. Either the existing string or a new one. I don't think it much matters which.

[ricnewton]

Cool, I'll close this request then.