Windows XP X64 Terminal Server patch part 1 (mandatory)

Author: daNIL

19 Dec

Windows XP X64 shares the same binaries with Windows 2003 X64, but Terminal Server has some restrictions on XP. This article shows you how to get rid of them and is based on cw2k ideas from the original Windows XP Terminal Server patch.

Version 1.1 contains bug#1 fix and is smaller (less bytes are changed).

1) Winlogon.exe contains a function, called EnumerateMatchingUsers which in turn calls IsProfessionalTerminalServer function. We need to patch this function to return zero (false):

.text:0000000100042F77 IsProfessionalTerminalServer proc near ; CODE XREF: EnumerateMatchingUsers:loc_10002B44Bp
.text:0000000100042F77 ; DATA XREF: .pdata:00000001000D01DCo …
.text:0000000100042F77
.text:0000000100042F77 VersionInformation= _OSVERSIONINFOW ptr -138h
.text:0000000100042F77 var_20 = word ptr -20h
.text:0000000100042F77 var_ 1E = byte ptr -1Eh
.text:0000000100042F77 var_18 = qword ptr -18h
.text:0000000100042F77
.text:0000000100042F77 48 81 EC 58 01 00 00 sub rsp, 158h => 31 C0 C3 xor eax, eax; retn
.text:0000000100042F7E 48 8B 05 F3 3A 08 00 mov rax, cs:__security_cookie
.text:0000000100042F85 48 89 84 24 40 01 00 00 mov [rsp+158h+var_18], rax
.text:0000000100042F8D 48 8D 4C 24 20 lea rcx, [rsp+158h+VersionInformation] ; void *
.text:0000000100042F92 33 D2 xor edx, edx ; int

But it’s not the only place; there is a function named IsPerOrProTerminalServer. It has a few usages; however we will patch only 1 usage ~~usages~~ in a function called MultiUserLogonAttempt:

.text:0000000100044A91 E8 71 E5 FF FF call IsPerOrProTerminalServer
.text:0000000100044A96 85 C0 test eax, eax
.text:0000000100044A98 0F 84 C9 00 00 00 jz loc_100044B67 ~~=> 0F 8D C9 00 00 00 jge loc_100044B67~~ Not required in version 1.1, causes bug #1 to happen.
…
.text:0000000100044B13 E8 EF E4 FF FF call IsPerOrProTerminalServer
.text:0000000100044B18 85 C0 test eax, eax
.text:0000000100044B1A 74 0C jz short loc_100044B28 => EB 0C jmp short loc_100044B28

2) Termsrv.dll. Let’s make Terminal Server think it’s running on a server OS:
In ServiceMain, termsrv.dll initializes a global variable called gbServer. We need its value to be true (1):

.text:000007FF7B877DAF 33 FF xor edi, edi
…
.text:000007FF7B877F77 33 C9 xor ecx, ecx ; ConditionMask
.text:000007FF7B877F79 C7 05 9D 2C 05 00 1C 01 00 00 mov cs:gOsVersion.dwOSVersionInfoSize, 11Ch
.text:000007FF7B877F83 C6 05 B0 2D 05 00 01 mov cs:gOsVersion.wProductType, 1
.text:000007FF7B877F8A FF 15 F8 9A FF FF call cs:__imp_VerSetConditionMask
.text:000007FF7B877F90 48 8D 0D 89 2C 05 00 lea rcx, gOsVersion ; lpVersionInformation
.text:000007FF7B877F97 BA 80 00 00 00 mov edx, 80h ; dwTypeMask
.text:000007FF7B877F9C 4C 8B C0 mov r8, rax ; dwlConditionMask
.text:000007FF7B877F9F FF 15 73 95 FF FF call cs:__imp_VerifyVersionInfoW
.text:000007FF7B877FA5 8B CF mov ecx, edi ~~=> 31 C9< xor ecx, ecx~~ Not required in version 1.1 since edi contains zero already
.text:000007FF7B877FA7 48 8D 15 B2 AE FF FF lea rdx, SubKey ; “System\\CurrentControlSet\\Control\\Termin”…
.text:000007FF7B877FAE 85 C0 test eax, eax
.text:000007FF7B877FB0 48 8D 44 24 60 lea rax, [rsp+78h+hKey]
.text:000007FF7B877FB5 41 B9 19 00 02 00 mov r9d, 20019h ; samDesired
.text:000007FF7B877FBB 0F 94 C1 setz cl => FF C1 90 inc ecx; nop
.text:000007FF7B877FBE 45 33 C0 xor r8d, r8d ; ulOptions
.text:000007FF7B877FC1 48 89 44 24 20 mov [rsp+78h+var_58], rax
.text:000007FF7B877FC6 89 0D 30 B0 04 00 mov cs:gbServer, ecx

So we have promoted ourselves to server. However on server OS it’s not allowed to disconnect the console (STATUS_CTX_CONSOLE_DISCONNECT = $C00A0027). So we need to patch 2 places where this code is used:

.text:000007FF7B889D99 85 C0 test eax, eax
.text:000007FF7B889D9B 75 21 jnz short loc_7FF7B889DBE => EB 21 jmp short loc_7FF7B889DBE
.text:000007FF7B889D9D 48 8D 4B 18 lea rcx, [rbx+18h]
.text:000007FF7B889DA1 BF 27 00 0A C0 mov edi, 0C00A0027h

and one more

.text:000007FF7B88AA1B 45 85 E4 test r12d, r12d
.text:000007FF7B88AA1E 74 0A jz short loc_7FF7B88AA2A => EB 0A jmp short loc_7FF7B88AA2A
.text:000007FF7B88AA20 BB 27 00 0A C0 mov ebx, 0C00A0027h

That’s all for the mandatory patches! To apply them, you need to

At first, make sure you’re doing it from 64 bit process (for example, 64 bit explorer.exe)! 32 bit processes are redirected to %windir%\SysWOW64 directory (read http://msdn.microsoft.com/en-us/library/aa384187(VS.85).aspx).
Delete (or move) all termsrv.dll and winlogon.exe files (they are usually in %windir%\system32\DllCache, in %windir%\ServicePackFiles, or maybe somewhere else), except files in %windir%\system32 . You also need to remove the Windows XP x64 distributive from your CD and/or network location.
Rename %windir%\system32 winlogon.exe and termsrv.dll to (for example) winlogon.bak and termsrv.bak. If you’ve done it correctly, you will notice messages like.
Copy winlogon.bak and termsrv.bak to some other directory (e.g. c:\temp) and rename them back to winlogon.exe and termsrv.dll. Apply patch to them.
Move patched files back to their original location (%windir%\system32). You will see the WPA message (like picture above) again.
Reboot
In case the system will not boot, you’ll need to restore your backups (winlogon.bak and termsrv.bak)

Downloads:

	version 1.1
~~Windows Xp X64 Terminal Server Mandatory Patch (5141 downloads )~~	~~version 1.0~~

Registry changes: make sure that the following keys are set:

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\AllowMultipleTSSessions => 1
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\WinStationsDisabled => 0
HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\Console\fEnableWinStation => 1
HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp\fEnableWinStation => 1

Some issues remains though: you cannot start a session to localhost (a workaround is connecting to 127.0.0.2), and if you lock your workstation from an RPD Session (not console), you’ll just get disconnected (in case of FUS). I will address these issues in the part 2.

Bug #1 Other known issue: a zero-session winlogon will NOT connect to the existing session, but will create a new one instead. This is being investigated currently. Fixed in version 1.1

Please consider donating something (even a small amount is ok) to support this site and my work:

Filed under: General, Terminal Server

48 Responses for "Windows XP X64 Terminal Server patch part 1 (mandatory)"

cw2k December 23rd, 2008 at 18:06 1
Just an addition to:
…however we will patch only usages in a function called MultiUserLogonAttempt:
So
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
AllowMultipleTSSessions=1
must be 1 else we will get out old error message that we are not allow to blah…
The ‘general Idea’ for finding patchlocations is:
Set AllowMultipleTSSessions=0 and set a breakpoint in Winlogon on all VerifyVersionInfoW and the on a hold check further whether that VerifyVersionInfo was relevant or not.
…more If I’ve more time…
daNIL December 24th, 2008 at 12:31 2
Thanks, the article has been updates with registry settings.
Pasha December 24th, 2008 at 14:23 3
oh my God! it really works!!!!!! THANK YOU daNIL! Thank you Remko! Thank you for all! I think that Internet should know their Heroes! 🙂 I will post it in Russian segment of Inet with your copyrights! Hope somebody who has credit card will donate you!
BLiTZ December 24th, 2008 at 15:06 4
Great work, I really share your passion of patching some neat staff in Windows binaries just for fun. I’ve just installed Win2008 on my home NAS\Media\Server machine so I’ll try to patch it, because I dont want to install Terminal Services.
Remko December 24th, 2008 at 15:30 5
@Blitz: I already have a patch for 2008 online, or did you mean 2008 X64?
@Pasha: so your girlfriend is happy again? 😉
Pasha December 25th, 2008 at 11:12 6
@Remko
yes, she is happy! but you even couldn’t imagine how happy am i since that moment 😉
YasonBy December 28th, 2008 at 9:42 7
Thanks, daNIL! That was impressive and just in time!
I dared to translate your post to Russian and publish it here: http://habrahabr.ru/blogs/windows/47956/ (all credits preserved).
GarberFC January 9th, 2009 at 6:51 8
How do I apply the patch? I’m not familiar w/ the file extension .dup2?
TIA
GarberFC January 9th, 2009 at 22:26 9
Applied the patch and it’s working great! I’ve been looking for a patch for about a YEAR! Please enjoy the $$$ I’m sending you…
Frank
Remko January 11th, 2009 at 11:18 10
Tx Frank, this will help me pay the hosting bill 😉
CDASwork February 5th, 2009 at 23:14 11
I followed this guidance but something did not work for me. Every time I restart my computer the AllowMultipleTSSessions word is set back to 0. Any suggestions? Thanks.
daNIL February 5th, 2009 at 23:46 12
Does you computer belong to domain? If yes, it may have policy or registry update setting for that key. You may also check the permissions for HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon key, and remove write access to it for anyone except SYSTEM after you’ve set the value.
Pol@r1s February 6th, 2009 at 16:31 13
daNIL
Thnx a lot for this new patch! If you don’t mind, I want to ask you for help.
I’ve some strange problems with the patched OS. I’ve applied a patch for SP2 files more than one month ago, and all was fine. But about 1.5 weeks ago I’ve discovered that I couldn’t remotely login on the system. RDP client doesn’t indicate any error,
I’ve checked firewall – RDP port is open, incoming connection isn’t blocked.
Please help me! 🙂 If you don’t mind, I would prefer to speak with you by e-mail or jabber in russian 🙂 My address is tov.stalin_at_gmail_dot_com
Sponk February 9th, 2009 at 0:47 14
Thanks a lot for the patch! I used to run XP Pro with the Remote Desktop patch, but I recently upgraded to x64 and thought it would be just as easy to patch as with the 32-bit version..
Do you know if it’s possible to connect to the console session with this patch just like with the 32-bit one? Right now I’m getting a new session every time I connect. I would like to get to the console where all my programs are already running.
Cheers!
daNIL February 9th, 2009 at 10:53 15
Sponk, there are a few ways to achieve this.
1) Disable multiple sessions for the same user. To do it, run “mmc gpedit.msc”, go to “Computer Configuration/Administrative Templates/Windows Components/Terminal Services/Restrict Terminal Services users to single remote session” and set it to Enabled. No restart is required.
2) When you’ve connected to the new session, you can execute Task Manager (Ctrl+Shift+Esc), click on Users tab, rightclick the session you need, and click “Connect”.
Sponk February 9th, 2009 at 14:55 16
Wow! Was it that easy? 🙂 I’d almost given up on this issue. Thanks A LOT for your quick help!
I’d tried connecting with /console (which only gave me some wierd “Error: Sucessfully completed” message) and the Terminal Service Manager from 2003 to connect to the console session, but neither worked. But the policy change you gave me did the trick! Thanks!
Claude February 11th, 2009 at 14:59 17
What program did you use to edit winlogon.exe? (Part of code from it is shown in your samples).
daNIL February 11th, 2009 at 17:33 18
IDA pro was used to to illustrate these parts of code;
However, for editing winlogon.exe and other binary files, i use program named Hiew.
Pavan February 12th, 2009 at 1:07 19
I am trying to do this but couldnt get it to work. I changed the file names to .bak, but as soon as I changed winlogon.exe to .bak, new winlogon.exe appears in system32. When I try to patch the files in the temporarily created folder it gives an error, can not access winlogon.exe, file may be in use blah!. Anyways I copied the newly created files to system32 and rebooted the system and made sure abt all the registry keys, but when I try to logon from another machine, it asks me to logout on the actual system. Could someone guide me over here??
-thanks
daNIL February 12th, 2009 at 22:44 20
Pavan,
If the files keep appearing that means that WPA is still working. Please doublecheck that:
1) You have removed Windows XP x64 distributive from network location, cd/dvd roms, usb drives, or somewhere on your hard disc.
2) You have deleted/renamed ALL winlogon.exe instances (except in system32 folder). On my system, they are in D:\WINDOWS\system32\dllcache and D:\WINDOWS\ServicePackFiles. They can also be located in some other paths on your windows directory, like D:\WINDOWS\$NtServicePackUninstall$ (turn on “show hidden and system directories” to view them).
Pol@r1s February 14th, 2009 at 5:23 21
I want to inform all of you about very strange problem that have been fixed. The problem isn’t connected with the daNIL’s patch, but I think that some of users could be faced with it.
——————————————-
The problem was related with new ATI Catalyst 9.1 driver. Before it I used 8.11 version, and RDP worked without any problem. After upgrading the driver I suddenly discovered that I couldn’t connect remotely by RDP to the x64 system. I didn’t understand anything in the situation and asked daNIL for help, because I thought that there was smth. wrong with the patched files; fortunately daNIL agreed to help. 🙂
After a couple hours working with TeamViewer, daNIL discovered that there is a problem with RDP video driver – rdpdd.dll, this dll couldn’t start and return error. So he offered me to try to downgrade the ATI driver, and this method worked.
After successful solution I’ve found several messages about similar problems on the official ATI/AMD.
Indeed, the problem isn’t connected with bugs in ATI/AMD driver – the problem is in the windows x64 itself:
(quote from NVIDIA forum)
This problem is not specific to any one graphics company. It can probably happen with printer drivers too.
The root of the problem is that the session image space is too small and it can’t load any more drivers into it. The session image space is shared for the display driver drivers and printer drivers. rdpdd = remote desktop protocol display driver.
So, to fix the problem one should add to the registry the following key:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management]
“SessionImageSize”=dword:00000020
Finally this method is working on the catalyst 9.1 driver.
———————————————-
P.S.: I would like to thank daNIL for help once more!
adam February 25th, 2009 at 20:41 22
hello,
i’ve got the following problem with the XP 64 bit patch:
when i patch the termsrv.dll and winlogon.exe everything works fine, all options to termian server from:
Group Policy Object Editor->Administrative Templates->Windows Components->Terminal Services
works fine, for ex.: i can set “Restrict Terminal Services users to a signle remote session” and it works.
My problem shows up after installation new software, usually some big utilities like VisualStudio 2008, but sometime i install small soft and the terminal service break down.
Breaking down consist on that i cant use single session even though “Restrict Terminal Services users to a signle remote session” is enabled.
Everytime i want to connect to the machine remotely with mstsc after typing user and password and hit “connect” button, window message shows up (after delay ~10sec) with window title:
“Logon Connect Failed”
and message:
“Error connecting to existing session from MyUserName (Id 0)
The Operation completed successfully.
A new session will be created.”
Since it break down, terminal server always works wrong. Any new connection create new session. Console session working wrong too.
Any clue how to fix it? I tried to monitor the registry and files, but i cant find solution.
regards
daNIL February 25th, 2009 at 21:49 23
Hello adam,
Can you please check if your winlogon.exe and especially termsrv.dll (which are in system32 folder) are patched? If you’ve installed some new software, e.g. Visual Studio, it may have replaced these files with the “correct” ones! This is a disadvantage of the patch – you’ll always have to look up after your patched files 🙂 I recommend you to have a copy of patched files in your system32 folder, e.g. winlogon.patched.bak, so you can always do a quick check if files have been restored or not.
adam February 28th, 2009 at 15:01 24
Hello again 🙂
i found the solution – i’ve checked Event system log and saw that during the remote login there are some messages about unable to load tsddd.dll and vga.sys and also some error with ATI drivers!!! that remind me Pol@r1s problem/solution. I applied it:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management]
“SessionImageSize”=dword:00000020
and all my problems gone
Salute!
Jab March 12th, 2009 at 10:21 25
I’ve a question, i’m trying to connect 2 users via rdp on a xp pro sp2 (fully updated) x64, is this thread all about that? If so, i don’t also understand how to patch the winlogon.exe/termsrv.dll.
I also didn’t get the message that the xp cd is needed, which i got when i succesfully patched mij xp sp3 pro x86, but on xp pro sp3 i have to disable the windows firewall to logon after reboot (on the pc i try to logon).
donz March 25th, 2009 at 4:30 26
hello…
many thank daNiL, but i still confuse.
How do I apply the patch? cause i’m not familiar with the file extension .dup2?
donz March 25th, 2009 at 5:02 27
hello daNIL…
i’m back again with little case, i try RDP in vista x64 was succesfully, but when i’m connect from linux (all linux OS), depth of color only 16bit, why can’t until 24bit or higher like in xp?
please can u help me daNIL 🙂
thanks
daNIL March 25th, 2009 at 11:05 28
Hello donz,
Please read this article if you’re unsure about using dup2 project files. About colour depth – are you talking about Vista x64 or XP x64? In any case, Terminal Server patch doesn’t change or modify any colour restrictions. You may need to check
1) Your RDP client settings – make sure they are supporting 24 bit colour
2) Your server settings – check system policies “Computer Configuration\Administrative Templates\Windows Components\Terminal Services\Limit maximum color depth”
3) Registry. These (or even more) keys may have affect on color depth:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\Wds\rdpwd\ColorDepth
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp\ColorDepth
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp\fInheritColorDepth
Alex May 28th, 2009 at 15:13 29
patching winlogon.exe doesn’t work for me
i always get the following error:
“Can’t find pattern!Trying next one…
nothing patched!”
any idea what’s wrong?
daNIL May 28th, 2009 at 16:32 30
Alex,
can you please check and write your version of winlogon.exe? This patch was created and tested on Windows XP x64 SP2 winlogon.exe version 5.2.3790.3959 . It may not work on previous Service Packs, so you have to upgrade them to the latest one.
Also, are you sure you’re trying to pacth 64 bit version of winlogon.exe?
Alex May 28th, 2009 at 19:13 31
Ok…. looks like you’ve found the cause
My winlogon.exe version is: 5.2.3790.4277 (srv03_sp2_qfe.080422-1208)
And yes, i’m using windows XP x64 US-English SP2 the winlogon found in %windir%\system32
daNIL May 28th, 2009 at 20:20 32
How did you get this file? Maybe you have installed something like pre-sp3?
Alex May 28th, 2009 at 21:25 33
a google search got me here http://support.microsoft.com/kb/946633 looks like this version is only included in that hotfix…
daNIL May 28th, 2009 at 22:22 34
Thanks for into, i’ll get this hotfix installed and create/update patch soon. However, you can disassemble winlogon.exe and try to patch it using the instructions in the article.
daNIL June 3rd, 2009 at 15:10 35
Please try this one for patching winlogon.exe. You should be able to patch termsrv.dll using the old patch (you may need to remove winlogon patch from the dup project file if it will complain about invalid pattern).
Alex June 5th, 2009 at 17:53 36
Great, this one is working perfectly.
Thanks a lot 🙂
Zenchik November 9th, 2009 at 7:22 37
Hi from Russia
sorry for my bad English
i have some problem :
when i connect via RDP and try catch my old session
system create new session.
how fix it???
Lev Serebryakov January 23rd, 2010 at 22:55 38
Same problem as Zenchik has, here 🙁
Terminal patch for XP/x32 doesn’t have this problem, but this one does 🙁 Could it be fixed?
daNIL February 5th, 2010 at 13:35 39
Hi Zenchik, Lev,
Please read my comment #15, it should solve your issues 🙂
MrPoLLo February 7th, 2010 at 22:01 40
I did restart the computer approximately 50x, and this patch works perfectly 100%
thanks,
Deskyet March 6th, 2010 at 4:29 41
Thankyou! This is great.. was looking for something working
Jo! February 14th, 2011 at 2:40 42
hi guys,
1 thing…
When using winhex editor to change bytes, winlogon at .text:0000000100042F77 must be changed this way:
48 81 EC 58 01 00 00 (sub rsp, 158h)
to
31 C0 C3 00 00 00 00 (xor eax, eax; retn)
Adding zeroes changes 5 words to 5 words and addresses below are not shift.
miguel pires October 1st, 2011 at 15:39 43
Hi, i’m trying to do this to my Windos XP 64bit that as the termsrv.dll version 5.2.3790.3959, my first issue is that i’m trying to download the patch and extract but i’m unable, wend i try to extract the file i get ” The Compressed (zipped) folder is invalid or corrupte”
Can any one explain me what i’m doing wrong?
Regards,
Sergey October 31st, 2011 at 17:51 44
My winlogon.exe version is: 5.2.3790.4516
can you help me? Patch not working for that version.
daNIL November 3rd, 2011 at 16:11 45
Sergey,
How did you manage to get this version?
Please upload it somewhere and give me the link, i will try to help you
Sergey November 5th, 2011 at 10:56 46
I uploaded winlogon (5.2.3790.4516) to depositfiles http://depositfiles.com/files/uzxdqdv1l thanks
Febers December 24th, 2011 at 19:09 47
have the same version and problem as Sergey
vjames January 31st, 2012 at 12:30 48
Thanks Remko you are genius. Microsoft should hire you for system programming. any ways does it works with Win Xp Pro Sp3 32 bit version. If yes i would like to try it one of my pc plsss suggest.