Open ZooShu opened 5 years ago
Just updated win10 home to 17763.168. Broke Rdp, :(
I am also having issues following Update to 10.0.17763.168 Please add support for this build
Not good, too many times now it all go to pieces!
Hello All . just have a look to #601 - hajubu - all you need is there. Good luck -
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.
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?
17763.168 was installed now I also have stopped working LOL version 1809 was working so goo until now
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
Update:
Little modification and this is where I stand now
I had to restartRemote 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
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.
I managed to do. I took the file from this post https://github.com/stascorp/rdpwrap/issues/601#issue-381460674 replaced it at home. And I added lines from the same post to my rdpwrap.ini file.
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 #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.
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?
@StarfighterJ wrote: …. I think I understand just copy and Paste 10.0.17763.1 data for .165 and a .168 correct?
NO … why doesn't the RDPWrap-V1.62 update.bat do this for us? RDP-Wrapper repository (https://github.com/stascorp/rdpwrap/tree/master/res/ rdpwrap.ini :: Is still on Updated=2018-10-10 and contains only the ini-sections for Win10 1809 RTM [10.0.17763.1] and [10.0.17763.1-SLInit] REMARK ; I'm pretty sure that it will be updated as soon $MS-Tuesday in Decmeber18 works fine out. update:: see post #611 (10.0.17763.194 is out ! 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] ....... read more in #611
From 17763.1 to 17763.165 are Offset-Differences [10.0.17763.165] // LocalOnlyOffset.x64=xxxxx //xxxxx.(17763.1) =77941 --> xxxxx.(17763.165) =77AF1 // ( tested and validated ) 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. THEREFORE The other „new“ build section 165-167-168 Contains the SAME Data (except the Header inside the square-brackets) 1) Paste and copy from my post in #601 -hajubu - 2018-11-22 [10.0.17763.165] and [10.0.17763.165-SLInit] 2) Replicate copy of data in .165 to new ini section inside each Header to [10.0.17763.167] and [10.0.17763.167-SLInit] 3) Replicate copy of data in .165 to new ini section inside each Header to [10.0.17763.168] and [10.0.17763.168-SLInit] Iinfo from build .1 up to .134 Data for 10.0.17763.1 are the same (.1) And from 1.65 up to .168 are the same But the termserv.dll build have different internal build numbers -> own numbered data sections
Please be aware not tripping over „Windows OS stumbling Stones“
data ownership // security Levels // etc
Read my remarks for using stopping and starting net termservice
• Good Luck
@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 👍 🥇
Andre wrote: @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 👍 🥇
Hello Team, I just want to add that we do have still an open point to be cleared.
This open point could have a "hidden" influence to the "single user session" - function ( even I could not see/find/obeserve a wrong/not exspected reaction up til now in my Testbed.
I do prefer the logical position of the SingleUserOffset according to the "official" rdpwrap.ini Release (2018-10-10) up till now ( 17134.1 , 17763.1 )
17134.1 == ; SingleUserOffset.x64=1511C 17763.1 == ; SingleUserOffset.x64=1322C
UNTIL WE KNOW BETTER. b.r. Hajubu
;--------------------------------------------- ;This logical position was already used in 17134.1 IN rdpwrap.ini UNTIL 2018-10-10
; SingleUserPatch.x64=1 ;.text:0000000180015100 ; int64 fastcall CSessionArbitrationHelperMgr::IsSingleSessionPerUserEnabled(…) ;.text:0000000180015119 mov dword ptr [rax+8], 1 dword ptr [rax+8],1 <--Zero ; SingleUserOffset.x64=1511C ;--------------------------------------------- ;--------------------------------------------- ; -- first seen ; -- Github StasCorp/Code/res ; -- original rdpwrap ini 2018-10-10 ;. -- 17763.1 ; validated .1 up to .134 and .165,.167 ,.168
; SingleUserPatch.x64=1 ;.text:0000000180013210 ; int64 fastcall CSessionArbitrationHelperMgr::IsSingleSessionPerUserEnabled(...) ;.text:0000000180013229 mov dword ptr [rax+8], 1 <-- Zero :: C7 08 '01' 00 00 00 ; SingleUserOffset.x64=1322C ;--------------------------------------------- ;--------------------------------------------- ; -- first seen -- Github StasCorp/rdpWrap ; -- #601 @RoberSpir 2018-11-16 ; -- and furthermore in myDigitalLife Forum -- ; -- 17763.165 - 168
; SingleUserPatch.x64=1 ;.text:00000001800132E0 ; int64 fastcall CSessionArbitrationHelper::IsSingleSessionPerUserEnabled() ;.text:00000001800132F7 mov dword ptr [rdx], 1 <-- Zero :: C7 02 '01' 00 00 00 ; SingleUserOffset.x64=132F9 ;---------------------------------------------
Can someone upload the working dll and ini files here?
@ 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?
I edited rdpwrap.ini edit for 17763.168 pursuant to #611. Works excellent for me. Thanks for making my life easier.
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.
I attempted the warezio ini file linked here: https://github.com/stascorp/rdpwrap/issues/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.
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.
Regardless, end users just want to hit "update.bat" in Admin mode and have it work a minute or two later, you know?
@jaxjexjox wrote: Regardless, end users just want to hit "update.bat" in Admin mode and have it work a minute or two later, you know?
… up till now there is no „automatic“ solution Ready for „update.bat“- Button
Meanwhile you can use a manually Job:
see last post of vibaaa in #611 he had managed it too
He added also his tested rdpwrap.ini – using the official data from the repo and added the necessary data section.
@ andrePKI also had given a very short „cooking recipee“ how doing the Exchange of the rdpwrap.ini.
BTW – I’m just an user like you !
Good Luck !
I have tried number of ways from other threads, finally I came up a simple and workable solution for build 10.0.17763.195 (x32 and x64 edition) .
If Listener state is not green, please do the following:-
Hope this helps.
P.S. The files termsrv.dll and rfxvmt.dll are extracted from Build 10.0.17763.195. x32 and x64.
rfxvmt_32bit.zip rfxvmt_64bit.zip termsrv_x32.zip termsrv_x64.zip rdpwrap.ini.zip - Fixed new line issue
I like the instructions you provided @explorerhk , but I advise against replacing any Windows components. It's much better to find out why what is on the machine does not work. View properties of termsrv.dll, get the version, and make sure that section is present in the ini file.
Again, I like the instructions.
I like the instructions you provided @explorerhk , but I advise against replacing any Windows components. It's much better to find out why what is on the machine does not work. View properties of termsrv.dll, get the version, and make sure that section is present in the ini file.
Again, I like the instructions.
I think most of the people like me just want to fix the issue and get it work again. I'd leave this to someone who is really interested in finding the root cause.
BTW, those two files termsrv.dll and rfxvmt.dll are extracted from Build 10.0.17763.194. x32 and x64.
Thanks
Anything above worked for me. Need an effective solution, please
This would be great if we had an official fix that work out of the box instead of zillions uncomprehensible, confusing, contradictory and incomplete instructions here and in other issues that may or may not work... I know this just does not happen magically so thanks in advance to whoever maintains this program.
Like many others, I was also having issues getting RDPWrap to work after updating my Windows 10 install to 10.0.17763.195. I had tried literally everything recommended in this issue and/or referenced in others to no avail. However, I was surprised to find the following commands worked for me and it is now running fine.
rdpwinst.exe -u rdpwinst.exe -i
I am not sure why these two commands fixed it for me as I had uninstalled / reinstalled using the bat files numerous times. Just thought I'd share in case this could potentially help someone else.
But maybe it doesn't work fine for me. My OSversion is Win10 Home 17763.195. Operating as the instuction, I met a problem on step 4, part 1. After I started termservice via net start termservice
, it shut immediately. I don't know what's wrong. Is there any other solution?
BTW, I've test it on both of my two computers with the same OS version. It worked nowhere.
I can confirm issues with the provided .ini I have a PC WIN10 pro 17763.195 working fine after updating .ini as described. Another PC with same OS Version is not working. RDP service crashes immediately after updateting .ini and restarting service.
Hi, Been trying around, but so far no luck. Did manage to get "Fully supported", but listening state keeps saying "Not listening". Any idea's on when official support will be available?
@markhike: Thanks a lot. The modified .ini is working for me (new line - ENTER at the end)! By the way, it is a little bit confusing that a non modified .ini is working for another PC with WIN 2010 pro, too. But I am not worried about that, because it is working on all of my PCs now.
The problem was with the line endings (LF instead of CRLF) rather than a missing newline.
Here is the fixed rdpwrap.ini
file (from #612) to put into C:\Program Files\RDP Wrapper
https://drive.google.com/open?id=1eln4v8jyXyRrTPFTajg12HIa9csR3YAo
You need to restart the service (or windows) for it to take effect
Finally I figured it out for 195. You don't need to dlls, just the .ini file. HOWEVER, there is a small issue with the ini file provided by explorerhk. You need to add a newline (the enter key) at the end of the file!!! Just then follow explorerhk's instructions and it will work! (at least on Windows 10 pro)
Just got back from holiday, thank you for finding the root cause. I made a little bit clean up of my original ini file before uploading to GitHub, that's why I didn't realize the issue. I have uploaded the new ini file to my original reply again, hope this helps.
@explorerhk tried your files and Listener State is still NOT LISTENING
followed these steps:
win x64 pro 10.0.17763.195
@kamilmirza, you should not be replacing or modifying any windows components when rdpwrap is used. You should only use what Microsoft put on your machine.
@explorerhk tried your files and Listener State is still NOT LISTENING
followed these steps:
- net stop termservice
- replaced termsrv.dll and rfxvmt.dll
- installed rdpwrap
- replaced rdp.ini
- net start termservice
- reboot
win x64 pro 10.0.17763.195
You may need to revert the DLLs back to the original. I found that the dll from rfxvmt_64bit.zip is a different size compared to the original. Then just follow @explorerhk's instructions with the fixed ini file:
Hi Everyone, I have tried with this .ini file and it worked for me, it's for 10.0.17763.167 version x64 rdpwrap.zip
First, stop the service running CMD as administrator, then run net stop termservice Replace rdpwrap.ini in C:\Program Files\RDP Wrapper then run net start termservice Very important Reboot your PC then when your pc rebooted, run RDPConf to check the states, make sure All states are green
But the recomendation not worked for version 10.0.17763.168 :(
Hello,
I have the same problem see message from smiler999
I'm new to RDPWrap & Github so please forgive me for not understanding protocol here, but I don't understand something....
This program appears dead, as there has been no official support since it "broke" last month, yet the author (binarymaster) continues to stop by time to time to "close" issues that are very obviously still open. So if this program has been abandoned, why bother to come and close the issues? If it has not been abandoned, why not at least a comment saying "I am working on it"?
Please clarify, thanks!
I just wanted to confirm that this is working on my fully updated system. The fixed ini file is all that is needed. I couldn't get it working since I was trying to used the modified dlls (so don't use those!) Luckily I backed up the original files before using the modified dlls.
I will restate instructions for people on winver 10.0.17763.195 (10.0.17763.168 in RDPConf). I am assuming you already have rdpwrap installed but it isn't working.
2.Extract the ini to your desktop.
Run cmd as Administrator
net stop termservice
Open Explorer and go to \Program Files\RDP Wrapper
Drag and drop the ini on the desktop in to RDP Wrapper\ and replace the file in the destination.
Assuming you have your original dlls in System32\ go back to the cmd window and: net start termservice
Check RDPConf
I will upload my dlls here as well for anyone that already deleted them and don't have them in the Recycle Bin. termsrv.dll need TrustedInstaller to be owner, so make that change when you put it in System32\ I' dlls.zip
m not sure what other permissions are necessary.
I'm new to RDPWrap & Github so please forgive me for not understanding protocol here, but I don't understand something....
This program appears dead, as there has been no official support since it "broke" last month, yet the author (binarymaster) continues to stop by time to time to "close" issues that are very obviously still open. So if this program has been abandoned, why bother to come and close the issues? If it has not been abandoned, why not at least a comment saying "I am working on it"?
Please clarify, thanks!
Probably closing them since people keep asking how to fix something that has already been addressed.
Check out my post above if you are on the same version, it should work.
ditchmagnet's post above resolved my issue, thanks bud
@ditchmagnet thanks a lot, works great again 10.0.17763.195 x64 pro
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