Skip to main content
added 32 characters in body
Source Link
PolarBear
  • 533
  • 5
  • 8

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:

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 Handle.exe-with-Unicode-supportSysinternals-console-utils-with-Unicode-support GitHub repository.

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:

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 Handle.exe-with-Unicode-support GitHub repository.

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:

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.

fixed link formatting
Source Link
Kamil Maciorowski
  • 75.7k
  • 22
  • 152
  • 229

For files that contain non ASCII symbols, The [Sysinternals Handle] utility (https://learn.microsoft.com/en-us/sysinternals/downloads/handleSysinternals Handle utility) prints the file names with ?. A similar problem is also reported in the following places:

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 Handle.exe-with-Unicode-support GitHub repository.

For files that contain non ASCII symbols, The [Sysinternals Handle] utility (https://learn.microsoft.com/en-us/sysinternals/downloads/handle) prints the file names with ?. A similar problem is also reported in the following places:

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 Handle.exe-with-Unicode-support GitHub repository.

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:

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 Handle.exe-with-Unicode-support GitHub repository.

added 162 characters in body
Source Link
PolarBear
  • 533
  • 5
  • 8

For files that contain non ASCII symbols, The [Sysinternals Handle] utility (Sysinternals Handlehttps://learn.microsoft.com/en-us/sysinternals/downloads/handle) prints theirthe file names with ?. A similar problem is also reported in the following places:

Reproduction scenario

  • FileOpen a file C:\test\fileфайлファイル文件.pdf opened in Adobe Acrobat Reader just to makelock it locked.
  • ExecuteExecuting the following command in the cmd.exe printsresults 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 happensoccurs 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 workaroundedworked around?

Best workaround at thisthe moment.

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

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

Reproduction scenario

  • File C:\test\fileфайлファイル文件.pdf opened in Adobe Acrobat Reader just to make it locked
  • Execute the following command in the cmd.exe prints file name 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 happens if I redirect the output to a file using 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 workarounded?

Best workaround at this moment

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

For files that contain non ASCII symbols, The [Sysinternals Handle] utility (https://learn.microsoft.com/en-us/sysinternals/downloads/handle) prints the file names with ?. A similar problem is also reported in the following places:

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 Handle.exe-with-Unicode-support GitHub repository.

added 162 characters in body
Source Link
PolarBear
  • 533
  • 5
  • 8
Loading
added 139 characters in body
Source Link
PolarBear
  • 533
  • 5
  • 8
Loading
added 56 characters in body
Source Link
PolarBear
  • 533
  • 5
  • 8
Loading
added 210 characters in body
Source Link
PolarBear
  • 533
  • 5
  • 8
Loading
deleted 3 characters in body
Source Link
PolarBear
  • 533
  • 5
  • 8
Loading
added 100 characters in body
Source Link
PolarBear
  • 533
  • 5
  • 8
Loading
Source Link
PolarBear
  • 533
  • 5
  • 8
Loading