Windows 10 April 2018 Update (1803) Build 17134.1 (x64) termsrv.dll version 10.0.17134.1 (x64) Decided to check the code... Revised Method Find: 8b 99 3c 06 00 00 8b b9 38 06 00 00 3b df 0f 84 Replace With: c7 81 3c 06 00 00 ff ff ff 7f 90 90 90 90 90 e9 Code: 0x180010e72 c7813c060000. mov dword [rcx + 0x63c], 0x7fffffff ; [0x7fffffff:4]=-1 0x180010e7c 90 nop 0x180010e7d 90 nop 0x180010e7e 90 nop 0x180010e7f 90 nop 0x180010e80 90 nop ,=< 0x180010e81 e916a10200 jmp 0x18003af9c ;[1] | 0x180010e86 33c9 xor ecx, ecx | 0x180010e88 b813000ad0 mov eax, 0xd00a0013 | 0x180010e8d 3bdf cmp ebx, edi | 0x180010e8f 488b5c2430 mov rbx, qword [rsp + 0x30] ; [0x30:8]=-1 ; '0' ; 48 Original Method Find: 8B 99 3C 06 00 00 8B B9 38 06 00 00 Replace With: B8 00 01 00 00 89 81 38 06 00 00 90 Code: 0x180010e72 b800010000 mov eax, 0x100 ; 256 0x180010e77 898138060000 mov dword [rcx + 0x638], eax 0x180010e7d 90 nop 0x180010e7e 3bdf cmp ebx, edi *** I don't like this! *** ,=< 0x180010e80 0f8416a10200 je 0x18003af9c ;[1] | 0x180010e86 33c9 xor ecx, ecx | 0x180010e88 b813000ad0 mov eax, 0xd00a0013 | 0x180010e8d 3bdf cmp ebx, edi | 0x180010e8f 488b5c2430 mov rbx, qword [rsp + 0x30] ; [0x30:8]=-1 ; '0' ; 48
"Balony" never did explain how he found the new location. Are you saying that it was wrong, despite it appearing to work? What's also new here is what to replace it with, which is all new for the first time in recent memory. What's the story behind that?
Thanks, Prince_Charles, I'm glad you noticed that and were able to figure it out. I tried it out and it's working well.
termsrv.dll version 10.0.17763.1 x64 FIND: 39813C0600000F847F2C0100 REPLACE: B80001000089813806000090 FIND: 8B8058010000FF1597 REPLACE: 8B8058000000FF1597 Prelimanary findings! Drastic changes have been made to RDP: 10.0.17134.x functions much better. I'm sure that the guys at RDPWrap will figure things out; but I prefer to patch the binary.
Thanks very much! I was just about to delve into what you had posted last time, which has worked very well, to see if it could be applied this time. How is this one working better? Do you mean RDP in general, or the patch specifically (which I didn't see any problem with)?
Patched RDP termsvr.dll RS4 10.0.17134.x functions extremely well: concurrent users and nested sessions: you can invoke an RDP session from an RDP session. You can even get accelerated graphics from an ESXI virtual machine. Patched RDP termsrv.dll RS5 is lacking: users can access multiple (more than 2) accounts but not concurrently; but it's possible to get a concurrent RDP session to a local account (if the user is physically at the computer!) It's early days yet, I've assumed that 17763.1 is RTM and am making preparations. Edit --- termsrv 10.0.17763.1 x64 functions correctly with RDPWrap: [10.0.17763.1] LocalOnlyPatch.x64=1 LocalOnlyOffset.x64=77941 LocalOnlyCode.x64=jmpshort SingleUserPatch.x64=1 SingleUserOffset.x64=3E570 SingleUserCode.x64=Zero DefPolicyPatch.x64=1 DefPolicyOffset.x64=17F45 DefPolicyCode.x64=CDefPolicy_Query_eax_rcx SLInitHook.x64=1 SLInitOffset.x64=1ABFC SLInitFunc.x64=New_CSLQuery_Initialize [10.0.17763.1-SLInit] bInitialized.x64 =ECAB0 bServerSku.x64 =ECAB4 lMaxUserSessions.x64 =ECAB8 bAppServerAllowed.x64 =ECAC0 bRemoteConnAllowed.x64=ECAC4 bMultimonAllowed.x64 =ECAC8 ulMaxDebugSessions.x64=ECACC bFUSEnabled.x64 =ECAD0 I'm certain that changes have been made to RS5 default SL policies. RDPWrap is the better choice if you want concurrent user sessions (and convenience): patched termsrv.dll is sufficient if you are satisfied with single user sessions (and can't be arsed to mess around with product policy).
I did the B80001000089813806000090 one above on 17763 (clean install, two PCs), and it appears to be working (I don't care about the same account concurrently), but I am seeing something very strange with profiles, and I'm wondering if the patch could possibly be the cause. I've used these patches for years and have never seen anything like this, but you do say there have been drastic changes to RDP, so I thought I'd throw this question out there. What happens is that I'll go to login via RDP with the same account as I used before (it had been logged out from before), and occasionally I'll be asked to step through the setup screens again, as if I'm logging in for the first time. And sure enough, the profile has been wiped. It's 100% the correct account, the one I always use, so that's not the problem; it's listed unmistakably in c:\users (the other user has a completely different name).
The (RDP/Terminal Server) SL policies in Windows 10 Enterprise 10.0.17763.1 have been deprecated: Windows 10 Enterprise 10.0.17134.x has the same SL policies as Windows Enterprise for Virtual Desktops 10.0.17763.1 It is not sufficient to apply just B80001000089813806000090, you also have to apply 8B8058000000FF1597, 00EB18488D is only applicable to Windows Enterprise for Virtual Desktops. == termsrv.dll x64 10.0.17763.1: 39813C0600000F847F2C0100 ===> B80001000089813806000090 8B8058010000FF1597 ===> 8B8058000000FF1597 007418488D ===> 00EB18488D === Also, check out Binarymaster's RDPWrap with the amended values for 10.0.17763.1. RDPWrap when configured approriately fully replicates the behaviour of Windows Enterprise for Virtual Desktops 10.0.17763.1 (and Windows 10 Enterprise 10.0.17134.x) when used with Windows 10 Enterprise 10.0.17763.1 I've tested my termsrv patch and RDPWrap 10.0.17763.1 using RDPCheck and remote connections: and everything functions as expected. As an aside, as administrator, before and after applying 8B8058000000FF1597 use RDPCheck to login into the same administrator account: note the difference in behaviour! RDP can be configured using RDPConf and Group Policy Windows Enterprise for Virtual Desktops is just an exercise in polishing a turd.
Oh. I'm so used to only doing the one, that's all I did. For now, I've reverted the termsrv.dll to stock on the 17763 systems in order to see if the profile problem recurs then. I really can't predict if the half-patch was involved or not.
There is no need to tamper with termsrv.dll or use RDPWrap with an activated Windows Enterprise for Virtual Desktops; it appears that (unlimited) multiple and concurrent sessions are supported by default! Windows Enterprise for Virtual Desktops is essentially a "desktop server" operating system with RDP/RDSH/Terminal Server functionality that by default should be in Windows Enterprise. Perhaps, Microsoft should rename Windows Enterprise, Windows Emasculated.
2 Prince_Charles: Can we ask to upload a working termsrv.dll x64 10.0.17763.1 please? Many thanks for findings!
Download an ISO x64 flavour of Windows PRO or whatever, go to the "sources" directory drag the install.wim into 7zip file manager, navigate to where the termsrv.dll is located, load the termsrv.dll into an hex editor - then search and replace. HxD is a more than adequate hex editor.
termsrv 10.0.17763.1 x64 for me work this, don't forget to restart the service or restart your computer rdpwrap.ini [10.0.17763.1] LocalOnlyPatch.x64=1 LocalOnlyOffset.x64=77941 LocalOnlyCode.x64=jmpshort SingleUserPatch.x64=1 SingleUserOffset.x64=132F9 SingleUserCode.x64=Zero DefPolicyPatch.x64=1 DefPolicyOffset.x64=17F45 DefPolicyCode.x64=CDefPolicy_Query_eax_rcx SLInitHook.x64=1 SLInitOffset.x64=1ABFC SLInitFunc.x64=New_CSLQuery_Initialize [10.0.17763.1-SLInit] bInitialized.x64 =ECAB0 bServerSku.x64 =ECAB4 lMaxUserSessions.x64 =ECAB8 bAppServerAllowed.x64 =ECAC0 bRemoteConnAllowed.x64=ECAC4 bMultimonAllowed.x64 =ECAC8 ulMaxDebugSessions.x64=ECACC bFUSEnabled.x64 =ECAD0
It's interesting that my SingleUserOffset.x64=3E570 can be used to physically patch termsrv.dll AND hooked into RDPWrap. But SingleUserOffset.x64=132F9 only works with RDPWrap! Anyway, Windows 10.0.77763.1 is a shoddy bloated release: the RDP performance is awful. I never thought I would say this, but when you debloat and secure macOS 10.14 it is the operating system that Windows 10 can only aspire to be. Perhaps Dona and Co should spend less time noncing around at conventions and dedicate more time trying to write decent code.
2 Prince_Charles: Yes, thanks. Now the patched termsrv.dll, upon connect, always creates another RDP session for the same user. Any clear instructions / workaround how to disable this weird behavior?..