Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Looking for 10.0.17763.168 support #606

Open
ZooShu opened this issue Dec 6, 2018 · 95 comments
Open

Looking for 10.0.17763.168 support #606

ZooShu opened this issue Dec 6, 2018 · 95 comments
Labels
add build Add new termsrv.dll build for support

Comments

@ZooShu
Copy link

ZooShu commented Dec 6, 2018

Just trying the tool for the first time and I'm not sure what I'm doing. Already broke the server once and had to connect via KVM Console to get back on

Any help/steps would be great

https://i.imgur.com/hHgEY6u.png

Thanks in advance

Here's the dll file

https://transfer.sh/LaY0f/termsrv.zip

@binarymaster binarymaster added the add build Add new termsrv.dll build for support label Dec 6, 2018
@stefan7n
Copy link

stefan7n commented Dec 6, 2018

Just updated win10 home to 17763.168. Broke Rdp, :(

@DHaak93
Copy link

DHaak93 commented Dec 7, 2018

I am also having issues following Update to 10.0.17763.168
Please add support for this build

@bezik46
Copy link

bezik46 commented Dec 7, 2018

Not good, too many times now it all go to pieces!

@hajubu
Copy link

hajubu commented Dec 7, 2018

Hello All . just have a look to #601 - hajubu - all you need is there. Good luck -

@quicken2k
Copy link

Well, it does work on the latest CU update to Win10., I am only allowed one connection at a time. When I log on other users get kicked off

I am using Win10 Pro 64 Bit.

@barakumis
Copy link

Good day. I installed 17763.168. And it all stopped working.
Please tell me in detail what needs to be done to make it work again?
1

@StarfighterJ
Copy link

17763.168 was installed now I also have stopped working LOL version 1809 was working so goo until now

@ZooShu
Copy link
Author

ZooShu commented Dec 8, 2018

hey haijubu, I followed the steps in #601 and I did the

net stop TermService net start TermService

and after that I did a reboot

but this is what I get

and I'm unable to connect via RDP to my server.

Right now I'm connected via TermViewer and this is what I tried

It's still the same and I'm unable to connect.

I have Windows 10 Enterprise installed with legit license

I tried starting it manually from services and this is what I get

Any help would be appreciated.

I only want multiple people to be able to connect using RDP at the same time, that is all

Thanks

@ZooShu
Copy link
Author

ZooShu commented Dec 8, 2018

Update:

Little modification and this is where I stand now

I had to restart Remote Desktop Services UserMode Port Redirector manually but still no luck

I also added 3389 to firewall rules. Both UDP and TCP for both incoming and outgoing just in case it might help.
Still no luck

@quicken2k
Copy link

Well, it does work on the latest CU update to Win10., I am only allowed one connection at a time. When I log on other users get kicked off

I am using Win10 Pro 64 Bit.

Once you install December 5, 2018—KB4469342 (OS Build 17763.168) CU update it limits the termserv.dll to one connection at a time, I did have a backup of termsrv.dll, replaced it, and now it is working again. Just a heads-up in case anyone else runs into the issue.

@barakumis
Copy link

I managed to do.
I took the file from this post #601 (comment)
replaced it at home.
And I added lines from the same post to my rdpwrap.ini file.
2

@hajubu
Copy link

hajubu commented Dec 9, 2018

Hello Team,
I did a full recheck for all version/builds 17763.1,.165,.167, .168
// last CU KB4469342 (v168.1.10 ) and SSU KB4470788 both from 2018-12-04 // msu::SSU must be installed before CU , only the 'older' KB4469342 (cab) should/(must) be overwritten. I also installed KB4471331(adobe flash) and KB 4469041 -preview CU upd NetFramew.3.5/4.72) which I believe not so important //
2 TestBeds) host x64pro and client x64 (Pro AND Home) __ !! ARE WORKING in both direction !!
i.e. local RDPcfg ,RDPchk and "life" from 17763.168 and to VM-Client-17763.165,.167,.168
AND a real x64pro-PC to a x64Home-PC
Look at #601 - hajubu posts (2018-11-21, -22 build .165, 18-12-07 and -08
-------2018-11-21------------
Something has changed from 17763.1 (incl .55, .107 and .134) to 17763.165 in the x64-data
[10.0.17763.165] // LocalOnlyOffset.x64=xxxxx
//xxxxx.(17763.1) =77941 --> xxxxx.(17763.165) =77AF1 ( tested and validated )
all other x64-ini-data for 1809rs517763.1 to .134 are the same as .165-data
hint: SingleUserOffset.x64=132F9 may be also ==1322C as in the original-ini from 2018-10-10
-------2018-11-22-------------

  1. ;--------snip-----from here ... [10.0.17763.165] ...to... ;--------snip-------------
  2. ;--------snip-----from here ... [10.0.17763.165SL-Init] ...to... ;--------snip-------------
  3. read the snip ;------------------------use as batch / cmd ------------------------- or save it to a txt.file
  4. termsrv.dll was meanwhile updated to .167(18-11-27) and .168(18-12-04),
    offsets seems to be the same as in .165. Therefore (if you have a need for it ) just change the ini header for the "new" build or ................
    Add for each build a section for [10.0.17763.nnn] and [10.0.17763.nnn-SLInit] with the data (in Add support for 10.0.17763.165 #601 -hajubu) using the snipping data [10.0.17763.165] and [10.0.17763.165-SLInit].
    ------2018-12-08----------
    Additional Remarks given another team member:
    For each build , you need the two ini-Section [10.0.17763.nnn] and [10.0.17763.nnn-SLInit] / nnn= (1 , 165, 167, 168 ) is given, which contains both (.x64 and .x86) offset-values.
    This ensures that all these builds will be recognized.
    I did a replication of my findings (snip-listing Sections [10.0.17763.165] and [10.0.17763.165-SLInit] above) for all three 177763.nnn-builds (165,167,168), adding these section by taking the original build from 2018-10-10 from the repository,containing already the both 177763.1 Sections( with 64 and x86)
    whereby the build-number were set according to the wanted build.
    (! There is a main difference from build 17763.1 to 17763.165).
    For better reading (and -may be- for the init of rdp-wrapper )
    I did put each section for itself behind 17763.1 and behind 17763.1-Slinit.
    Please be aware not stumbling over
    a) os-bit version
    b) not using "net stop TermService" and changing the "newly" edited ini-file.
    See my comment for a risk of overwriting this file using unmodified "install.bat/uninstall.bat" or the "update.bat" . batch/cmd in 3) and it might be a good idea to change in the [Main] section the Updated=yyyy-mm-dd to your "year-month-day" figures e.g. 2018-12-09
    c) after you have replaced the ini-file do restart the "PC" or at least use "start net TermService".
    Stopping and starting may have another trips/tripping , restart the system can be a better idea.
    Remark:
    Each build 17763.1 , .165 , 167 , 168 comes with an own "build" version of Termsrv.dll ( x64,x86).
    The rfxvmt.dll (x64 , x86 ) has always 17763.1, whereby the the added (older) rfxvmt.dll in syswow64 from the rdp-wrapper install also still works fine.
    Therefore in x64 you have several choices to circumvent the stumbling stones.
    Please let me know if this helped.
    Getting the Termsrv.dll and rfxvmt.dll from the dedicated install.wim (x64 / x86) or do a simple VM install of the OS-build of your choice ( my recommendation) and follow up the workflow,
    Exchanging a "dll" in a system you have to have special rights as you know already for sure.
    image

@StarfighterJ
Copy link

I think I understand just copy and Paste 10.0.17763.1 data for .165 and a .168 correct?

Dumb Question why doesn't the RDPWrap-V1.62 update.bat do this for us?

@hajubu
Copy link

hajubu commented Dec 9, 2018 via email

@andrePKI
Copy link

andrePKI commented Dec 9, 2018

@ZooShu, @quicken2k @stefan7n , @DHaak93, @scerazy , @barakumis, @StarfighterJ :
I wrote down the exact steps I did in (#601). This works fine for 10.17763.168.
I think this is the most comprehensive way to understand what to get it working.
Thanks to @hajubu and @RobertSpir 👍 🥇

@hajubu
Copy link

hajubu commented Dec 9, 2018 via email

@FOSSFOREVER
Copy link

Can someone upload the working dll and ini files here?

@hajubu
Copy link

hajubu commented Dec 12, 2018 via email

@dmcdivitt
Copy link

I edited rdpwrap.ini edit for 17763.168 pursuant to #611. Works excellent for me. Thanks for making my life easier.

@jaxjexjox
Copy link

I think I understand just copy and Paste 10.0.17763.1 data for .165 and a .168 correct?

Dumb Question why doesn't the RDPWrap-V1.62 update.bat do this for us?

This is very very much, not a dumb question, at all.

I'd love to know myself to be honest.

@jaxjexjox
Copy link

I attempted the warezio ini file linked here: #611
This has resulted in my machine being no longer accessible.

Recommend others avoid for time being until this is fixed.
I have also moved my Windows 10 on to the 'slower' release channel for updates.

@andrePKI
Copy link

andrePKI commented Dec 19, 2018

I think I understand just copy and Paste 10.0.17763.1 data for .165 and a .168 correct?
Dumb Question why doesn't the RDPWrap-V1.62 update.bat do this for us?

This is very very much, not a dumb question, at all.

I'd love to know myself to be honest.

LOL, I like your post. But it is not correct. Only the -SLInit sections are (at least for versions till 194) are equal. The [10.17763.xxx] sections are different for each version.

@jaxjexjox
Copy link

Regardless, end users just want to hit "update.bat" in Admin mode and have it work a minute or two later, you know?

@hajubu
Copy link

hajubu commented Dec 19, 2018 via email

@niwhsa9
Copy link

niwhsa9 commented Jan 8, 2019

@ Tom wrote ( Tom Forever) Just read #611 for the actual data needed ; you should Need Nothing else.

----------------------------- 10.0.17763.194 - CU KB4471332 - keeps/lifts the termsrv.dll to its file version 10.0.17763.168. Therefore since .165, .167, .168 use the data-offset, which are the same, we have to add to the rdpwrap.ini dated 2018-10-10 ( last.ini in the repository - code: res\rdpwrap,ini). Ensure you have the correct ini file with two ini-sections [10.0.17763.1] , [10.0.17763.1-SLInit] and add then the two sections [10.0.17763.168], [17763.168-SLInit] Keep an eye on Acces Rigths and at least use "stop net termservice" before you exchange the rdpwrap.ini (2018-10-10) with your newly edited ini file. ---read more in #611 Or If is to keen just wait till the updated „official“ and validated Version of rdpwrap.ini will be given into the repository (Code: res\rdpwrap.ini) then you can just push the button after you have updated your OS to Version 10.0.17763.194 (-.1.5). My recommendation is just do your Job in a VM/VBox with the last ISO e.g. even the RTM 17763.1 will do it for any purpose , you want (x64,x86 – Home, Pro, etc). Then you can pick up what you ever need for your purpose. .Good Luck Von: Tom Gesendet: Mittwoch, 12. Dezember 2018 18:41 An: stascorp/rdpwrap Cc: hajubu; Mention Can someone upload the working dll and ini files here?

the solution in issue #611 worked perfectly for my system.

@artemmen
Copy link

artemmen commented Jan 9, 2019

Вчера пропустил обновление до 168 и все пропало, при том что все зеленое. Только одно соединение и ничего выше не помогло. Хорошо что возможность отката обновлений есть еще, что и спасло после нескольких часов попыток вернуть работоспособность.

@Kommunist7304
Copy link

Когда будет официальное обновление без ручных ковыряний?

When will there be an official update without manual picking?

@Davey126
Copy link

Developer/maintainer doesn't publish a schedule. Check back for updates.

@cmhowarth
Copy link

cmhowarth commented Jan 10, 2019

I have tried this and failed so many times now - I don't know what to do next. I had RDPWrap working for release 1803 with no problems. Updating it for 1809 I can't get it to work. I have tried everything in threads 601, 606 and 611.
I have Win10 x64 Home v1809.
I used the ini file from the other threads, which people say works:
rdpwrap.zip
I start with it uninstalled.

  1. From an elevated command prompt I run: RDPWInst -i -o.
  2. Then I ran RDPWInst -w
    image
  3. I did: net stop termservice (it wasn't running so did nothing)
  4. I replaced the C:\Program Files\RDP Wrapper\rdpwrap.ini with the one above.
  5. I then started the termservice again: net start termservice It stayed in a state of "starting".
    image
  6. I rebooted. The service was still permanently in a state of "starting":
    image
    image
    The only way I can stop it is going into the Task Manager, finding the process and killing it.
    Nothing obvious in the Event Viewer.
    I don't understand why I'm finding it so difficult when others aren't and previously I had it working.
    Can anyone help or have any suggestions?

@andrePKI
Copy link

andrePKI commented Jan 10, 2019

@cmhowarth Chris, first find the version of your termsrv.dll (it is in C:\Windows\System32, rightclick it from Explorer)
image
Next, go to the directory where you installed RDPWrapper (By default it is in C:\Program Files\RDP Wrapper). Check if the INI files does contain the two sections for your version (.168 in my case):


[10.0.17763.168]

[10.0.17763.168-SLInit]

Make sure the file ends with a newline (i.e. in Notepad you must be able to move the cursor beyond the last line, like this)
image
(The file in your zip is OK for .168). Make sure the file is in the same folder as rdpwrap.dll, e.g. C:\Program Files\RDP Wrapper.
If you made any changes, restart the service.
Note that most of things you do require you to do it as Administrator (or click Yes in the User Account Countrol popup window, if any)

@andrePKI
Copy link

@jaxjexjox https://github.com/stascorp/rdpwrap/issues/606#issuecomment-451835245
Not sure why you blame Microsoft? They are free to modify their own software at will ;-) Multiple RDP sessions into a Windows10 workstation is not a supported Microsoft scenario. Hence to us it is a matter of keeping up with the changes. Basically it is nothing more than a workaround or hack, and I would not be surprised if it is against the Windows EULA.
The fact that so many users find issues in W10 and not W7 is that W7 is more or less stable at this point, whereas W10 is (especially in the preview fast and slow rings) constant improvement.
Also I have seen people picking on and even being very rude to the IMHO very clever guy who made this software @binarymaster. A BIG THANK YOU for Stanislav!

@alyexe
Copy link

alyexe commented Jan 10, 2019

Works for me. Try to add this to c:\Program Files\RDP Wrapper\rdpwrap.ini :

[10.0.17763.168]
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.168-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

Last line MUST be empty
Dont forget to "rdpwinst -r" ;)

@Davey126
Copy link

Davey126 commented Jan 11, 2019

_> > I have tried this and failed so many times now - I don't know what to do next. I had RDPWrap working for release 1803 with no problems. Updating it for 1809 I can't get it to work. I have tried everything in threads 601, 606 and 611.

I have Win10 x64 Home v1809.
I used the ini file from the other threads, which people say works:
rdpwrap.zip
:_
Most others are using Win10 Pro vs Home. Quite possible additional tweaks will be needed to accomodate the latter.

@cmhowarth
Copy link

@andrePKI Thanks for the suggestions.

  1. Yes, my termsrv.dll matches yours (except the modified date, which you might expect)
    image

  2. Yes, my in file had those 2 sections, but the first had different offsets than @alyexe's post (despite others saying it worked for them). I replaced it with the sections from @alyexe 's post above making sure the last line is empty.

  3. Restarted with RDPWrap -r (elevated cmd prompt)
    Service is still permanently "starting" and not listening. Aargh!

@Davey126 - Yes I am doing it for Win10 Home but that's the point of it. I don't need it for my Win10 Pro machine because that already allows RDP for 1 session, which is all I need. I just need to be able to access my other 2 machines' desktops (1 Pro, 1 Home) from my main system without having to have a KVM switch.

@Davey126
Copy link

@cmhowarth - no challenge on your use case; simply observing what works for most may not be applicable in your situation due to difference in platform. I the past I used rdpwrap on Win 10 Home boxes and appreciated the capability it brought to the table (in violation of the EULA). Good luck.

@Hamza31231
Copy link

I managed to do.
I took the file from this post #601 (comment)
replaced it at home.
And I added lines from the same post to my rdpwrap.ini file.
2

YES !!! THIS WORKS !!!
PLEASE DO NOT FORGET TO WRITE-PROTECT YOUR rdpwrap.ini. Otherwise the tool will download new version that das not contain the needed additional marks like discribed here: #601

  1. Download newest version rdpwrap
  2. Install RDPwrap normaly
  3. Download newest rdpwrap.ini ( https://github.com/stascorp/rdpwrap/blob/master/res/rdpwrap.ini ) and place it into your rdpwrap install folder
  4. add this lines to your rdpwrap.ini

[10.0.17763.165]
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.165-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

  1. Download this termsrv ( https://github.com/stascorp/rdpwrap/files/2588141/termsrv_x64.zip )
  2. replace safely yout termsrv.dll with this new downloaded one
  3. write proctect yout rdpwrap.ini in your install folder (that you downlooaded in step 3 and modified in step 4)
  4. start update.bat

THAT WORKS 100% on 10.0.17763.165

@Developer Team:
Sdelajte etot malenkij update poshalusta !
Agromnoje spasibo sa vashu rabotu !

@incheyeg
Copy link

hey newbie here :)

trying to make this work on windows 10 pro 1809 17763.253 I seen a thread was opened already for 17763.253 and was closed:

#636

the ticket advises this was a duplicate and links to this thread.... doe this mean I can use the fix here or that 1809 17763.253 isn't supported?

basically what I'm trying to achieve here is to rdp into my account through my Mac's Microsoft Remote Desktop app while another user is using a different account on the same pc, is this possible?

@cmhowarth
Copy link

Thanks @Hamza31231 , that has now got me to the next stage - it all now shows green and listening.
However, I now have the same problem as @spamme2 in that I can't connect from the remote computer. It terminates immediately when trying to connect. I get the same behaviour from the RDPWrap computer itself when using RDPCheck.

@Hamza31231
Copy link

Hamza31231 commented Jan 18, 2019 via email

@Hamza31231
Copy link

Hamza31231 commented Jan 18, 2019 via email

@cples408
Copy link

working with this file - ini_rdpwrap.zip

p1
p2

@cmhowarth
Copy link

Finally working! Thanks @cples408 - that ini file did the trick (I copied back my original termsrv.dll v168 Home)
I don't know what's going on but I tried multiple .ini files which people said were working for .168 and none of them worked till now.

@hrco1980
Copy link

i hav problem with
rdp wrap winwer 10.0.17763.195
thx

@tbishop9
Copy link

@binarymaster, it's now been 7 weeks since this build was reported. INI files to rectify the issue have been available for most of that time.
You seem to be still active on general issue admin, just curious as to why you haven't published the updated INI file/s?
Is your plan for the future that everyone will download the tool, find it doesn't work and then have to read through issue tickets to teach themselves how to manually patch the INI file?

@jaxjexjox
Copy link

I can't believe the INI file hasn't be updated at this URL yet?

https://github.com/stascorp/rdpwrap/tree/master/res

This is astounding, why has this not been updated? WTF is going on?

@cowwoc
Copy link

cowwoc commented Jan 25, 2019

Looking at https://github.com/binarymaster/ Contribution history I submit to you that this project is dead, either temporarily or permanently, because binarymaster is very active on other projects that seem to interest him more.

Looking at https://github.com/stascorp/rdpwrap/network it seems that https://github.com/tmaguire/rdpwrap is the most active fork of this project and 10.0.17763.168 is supported.

I recommend you try out that fork and report back (post a comment here) whether it's worth moving on to greener pastures.

@tbishop9
Copy link

Thanks @cowwoc, have checked out tmaguire's fork but I can't see where to download the compiled installer and batch files - at https://github.com/tmaguire/rdpwrap/releases I can only download the source code. Any ideas?

@cowwoc
Copy link

cowwoc commented Jan 29, 2019

@tbishop9 Not sure. I suggest asking the author directly. His email is listed here: https://github.com/tmaguire

@Mochalo
Copy link

Mochalo commented Jan 30, 2019

Спасибо всё работает
Надо остановить службу изменить ini файл
Запустить .

rdpwrap.zip

@stascorp stascorp locked as too heated and limited conversation to collaborators Jan 31, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
add build Add new termsrv.dll build for support
Projects
None yet
Development

No branches or pull requests