I have numerous PCs in my office right now, and a couple more elsewhere in the house. My usual modus operandi is to work from my primary desktop, and use Remote Desktop Connection (and the RDP protocol) to jump onto and work with those other machines. I do this dozens of times daily, as I check various Windows versions, VMs, and more. At least 1 time out of 4, when I start up an RDP connection it sits on the remote PC’s lock screen for some time (minutes, even). Only recently have I researched this, and come up with a possible RDP session startup delay fix. You can see it in the unchecked box at lower left in the lead-in graphic: persistent bitmap cache.

What Is This Possible RDP Session Startup Delay Fix?

Another workaround is to close the opening session, then open it again. This almost always works. But in reading over a set of possible fixes in an April 2024 TheWindowsClub story on this very topic, I came across one I’d neither heard of before, nor tried. So, of course, I tried it: it involves unchecking the “Persistent bitmap caching” entry on the expanded Remote Desktop Connection app’s Experience tab as shown above.

I tried that on a couple of PCs that were showing significant delays in starting RDP sessions just now. And guess what? After that tweak, they opened right up. I’m guessing the delay might come from loading the cache at session startup, which the app uses to speed reproduction of already-known (and cached) screens. So it’s gonna be a tradeoff: faster startup at first, but slower response when screens need to move across the network that would otherwise already be stored.

I’m not sure it’s a total win, but it’s interesting to try such things out and see how they work for you. To me that’s the essence of getting things right in Windows-World — namely finding and using the right controls, to do what you need in a way that you can live with.

It’s a “one step forward, one step back” situation. The latest Windows 11 Insider release to the Beta Channel brings optional seconds back to the Taskbar clock. But using a remote access windows clips seconds display, as shown in the lead-in graphic. I’ve posted a report about this to the  feedback hub. Amusingly, it’s attracted an MS response from 3 months ago that says (in condensed form) “We fixed this in the Dev channel 3 months ago.” Uhhh … not really … I see it right there so it isn’t fixed.

Note: I included a snip of the Winver output from the Beta Channel Build 22624.1470 above the Taskbar clock to document its release of origin. You can see about half of the time read-out from that clock at the lower right (enough to tell that it says 11:51:45 AM, in fact).

Reporting Remote Access Window Clips Seconds Display

Here’s what I wrote to the Feedback Hub:

Text from my Feedback Hub report Friday 3/24

One more thing: when you make this change in Build 22624.1470, it doesn’t affect taskbar display until after a reboot. And indeed, upon rebooting the clock initially showed up initially sans seconds display. They showed up later on, as the PC went through its desktop initialization process after I’d logged in. That was kind of interesting, too…

What To Do About “the Clip?”

There’s not much one can do about this issue because Windows 11 still lacks icon size controls for the taskbar. From what I hear these controls are planned for inclusion in some upcoming Windows 11 release. If MS doesn’t get around to fixing this admittedly minor if not miniscule issue, access to icon sizing will probably take care of things at some later date.

I’ll also note that this issue does not occur when I log directly into that test machine (a Lenovo ThinkPad X380 Yoga [8th-gen Intel CPU, Intel graphics, 16 GB RAM]). So it really is an issue with the way the Remote Desktop  Connection application handles taskbar display at the moment. Just for grins, I also tried a connection through the Remote Desktop UWP app. For the record, it clips that window’s clock display, too. Thus, it looks like a taskbar height issue FWIW.

For a while there, I was wondering if I’d done something wrong. I’d just gotten RDP working on my P360 Ultra. But after upgrading to Windows 11 22H2, it stopped working again. Annoyingly, it showed the same symptoms I’d just been able to fix  — connection briefly made, then dropped. But nothing I tried was able to return it to work. In frustration, I switched to TeamViewer free (which worked properly no sooner than installed on client and server PCs). Now, I’m reading my recent 22H2 RDP mystery widely reported in the Windows media. Here’s a taste, from MSPowerUser.

Info on Recent 22H2 RDP Mystery Widely Reported

As I read the symptoms described in reporting on the 22H2 RDP issues, I thought to myself: “This sounds familiar.” And indeed, the error message shown strongly supports one of the possible outcomes to which that language leads:

installing the update caused their Remote Desktop on Windows 11 system to fail to connect (or connect only to disconnect or freeze later).

For the P360, the connection would briefly appear as the RDP title bar at the top of my second monitor. It would, however, stay black. In 10 seconds or so, the error message from the lead-in graphic would pop up. Sigh.

Why Did I Drive Myself Crazy?

The funny thing about this error message — and it’s definitely not funny, ha-ha — is that it’s the same darn one I had just fought through and fixed the week before. In that case, it turned out to be a registry hack that fixed my problem.

I jumped to the erroneous conclusion that my old problem had come back, and spent a good 2-3 hours trying to fix it. I knew it had to be something in the registry, but I couldn’t figure out what. Then, recognizing it was taking too much time to troubleshoot, I simply switched over to TeamViewer.

As it turns out, that was exactly the right strategy. Apparently a LOT of people are having RDP troubles with 22H2. So that workaround comes recommended for others who might find themselves in the same boat. OTOH, the MSPowerUser story suggests another reghack that may see some users clear to restored RDP access. I might have to try it, and see if it works for the P360 Ultra.

And that’s the way things sometimes go, here in WindowsWorld. If and when this gets fixed, I’ll report back. Stay tuned!