stascorp / rdpwrap

RDP Wrapper Library

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Locked out of PC after using RDPWrap

AndrewSav opened this issue · comments

Windows 10 RTM Pro x64

Steps to reproduce:

  • Install RPWrap, make sure to update rdpwrap.ini to the lastest
  • Set the configurations as follows:

Picture1
[Enable RDP Check, Single User Session Uncheck, Default Auth, Shadowing with request]

  • Lock your desktop
  • Go to another pc.
  • Create an RDP session to your installation with the same user as you used above
  • Minimize it but do not close
  • Create a second RDP session to your installation with the same user as you used above
  • Disconnect both sessions. Do not Sign Out.
  • Try RDPing again or try log locally. In both cases you will be greeted with a screen similar to this:

Picture2
[Empty blue screen with a single string "Error in the DLL" and "ok" button underneath]

The only thing you can do now to get in is power-cycle and loose all your work.

This is the content of the log file after the power-cycle:

Initializing RDP Wrapper...
Base addr:  0x00007FF949CB0000
SvcMain:    termsrv.dll+0x000000000000CDF0
SvcGlobals: termsrv.dll+0x00000000000345A0
Version:    10.0.10240.16384
Freezing threads...
Patch CEnforcementCore::GetInstanceOfTSLicense
Patch CSessionArbitrationHelper::IsSingleSessionPerUserEnabled
Patch CDefPolicy::Query
Hook CSLQuery::Initialize
Resumimg threads...
<<< SvchostPushServiceGlobals
>>> ServiceMain
<<< ServiceMain
>>> CSLQuery::Initialize
SLInit [0x00007FF949DA23B8] bServerSku = 1
SLInit [0x00007FF949DA3470] bRemoteConnAllowed = 1
SLInit [0x00007FF949DA3460] bFUSEnabled = 1
SLInit [0x00007FF949DA23B4] bAppServerAllowed = 1
SLInit [0x00007FF949DA3468] bMultimonAllowed = 1
SLInit [0x00007FF949DA23B0] lMaxUserSessions = 0
SLInit [0x00007FF949DA346C] ulMaxDebugSessions = 0
SLInit [0x00007FF949DA3464] bInitialized = 1
<<< CSLQuery::Initialize
Initializing RDP Wrapper...
Base addr:  0x00007FFCE1CC0000
SvcMain:    termsrv.dll+0x000000000000CDF0
SvcGlobals: termsrv.dll+0x00000000000345A0
Version:    10.0.10240.16384
Freezing threads...
Patch CEnforcementCore::GetInstanceOfTSLicense
Patch CSessionArbitrationHelper::IsSingleSessionPerUserEnabled
Patch CDefPolicy::Query
Hook CSLQuery::Initialize
Resumimg threads...
<<< SvchostPushServiceGlobals
>>> ServiceMain
<<< ServiceMain
>>> CSLQuery::Initialize
SLInit [0x00007FFCE1DB23B8] bServerSku = 1
SLInit [0x00007FFCE1DB3470] bRemoteConnAllowed = 1
SLInit [0x00007FFCE1DB3460] bFUSEnabled = 1
SLInit [0x00007FFCE1DB23B4] bAppServerAllowed = 1
SLInit [0x00007FFCE1DB3468] bMultimonAllowed = 1
SLInit [0x00007FFCE1DB23B0] lMaxUserSessions = 0
SLInit [0x00007FFCE1DB346C] ulMaxDebugSessions = 0
SLInit [0x00007FFCE1DB3464] bInitialized = 1
<<< CSLQuery::Initialize

In this case, normally LogonUI should propose to select one of available sessions to connect to, but "Error in the DLL" happened.

Seems to be Windows 10 bug, not related to RDP Wrapper, because everything in the log is okay.

Well, I cannot really trigger it without RDP wrapper. So may be not bug, just not everything is patched that needs to be patched? Win 10 termserv probably does not expect to find more than 2 session on the Pro edition, and when it does it bugs out. May be a clever security measure and may be they simply assumed that there will never be 2 connections from the same user, which would be entirely reasonable and would not qualify as a bug. In any case RDP Wrap does not cope.

As I understand you are not willing to investigate and try and fix as you consider it not your problem? Did I get that right?

I leave this issue open as a reminder about this problem, and maybe someday I'll research it.

This is possibly related to #37

I encountered "Error in the DLL" problem with windows 2016 AND testing "single session per user".

Single session disabled with rdpconf -> login with rdp twice -> disconnect ONE rdp session (so that one session is stil connected, one disconnected -> enable single session with rdpconf -> login again

new connection will get "Error in the DLL". I can "resolve" it by logging out other running sessions from the still-connected rdp session (task manager -> users), so that only one session is running (the one connected with rdp).

After that you can login with either console or RDP

What is really bad in my case, is that once you dc'ed you have no longer a way in, neither locally nor remotely. The power button is the only way.

@AndrewSav are you able to reboot in recovery mode using the Shift + Restart combination?

@dav01it, apologies, I don't understand what you mean. Why would I want to boot in recovery mode?

I thought you were unable to login and even to remove rdpwrap!? isn't it?
Il 19/ago/2015 13:21, "Andrew Savinykh" notifications@github.com ha
scritto:

@dav01it https://github.com/dav01it, apologies, I don't understand what
you mean. Why would I want to boot in recovery mode?


Reply to this email directly or view it on GitHub
#50 (comment)
.

@dav01it that's just until reboot. All the opened programs and unfinished work is then lost.

I think usually what happens is if you have two disconnected sessions with the same username, and you try reconnect, it should ask you WHICH of the two disconnected sessions you'd like to connect to. I guess this "function" is missing from the Windows 10 DLL, which is why we're getting that error in this situation? The same error then occurs if you try to log onto that account directly on the physical system / console, so it definitely seems to be a problem with the Windows DLL in this regard. Reboot fixes the issue until multiple sessions are opened for that user again. Best workaround for now is to just avoid the multiple logins per user functionality for now?

@fragtion sounds very plausible. The conclusion from this that I can draw is that there should be different dlls then for client and for server. (Or same dll that checks OS and then it would mean that RDPWrap is not patching it sufficiently to disable the check). Not checking for multiple connection when you are assuming that there should be none is perfectly reasonable, but that's a change in the dll from the previous windows versions.

I can confirm @fragtion's theory. I had "Error in the DLL" trying to log into my user account, so I logged into my wife's account instead. Sure enough, Task Manager showed that there were two disconnected connections to my account. I logged one of those accounts off (using Task Manager) and then retried connecting to my account. Sure enough, it worked.

@binarymaster So, where do we go from here?

Same problem here (2 logon with same user -> both disconnect -> try to reconnect -> DLL error)
I think the point is exactly as binarymaster said:

In this case, normally LogonUI should propose to select one of available sessions to connect to, but "Error in the DLL" happened.

Probably windows 10 does NOT have support for the session selection, and therefore this error.
I don't remember if and how this scenario worked in Windows 8.1

No, Windows 10 definitely has multi session selection support, I think the
checking code address merely moved.
On Oct 9, 2015 6:03 AM, "Edoa" notifications@github.com wrote:

Same problem here (2 logon with same user -> both disconnect -> try to
reconnect -> DLL error)
I think the point is exactly as binarymaster said:

In this case, normally LogonUI should propose to select one of available
sessions to connect to, but "Error in the DLL" happened.

Probably windows 10 does NOT have support for the session selection,
and therefore this error.
I don't remember if and how this scenario worked in Windows 8.1


Reply to this email directly or view it on GitHub
#50 (comment)
.

I can't get multiple sessions with the same user to work with Windows 10. Every time I log in remotely, it connects to the existing session (the desktop) and disconnects the desktop. I have the "single session per user" unchecked. The same behavior occurs if it is checked.

Possible workaround:

  • make sure to have at least one other RDP enabled login (beforehand)
  • login to this account when the other one is "locked" this way
  • use "disconnect session" for one of both sessions and you may be able to re-connect to the other one