PsExec v2.32

Published Jan 14 2021 06:24 PM 4,960 Views

PsExec v2.32

This update to PsExec fixes a bug where the -r option was not honored.
Occasional Contributor

Sorry to say psexec 2.32 is buggy also. The -h option to remotely run an elevated activity fails. It worked in 2.2.

eg. the following worked with 2.2 but fails on 2.32:

psexec \\RemoteSystem -h -u administrator -p password c:\demoprogram.exe


Failure on 2.32:
PsExec could not start c:\demoprogram.exe on RemoteSystem:
Logon failure: the user has not been granted the requested logon type at this computer.

Senior Member

I can confirm I see the same issue.  And worth noting that it's a problem both with -h and without -h, but only when specifying alternate credentials.  When using -s with alternate credentials, it does not occur.  Also, when using integrated security (no alternate credentials) it does not occur.


To be clear, both of these commands fail with the same error ( Logon failure: the user has not been granted the requested logon type at this computer. ):

psexec \\RemoteSystem -h -u administrator -p password c:\demoprogram.exe

psexec \\RemoteSystem -u administrator -p password c:\demoprogram.exe


However, this command does not fail:

psexec \\RemoteSystem -s -u administrator -p password c:\demoprogram.exe

Regular Visitor

Sorry for my message, but I don't know another way how report a bug of "Junction" and "Streams" to Sysinternals team...


When I run "Junction" and "Streams" utilities (I am using Windows 10 build 1809 x64 Russian language), I saw the "?" symbols instead of russian (cyrillic) symbols in error-messages and files/folders names. Is this a bug of "Junction" and "Streams" utilities?


I run utilities like below:
junction64.exe -nobanner -accepteula -s C:\ > j.log
streams64.exe -nobanner -s C:\ > s.log

Files "j.log" and "s.log" are text-files with Codepage 1251 (ANSI) symbols.

For example, some output strings of "Junction" Utility (file "j.log"):

Failed to open \\?\C:\\pagefile.sys: ??????? ?? ????? ???????? ?????? ? ?????, ??? ??? ???? ???? ????? ?????? ?????????.

\\?\C:\\Program Files\windows nt\???????????: JUNCTION
Print Name : C:\Program Files\Windows NT\Accessories
Substitute Name: C:\Program Files\Windows NT\Accessories

\\?\C:\\ProgramData\???????: JUNCTION
Print Name : C:\ProgramData\Microsoft\Windows\Templates
Substitute Name: C:\ProgramData\Microsoft\Windows\Templates

and some output strings of "Streams" Utility (file "s.log"):

Error opening C:\pagefile.sys:
??????? ?? ????? ???????? ?????? ? ?????, ??? ??? ???? ???? ????? ?????? ?????????.

Error opening C:\swapfile.sys:
??????? ?? ????? ???????? ?????? ? ?????, ??? ??? ???? ???? ????? ?????? ?????????.

Error opening C:\Documents and Settings\All Users\Application Data\Application Data\Application Data\Application Data\
Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\??????? ????\Programs\??????????\7-Zip:
??????? ?? ??????? ????? ????????? ????.

And Does "Streams" utility recognize and not process Junctions, Reparse Points, Symbolic Links in Folders?

Frequent Visitor

Hi All,


Looks like the "master" .ZIP file "" is missing?







Thanks for raising the issues, we are investigating.


@SingularMark the Suite is now re-published, thanks for reporting!

Senior Member

@MikeDiack@siegfried_hello - also add the -i switch to get an interactive session.

Occasional Contributor

Thanks for this, I can confirm what foxmsft930 said, it's a shame the documentation / changelog didn't make it more obvious that this was a breaking change in 2.32.

With Psexec 2.32 (build of 15 Jan 2021):

psexec \\RemoteSystem -h -u administrator -p password c:\demoprogram.exe

fails with:
Logon failure: the user has not been granted the requested logon type at this computer

BUT (with the additional -i parameter before the -h), this works.

psexec \\RemoteSystem -i -h -u administrator -p password c:\demoprogram.exe


Note the change              ^

Thanks to all, but please make it obvious in future if introducing breaking changes in builds.



@MikeDiack thanks for the feedback, we'll do better with breaking changes going forward.

Senior Member

Are we saying that now in order to use -h you must also specify -i ?   You can no longer specify -h without -i ?    If this is the case then perhaps the actual help text inside of the app should be updated to note this, but it also then raises the question of why -i would be needed at all.  That is to say that when you execute -h, if -i is required then it should automatically execute -i under the hood, no? Or perhaps it should immediately spit out an error that "in order to use -h you must now also specify -i" or something like that.  This is just my immediate reaction/thought.  I'm confused about why all of a sudden in v2.32 -i would be a requirement for executing with -h, as they are two distinct operations.  Thanks.

Occasional Contributor



It looks exactly like that Siegfried.

If I try to run a process on a remote pc that DOES NOT require elevation, with psexec 2.20, I work as before (see my post of 20 Jan) but omit the -h parameter (note the -h is gone now as I don't want demoprogram.exe run elevated).
psexec \\RemoteSystem -u user -p password c:\demoprogram.exe

But with 2.32, if I try that as before:

psexec \\RemoteSystem -u user -p password c:\demoprogram.exe

Again I get a login failure and again I have to use the -i parameter with version 2.32. :(

psexec \\RemoteSystem -i -u user -p password c:\demoprogram.exe

So in a nutshell it looks like -i is almost always required now in 2.32, and this tends to beg the question why it's an option any more (if it's always required!) instead of silently active in 2.32 to avoid back compatibility problems!!!! Perhaps a question for @lukekim and the SysInternals developers?

Senior Member

@lukekim - are there plans to fix the local privilege escalation issue?  Maybe just as simple as changing the default behavior to add a random suffix to the remote service and pipe name at run time?  Then it no longer needs to allow multiple connections to the existing pipe since each new psexec connection will use a new service and pipe name? 


@siegfried_hello the escalation issue should be fixed in the latest release. Please ensure both the client and service are updated and running the latest version. If you believe you are still seeing the issue please email us at along with detail reproduction steps. Thanks!

Senior Member

Thanks, @lukekim .  I will email you too, as requested, but just wanted to highlight here that David Wells, the researcher who discovered the LPE vulnerability, says that he confirmed it still exists in the new 2.32 version, but with only a minor modification to his original PoC code.  See his note at top of his blog here:

Occasional Visitor

Hi, David here. That's correct, PoC can be seen here


@CE2Wells can you please email us at We'd like to work together to resolve this, thanks!

Occasional Visitor

Agreed with @MikeDiack . The -i option is required not only in conjunction with the -h option, but in general always for a successful start.
The only exception is running with a system account (using -s)'s%20a%20problem%20both%20with%20-h%20and%20without%20-h%2C%20but%20only%20when%20specifying%20alternate%20credentials.%26nbsp%3B%20When%20using%20-s%20with%20alternate%20credentials%2C%20it%20does%20not%20occur.%26nbsp%3B%20Also%2C%20when%20using%20integrated%20security%20(no%20alternate%20credentials)%20it%20does%20not%20occur.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3ETo%20be%20clear%2C%20both%20of%20these%20commands%20fail%20with%20the%20same%20error%20(%20%3CSPAN%3ELogon%20failure%3A%20the%20user%20has%20not%20been%20granted%20the%20requested%20logon%20type%20at%20this%20computer.%20)%3C%2FSPAN%3E%3A%3C%2FP%3E%3CP%3E%3CSPAN%3Epsexec%20%5C%5CRemoteSystem%20-h%20-u%20administrator%20-p%20password%20c%3A%5Cdemoprogram.exe%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%3CSPAN%3Epsexec%20%5C%5CRemoteSystem%20-u%20administrator%20-p%20password%20c%3A%5Cdemoprogram.exe%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%3CSPAN%3EHowever%2C%20this%20command%20does%20not%20fail%3A%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%3CSPAN%3Epsexec%20%5C%5CRemoteSystem%20-s%20-u%20administrator%20-p%20password%20c%3A%5Cdemoprogram.exe%3C%2FSPAN%3E%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-2066846%22%20slang%3D%22en-US%22%3ERe%3A%20PsExec%20v2.32%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-2066846%22%20slang%3D%22en-US%22%3E%3CP%3ESorry%20for%20my%20message%2C%20but%20I%20don't%20know%20another%20way%20how%20report%20a%20bug%20of%20%22Junction%22%20and%20%22Streams%22%20to%20Sysinternals%20team...%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EWhen%20I%20run%20%22Junction%22%20and%20%22Streams%22%20utilities%20(I%20am%20using%20Windows%2010%20build%201809%20x64%20Russian%20language)%2C%20I%20saw%20the%20%22%3F%22%20symbols%20instead%20of%20russian%20(cyrillic)%20symbols%20in%20error-messages%20and%20files%2Ffolders%20names.%20Is%20this%20a%20bug%20of%20%22Junction%22%20and%20%22Streams%22%20utilities%3F%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EI%20run%20utilities%20like%20below%3A%3CBR%20%2F%3Ejunction64.exe%20-nobanner%20-accepteula%20-s%20C%3A%5C%20%26gt%3B%20j.log%3CBR%20%2F%3Estreams64.exe%20-nobanner%20-s%20C%3A%5C%20%26gt%3B%20s.log%3C%2FP%3E%3CP%3EFiles%20%22j.log%22%20and%20%22s.log%22%20are%20text-files%20with%20Codepage%201251%20(ANSI)%20symbols.%3C%2FP%3E%3CP%3E%3CBR%20%2F%3EFor%20example%2C%20some%20output%20strings%20of%20%22Junction%22%20Utility%20(file%20%22j.log%22)%3A%3C%2FP%3E%3CP%3EFailed%20to%20open%20%5C%5C%3F%5CC%3A%5C%5Cpagefile.sys%3A%20%3F%3F%3F%3F%3F%3F%3F%20%3F%3F%20%3F%3F%3F%3F%3F%20%3F%3F%3F%3F%3F%3F%3F%3F%20%3F%3F%3F%3F%3F%3F%20%3F%20%3F%3F%3F%3F%3F%2C%20%3F%3F%3F%20%3F%3F%3F%20%3F%3F%3F%3F%20%3F%3F%3F%3F%20%3F%3F%3F%3F%3F%20%3F%3F%3F%3F%3F%3F%20%3F%3F%3F%3F%3F%3F%3F%3F%3F.%3C%2FP%3E%3CP%3E%5C%5C%3F%5CC%3A%5C%5CProgram%20Files%5Cwindows%20nt%5C%3F%3F%3F%3F%3F%3F%3F%3F%3F%3F%3F%3A%20JUNCTION%3CBR%20%2F%3EPrint%20Name%20%3A%20C%3A%5CProgram%20Files%5CWindows%20NT%5CAccessories%3CBR%20%2F%3ESubstitute%20Name%3A%20C%3A%5CProgram%20Files%5CWindows%20NT%5CAccessories%3C%2FP%3E%3CP%3E%5C%5C%3F%5CC%3A%5C%5CProgramData%5C%3F%3F%3F%3F%3F%3F%3F%3A%20JUNCTION%3CBR%20%2F%3EPrint%20Name%20%3A%20C%3A%5CProgramData%5CMicrosoft%5CWindows%5CTemplates%3CBR%20%2F%3ESubstitute%20Name%3A%20C%3A%5CProgramData%5CMicrosoft%5CWindows%5CTemplates%3C%2FP%3E%3CP%3E%3CBR%20%2F%3Eand%20some%20output%20strings%20of%20%22Streams%22%20Utility%20(file%20%22s.log%22)%3A%3C%2FP%3E%3CP%3EError%20opening%20C%3A%5Cpagefile.sys%3A%3CBR%20%2F%3E%3F%3F%3F%3F%3F%3F%3F%20%3F%3F%20%3F%3F%3F%3F%3F%20%3F%3F%3F%3F%3F%3F%3F%3F%20%3F%3F%3F%3F%3F%3F%20%3F%20%3F%3F%3F%3F%3F%2C%20%3F%3F%3F%20%3F%3F%3F%20%3F%3F%3F%3F%20%3F%3F%3F%3F%20%3F%3F%3F%3F%3F%20%3F%3F%3F%3F%3F%3F%20%3F%3F%3F%3F%3F%3F%3F%3F%3F.%3C%2FP%3E%3CP%3EError%20opening%20C%3A%5Cswapfile.sys%3A%3CBR%20%2F%3E%3F%3F%3F%3F%3F%3F%3F%20%3F%3F%20%3F%3F%3F%3F%3F%20%3F%3F%3F%3F%3F%3F%3F%3F%20%3F%3F%3F%3F%3F%3F%20%3F%20%3F%3F%3F%3F%3F%2C%20%3F%3F%3F%20%3F%3F%3F%20%3F%3F%3F%3F%20%3F%3F%3F%3F%20%3F%3F%3F%3F%3F%20%3F%3F%3F%3F%3F%3F%20%3F%3F%3F%3F%3F%3F%3F%3F%3F.%3C%2FP%3E%3CP%3EError%20opening%20C%3A%5CDocuments%20and%20Settings%5CAll%20Users%5CApplication%20Data%5CApplication%20Data%5CApplication%20Data%5CApplication%20Data%5C%3CBR%20%2F%3EApplication%20Data%5CApplication%20Data%5CApplication%20Data%5CApplication%20Data%5CApplication%20Data%5CApplication%20Data%5CApplication%20Data%5C%3F%3F%3F%3F%3F%3F%3F%20%3F%3F%3F%3F%5CPrograms%5C%3F%3F%3F%3F%3F%3F%3F%3F%3F%3F%5C7-Zip%3A%3CBR%20%2F%3E%3F%3F%3F%3F%3F%3F%3F%20%3F%3F%20%3F%3F%3F%3F%3F%3F%3F%20%3F%3F%3F%3F%3F%20%3F%3F%3F%3F%3F%3F%3F%3F%3F%20%3F%3F%3F%3F.%3C%2FP%3E%3CP%3E%3CBR%20%2F%3EAnd%20Does%20%22Streams%22%20utility%20recognize%20and%20not%20process%20Junctions%2C%20Reparse%20Points%2C%20Symbolic%20Links%20in%20Folders%3F%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-2075813%22%20slang%3D%22en-US%22%3ERe%3A%20PsExec%20v2.32%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-2075813%22%20slang%3D%22en-US%22%3E%3CP%3EThanks%20for%20raising%20the%20issues%2C%20we%20are%20investigating.%3'll%20do%20better%20with%20breaking%20changes%20going%20forward.%3C%2FP%3E%3C%2FLINGO-BODY%3E
Version history
Last update:
‎Jan 14 2021 06:24 PM
Updated by: