The problem with Cyrillic file names

[westyles]

The program does not understand files with Cyrillic names? but Handle.exe He understands:

C:\Windows\System32>"C:\1\Handle2.exe" --path "C:\Windows\Temp\vmware-vmsvc-СИСТЕМА.log"

C:\Windows\System32>"C:\1\Handle.exe" -AcceptEula "C:\Windows\Temp\vmware-vmsvc-СИСТЕМА.log"

Nthandle v5.0 - Handle viewer
Copyright (C) 1997-2022 Mark Russinovich
Sysinternals - www.sysinternals.com

vmtoolsd.exe       pid: 3016   type: File           1E8: C:\Windows\Temp\vmware-vmsvc-???????.log

C:\Windows\System32>

[westyles]

Although it's probably not the file name, because it understands another file:

C:\Windows\System32>"C:\1\Handle2.exe" --path "C:\1\11 фыв.txt"
C:\Windows\System32\WindowsPowerShell\v1.0\powershell_ise.exe pid: 8568 DESKTOP-JFPVQPV/W1125H2
  C:\1\11 фыв.txt

[westyles]

It turns out that the program cannot detect the blocking of this file by the process vmtoolsd.exe
Although another file nearby does not have Cyrillic characters in its name, the program sees it as blocked:

C:\Windows\System32>"C:\1\Handle2.exe" --path "C:\Windows\Temp\vmware-vmvss-СИСТЕМА.log"

C:\Windows\System32>"C:\1\Handle2.exe" --path "C:\Windows\Temp\vmware-vmusr-W1125H2.log"
C:\Program Files\VMware\VMware Tools\vmtoolsd.exe pid: 6636 DESKTOP-JFPVQPV/W1125H2
  C:\Windows\Temp\vmware-vmusr-W1125H2.log
------------------------------------------------------------------------------

So it's still a matter of encoding the path that the program gets from the process.

[PolarGoose]

@westyles,

Thank you for the bug report.
Very interesting. Actually, there is even a unit test for this use case, and it passes even inside a GitHub Actions runner.

Do you run the commands as an Admin?

[PolarGoose]

Also, while we are discussing this issue, you can use Sysinternals-console-utils-with-Unicode-support as a workaround. It contains the original Handle.exe that prints Unicode file names properly.

[westyles]

Do you run the commands as an Admin?

Yes

In the program output, the most important thing is not the path that it outputs in addition to the process PID, but the PID itself and the process name.
Therefore, what was interesting about your utility was that it could see blocking processes and their PIDs, which Handle.exe might not be able to see.
It is not necessary to display the path in the output when specifying a file, and it is even superfluous. The most important things are the PID and the process name. We specify the path to the file for verification purposes anyway. For folders, it makes sense to show the paths to the files.

[PolarGoose]

Can you try to repeat the experiment: run Handle.exe and Handle2.exe as a normal user?

[westyles]

Can you try to repeat the experiment: run Handle.exe and Handle2.exe as a normal user?

From the user Handle.exe it does not see processes with access from the system.
Handle2.exe started to see the process for the second file from SYS cmd!

Handle ##################
sees the process (from admin):
"C:\1\Handle.exe" -AcceptEula "C:\Windows\Temp\vmware-vmsvc-СИСТЕМА.log"
"C:\1\Handle.exe" -AcceptEula "C:\Windows\Temp\vmware-vmusr-W1125H2.log"
NOT sees the process (from admin/SYS/TI):
"C:\1\Handle.exe" -AcceptEula "C:\Windows\Temp\vmware-vmtoolsd-СИСТЕМА.log"
"C:\1\Handle.exe" -AcceptEula "C:\Windows\Temp\vmware-vmvss-СИСТЕМА.log"

Handle2 #################
sees the process (from admin):
"C:\1\Handle2.exe" --path "C:\Windows\Temp\vmware-vmusr-W1125H2.log"

not sees the process (from admin):
"C:\1\Handle2.exe" --path "C:\Windows\Temp\vmware-vmsvc-СИСТЕМА.log"
"C:\1\Handle2.exe" --path "C:\Windows\Temp\vmware-vmtoolsd-СИСТЕМА.log"
"C:\1\Handle2.exe" --path "C:\Windows\Temp\vmware-vmvss-СИСТЕМА.log"

but sees the process!!! (from SYS):
"C:\1\Handle2.exe" --path "C:\Windows\Temp\vmware-vmusr-W1125H2.log"
"C:\1\Handle2.exe" --path "C:\Windows\Temp\vmware-vmsvc-СИСТЕМА.log"

It turns out that there is a difference with access to processes under the admin for Handle.exe and Handle2.exe
But the processes for file 3 and 4 do not see both programs from cmd under any rights.

[PolarGoose]

Ok, I think I know what happens.

Handle2.exe uses WinAPI to obtain the information about locks. It is limited by the user's access rights. For example, you can't get access to processes run by more privileged users.
Sysinternals handle.exe works the same way when you run it as a normal user.

However, when run as an admin, Sysinternals handle.exe uses a completely different way to obtain file handles. It uses the PROCEXP152.SYS driver. Thus, it doesn't care about any user's access rights and can show handles from any process in the system.

I think your problem is that the vmware-vmtoolsd-СИСТЕМА.log is locked by NT AUTHORITY\SYSTEM user, and thus you can't see the locks using Handle2.exe when you run it as an admin.

What options you have:

• Run Sysinternals handle.exe as an admin: it can print output as a CSV. Create a PowerShell script that parses the CSV output and gets the extra information that you need.
• Run Handle2.exe as a NT AUTHORITY\SYSTEM user.

I thought about making Handle2.exe use the same driver when it runs as an admin. I even created a NuGet package ProcExp152SysDotNetProxy. I probably need to finally add it to Handle2.exe.

[westyles]

I probably need to finally add it to Handle2.exe.

It would be possible to add a driver.
But it would be better to teach Handle2.exe to see file locks that Handle.exe cannot see.
Since there is this easily repeatable example, you can practice on it - Those two files that no program can see under any permissions.

[PolarGoose]

"C:\1\Handle.exe" -AcceptEula "C:\Windows\Temp\vmware-vmvss-СИСТЕМА.log"

But it would be better to teach Handle2.exe to see file locks that Handle.exe cannot see.

It is interesting that SysInternals handle.exe doesn't see who locks this file if you run it as an admin. I would assume that because it uses the kernel driver, it should be able to find the locking process.

I need to look into it a bit more.

Thanks a lot for the example.

However, I'm not sure that anything can be improved. It is just how the Windows API and access rights work.