[BUG] Strings tab from ProcExp64 v17.5.0.0 can only partially display an error message if containing an accented character (i.e. 'è') and rest of error message is displayed 1 line below

[SwimmeRM]

Strings tab from ProcExp64 v17.5.0.0 can only partially display an error message if containing an accented character (i.e. 'è') and rest of error message is displayed 1 line below.

• displayed results in ProcExp64 Strings tab are shown in 1st screenshot file [ProcExp64_v17.5.0.0_Strings_CurrentlyDisplayedEffectOfSameErrorMessageFrom_System32_it-IT_KernelBase.dll.mui_WhenFindingAnAccentedCharacter_#0.png]
  
• involved error message is the same one involved in bug [BUG] Contig64 v1.83 incorrectly shows wrong character (0xDE) instead of expected 'è' (0xE8)(=small'e'+graveAccent) when displaying a localized error message with an accented letter #799 so I'm also adding here same Notepad evidence screenshot also added in same above reported bug [Notepad_ShowingThatOriginalErrorMessage(from_System32_it-IT_KernelBase.dll.mui)IndeedHasCorrectCharacter_#2.png]
  
• (only added as a known reference anyway because this error will be displayed on non localized OS versions when just simply trying to reproduce how bug [BUG] Contig64 v1.83 incorrectly shows wrong character (0xDE) instead of expected 'è' (0xE8)(=small'e'+graveAccent) when displaying a localized error message with an accented letter #799 issue was found on Windows 11 x64 or Windows 10 x64 clients) this should also be original en-US version of localized error message that in bug [BUG] Contig64 v1.83 incorrectly shows wrong character (0xDE) instead of expected 'è' (0xE8)(=small'e'+graveAccent) when displaying a localized error message with an accented letter #799 is currently displayed with wrong character (0xDE=222dec) instead of expected accented character 'è' (0xE8=232dec) in 4th screenshot file [Notepad_ShowingThatOriginalSource(EN-US)ErrorMessage(from_System32_en-US_KernelBase.dll.mui)Corresponding2ItalianDisplayedVersion_#3.png]
  N.B. Because in my OS I've not configured a separate account to login using en-US MUI only ..\System32\en-US\KernelBase.dll.mui is not loaded into memory and so for it I cannot open another Strings tab to show that US English version of error message would just be displayed in a single line.
  

P.S. Even if so far untested by me same error is very likely expected to be found also in x86 version of ProcExp v17.5.0.0.
Test results always from Windows 7 SP1 x64 Ultimate client.

17:55 06/04/2024

Today I only came back here again only because I thought I probably understood reason behind issue I reported here but now I've also been made quite uncertain if this my assumption might be valid (see also my last update in #799 that I opened before further widening issue scope here for additional ProcExp64 applicability).
Anyway, here is (for what if I thought I nearly understood) just like if the display of the error message was only generated for being displayed with codepage 1242 (so Windows own default one) together with codepage 437 (used by CMD in US), instead of codepage 850 that is CMD default one on my Windows 7 SP1 x64 Ultimate that is a MUI (Multilingual) version but obviously originally setup only for Italy, my country, and Italian, my language. And here's a screenshot describing how I reached this partial conclusion (also related to the fact that System32\it-IT\KernelBase.dll.mui contents are written in Unicode):

So, what this also mean is, that if my assumption was right too, then to really be sure to avoid same issue, every Sysinternals utility should, always check which is default code page being used by CMD when they're started in a such session, then upon receiving a localized system error message from Kernel it should quickly reconvert it to avoid what it seems to be a default display for codepage 1242 (Windows default one) but also back into a codepage 850 which is CMD default one for Italy.