Non-ASCII characters replaced by ? when Start11 persists menu labels
Start11 2.8.0.2 · Windows 11 Pro 26200 · French (fr-FR) · system ANSI codepage 1252
Stardock Forums
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
| Menu element | Expected | Actual |
|---|---|---|
| Pinned section header | Épinglés | ?pingl?s |
| Right column — Downloads | Téléchargements | T?l?chargements |
| Right column — Settings | Paramètres | Param?tres |
| Right column — Run | Exécuter… | Ex?cuter... |
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:
| Renders | Source | Examples |
|---|---|---|
| broken | Start11 registry cache (Start8.ini hive) |
Épinglés, Téléchargements, Paramètres, Exécuter… |
| correct | read live from lang\fr.lng (UTF-16LE) or from the shell |
Documents récents, app tile “Paramètres” |
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:
| Key | Content | Corrupt values |
|---|---|---|
Start8\Locations |
right-column labels (Win7/Modern style) | 3 |
Start8\Locations10 |
right-column labels (Win11 style) | 3 |
Groups, Groups11 |
pinned-group display name | 2 |
Searches |
query → target path map | 23 |
SResults2 |
result ranking, path used as value name | 16 |
RecentSearches |
recent query history, full .lnk paths |
12 |
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
- Install Start11 on Windows 11 with display language French (any locale whose labels contain non-ASCII characters).
- Set the Start menu to the Windows 11 style, with the right-hand column enabled and Downloads / Settings / Run shown.
- Open the Start menu. The header reads
?pingl?s; right-column entries readT?l?chargements,Param?tres,Ex?cuter.... - Inspect
HKCU\Software\Stardock\Start8\Start8.ini\Start8\Locations10: values already containU+003F.
Ruled out during diagnosis
- System ANSI codepage is 1252, locale fr-FR — both encode the affected characters.
lang\fr.lngis UTF-16LE with a BOM and holds correct accented strings.- Segoe UI present and intact;
FontSubstitutesat stock values. A missing glyph would render as.notdef, not?. - No
AppInit_DLLs;explorer.exehosts only ordinary shell extensions plusStart10_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.
