[Bug]: CJK file names render as tofu in Explorer item views and desktop icon labels

[wanf3ng]

Windows Sandbox version

• Microsoft Store package: MicrosoftWindows.WindowsSandbox 0.8.107.0
• C:\Windows\System32\WindowsSandbox.exe: 10.0.26100.8875
• C:\Windows\System32\WindowsSandboxClient.exe: 10.0.26100.8875

Windows build number

• Host: Windows 11 Pro 25H2, build 26200.9168, x64
• Windows Sandbox guest: Windows 11 24H2, build 26100.9168, x64
• Guest BuildLabEx: 26100.1.amd64fre.ge_release.240331-1435

Other software

None is required to reproduce the issue. The controlled reproduction used a
.wsb file that only mapped a diagnostic-script directory read-only. It had no
LogonCommand and made no automatic registry or font changes.

Steps to reproduce the bug

1. On the host, use the following language configuration:

   • Culture: en-US
   • UI culture: en-US
   • System locale: en-US
   • User language list: en-US, zh-Hans-CN
   • Home location: China

2. Launch a pristine Windows Sandbox instance.

3. Open Windows PowerShell in the sandbox.

4. Create folders with CJK names without relying on source-file encoding:

   $name = -join @(
       [char]0x4E2D,
       [char]0x6587,
       [char]0x663E,
       [char]0x793A,
       [char]0x6D4B,
       [char]0x8BD5,
       '-',
       [char]0x4F60,
       [char]0x597D
   )
   
   New-Item -ItemType Directory -Path `
       (Join-Path ([Environment]::GetFolderPath('Desktop')) $name)
   
   New-Item -ItemType Directory -Path `
       (Join-Path "$env:USERPROFILE\Downloads" $name)

5. Inspect the name in all of the following places:

   • the desktop icon label;
   • the Explorer item view in Downloads;
   • the Explorer tab title;
   • the Explorer address bar;
   • the folder Properties window title;
   • the folder-name edit control on the General tab of Properties.

Expected result

The same Unicode CJK folder name should render correctly in every Explorer and
Shell surface.

Actual result

The Unicode name is intact, but rendering differs by Shell surface:

Surface	Result in a pristine sandbox
Desktop icon label	CJK glyphs render as square boxes/tofu
Explorer item view	CJK glyphs render as square boxes/tofu
Explorer tab title	CJK renders correctly
Explorer address bar	CJK renders correctly
Folder Properties title bar	CJK renders correctly
Folder-name edit control in Properties	CJK glyphs render as square boxes/tofu

This occurs even though the relevant CJK font files are present:

C:\Windows\Fonts\msyh.ttc    Exists=True
C:\Windows\Fonts\msyhbd.ttc  Exists=True
C:\Windows\Fonts\msyhl.ttc   Exists=True
C:\Windows\Fonts\simsun.ttc  Exists=True

The pristine sandbox reports:

Registry WindowMetrics IconFont:
Face='Segoe UI'; Height=-12; Weight=400; CharSet=1; Bytes=92

SPI_GETICONTITLELOGFONT:
Face='Segoe UI'; Height=-12; Weight=400; CharSet=1; StructSize=92

Segoe UI Variable FontLink values: 0
Segoe UI Variable values containing Microsoft YaHei UI: 0

GRE_Initialize values:
GUIFont.Facename           = absent
GUIFont.Height             = absent
GUIFont.CharSet            = absent
LastBootTimeFontCacheState = absent

On the host, both the registry IconFont and the live User32 icon-title font are
also Segoe UI / CharSet 1, but CJK renders correctly. The host has all 15
Segoe UI Variable FontLink values, all 15 include Microsoft YaHei UI, and
the host has GRE_Initialize configured as SimSun / CharSet 134 before the
interactive user session starts.

Controlled current-session workaround experiment

I tested a current-session-only workaround without importing FontLink values,
without changing GRE_Initialize, without writing HKLM, without restarting the
font cache, and without persisting WindowMetrics\IconFont.

The test called:

SystemParametersInfo(
    SPI_SETICONTITLELOGFONT,
    sizeof(LOGFONT),
    LOGFONT(Microsoft YaHei UI, CharSet 134),
    SPIF_SENDCHANGE
)

SPIF_UPDATEINIFILE was intentionally not used. Read-back showed:

Before:
Registry IconFont = Segoe UI / CharSet 1
User32 IconFont   = Segoe UI / CharSet 1

After SPI_SETICONTITLELOGFONT:
Registry IconFont = Segoe UI / CharSet 1
User32 IconFont   = Microsoft YaHei UI / CharSet 134

The visual results were reproducible across two controlled runs:

Stage	Explorer item view	Desktop icon label	Properties name edit control
Pristine baseline	Tofu	Tofu	Tofu
After SPI call and view refresh	Correct CJK	Tofu	Tofu
After restarting Explorer, with no additional font changes	Correct CJK	Correct CJK	Tofu

After Explorer restarted, the registry value was still Segoe UI / 1 and the
live User32 value remained Microsoft YaHei UI / 134.

This suggests that the Explorer item view and desktop icon-label paths do not
obtain a working CJK fallback in the pristine Sandbox session. Existing Shell
surfaces also cache font objects differently: refreshing the item view is
enough for that view, while the desktop requires Explorer to be recreated. The
Properties name edit control appears to use a separate font path and remains
affected by the bug.

The current-session workaround is diagnostic evidence, not a complete fix for
all affected Shell controls.

Included system information

Host hardware:

Manufacturer: Lenovo
Model: 21CY
CPU: 12th Gen Intel Core i7-12700H
Logical processors: 20
Memory: 31.7 GB
Architecture: 64-bit
Hypervisor present: True
GPU: Intel Iris Xe Graphics, driver 31.0.101.4502
Additional display adapter: GameViewer Virtual Display Adapter 15.6.5.199

Host language configuration:

Culture: en-US
UI culture: en-US
System locale: en-US
User languages: en-US, zh-Hans-CN
Home location: China

Sandbox language configuration:

Culture: en-US
UI culture: en-US
System locale: en-US
User languages: en-US, zh-Hans-CN

The diagnostic was launched from a normally opened PowerShell window in the
stock sandbox. WDAGUtilityAccount reports Elevated=True by default in this
environment; no explicit UAC elevation was requested. The current-session
experiment performed no HKLM writes.

Screenshots

Before: Explorer item view and Properties name field render tofu

The Explorer item name and the Properties name edit control render the CJK
name as tofu, while the Properties title bar renders the same Unicode name
correctly.

Before: address bar and tab title are correct, but the desktop label is tofu

The Explorer address bar and tab title render CJK correctly, while the desktop
icon label renders tofu.

After the current-session SPI change and Explorer restart

The Explorer item view and desktop icon label render CJK correctly. The
Properties name edit control remains affected and still renders tofu.

[wanf3ng]

A minimal public workaround is now available:

https://github.com/wanf3ng/windows-sandbox-cjk-font-workaround

It applies SPI_SETICONTITLELOGFONT only to the current Windows Sandbox session, changes the User32 icon-title font to Microsoft YaHei UI with charset 134, broadcasts the setting change, and restarts Explorer. It does not write HKLM, change FontLink/GRE settings, restart the font cache, or use SPIF_UPDATEINIFILE.

The generated .wsb was validated in a fresh Sandbox guest on build 26100.9168: Explorer item names and desktop icon labels rendered CJK correctly after the workaround. The folder-name edit field in Properties remains a known limitation because it uses a different font path.