Zooming Enhanced Sessions in Hyper-V

In Hyper-V, there are two possible connection methods to connect to a guest. They are:

• Console interface. This is similiar to other offerings and is the one that always works.
• Enhanced Session.

Enhanced Session is one functinoality unique to Hyper-V: it uses vsock, a type of special socket for host-guest communication, to enabling connecting to a guest with Remote Desktop protocol. It can only be connected via vmconnect.exe, which is automatically launched when double-clicking a virtual machine inside Hyper-V manager.

Enhanced Session is supposedly to be faster than console interface and allows forwarding of resources such as sound and folders. However, it is a hurdle to use on HiDPI displays, as it relies on guests to perform scaling and does not perform scaling in the application itself. This can be solved by using program compability feature from the Windows OS, which is able to force an application to scale.

By copying %WINDIR%\System32\vmconnect.exe to any arbitary location, and forcing scaling by system in compability menu, it can be forced to scale to a bigger DPI and allows ease of use on HiDPI monitors. It is also possible to set HiDPI settings directly vmconnect.exe within %WINDIR%\System32 if desired to do so.

 

After applying these settings, enhanced session could be used with ease on HiDPI monitors.

Mysteries of "Write error during flashing" when updating BIOS on ThinkPads

Recently I ran into some issues with one of my ThinkPads, and updating both its BIOS and EC firmware to latest version could help a bit to troubleshoot the issue. However, I ran into a mysterious issue:

No matter how I launch its update utility, either invoking its GUI or by calling `WinFlash` from command line, it always ended up with failure. This always sounds scary, as "Flash Error" sometimes implies the flash is corrupted and one has to RMA the device. Think of the hassle of having to call support...

After some fumbling, it appears winuptp.exe leaves some logs in Winuptp.log, inside the same directory! Would its content be helpful?

2025-01-11 23:43:38.575 <NOTICE> BIOS Flashing ...

2025-01-11 23:44:12.535 <ERROR> Failed to update BIOS (102).

2025-01-11 23:44:12.535 <NOTICE> Retry BIOS update ... (1).

2025-01-11 23:44:46.319 <ERROR> Failed to update BIOS (102).

2025-01-11 23:44:46.319 <NOTICE> Retry BIOS update ... (2).

2025-01-11 23:45:20.648 <ERROR> Failed to update BIOS (102).

2025-01-11 23:45:20.648 <NOTICE> Retry BIOS update ... (3).

2025-01-11 23:45:54.902 <ERROR> Failed to update BIOS (102).

2025-01-11 23:45:54.904 [Flash Error] <ERROR> Write error during flashing.

2025-01-11 23:45:58.118 <NOTICE> LenovoBiosUpdateTool shutting down

No, it's not useful at all. It doesn't even makes sense when it tried to retry three times on failure! But I am left without all options at this point. I even tried to use the .iso provided by Lenovo, which is a self-booting image. It ended up with the same failure (image from Lenovo forums):

I decided to see what's happening behind the scenes. I fired up Process Monitor, filtered for WinFlash.exe, and saw this:

It appears Winflash tries to write the actual BIOS image to EFI System Partition (ESP) and then have the system update entire BIOS from ESP. Windows by default only allocates 100MiB for ESP and usually have some contents occupying the partition (bootloader, etc). No wonder why updating fails, but Lenovo did not factor this into its tooling and does not elaborate on its failure.

A quick remedy resolved the issue, and I now have a updated BIOS:

• Use diskmgmt.mmc to perform a 100MiB shrink on main partition. This creates a un-used space on the right-side of the main partition.
• Reboot to a Linux-based environment. Use gparted to move MSR and main partition to the right. The MSR must be in front (left) of main partition but behind the ESP.
• Re-size the ESP. Resizing the partition will success but will fail when resizing its filesystem as libparted does not support growing ESP at the moment of writing.
• Mount the ESP partition and rsync -avr everything to any arbitrary location for temporary storage.
• Delete ESP partition. Re-create and re-format new ESP partition. Copy everything back to new partition and reboot.

Except when moving the main partition, mishaps in other steps are probably not fatal; Windows Recovery Environment should be able to fix partition tables and the ESP.