search

stascorp / rdpwrap

RDP Wrapper Library
Apache License 2.0
14.56k stars 3.81k forks source link

Looking for 10.0.17763.168 support #606

Open ZooShu opened 5 years ago

ZooShu commented 5 years ago

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

stefan7n commented 5 years ago

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

DHaak93 commented 5 years ago

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

bezik46 commented 5 years ago

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

hajubu commented 5 years ago

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

quicken2k commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

ZooShu commented 5 years ago

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 commented 5 years ago

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

quicken2k commented 5 years ago

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 commented 5 years ago

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. 2

hajubu commented 5 years ago

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. image

StarfighterJ commented 5 years ago

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 commented 5 years ago

@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

andrePKI commented 5 years ago

@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 commented 5 years ago

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 ;---------------------------------------------

FOSSFOREVER commented 5 years ago

Can someone upload the working dll and ini files here?

hajubu commented 5 years ago

@ 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?

dmcdivitt commented 5 years ago

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

jaxjexjox commented 5 years ago

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 commented 5 years ago

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.

andrePKI commented 5 years ago

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 commented 5 years ago

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

hajubu commented 5 years ago

@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 !

explorerhk commented 5 years ago

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) .

  1. First, install rdpwrap v1.62 https://github.com/stascorp/rdpwrap/releases/download/v1.6.2/RDPWrap-v1.6.2.zip
  2. Go to Administrative command prompt, then run "net stop termservice"
  3. Replace rdpwrap.ini in C:\Program Files\RDP Wrapper (The new file supports both x32 and x64)
  4. Go to Administrative command prompt, then run "net start termservice"
  5. Finally, go to C:\Program Files\RDP Wrapper folder, run RDPConf to check the states
  6. Make sure All states are green
  7. Congrats! You should now be able to RDP to your desktop.

If Listener state is not green, please do the following:-

  1. Go to Administrative command prompt, then run "net stop termservice"
  2. Replace termsrv.dll and rfxvmt.dll in c:\windows\system32 (Please download the correct OS version)
  3. Repeat Step 4 to 6 above.

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

image

dmcdivitt commented 5 years ago

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.

explorerhk commented 5 years ago

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

olopez66 commented 5 years ago

Anything above worked for me. Need an effective solution, please

bubbleguuum commented 5 years ago

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.

joebeem commented 5 years ago

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.

pupuvovovovo commented 5 years ago

Link

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.

alexfon commented 5 years ago

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.

markhike commented 5 years ago

Finally I figured it out for 195. You don't need to use the 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)

Sh00tmaniak commented 5 years ago

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?

alexfon commented 5 years ago

@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.

mickael9 commented 5 years ago

Working fix

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

explorerhk commented 5 years ago

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.

kamilmirza commented 5 years ago

@explorerhk tried your files and Listener State is still NOT LISTENING

followed these steps:

  1. net stop termservice
  2. replaced termsrv.dll and rfxvmt.dll
  3. installed rdpwrap
  4. replaced rdp.ini
  5. net start termservice
  6. reboot

win x64 pro 10.0.17763.195 rdp

dmcdivitt commented 5 years ago

@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.

markhike commented 5 years ago

@explorerhk tried your files and Listener State is still NOT LISTENING

followed these steps:

  1. net stop termservice
  2. replaced termsrv.dll and rfxvmt.dll
  3. installed rdpwrap
  4. replaced rdp.ini
  5. net start termservice
  6. reboot

win x64 pro 10.0.17763.195 rdp

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:

  1. First, install rdpwrap v1.62 from https://github.com/stascorp/rdpwrap/releases/download/v1.6.2/RDPWrap-v1.6.2.zip
  2. Go to Administrative command prompt, then run "net stop termservice"
  3. Replace rdpwrap.ini in C:\Program Files\RDP Wrapper
  4. Go to Administrative command prompt, then run "net start termservice"
  5. Finally, go to C:\Program Files\RDP Wrapper folder, run RDPConf to check the states, make sure All states are green
gustavoechavarria commented 5 years ago

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 image

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

smiler999 commented 5 years ago

But the recomendation not worked for version 10.0.17763.168 :(

smiler999 commented 5 years ago

default

smiler999 commented 5 years ago

https://t.me/rdpwrap/614

michel130 commented 5 years ago

Hello,

I have the same problem see message from smiler999

DaltWisney2 commented 5 years ago

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!

ditchmagnet commented 5 years ago

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.

  1. Download the fixed ini file in explorerhk's post above or here: rdpwrap.zip

2.Extract the ini to your desktop.

  1. Run cmd as Administrator

  2. net stop termservice

  3. Open Explorer and go to \Program Files\RDP Wrapper

  4. Drag and drop the ini on the desktop in to RDP Wrapper\ and replace the file in the destination.

  5. Assuming you have your original dlls in System32\ go back to the cmd window and: net start termservice

  6. 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.

working

ditchmagnet commented 5 years ago

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.

wzsun commented 5 years ago

ditchmagnet's post above resolved my issue, thanks bud

kamilmirza commented 5 years ago

@ditchmagnet thanks a lot, works great again 10.0.17763.195 x64 pro