This does not happen for me. I am using 4.3.18 with Windows 11 25H2 Pro. Maybe this behavior depends on the graphics card used by Qubes???
I added “de locale, renamed user” 25h2 image to my testing environment, but it takes some more time to chase the update bug.
Grab 4.3.30. A lot of bugs chased in between
Will proceed with settings issues now.
Next week - I’m on holiday now.
4.3.32 is performance release, composite windows (Explorer, MS Office) are rendered much faster now.
I think you followed the wrong instruction (original qwt), I reduced the number of reboots, but it should do no harm. On seamless mode: my intention was to make it require a reboot, but on a second thought.. why? Fixing now. Config window is the next.
I checked the new QWT version 4.3.32, which performs better than the previous ones, but still has some errors.
- The Windows menu is shown just once for a second and then disappears. Trying to start it once again just shows a black rectangle where the menu should be; it has the intended size.
- Submenus shown from the Open-Shell menu or from the Explorer’s right-click menu are rendered badly.
- Trying to start the updater from within Windows leads to an error message that no internet connection is possible, but the Windows updater seems to find out that there are updates. Afterwards, a command window pops up repeatedly, caused by the notifier utility.
- Trying to start the updater from the Qube manager, which shows that it knows about existing updates, shows the following error:
Updating Windows-11
ERROR (Exception [Errno 13] Permission denied: ‘var/log/qubes/update-Windows-11.log’)
- When the updater is closed, the following error message pops up:
Command’[‘/usr/bin/qubes-update-gui’,‘targets’,‘Windows-11’]’
returned non-zero exit-status 26.
I hope this helps a bit.
thanks, will investigate.
Windows 10 is still the friendlier system: the native Windows menu behaves correctly, and the submenus render properly.
there is A LOT of experimental features I am exploring on win11, so it is expected to be flakey for a while. it would be worth it at the end i hope ![]()
In 4.3.33 i made a major improvement to update machinery, among other fixes, please test. the update log must have wrong permissions, delete the old one first.
Now Testing 4.3.33, with the following results:
-
The Windows native menu is shown just once when invoked directly. Afterwards, nothing seems to happen, neither from Open-Shell now directly, but the menu seems to be “shown” invisibly, because clicking somewhere in the space where it should be my invoke some function, like starting Paint or so - very weird. Also, a message “VMNAME: Oubes: A window could not be shown” may pop up. Here’s the log of the gui-agent from the installation, if this helps:
gui-agent-20261004-134808-3128.log (10.8 KB)
-
The bad rendering of submenus is fixed.
-
Right-clicking on a file in Explorer works as expected.
-
Trying to update from the Qube manager still shows (wrongly) that no updates are available.
-
Trying to update from within the qube still leads to the complaint that no internet connection is available.
-
The same happens when trying to execute the update for KB5101684, which is shown in the Windows Update window.
During the tests, the following log was created in /var/log/qubes:
qrexec.Windows-11-idd.log (2.2 KB)
I’m not sure what triggered this.
So far, there is no var/log/qubes/update-Windows-11.log.
Updater seems to have upgrade bug: upgrading qwt while update scan is running leaves the updater unupdated
WIll fix soon.
It is normal that stock WU path is unavailable – there is no system-wide proxy for security reasons, so you need to use dom0 updater. Will think more about how to make selective updates work.
Side note on code quality: a lesson I learned the hard way. Original QWT had a lot of “meat slop” in code: race conditions, undefined branching, nondeterministic expectations with sleep-and-wait in hope “it eventually settles”. Also, Qubes “abuses” libvirt/qemu/xen in a way Xenserver never does, and under some occasions vCPUs may go spinlock in interrupt routines, and I was chasing this defect from the very beginning. In many of these chases, I did occasional “quality refactoring” that was aimed to improve how it behaves. I made several deep audits with state of the art LLMs, but none came up with plausible conclusion.
My general rule stands: do not touch upstream, do not rely on host system improvements in attempts to solve your problems even if there are obvious bugs. It is not just slow and outside of my area of work, it is wrong and may have non-obvious security implications i do not want to take responsibility for. If other guest systems are stable and fast, so could be mine.
Guess what? The better my code gets, the worse it behaves. Spinlock rate was crawling up after almost every quality improvement, I brought it down with more workarounds, then it repeated.
I evaluated my historical data with Jev and got 0.99 confidence: it is true. It gets worse all the way, after almost every major code rewrite.
Turns out, all this “opportunistic condition handling” eases and distributes host API workload in a way that just somehow “works better”. I evaluated this hypothesis separately, and now I am targeting it directly, with more success ![]()
Now testing version 4.3.35 with a Windows 11 25H2 template. Some results:
- When starting the VM after the installation of QWT, a lot of notifications pop up:
- The native Windows menu is now invisible in seamless mode and not clickable, but on the first try, more messages pop up, while it works in non-seamless mode:
- Right-clicking a file opens the context menu, but, at the first click, the top ow that should show the icons for copy, paste, etc: is blacked out, while further right-clicks succeed:
The following behavior is unchanged, possibly connected with some of the messages:
-
Trying to update from the Qube manager still shows (wrongly) that no updates are available.
-
Trying to update from within the qube still leads to the complaint that no internet connection is available.
-
The same happens when trying to execute the update for KB5101684, which is shown in the Windows Update window.
@arkenoi Your descriptions of the fixes make me shudder: you are walking in a deep morass! This shows the effect of M$ reducing or even closing its QA department some 10 years ago clearly. And I am afraid that it will get worse now that they are replacing their programmer with AI and probably never check the AI output.
updates are somewhat tricky (if you are curious about how this thing works, here is the description: qubes-win-idd-driver/docs/ADR-updater.md at main · arkenoi/qubes-win-idd-driver · GitHub ). will try to reproduce and make better tests. it should had worked already (i specifically tested it on german edition), but.. KB510684 is “preview cumulative” and is handled in most ugly possible way. On it now.
Start menu is expected to be not working in seamless (at least not with hotkey. as a menu shortcut maybe).
Windows graphics subsystem itself is a terrible architectural mess by itself, but that’s what we got.
update within the qube is not expected to work (at least, yet).
“the guest is waiting on sign-in” is part that worries me. are you sure you did not disable auto logon?
UPD: I intentionally did not decouple the user session from system boot, so it is expected to behave in most strange ways if you log out, enable password, switch users or use managed accounts. Tell me if you want this to be sorted out early, it is quite low in my priorities.
No - Autologon is on and working:
Autologon.reg.gz (7.0 KB)
I didn’t do any of these actions; I just booted and auto-logged on with the defined username.
crazy stuff
this part is hard to reproduce.
Now I tested on a new Windows 10 22H2 template, which had no previous version of QWT, as was the case for my Windows 11 25H2 template, with very good results:
- The lot of notifications shown in Windows 11 do not appear. There is just one message that appears during QWT installation and, later on, during boo and several times after that. This message also appeared for Windows 11:
- The native Windows menu is still visible and works as expected in both seamless and non-seamless mode.
- Right-clicking a file works as expected, too.
- The Qubes taskbar shows available updates for Windows 10 (I wonder that there are still some), and allows you to install them using the Qubes proxy without complaint.
- Furthermore, Windows 10 is much faster than Windows 11, although it has only 12 GiB instead of the 16 GiB used for Windows 11.
Comparing the results for Windows 10 and 11, I conclude that we’d have a much better Windows environment if we could just throw away any (Windows-?) software M$ has written over the last 10 or so years. By the way, the Windows 11 native menu was something they created anew from scratch - which they had better avoided. ![]()





