Sysinternals Handle prints question marks "?" instead of non ASCII symbols

Question

For files that contain non ASCII symbols, The Sysinternals Handle utility prints the file names with ?. A similar problem is also reported in the following places:

• Handle encoding problem
• Russian language in Handle.exe
• Question about Handle.exe in SysInternals

Reproduction scenario

• Open a file C:\test\fileфайлファイル���件.pdf in Adobe Acrobat Reader just to lock it.
• Executing the following command in cmd.exe results in the file name being printed as C:\test\file??????????.pdf:

C:\> handle64 -nobanner C:\test\fileфайлファイル文件.pdf
Acrobat.exe        pid: 10616  type: File           440: C:\test\file??????????.pdf

• The same occurs if I redirect the output to a file by using the command handle64 -nobanner C:\test\fileфайлファイル文件.pdf > 1.txt. The file content will be the same as in a console. Opening the file in a HEX editor shows that ? signs are actual question marks with the code x3F. Therefore, I assume that it is not a problem with the encoding on my machine.

Question

How can it be fixed or worked around?

Best workaround at the moment.

Binary patch from @NewcomerAl's answer fixes this issue. The patched binary can be downloaded from the Sysinternals-console-utils-with-Unicode-support GitHub repository.

Answer 1

It is possible to workaround this issue by applying the following binary patch to HANDLE64.EXE V5.0 that injects _setmode(_fileno(stdout), _O_U8TEXT) at the beginning of the main function. This function makes Handle tool print its output in UTF8 format that supports non ASCII symbols.

Patch

# Description
# injects `_setmode(_fileno(stdout), _O_U8TEXT)` at the beginning of the `main` function. Only works for "HANDLE64.EXE v5.0"
handle64.exe
00008510: 48 E9
00008511: 33 FF
00008512: C4 DF
00008513: 48 02
00008514: 89 00
00036514: 00 50
00036515: 00 51
00036516: 00 52
00036517: 00 41
00036518: 00 50
00036519: 00 41
0003651A: 00 51
0003651B: 00 48
0003651C: 00 83
0003651D: 00 EC
0003651E: 00 30
0003651F: 00 BA
00036522: 00 04
00036524: 00 B9
00036525: 00 01
00036529: 00 E8
0003652A: 00 7A
0003652B: 00 FD
0003652C: 00 FD
0003652D: 00 FF
0003652E: 00 48
0003652F: 00 83
00036530: 00 C4
00036531: 00 30
00036532: 00 41
00036533: 00 59
00036534: 00 41
00036535: 00 58
00036536: 00 5A
00036537: 00 59
00036538: 00 58
00036539: 00 48
0003653A: 00 33
0003653B: 00 C4
0003653C: 00 48
0003653D: 00 89
0003653E: 00 84
0003653F: 00 24
00036540: 00 50
00036541: 00 01
00036544: 00 E9
00036545: 00 D2
00036546: 00 1F
00036547: 00 FD
00036548: 00 FF

How to apply

1. Save the abovementioned patch into a file patch.txt and place it next to the handle64.exe executable.
2. Download a powershell script from this answer by @DitherSky and place the script next to the handle64.exe executable.
3. Create a batch script file runme.cmd with commands below and place it next to the handle64.exe executable:

@cd /d "%~dp0"
@powershell -executionpolicy bypass -File fc2bin.ps1 -Apply patch.txt
@pause

4. Run the batch script runme.cmd to apply fix to the handle64.exe executable.

Answer 2

This is a known limitation that they have no intention of fixing.
There are pages in learn.microsoft.com that elude to this fact.

The suggestions on how to deal with it is to build your own copy using one of the several links provided in the link above.

You would save yourself some time looking for a solution rather than a work-around.