Thanks for the report. This bug is kind of hilarious. At first I thought that the spaces in the folder were the problem, but they aren't. Well, not really. That is, if you remove the spaces then the problem goes away, but it also goes away if you just remove one space, or if you add more.

The problem is that UIforETW looks for a previously running copy of itself and activates itself if it finds one. And it does that with this code:

HWND prevWindow = FindWindow(NULL, L"UI for ETW");
if (prevWindow)
{
	// Only allow one copy to be running at a time.
	SetForegroundWindow(prevWindow);
}

In your scenario the name of the Explorer window is "UI for ETW" so the explorer window is found and activated.

I should be using a clearly unique mutex or some-such, or else checking what process owns the window, or something. Anyway, that's the problem.

Pull requests welcome, or else I'll get around to fixing it at some point. Thanks again.

Link to the problematic code, which was there in the very first commit:

https://github.com/google/UIforETW/blob/main/UIforETW/UIforETW.cpp#L194

In addition to the obvious workaround of renaming the folder you can also workaround this by configuring explorer to display full path names in window titles.

Fixing this will be easy, but I don't know when I'll do a new release.

This fix will ship in the next release.

I've added an extra fix that would not switch to an open folder with the same name, but uniquely identify only the duplicate UIforETW instance via a unique window message.
This should fully cover this issue