Restored Windows qube has no app menu entries; entries can't be added

[GWeck]

Qubes OS release

R4.2.0-rc1

Brief summary

If Windows Qubes (tested with Windows 7 and 10 templates and AppVMs) are restored from a backup, their Qubes application menus are empty or contain only the Start qube entry. The application refresh window of the Qube Manager may just contain Application missing in template entries or none at all. Refreshing the menu has no effect.

Steps to reproduce

Install a Windows Qube in R4.2, and try to populate its Qubes menu.

Expected behavior

Entries in the Windows menu should be available in the available pane of the application menu window, and it should be possible to move them to the show pane to select them for use in the Qubes menu. At least, after pushing the Refresh button, the Windows menu entries should be made available.

Actual behavior

The left pane stays empty, and no Windows menu entries can be selected for the Qubes menu. The CLI command qvm-sync-appmenus has no effect.

This may be caused by an incompatibility between the old Qubes menu and the new application menu of R4.2.

[marmarek]

This applies only to restoring from backup, right? On fresh Windows install it appears to work fine: https://openqa.qubes-os.org/tests/76774#step/windows_clipboard_and_filecopy/6

[GWeck]

I checked now with a new installation of Windows 10 Pro 21H2 and QWT 4.1.69, according to the documentation.

• The menus are shown and can be transferred to the Qubes menus. Their content is not identical to the Windows menu structure, however. Just some entries in the submenus are shown in Qubes, but these can be moved as expected.
• It is possible to start a Windows qube by clicking on the Qubes menu entry for that qube, e.g. on Notepad, which is available.
• Clicking on such a menu entry, when the Windows qube is running, starts some action in this qube: there is a spinning wheel for some seconds, but the app is not started.
• The Qube Manager offers the actions to enable/disable seamless mode. As is to be expected for Windows 10, this has no effect on the display of the Windows qube, but the Qube Manager crashes.

[marmarek]

• It is possible to start a Windows qube by clicking on the Qubes menu entry for that qube, e.g. on Notepad, which is available.

Does the application start in this case?

[marmarek]

• Their content is not identical to the Windows menu structure, however. Just some entries in the submenus are shown in Qubes

What is example difference? Some entry is missing?

[GWeck]

Does the application start in this case?

No - there is just the spinning wheel near the cursor, but nothing happens. After a few (5 or so) seconds, the wheel disappears. From within Windows, the application can be started.

What is example difference? Some entry is missing?

These are the menu entries that are available within Qubes:

:-Windows-system32-config-systemprofile-AppData-Roaming-Microsoft-Internet Explorer-Quick Launch Microsoft Edge
Accessibility Speech Recognition
Accessories Math Input Panel
Accessories Notepad
Accessories Paint
Accessories Quick Assist
Accessories Remote Desktop Connection
Accessories Snipping Tool
Accessories Steps Recorder
Accessories Windows Fax and Scan
Accessories Windows Media Player
Accessories Wordpad
Accessories-System Tools Character Map
Administrative Tools Component Services
Administrative Tools Computer Management
Administrative Tools dfrgui
Administrative Tools Disk Cleanup
Administrative Tools Event Viewer
Administrative Tools iSCSI Initiator
Administrative Tools Memory Diagnostics Tool
Administrative Tools Performance Monitor
Administrative Tools Print Management
Administrative Tools RecoveryDrive
Administrative Tools Registry Editor
Administrative Tools Resource Monitor
Administrative Tools Security Configuration Management
Administrative Tools services
Administrative Tools System Configuration
Administrative Tools System Information
Administrative Tools Task Scheduler
Administrative Tools Windows Defender Firewall with Advanced Security
Immersive Control Panel
Microsoft Edge
Start qube
System Tools Task Manager
Windows PowerShell 
Windows PowerShell ISE (x86)

This corresponds roughly to the last two submenus Accessories and Adminitrative Tools of the Windows menu. The rest of the Windows menu is completely missing.

I backed up my two Windows test qubes and restored them from the backup. The behavior stays the same, i.e. these menus are available after a refresh, and can be transferred to the Qubes menu, but have no effect on the Windows qube, with the exception that they start it if it is not running, but they start no apps.

[GWeck]

I repeated the test now with Windows 7 Professional SP1 fully updated, which I installed as new HVMs.

Here, Qubes shows the correct (as far as I could see) menu structure as available, and the menu items can be selected for the Qubes menu. The selected Qubes menu entries work as they should. and, in seamless mode, the Windows VM can be started, by e.g. selecting the Windows Explorer menu entry, whereupon the qube starts and shows the Windows Explorer - just as it should.

On the other hand, Windows 10 (and probably also W11) works correctly under Qubes R4.1.2. So the whole thing probably is caused by the menu interface between W10 and the new Qubes application menu, whereas a new installation of Windows 7 is not affected. With Windows 7, only VMs restored from R4.1.2 are affected.

[marmarta]

The menu doesn't really change much in the way programs are run, though. I wonder if it's not a difference in the way .desktop files for windows qubes are generated.

[GWeck]

That's plausible: Windows 10 may simply deliver wrong or insufficient information to create the .desktop files.

On the other hand, with respect to the broken menus on qubes restored from R4.1 backup, could it be that there some information needed to create the .desktop files is missing?

[GWeck]

Maybe I found a cause of the problems mentioned above: Creating the App menu desktop files from the Windows menus involves starting the Powershell script get-appmenus.ps1 in the Windows qube. In Qubes R4.2 (with QWT 4.1.68 or QWT 4.1.69), this script does not find/process the Windows menu entries. Instead, it throws errors like the following:

Script_Errors.txt

Consequently, the lists of .desktop files and icons are not filled, and the list of hashes in the registry key AppMenus stays empty. If you fill these lists manually, e.g. from an R4.1 system, the menus work as expected.

As I don't speak Powershell, I have no idea what went wrong there and what is the difference to R4.1.

[DemiMarie]

@GWeck Can you set the language of the Windows machine to English and retry? Those look like ArgumentNullException or NullReferenceException, but I can’t read enough German to understand it.

[GWeck]

I am not too sure how to install English in my Windows VM, but I am trying. It may take some time, however.

At least I tried to translate the log file using the DeepL translator, and it looks plausible. Here are the results:

Script_Errors_English.txt

I hope this helps a bit until I get the real text in English.

[GWeck]

The reason for these errors is that the COM-object WshShell is created with the wrong type. Executing $WshShell | Get-Member returns

   TypeName: System.__ComObject

Name                      MemberType Definition
----                      ---------- ----------
CreateObjRef              Method     System.Runtime.Remoting.ObjRef CreateOb...
Equals                    Method     bool Equals(System.Object obj)
GetHashCode               Method     int GetHashCode()
GetLifetimeService        Method     System.Object GetLifetimeService()
GetType                   Method     type GetType()
InitializeLifetimeService Method     System.Object InitializeLifetimeService()
ToString                  Method     string ToString()

while it should return

   TypeName: System.__ComObject#{41904400-be18-11d3-a28b-00104bd35090}

Name                     MemberType            Definition
----                     ----------            ----------
AppActivate              Method                bool AppActivate (Variant, Va...
CreateShortcut           Method                IDispatch CreateShortcut (str...
Exec                     Method                IWshExec Exec (string)
ExpandEnvironmentStrings Method                string ExpandEnvironmentStrin...
LogEvent                 Method                bool LogEvent (Variant, strin...
Popup                    Method                int Popup (string, Variant, V...
RegDelete                Method                void RegDelete (string)
RegRead                  Method                Variant RegRead (string)
RegWrite                 Method                void RegWrite (string, Varian...
Run                      Method                int Run (string, Variant, Var...
SendKeys                 Method                void SendKeys (string, Variant)
Environment              ParameterizedProperty IWshEnvironment Environment (...
CurrentDirectory         Property              string CurrentDirectory () {g...
SpecialFolders           Property              IWshCollection SpecialFolders...

So there is no method SpeicalFolders that could be invoked to retrieve the Windows menu structure. I suppose that the type of the COM-object to be created just does not exist. I checked that .NET 3.5.1 and 4.8 are both installed on a system returning the correct COM-Object and on the faulty VM under Qubes R4.2, so there must be something else missing.

I'll continue checking.

[DemiMarie]

• The Qube Manager offers the actions to enable/disable seamless mode. As is to be expected for Windows 10, this has no effect on the display of the Windows qube, but the Qube Manager crashes.

Please report a bug for this @GWeck.

[GWeck]

Just created issue #8677

[GWeck]

Restoring a backup from Qubes R4.1 in R4.2 destroys the COM-Structure of the restored Windows 7 qube:

• I checked the structure of WshShell of a Windows 7 template under Qubes R4.1.2 with Get-Member, which was correct.
• Then I backed up this qube and and restored it under Qubes R4.2.0-rc4, not changing anything in the restored qube. There I got the wrong structure as listed above.

This looks as if the restore of Windows qubes from R4.1 is faulty under R4.2.

[GWeck]

Backup-restore seems to be innocent: I just copied root.img manually from R4.1.2 to R4.20.-rc4, and the behavior is the same: The qube under R4.2.0-rc4 has the faulty COM-Object WshShell.

[DemiMarie]

@GWeck How much is on root.img and how much is on private.img? I wonder if some COM stuff (registry?) wound up under private.img.

[GWeck]

No change if private.img is copied together with root.img. Anyhow, I suppose that the relevant parts are stored under HKLM and not under HKCU, which is kept in the private image.

The problem seems to come from the fact that Wscript.Shell is used to create a COM-object of the wrong type, as shown in the first lines of the listings above. This affects just the scripting host; other COM-objects like Shell.Application behave normally. On the other hand, the scripting host can be started normally, but this does not change the behavior.

[GWeck]

I did some more testing in order to locate the cause of the problems with transferring the Windows menus to the Qubes menu. All tests were performed on Qubes R4.2.0-rc5 fully updated.

• An empty Windows 7 template without any applications can be transferred via backup from Qubes R4.1.2 to R4.2. If Qubes Windows Tools were never installed in this qube, QWT version 4.1.69-1 can be installed under Qubes R4.2 without breaking the access from Powershell to the Windows scripting host, and the Windows menus can be transferred to the Qubes menu. The Windows qube will run with or without seamless mode and can be switched from one mode to the other. Later on, it was possible, without problems, to build the application structure originally used under Qubes R4.1.2 in this template, and an AppVM could be based on this template, running as it should.

The direct transfer of a Windows 7 template having Qubes Windows Tools on board from R4.1.2 to R4.2.0-rc5 showed a more difficult behavior:

• Transferring the Windows qube while Qubes Windows Tools 4.1.68-1 was installed in it resulted in breaking the scripting host as described above, such that no transfer of the Windows menus to the Qubes menus was possible. So far, I found no way to circumvent this error.

• If QWT is uninstalled in Qubes R4.1.2 before transferring the TemplateVM to R4.2.0-rc5, the scripting host can be accessed from Powershell in Qubes R4.2. Transferring the menus is not possible, however, as the necessary service for that is part of Qubes Windows Tools.

• Installing QWT 4.1.69-1 in this template under Qubes R4.2.0-rc5 without the Xen PV network and disk drivers and without the Qubes GUI Agent on this template preserves the structure of the scripting host, and the Windows menus can be transferred to the Qubes menu. The resulting system, however, is not able to run in seamless mode, as is to be expected.

• Changing QWT in this system from the installer to include the Xen PV drivers breaks the structure of the scripting host, as described above, and the Windows menus can no longer be transferred to the Qubes menu - if you try to refresh the Qubes menu for this template from the Qube Manager it is destroyed, as is to be expected.

• Changing QWT to include the Qubes GUI Agent seems to work normally until the required reboot of the qube, but then Windows does not come out of its boot sequence. Instead, the qube hangs and can only be killed - even shutdown is not possible. After being killed, the qube is really dead and can no longer be started at all.

• Installing QWT 4.1.69-1 directly with the optional Xen PV drivers, but without the Qubes GUI Agent breaks the use of the scripting host immediately, such that the menu transfer is destroyed.

• Trying to install QWT 4.1.69-1 with the Qubes GUI Agent, but without the optional Xen PV drivers immediately leads to a dead qube: The Window disappears while the installer is still running, and the qube can only be killed. By the way, trying to enable or disable seamless mode for this dead qube kills the Qube Manager, like described in issue #8677.

I hope this helps somewhat to pinpoint the cause of the problems and will repeat the tests with a Windows 10 TemplateVM.

[GWeck]

For Windows 10, the results are similar, but, of course, without the Qubes GUI Agent, which is not yet available for this system. All tests were performed on Qubes R4.2.0-rc5 fully updated.

• An empty Windows 10 21H1 template without any applications can be transferred via backup from Qubes R4.1.2 to R4.2. If Qubes Windows Tools were never installed in this qube, they can be installed under Qubes R4.2 without breaking the Windows scripting host, and the Windows menus can be transferred to the Qubes menu.

The direct transfer of a Windows 10 22H2 template from R4.1.2 to R4.2.0-rc5 showed a more difficult behavior:

• Transferring the Windows qube while Qubes Windows Tools 4.1.67-1 was installed in it resulted in breaking the Windows scripting host as described above, such that no transfer of the Windows menus to the Qubes menus was possible. This is not so tragic, as, after a boot, this system just shows a black window. So far, I found no way to circumvent this error.

• If QWT is uninstalled before transferring the template from Qubes R4.1.2 to R4.2.0-rc5, the Windows scripting host can be accessed from Powershell in Qubes R4.2. Transferring the menus is not possible, however, as the necessary service for that is part of Qubes Windows Tools. QWT deinstallation may cause the VM to crash with the message Inaccessible boot device or so, and will lead to crashes on subsequent boots. After several restarts, Windows offers to be booted in protected mode, and after this is done, no more crashes will occur.

• Installing QWT 4.1.69-1 with or without the optional Xen PV network and disk drivers on this template preserves the structure of the Windows scripting host, and the Windows menus can be transferred to the Qubes menu. If the optional drivers are included in the installation, Windows will crash with the message Critical process died, but after booting again will run normally.

Windows 11 will probably behave in the same way, as this system is basically just a somewhat more user-unfriendly version of Windows 10.

So, Windows 10 appears to be more robust than Windows 7, partially due to the lack of the Qubes GUI Agent. If the problems described in QSB-091 are solved, perhaps by including a new version of the Xen drivers, and a new version of the Qubes graphic driver is made available, as @marmarek has said at the Qubes Summit, then we might have an excellent integration of Windows into Qubes! I am looking forward to this and hope that Windows 7 - in my opinion the last usable version of this system - will still be supported.