Windows Version Number: Windows 11 Business Version 25H2 Build 26200.9106
App Version: 2.8.0.2

Start11 2.8.0.2 · Windows 11 Pro 26200 · French (fr-FR) · system ANSI codepage 1252

Summary

Start11 writes menu labels to its registry store under HKCU\Software\Stardock\Start8\Start8.ini through a lossy wide→narrow conversion. Every non-ASCII character is replaced by U+003F (?). The loss happens at write time — the values are already corrupt at rest. Reading and rendering are faithful, so the menu displays exactly what was stored.

Observed vs expected

Why only some labels break

In the same menu, in the same window and font, other accented strings render correctly. The discriminator is the source, not the rendering:

Note that fr.lng contains both "Pinned"="Épinglés" and "Recent documents"="Documents récents", correctly encoded. The first is cached and breaks; the second is read live and is fine. This rules out the language file as the source of the defect.

Evidence — raw codepoints from the registry

Dumped with Get-ItemProperty and printed as UTF-16 codepoints, so console encoding cannot distort the result:

HKCU\Software\Stardock\Start8\Start8.ini\Start8\Locations10

  20  0054 003F 006C 003F 0063 0068 0061 0072 ...   "T?l?chargements"   <-- 2x U+003F
  96  0050 0061 0072 0061 006D 003F 0074 ...        "Param?tres"        <-- 1x U+003F
  14  0045 0078 003F 0063 0075 0074 0065 0072 ...   "Ex?cuter..."       <-- 1x U+003F

HKCU\Software\Stardock\Start8\Start8.ini\Groups11

   0  $PINNEDDEF$|003F 0070 0069 006E 0067 006C 003F 0073|0|0|...       <-- 2x U+003F

CONTROL — same hive, written by a different code path:
HKCU\Software\Stardock\Start8\Start8.ini\Start8

  QC  0050 0061 0072 0061 006D 00E8 0074 0072 ...   "Paramètres rapides"  <-- U+00E8 intact

The QC control value proves the defect is confined to specific write paths, not to the registry store, the system codepage, the font, or the locale.

Conversion target is 7-bit ASCII, not the system ANSI codepage

U+2019 (typographic apostrophe) is also lost — RecentSearches holds "Gérer les certificats d?ordinateur". CP1252 encodes both U+00E9 (0xE9) and U+2019 (0x92), so WideCharToMultiByte(CP_ACP, …) would round-trip both without loss. Losing both points to a conversion that is effectively ASCII-only — the signature of wcstombs or a narrow printf("%s") running under the default "C" locale in the INI-emulation writer.

Affected registry keys

All under HKCU\Software\Stardock\Start8\Start8.ini:

Functional side effect, not only cosmetic

The search caches store full file paths. A corrupted path no longer resolves:

stored:  C:\Users\<user>\AppData\Local\Stardock\Start10Ctrlpnl\Param?tres VPN.lnk
on disk: C:\Users\<user>\AppData\Local\Stardock\Start10Ctrlpnl\Paramètres VPN.lnk

Cached search results pointing at accented Control Panel shortcuts cannot be launched. This affects a large share of the French Control Panel set, which Start11 itself generates into Start10Ctrlpnl with correctly accented filenames.

Steps to reproduce

1. Install Start11 on Windows 11 with display language French (any locale whose labels contain non-ASCII characters).
2. Set the Start menu to the Windows 11 style, with the right-hand column enabled and Downloads / Settings / Run shown.
3. Open the Start menu. The header reads ?pingl?s; right-column entries read T?l?chargements, Param?tres, Ex?cuter....
4. Inspect HKCU\Software\Stardock\Start8\Start8.ini\Start8\Locations10: values already contain U+003F.

Ruled out during diagnosis

• System ANSI codepage is 1252, locale fr-FR — both encode the affected characters.
• lang\fr.lng is UTF-16LE with a BOM and holds correct accented strings.
• Segoe UI present and intact; FontSubstitutes at stock values. A missing glyph would render as .notdef, not ?.
• No AppInit_DLLs; explorer.exe hosts only ordinary shell extensions plus Start10_64.dll. No third-party text hooking.
• Not a rendering fault: correcting the stored values makes the labels display correctly with no other change.

Verification that reads are unaffected

Rewriting the six Locations / Locations10 values and the Groups11 group name with proper Unicode, then restarting explorer.exe, makes the menu render Épinglés, Téléchargements, Paramètres and Exécuter… correctly. Start11 reads back and renders the stored strings verbatim, with no re-corruption on load. This confirms the defect is confined to the write path.

Expected fix

Use the wide-character API throughout the Start8.ini registry writer, or convert with an explicit WideCharToMultiByte(CP_UTF8, …) rather than an implicit C-locale conversion. A migration pass to repair existing corrupted values would also be needed, since affected users keep the damaged cache across updates.

Workaround

Rewrite the cached labels with correct Unicode and restart explorer.exe. This holds until Start11 next writes those values — changing the menu style, toggling right-column items, or a version update reintroduces the corruption.