RDP Wrapper not listening: why it breaks after Windows updates and what to do instead

RDP Wrapper says Not listening when the Remote Desktop listener it is supposed to unlock never starts. In almost every case the reason sits right next to it in RDPConf: the version of termsrv.dll on your PC has no matching section in rdpwrap.ini, so the wrapper has no offsets to patch and RDPConf adds [not supported]. A Windows update that replaced termsrv.dll is the usual trigger. Running update.bat rarely helps today, because the project’s official INI was last updated on October 10, 2018 and stops at build 10.0.17763.1.

What does RDP Wrapper actually do?

RDP Wrapper Library (the stascorp/rdpwrap project on GitHub) turns on the Remote Desktop host and concurrent sessions on Windows editions that limit them: Home cannot accept Remote Desktop connections at all, and Pro allows one interactive user at a time. It does not touch the termsrv.dll file on disk. Instead it points the Remote Desktop service (TermService) at its own rdpwrap.dll, which loads the original termsrv.dll and changes a few bytes of it in memory.

Which bytes, and where, depends on the exact build of termsrv.dll. That is what rdpwrap.ini holds: one section per build, named after the four-part file version, with hexadecimal offsets for each patch. A shortened section from the official file:

[10.0.17763.1]
LocalOnlyPatch.x64=1
LocalOnlyOffset.x64=77941
SingleUserPatch.x64=1
SingleUserOffset.x64=1322C
DefPolicyPatch.x64=1
DefPolicyOffset.x64=17F45
SLInitHook.x64=1
SLInitOffset.x64=1ABFC

Offsets only fit the build they were measured on. When Windows Update installs a new termsrv.dll, its version number changes, the wrapper finds no section with that number, and it has nothing it can safely apply. That single design fact explains nearly every “not listening” report.

The release dates come from the project’s changelog and the Updated= line of the INI on its master branch, both checked on November 2, 2026. The installer can also put the files in System32 instead (RDPWInst.exe -i -s); the INI then sits next to rdpwrap.dll there.

How we checked: we did not run RDP Wrapper on a machine of ours for this article. The status logic below comes from reading RDPConf’s source (MainUnit.pas), the installer switches and every registry and file change from the installer’s source (RDPWInst.dpr), and the dates from the project’s GitHub history: release v1.6.2 published December 27, 2017, last change to rdpwrap.ini on October 10, 2018. All of it was checked on November 2, 2026.

Why does RDP Wrapper show “Not listening”?

RDPConf shows three states and a version, and each one points at a different cause:

• Wrapper state: Installed when the ServiceDll value of TermService contains rdpwrap.dll, Not installed when it contains termsrv.dll, 3rd-party when it contains neither or when TermService no longer runs inside svchost.exe (its ImagePath value).
• Service state: the state of TermService (Remote Desktop Services), for example Running or Stopped.
• Listener state: Listening when Windows has a session named RDP-Tcp, the listener that accepts connections on port 3389. Not listening when it does not.
• The version label next to the termsrv.dll version: [fully supported] if the INI contains a section with exactly that number, [supported partially] only for Windows Vista and 7 builds without one, and [not supported] otherwise.

How do I check my termsrv.dll version?

Use the version RDPConf shows, or build it the same way in PowerShell. Do not go by winver: the Windows build and the termsrv.dll file version are not always the same number, and only the file version has to match the INI. The second command then looks for that exact section in the INI next to the wrapper:

# termsrv.dll version as four numbers, the way RDPConf builds it
$v = (Get-Item "$env:SystemRoot\System32\termsrv.dll").VersionInfo
$ver = '{0}.{1}.{2}.{3}' -f $v.FileMajorPart, $v.FileMinorPart, $v.FileBuildPart, $v.FilePrivatePart
$ver

# is there a section [<that version>] in the INI? no output = [not supported]
Select-String -Path "$env:ProgramFiles\RDP Wrapper\rdpwrap.ini" -SimpleMatch "[$ver]"

Then see what the Remote Desktop service really loads and whether anything listens:

# which DLL TermService loads: ...\rdpwrap.dll = wrapper active, ...\termsrv.dll = Windows default
$dll = Get-ItemPropertyValue 'HKLM:\SYSTEM\CurrentControlSet\Services\TermService\Parameters' -Name ServiceDll
$dll
Get-AuthenticodeSignature $dll | Format-List Status, SignerCertificate

# service and listener
Get-Service TermService
qwinsta | Select-String -SimpleMatch 'rdp-tcp'          # a line with "Listen" = RDP-Tcp is up
Get-NetTCPConnection -LocalPort 3389 -State Listen -ErrorAction SilentlyContinue

termsrv.dll is signed by Microsoft. rdpwrap.dll is not, so a NotSigned status for it is expected; for a 3rd-party DLL it is a reason to find out where the file came from. If RDP runs on another port, put that number in the last line.

What about the rdpwrap.ini files people post?

Because the official file stopped in 2018, users find offsets for new builds themselves and post them in issue threads, forks and forum posts. RDPConf then turns green, since it only checks that the section header exists. Whether the offsets are right is another matter: the project’s own tracker has a case where a user-added section made TermService crash until it was deleted. You would be loading byte patches from an unknown author into the service that handles every Remote Desktop login, and repeating it after every update that changes termsrv.dll. We do not link to these files.

How do I remove RDP Wrapper cleanly?

Run uninstall.bat from the release folder as Administrator, or RDPWInst.exe -u. Both do more than remove the wrapper: they set fDenyTSConnections to 1, which switches Remote Desktop off, and delete the firewall rule named Remote Desktop for port 3389. RDPWInst.exe -u -k skips those two steps, so Remote Desktop stays enabled and the Remote Desktop rule stays in place. Then check that the service is back on Windows’ own DLL. If the uninstaller is gone, set the value back by hand and restart the service; do this at the PC itself, because the restart ends every RDP session:

$p = 'HKLM:\SYSTEM\CurrentControlSet\Services\TermService\Parameters'
Set-ItemProperty -Path $p -Name ServiceDll -Value '%SystemRoot%\System32\termsrv.dll' -Type ExpandString
Restart-Service TermService -Force

# the rule the installer added for 3389 TCP and UDP, open to any address
# (uninstall.bat already deleted it; -u -k and the manual route keep it)
Get-NetFirewallRule -DisplayName 'Remote Desktop' -ErrorAction SilentlyContinue | Format-Table DisplayName, Enabled, Direction
Remove-NetFirewallRule -DisplayName 'Remote Desktop'      # if 3389 should not be open to every address

Delete C:\Program Files\RDP Wrapper afterwards if it is still there. After uninstall.bat or -u, Remote Desktop is off: on Pro, turn it back on under Settings > System > Remote Desktop (see enabling Remote Desktop), and it then works the way Windows ships it, one interactive user at a time. On Home, the host side is gone again. A few changes stay behind either way: the installer also set EnableConcurrentSessions and AllowMultipleTSSessions to 1, may have added keys under Terminal Server\AddIns, and may have written rfxvmt.dll (or rdpclip.exe on Vista and 7) into System32; the uninstaller removes none of them.

Is RDP Wrapper legal?

The project’s own FAQ declines to answer (“There is no definitive answer”). Microsoft’s license terms are less vague. The Windows 11 terms that come with most PCs (OEM edition, last updated April 2024) say in section 2(c) that you may not:

• “work around any technical restrictions or limitations in the software” (2(c)(iv)), and
• “make the software available for simultaneous use by more than one user over a network” (2(c)(v)), which the same clause extends to using it as server software or to offer commercial hosting services.

Section 2(d)(v) adds that other people may use the PC remotely, at different times, only from devices “separately licensed to run the same or higher edition”. A wrapper that unlocks concurrent sessions on a client edition is hard to square with any of that. This is not legal advice; it is what the terms say. Remote Desktop into Home is a separate point: Microsoft’s Remote Desktop help page says the PC you connect to must run a Pro edition, so the licensed way to reach a Home PC over RDP is an upgrade to Pro.

Is RDP Wrapper safe?

The last point is documented: Trend Micro tracks it as HKTL_RDPWRAP, Cyble described a 2024 campaign that installed RDP Wrapper together with Tailscale on victims’ PCs, and AhnLab’s ASEC reported the Kimsuky group using a modified build. So if you find RDP Wrapper on a machine and did not put it there, treat it as an incident, not a convenience. And if you run it on a PC whose port 3389 is open to the internet, the installer’s firewall rule makes it reachable from any address; the same hardening as on a server applies, from an IP allowlist to an account lockout policy (see securing a Windows RDP server).

The supported way to multiple RDP sessions: Windows Server

Windows Server is built for exactly what people install RDP Wrapper for. Every edition allows two simultaneous remote sessions for administration without extra licenses, plus the console. More users at once need the Remote Desktop Session Host role and RDS client access licenses (CALs); Microsoft gives a 120-day grace period before a license server is required, and the CALs have to be for the same Windows Server version or a newer one. Multiple RDP sessions on Windows Server walks through both levels, including one account with two sessions.

If the goal is simply to reach your own PC from elsewhere, you need neither: Windows Pro accepts one Remote Desktop user out of the box, and enabling Remote Desktop takes the same commands on Pro as on Windows Server. If the goal is a Windows desktop that two people, a trading terminal and a bot can use around the clock, a Windows Server of your own is the clean way to get it.

Frequently asked