I tried the way you suggested too (default features only) - the result is: I didn’t have to kill the qube after QWT installation but after rebooting it the same error screen appears.
What do you mean by “stock distribution” (of what)?
Of QWT. Look at my project, it has it all in README.
I am not aware of your project. How do I look at it?
Does it solve my current issue?
Depends on how you look at that. But at least it uses modern, not outdated drivers. If you have more questions about Qubes security model and possible dom0 attack surface, I think I could explain this as well. Long story short, whatever guest OS does should never affect dom0 integrity.
Thanks for the link. That’s interesting. Will it work with Windows 7 too? And are you planning to submit it to the official project?
Thanks.
Right now, I am still fighting the setup. My goal is to make file transfer possible, so I can install the software I need.
Current progress:
I found that installing QWT in a way that does not result in the error screen I shared requires unchecking the whole Xen PV drivers section (not just the subsections). However, I can’t make the “Move user files” work. I tried creating the Q: drive on the second disk (private.img) before installing QWT, then running the qubes-tools-x64.exe but after reboot there is no Q: at all. Tried that in template and in AppVM - same result.
How do you do this?
Nope, I dropped Win7 support because even ESA has ended, there are no supported Win7 systems in the world 
“Move user files” DOES require PV disk driver destination, otherwise Qubes “system / private” separation is non-functional. So QWT moves user profiles to Q: automatically at install.
You really do want Win7? I can investigate this, but it is going to be low priority feature.
I am just wondering which QWT version you are using. If it’s 4.2.1 or later, this version uses PV drivers version 9.0.x, which is incompatible with Windows 7 (see the documentation). So far, the latest QWT version compatible with Windows 7 is the deprecated version 4.1.69, because it uses the compatible PV drivers version 8.2.2. This version is still available from the archives
Note, however, that this old version is affected by QSB-091, but, as I have stated in another post, the resulting risk is small or may not exist at all. Anyhow, Windows qubes are not trustworthy at all, so this may not change the risk situation. But as long as a Windows 7 qube stays completely offline, the risk of a successful attack is damn near zero.
Seriously, consistent support for Win7 is not worth it today.
It’s not worth primarily because of an insignificant user base.
But what if you have no license for W11 and do not intend to feed the alligator by buying one?
It works fine without activation. I, for one, feel no moral obligations about it because I purchased SEVERAL windows licenses in my life without any consent from my side, there was just no option to get same hardware without so-called “free” license. Telemetry is a different story, but it is mostly tunable.
This thread was never intended to be a feature request for software which I never even knew existed (your QWT which will hopefully merge upstream to the project one day), so the whole time I am referring to the official QWT only. All I need right now is to have a functional Win7 template and AppVMs, so I can install the software, as described in the OP.
Move user files DOES require PV disk driver destination, otherwise Qubes system / private separation is non-functional. So QWT moves user profiles to Q: automatically at install.
As explained earlier, PV drivers installation result in the error screen and non-bootable system.
As per docs we both referred to, the version I am using for Win7 on a 4.3.1 system is:
qubes-windows-tools-4.1.69-1.fc37.noarch.rpm
The software I need to use is as old (or maybe older) than Win7 itself anyway, so in regards to my XY problem it doesn’t matter that both are EOL. In that sense, wasting whatever resources for anything newer is simply not required.
I remember from another thread that you use Win7. How do you do this?
So did you succeed?
well, i think with package that old PV network drivers are most certainly incompatible with relatively modern Xen, and maybe disk drivers, too.
No.
well, it means the guest will work in qemu fallback. slow, but certainly no new attack paths.
I am starting to feel stupid here but I will try one more time:
Considering everything I said so far: How can I copy files to the Windows 7 qube?
I am running an age-old Windows 7, coming from Qubes R4.1 and ported to R4.2 and then to R4.3. When going to R4.2, I replaced QWT 4.1.68 with 4.1.69, but did nothing else.
What may be important is that this W7 system was fully updated, especially containing service pack 1 of W7. The latest updates after that are installed, but I have no idea if that is necessary; the service pack is necessary to run QWT.
Thanks for the feedback @GWeck.
My Win7 ISO has SP1 built in it, so I guess that is not a problem. Updates are obviously not an option and QWT does install. The problem seems to be that PV driver set and I am getting lost.