Windows 4.2 Support Functionally Incomplete - User Impacts and Solutions

Continuing the discussion from Qubes OS 4.1 has reached end-of-life; extended security support continues until 2024-07-31:

As a Windows user who needs Qubes as the (currently only?) way to run Windows 7, 10, and 11 systems in a reasonably secure manner, I have the impression that putting R4.1 to EOL is premature. Looking from this perspective, R4.2 is still not functionally completed, as long as the issues listed in What would you like to see improved in Qubes OS? are still open.

As described in QWT (support for Windows in Qubes OS) is not available anymore. When will this be solved? and issue #9102, this forces Windows users to decide whether they should continue using 4.1 even as an unsupported version or stop using Qubes as a protective shield for Windows altogether. Both alternatives will reduce their security considerably. The current market structure still requires many users to run Windows, so forcing them to abandon Qubes would, in my opinion, reduce the importance of this badly needed tool considerably.


I concur, not that my opinion matters nearly as much as yours does.

I use Windows as little as I possibly can (it has been months since I ran it as anything other than a test of something I wrote to support it), but when I need it, I need it and want to run it on QubesOS.


Windows works fine on 4.2, if you need QWT you can manually installed the version n-1 of the package which provides working QWT.

1 Like

Do you mean the QWT that are (the tools) blocked due to QSB-091?
This is not an acceptable option.
On the other hand, running Windows with Internet access is a way of giving up any hope of privacy and 85% of any security, so why not? :man_shrugging:


Unfortunately, there are still some open issues with QWT under Qubes R4.2, namely #9102 and #8328. Due to these issues, QWT 4.1.69-1 under R4.2 has some restrictions, which may allow to use it for some small work or tinkering around, but make it unsuitable for a production environment.

I don’t think that these problems are unsolvable, but as long as no one will work on them, Windows support under R4.2 is, in my opinion, not sufficient.

And then there is still the open problem of the Xen drivers of QSB-091, which still causes the “official” version 4.1.70-1 of QWT to be just a dummy. So far, there has, to my knowledge, been no attempt to integrate a newer version (9.0?) of these drivers into QWT, not to speak of the graphics driver and seamless mode for Windows …

For the last months, I have seen no action in this area, which is worrying me a lot.


Restricting Windows internet access to a - well-maintained, small - whitelist in sys-firewall may help a bit, but will be restrictive and probably cause a lot of maintenance work.

On the other hand, Windows users are used to suffering a lot :nauseated_face: :cry: :rage:


This is a rather unfortunate situation. Reading from #9019, it seems that the deprecation the Xen-provided drivers put the Qubes team between a rock and a hard place because in order to officially provide drivers microsoft has certain tyrannical requirements (for “security”, I guess). Quoting from #9019:

Release signing requires a few steps:

  • A proper code signing certificate (any authenticode one from a public CA is fine).
  • Windows Hardware Compatibility Program certification. The drivers need to be tested in the Hardware Lab Kit with a proper set of rules, then the (passing) results sent along the binaries and the signing cert to Microsoft for certification. If all goes well we receive MS-signed binaries back.
  • Some modifications to the Xen backend/pvdrivers might be needed, specifically to change the PCI device IDs so they don’t conflict with the upstream values. From my understanding only one set of drivers for a particular set of hardware IDs is permitted.
  • Changes to the building process to accommodate using a release cert, probably from an external storage/card reader.

Given this I think the only short-term solution is to either use offline VMs with compromised drivers (yuck, I understand) or build the new ones yourself (or ask for the test-signed to be made available) and run windows in test mode.


The test-signed drivers are available on Xen website:


This may be a dumb question, I am new to qubeos and having the same windows issues, would installing the PV drives from Xen be enough to replace the windows tools package or am I missing something?

It won’t be enough but I guess you can install the PV drives from Xen and install Qubes Windows Tools without Xen PV drivers (deselect their installation in the installer).

I tried to install the (unsigned) v9 Citrix drivers on Windows 11. Did not work. Your best bet is to use the last Qubes Windows Tools manually. At least on Windows 11.


You could deselect the disk and network drivers, but you would still need the bus and interface drivers, which cannot be deselected. Installing the new, version 9.0 Xen drivers along with QWT will either have no effect, because QWT still uses the old version 8.2.2 drivers, or it may even break QWT. Also, it it not clear if the new drivers are compatible with Windows 7.


Do the old drivers have the vulnerability and are they working/secure for windows 11?

1 Like

I read the announcement, but it said some might have not been compromised, I was wondering if any were verified to be uncompromised.

There is no way to tell whether they were compromised or not.

1 Like

No matter what, the issue should be addressed somehow. My full support to @GWeck on this.
Maybe step-by-step guide how to manually install Windows + QWT + test-signed drivers and have working windows qube as it was for R4.0/4.1 should be created. It can be enough for some time and some cases.

Because currently almost nothing is in docs about running Windows with QWT on the latest Qubes OS release.


I strongly concur with this take.

I use Qubes to virtualize windows for security purposes (as well as run test OS and app images in other VMs/qubes). If the 4.2 Windows support is not there, I won’t be migrating to it until it is production-quality-ready. I still have open issues which have not been resolved, which I hope will someday get some attention, but my system is quite usable in its current state.

What specifically is/are the problem/s with Windows support that need to be addressed, and who would be responsible for seeing them addressed from a management perspective? From what I am reading here, there seems to be multiple areas of concern, but it is not clear who, if anyone, is responsible for them, or if there is any real timeframe for them to be addressed. Maybe getting a handle on these details is a first step to developing a plan of action to resolving this situation. I certainly would like to see it resolved, and am happy to do whatever I can to help get it resolved.


TODO list is available in this Github Issue.

Rafał Wojdyła

Quoting Rafał from two days ago:

Yes, it should be available for user testing soon.

p.s.: Humorously talking, Interpretation of "soon" adverb requires proper context. If it is relative to average PC lifespan, to human’s lifespan or to humanity lifespan