[BUG] Strings64 v2.54 is unable to fully extract an error message if an accented character (i.e. 'è' (small'e'GraveAccent)) is present within.

[SwimmeRM]

Strings64 v2.54 is unable to fully extract an error message if an accented character (i.e. 'è' (small'e'GraveAccent)) is present within. Error message extraction can only work until last character before accented one. (This bug was discovered when doing further investigations for another bug already submitted as bug #799 now opened).
Also adding here an extracted error result file & more additional screenshots also helping to evidence issue:

• partial only error message that could be extracted only when specified minimal lenght of searched string was until last character before accented one in 1st file [KernelBase_IT_TranslationError_.txt]
  KernelBase_IT_TranslationError_.txt
• minimal valid lenght of string that can effectively be extracted is shown by Notepad status line 'Line 1, column 38' (is english translation of italian text displayed, error message is the same of 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) in 2nd screenshot file [Notepad_ShowingLenghtOfLastCharacterB4AnAccentedCharacter(SameThatWasWronglyDisplayedFromContig64)(since_System32_it-IT_KernelBase.dll.mui_IndeedHasCorrectCharacter)_#0.png]
  
• before of previous test showing partial extraction only, attempt to extract full lenght of error message was tried, but because of accented character presence 'No strings found.' message was displayed (once again Notepad was used to find total lenght of error message also displayed 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 but for this I'm only providing a copy of involved error message text with a wrong character (=0xDE=222dec) used instead of expected 'è' (=0xE8=232dec) accented character "Impossibile accedere al file. Il file Þ utilizzato da un altro processo.") and evidence of this and results of partial only extraction that resulted in 1st resulting file already attached above are shown in 3rd screenshot file [Strings64_v2.54_ResultsShowingNoResultsWithFullErrorLenght&ValidResultsOnlyIfStringLenghtIsLower&B4AnAccentedCharacter_#1.png]
  

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

17:20 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 Strings64 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 it also means 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 back into a codepage 850 which is CMD default one for Italy.