News, tips, advice, support for Windows, Office, PCs & more. Tech help. No bull. We're community supported by donations from our Plus Members, and proud of it
Home icon Home icon Home icon Email icon RSS icon

Blog Archives

  • Carboni: Jittery mouse when controlling Win10 version 1903 via RDP? There’s a solution.

    Posted on October 29th, 2019 at 09:41 woody Comment on the AskWoody Lounge

    From Noel Carboni:

    Have you seen a jittery mouse or black screen when controlling a Windows 10 v1903 or newer system via RDP?  I’ve discovered a workaround.

    When I upgraded my office computer to Windows 10 v1903 it created a new problem.  When I used my company’s VPN and RDP to control it remotely, the mouse would stutter or jitter.  RDPing into my office system is something I had been doing quite effectively and seamlessly when it was running Win 10 v1809, without any hint of such a problem.  The only thing that changed coincident with the introduction of the problem was the office system’s OS version.

    Based on observation, with Win 10 v1903, whenever a new graphic is loaded into the mouse cursor (e.g., the arrow changes to a finger or spinner or whatever) the cursor pointer is moved back to the position it was in where the change was requested by the controlled system.  This may not seem like a big deal, but trust me, while it does not leave the system completely unusable, when you move the mouse anything but excruciatingly slowly it makes it just plain irritating to use.

    A bunch of web searches later, culminating in a visit to the VMware workstation forum, I learned that Microsoft has enabled (and made default) the use of a second driver model on the system being controlled:  The WDDM model.  Up to now RDP has run off the XDDM display driver model, which is apparently better optimized for an interface that takes a noticeable amount of time to update a mouse cursor given mouse position input.  Remote connections take milliseconds, if not tens or hundreds of milliseconds.  Therein lies the problem.

    For some folks trying to make use of this combination of software and OS versions, the problem can be even worse:  They just get a black screen.  Do a search for “Windows 10 WDDM RDP” on Google and you’ll see that a fair number of folks are having RDP problems.

    The good news:  It turns out Microsoft thought ahead (as they often do) and provided a new policy for configuring the controlled system to use the older, tried and proven XDDM model.  If you have Windows 10 Pro, run gpedit.msc and navigate to the following:

    Local Computer Policy
    Computer Configuration
    Administrative Templates
    Windows Components
    Remote Desktop Services
    Remote Desktop Session Host
    Remote Session Environment

    Set the Use WDDM graphics display driver for Remote Desktop Connections policy to Disabled

    This will clear up jittery mouse and black screen problems and make a remote Windows v1903 (or Server 2016) or newer system a pleasure to use via RDP again.

    UPDATE: Interesting. There’s a post on the Microsoft Answers forum from KevinMarchant that complains about the “high CPU after disconnecting” problem on Win10 1903. That post is now marked “*** PROBLEM RESOLVED BY KB4522355 RELEASED OCTOBER 24TH 2019. ***”

    Any chance that the latest optional, non-security update actually fixes the mouse jitters, too?

    The KB article says:

    Addresses an issue with high CPU usage in Desktop Window Manager (dwm.exe) when you disconnect from a Remote Desktop Protocol (RDP) session.

  • Patch Lady – How to avoid using RDP in Windows

    Posted on August 21st, 2019 at 09:46 woody Comment on the AskWoody Lounge

    An important new article from Susan Bradley in CIO Online:

    BlueKeep and DejaBlue are both potent threats. All of the variants depend on using Remote Desktop Services (commonly abbreviated RDP). Susan Bradley takes you through the steps to avoid or hide RDP, particularly in an enterprise.

    I still recommend that you not install the August Windows patches, which include DejaBlue fixes, specifically because they’re throwing errors like flowers at a wedding. (The May patches for BlueKeep are another story entirely. You should’ve installed those long ago.) But if you have RDP enabled on an internet-facing connection, it’s time to shut it off.

    Those of you connected to corporate servers should follow Susan’s advice and figure out an alternative to public-facing RDP. Those of you with standalone computers can take a couple of simple steps:

    In Vista or Win7, click My Computer and choose Computer. At the top, click System properties. On the left, click Remote Settings. You should be on the Remote tab, and the button under Remote Desktop marked “Don’t allow connections to this computer” should be selected. If it isn’t, click it and click OK.

    In Win10, right-click Start and choose System. On the left, choose Remote Desktop. Make sure the slider to Enable Remote Desktop is set Off.

    I’m not going to guarantee that those simple steps will ward off the Blue Evil Eyes, if and when they appear. But they’ll make breaking your system with the Blues just that much harder.

    If you need to get into your system remotely, there are dozens of alternatives. I use the free Chrome Remote Desktop, but my needs are tiny and I’m not overly concerned about Google snooping me even more. If you want the Tesla version, check out Solarwinds from Dameware. – which is $380 per site.

  • Report that Server 2012 R2 Monthly Rollup KB 4512488 breaks RDP login

    Posted on August 14th, 2019 at 14:27 woody Comment on the AskWoody Lounge

    Reader @sdsalsero reports:

    Last night we upgraded our public-facing Server 2012R2-based RDS Gateway (GW) and Connection Broker (CB) servers to the brand-new Aug 2019 Rollup. After the patching, no one could login. We use an RDP connection file which specifies the use of the GW and has the CB listed as the target system. You would be prompted to authenticate, i.e., I assume your login request was passing through the GW to the CB, but then there was a completely generic error, “Unable to connect.”

    On the CB’s Windows Event application log,
    Microsoft-Windows-TerminalServices-SessionBroker-Client/Operational

    There are repeating pairs of 1306/1296 errors:

    1306, “RD Connection Broker Client processes request from a user”
    “Remote Desktop Connection Broker Client failed to redirect the user. Error: NULL”

    1296, “RD Connection Broker Client processes request from a user”
    “Remote Desktop Connection Broker Client failed while getting redirection packet from Connection Broker. Error: Remote Desktop Connection Broker is not ready for RPC communication.”

    Anybody else hitting that problem?