"Software Update" window cannot be interacted with on Windows

[xobs]

I have no way to reproduce this, but it's so bizarre that I thought I'd open an issue just so someone is aware of it.

I received a message saying there was a software update. I clicked "Ok", which opened my web browser and let me download the new version.

The installer downloaded and ran. While it was running I quit the existing version.

The installer then complained that I would need to reboot in order to proceed. I selected "No", and it informed me that the install was done and it would quit.

However, now I have a floating window on my screen that is only a border. I cannot interact with this window at all.

It shows up on the lock screen. It floats over the Snipping tool. It does not show up in Spy++, nor does it show up in Process Explorer. I cannot kill this window. The only recourse is a reboot.

I have no way to reproduce this, and I'm sure a reboot would solve it. However, this is truly a bizarre situation, and thought it might be nice to share it.

[xobs]

Closing the issue because it's not actionable.

[ForNeVeR]

Any idea how/why this happens, though? I've reproduced this twice on my Windows 11 machine already — seemingly any time I cancel an update the window is left in this state.

No KeepassXC process running, even no file handles on any of its DLLs open — how it this possible?

Tried to interact with this strange window with spy++ to no avail.

This is the first time I am seeing such an interesting case.

[mattezell]

lol same here - has been happening about a year... I've spent a lot of time trying to find a workaround, but eventually just have to reboot, @ForNeVeR .

I've tried to figure out what the offending process is via Process Explorer, which I've used for similar such tasks since like 2008 - but it's like this ghost window doesn't actually exist, so far as Windows knows... Unlike other similar lingering windows documented in Windows, this one doesn't impede clicking behind it or anything of the sort - it's just a visual annoyance... There's a "Find Windows Process" tool that you can drag over any window and it will highlight which process it is in the process list - and it just highlights whatever process has a window directly behind this ghost window 🤣 Weird...

I don't even want to admit how many hours over the past year I've wasted trying to figure this out, out of pure stubbornness in not wanting to reboot... Changing resolution doesn't work, killing Explorer doesn't work, Resetting my GPU doesn't work, Sleep doesn't work, It's hidden when PC locks but still there after unlock, disabling the external monitor it's one and reenabling doesn't work, NOTHING WORKS 🤣

[mattezell]

@ForNeVeR I've submitted a PR that should resolve this.

In the meantime, if you execute the following, it will clear the window without a reboot (Windows will restart DWM automatically)

taskkill /f /im dwm.exe

[ForNeVeR]

For the record, I've been reading some related information with some help from my peers, and we ended up thinking that this could be related to the uiaccess:true in the application manifest — which was apparently removed by #13116.

This whole story might be related to the "bands", or layers of windows on Windows (sorry, no pun intended) — see this article investigating some related aspects of window manegement which also mentions something aptly named ZBID_UIACCESS.

[droidmonkey]

There is no relation because that change was never shipped.

[ForNeVeR]

I see. But let me develop my theory, if only for the brainstorming purpose. Perhaps it's unrelated to the manifest, but the further explanation still sounds interesting.

If somehow KeepassXC manages to create its window decorations in the ZBID_UIACCESS "band", or any of the other higher bands, such as ZBID_ABOVELOCK_UX — this would explain at least why they seem to be visible even on top of the lock screen display!

My understanding is that normally, the "UI Access" band is reserved for stuff like on-screen keyboards. Which would explain why it behaves so weird at times, and dialog behavior might be unpredictable: it's just not much software using that, and it might not be well tested by Microsoft.

I have no explanation why it might leave a ghost version of the window decoration even after the process being terminated, though. This to me clearly looks like a bug in Windows.

[droidmonkey]

It's a bug or edge case in qt. This pr that fixes it explains exactly what is going on: #13201