Freeze with new Surface Pro 11 snapdragon?

Hello

I'm sorry to hear about the issue when running on ARM.

I can't think of a setting that might help here, although maybe one of my colleagues will jump in if they have an idea.

What I'd normally recommend in a case like this is to generate a process mini dump when RDM freezes and provide it to us, along with the details of the RDM version you were running when you created the dump. There are instructions here for creating a mini dump of a hung process: https://docs.devolutions.net/rdm/kb/rdm-windows/troubleshooting-articles/hung-rdm-dump-file-creation/.

It's important that you provide us the dump file in private, since it can contain segments of memory. Once you have a dump file, let us know here, and we can provide you a secure upload link

Please let me know if something isn't clear or you have further questions

Kind regards,

So there's no way to pull anything useful WHEN it happened? I just locked up again (first time I had it two times in a matter of hours) but of course I wasn't looking at the mini dump as something I had to have running all day long just IN CASE it locked up - I had hoped it was something to run afterwards that would catch data in that state. Of course, now that I locked up and downloaded and ran, I see in the instructions I have to have it running already...

I'll have to wait till like Friday before I have the leisure to have this going just in case something comes up. Will this then be capturing EVERYTHING that is done? What data will be included, since I do a lot of work for healthcare and such and so I can't have it getting things about their particular servers, passwords, etc... Will this be limited strictly to EXE and system file usage for however long the capture runs? As long as I'm not inadvertently sending things about client sites I shouldn't, then I can make it a habit of starting this up before I begin working once I'm back in the office on Friday.

Thanks

John

Hello

Ok, first I think there's a misunderstanding of the instructions. It's not necessary to run ProcExplorer beforehand, you can do it on the fly. Basically the steps are:

• Use RDM until it you get a freeze
• At that point, wait - don't kill the process
• Run ProcExplorer "as administrator" (downloading it first if necessary)
• Generate the minidump
• Now you can task kill RDM

This isn't running any kind of "trace" or logging of activity. What we are doing is capturing the state of the program at the time you generate the dump. Critically, this will allow us to see the stack of all the managed and native threads and hopefully determine where the deadlock is.

That said, a dump can contain segments of the process memory, and it does represent a small privacy risk if not handled properly. I'd recommend reading our security disclaimer: https://docs.devolutions.net/rdm/kb/rdm-windows/troubleshooting-articles/hung-rdm-dump-file-creation/security-disclaimer-sending-dump-file/. If you have further questions or concerns, myself or a member of our security team would be happy to answer them.

Unfortunately - since this doesn't seem to be a widespread issue (we don't have lots of users on ARM, so you might just be unlucky) I don't really have anything else to go on. I tried to reproduce on my side but could not; but it sounds very intermittent which is probably why. This is really the only way to understand this kind of crash.

Please, let me know if you have further questions or comments

Kind regards,

Instructions you pointed me to explicitly stated to run process explorere first, THEN open the program and try to duplicate.

1. Download and install the Sysinternals Suite utilities.
2. 
   
3. From the installation folder, start the procexp64.exe or procexp.exe application.
4. Launch Remote Desktop Manager.
5. Replicate the steps that trigger the issue in Remote Desktop Manager.
6. In the Process Explorer, right-click the RemoteDesktopManager.exe process.

That's why I asked what I did.

It's going now and we'll see if it locks up again today, otherwise I won't have a chance till Friday, so I'll let you know when I have something so you can tell me how to get it to you.

And I figured I was in the minority here. I was actually surprised when I looked at the process details and saw this running as an ARM executable, not just an emulated process...

John

Hello again

Yes, you're right, the step-by-step instructions are a bit misleading. I'll leaise with the documentation team to get that tidied up. I assure you, you can wait for a freeze before following the steps: we just want to capture the state of the application at that moment in time.

We worked hard to build RDM as a native ARM application, but there have definitely been some edge cases and it doesn't have widespread adoption right now. If you interested in trying, I could tell you how to run the app in emulated x64 mode. It may work around the problem, but I don't know how performance would be. Actually my experience of the x64 emulation on ARM is pretty good, but YMMV.

It could be worth trying to grab a process mini dump first so we have something to work with here, before trying that as a workaround.

Thanks and kind regards,

I'm fine sticking with the ARM architecture, despite the freezes. And since it generally only happens maybe once a day (today was the first time it happened twice but it's not often I'm pulling windows out of the main program to run screen side by side) it isn't crippling. Especially since the biggest pain is simply having to run through a bunch of Duo 2FA prompts when it opens all the servers that were previously open. it'd be a LOT more annoying if it lost that info in this process and didn't know what to re-open again.

So I'll just keep running it and pulling windows out to try to force the issue even when I normally wouldn't need to, just to try to get it to fail and generate the mini dump for you guys.

Thanks!

john

Hello

Sounds good - thank you. We'll wait to hear something. In the meantime, I've requested the documentation team to clarify the procedure in the linked KB article as discussed.

Thanks and kind regards,

OK, just happened, minidump is just under 17MB, let me know where to send it or upload it.

Thanks

John

Hello

Thank you. I've sent you a PM with instructions to send the file, let me know if you don't get that. And if you could confirm the RDM version that you were running when you created the file, it would make things faster for me.

Thanks again,

Renamed and uploaded just now, thanks! I had assumed most recent version of RDM sine I didn't get any nags recently opening it, but it's NOT. I'm running 2024.2.21.0

I'll hold off on upgrading until you tell me to go ahead in case you want me to try anything with it happening as things are now.

J

Hello

Yes - the most recent version is 2024.3.x, but this was only just released at the start of the week and to my knowledge it's not advertised in the automatic update yet. Usually when a major version is pushed the auto update is not changed for a week or two, to give a chance for stabilization or finding any major bugs that slipped past QA.

In this case I don't think it matters, and I think that you can update or not - I don't think it will change this issue.

The dump file doesn't reveal a lot of information, but based on a hunch and the information I do have, can you try the following?

• Open RegEdit.exe as administrator
• Navigate to HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\Client
• Create a DWORD named fClientDisableUDP and assign it a value of 1
• Reboot your machine at the first convenience

And after this, see if the problem reoccurs and let me know either way.

The usual disclaimers apply around editing your registry, but this is a "safe" change if done correctly we are just disabling the UDP transport for the RDP client. It won't impact functionality and can easily be reverted by deleting that DWORD entry again.

Please, let me know if you have any questions or comments.

Kind regards,

Done, but I'm finishing up the day from home so no big 49" external monitor for my surface pro 11 now, just itself, so I won't be pulling things out. But I'll be back to normal ops on Monday and will see what happens and update accordingly after a few days next week.

Thanks, and have a good weekend.

John

Maybe your hunch for the reg change made the difference. I've been going for hours here now at work on the multi mon and have one of them pulled out of the main app window, and not a single freeze so far.

Since I'll be doing this for a few days, I'll reply again after a few days and confirm it's not happening anymore if it keeps behaving, but I'd guess your change resolved my issue.

Thanks

John

Hello

Just checking in with you in case you've seen this issue again since disabling the UDP transport. If it turns out that this is the problem, I have some other tips for running with this configuration without needing to modify the registry.

I'll wait to hear back from you again

Thanks and best regards,

Haven't used it since Monday unfortunately, Tuesday I was tied up and I'm off Wednesdays. So been going this morning.

But I've also started having other issues with some specific things now in this install of Windows. Started out that the Surface app would no longer run - opens the splash screen then closes. Then the store did the same thing. And all the things to remove and reinstall or reset things haven't helped. Today I find that I can't run notepad or calculator. So I'm likely going to be doing a nuke and rebuild here. Errors in event log point to some .net issues, but even getting the appx files for the native framework and vclibs didn't help.

But the RDP issue happened for a week before those, and so far seems to be playing nice still despite these other issues I've got with some of the native assembly things here... So I'm guessing that the UDP setting resolved my RDM issue...

Yep, been going all day for about 5 hours so far, not a single hiccup with the RDM program despite the rest of the OS going to hell, so definitely can close this incident... You mentioned other tips, so I'll see what else you have to offer, but it seems to be solid now. Thanks!

Hello again

Well, first of all I'm glad things seem to be working better despite your other problems with your workstation.

We do see this issue semi-regularly and it's something that crops up outside of RDM - UDP transport in RDP connections to (some?) servers can cause the RDP control to freeze (in both the ActiveX and mstsc itself).

Typically, however, this happens on disconnect so I wonder why it would transpire when undocking or docking a tab in RDM. Can you confirm what settings you have for the display in the RDP connection? I wonder if it's resizing the control and performing a reconnect, instead of a dynamic resize.

Next, disabling UDP in the registry works but it somewhat heavy handed. Microsoft doesn't allow us to disable this at a "per session" level, but we do have a feature that can do that by working with internal properties of the ActiveX control. You can see in the RDP "Advanced" tab the option to "Disable UDP transport". While checking this, I note that we don't have a corresponding application level setting for "Default", but if you wanted to set this for some or all RDP entries you could use a batch edit.

Please, let me know if something isn't clear or you have further questions or problems

Kind regards,

Isn't happening when resizing or anything. And doesn't happen during the undocking or docking. Only happened AFTER something was undocked and somewhere else on the screen and active. No sessions seemed to be actually getting disconnected. And it never happened quickly - I'd be running for 10 or more minutes before I'd freeze in the earliest situations, but usually it ran fine like this for hours before freezing.

Display settings for are the same on all - screen sizing mode is default (none) as is remote desktop size. Zoom is 100%. I assume these are all just the default settings, I haven't had to change them on any of the systems I access. Colors also are I assume default settings - highest quality, 32 bits, and checked to display the connection bar when in full screen mode, and checked for connection bar pinned full screen.

I pull my connecitons.db from computer to computer when I get a new system, so this one is using the same DB and settings that were on the Surface Pro 9 for a few years, and never had a single instance of this, so I'm guessing there is definitely something specific with the ARM architecture in my case that's causing the problem, since I have multiple techs also all hitting the same servers without any issues either.

Although now I have to look since when I just reinstalled everything again this morning after rebuilding my Surface Pro 11 to fix the other issues (and found THAT - it was a speedtest program I downloaded and installed that trashed everything - it installs a .net prerequisite from 2015 that totally destroyed my ARM windows install), I saw the option for the free cloud data source. I'm going to have to look into how to convert my local source to that, since then I could potentially be able to use my phone in an emergency if someone needed something and I didn't have my Surface with me...

Not worried about UDP versus no UDP, my connections are all very high speed on all ends, no issues with latency, so the benefits for low speed connections aren't an issue, and the performance for everything is fine. Strictly hitting servers for management directly, no RDP gateway involved. Pretty straightforward and simple.

And all day yesterday, not a single freeze, so definitely that resolved my problems.

Thanks

John

Hello

Ok, I understand, and I'm glad this seems to have fixed things. The UDP transport does have buggy edge cases in different systems and different scenarios, which matches what you wrote. Overall if we see a freeze like this in MS RDP and I see lots of UDP threads in the application dump, disabling UDP is the first thing that I recommend.

Sorry to hear about your overall system difficulties. MS seems to be getting better here but ARM definitely still feels like a second-class citizen sometimes. I did hear that they might finally be offering Windows 11 ARM ISOs for download soon, so maybe they are starting to put more focus on this.

For converting your data source to a shared one, I'm afraid I can't offer any specific advice - that's not my area of expertise - but if you can't figure it out easily, I'd recommend a post on the RDM Windows support forum. There are lots of people here that can help with that and it will get better visibility in a standalone thread.

As always, please don't hesitate with other questions or feedback.

Kind regards,

Not to necro an old post, but since I was the only one experiencing this figured I'd just post here.

Happening again. So don't know if there was an update on the windows side or the devolutions side. My settings hadn't changed, and I"ve gone for the last month with no issues, but now it's happening even when I don't have a window undocked. Yesterday and today it totally froze multiple times and I have to end task and open again.

I have a minidump if someone wants me to send it to them.

John

Hi John

Sorry to hear that. You can submit the mini dump following the same instructions as before and I'll take a look. Let me know if you don't have the PM with the details in it still.

Also - you're not running a Windows Insider release, are you?

Kind regards

No, I've learned not to do the insiders stuff, since I rely on this not just for my own personal stuff but for work as well. So I've not used an insider build on any of my laptops for years. Just a PC or two at home.

And yep, I found the email and uploaded the file a minute ago.

Thanks

John

Hello

I've taken a look a the crash dump. What's happening is; we ask the Microsoft RDP control to disconnect, which it doesn't answer immediately (it can sometimes take a few moments to disconnect). Actually in this case I suspect that the RDP control itself is getting hung up; however this particular case has an "escape hatch" where we're only supposed to wait a maximum of 8 seconds before continuing - regardless what the RDP control is doing.

I have some ideas about this but I want to check: you had an RDP session open, you click to close the tab (which you expect to disconnect the session and close the tab), but instead RDM freezes, right? And just to be sure - although I'm pretty sure I know the answer - you can wait longer than 8 seconds and the app remains frozen?

Thanks and kind regards,

Actually, I wasn't closing anything - I just had multiple sessions open and active.

And it hung for at least 5 minutes while I waited to see what it would do, and then had to dig in here for the instructions to get the dump again...

Oddly enough it hasn't happened again other than those two days now where it happened several times each day.

Hello

It's really strange then. I definitely see the MS RDP control locked up (although why, I cannot say). This seems to cause the freeze in RDM despite having protections there (which, I'm definitely willing to admit could be imperfect); but the call stack shown on the deadlocked UI thread is originating from a click on a window/tab close button. Is it possible you clicked to close the window _after_ RDM had apparently locked up?

Thanks and kind regards,

I wouldn't doubt it if I clicked the hell out of the window after it locked up. ;)

I would've likely been trying to see if it was just a hiccup and would resume or was totally locked.

And still hasn't happened yet despite having RDP going pretty much all day long... May just have been some bizarre perfect storm of unrelated things that were going on for me those couple days.

Hello

Ok, that makes sense. Broadly we do see these kind of issues with the MS RDP ActiveX control. Although it provides a way to have multiple RDP sessions active in the host program, it's not something that Microsoft uses themselves (the closest thing they have is RDCMan, which is not really first party software - it's SysInternals). As a result we get weird behaviour that we have to code around, as well as breakage when they introduce new issues as the relevant DLLs get updated. Actually you can find several forum posts right now on the front page with people struggling with RDP freezes (although, most often, this is due to using a Windows Insider build which I know you are not).

One thing you could try is to switch to MS RDC (the "modern" MS RDP client); it has an ActiveX control and integrates nicely in RDM. It is a standalone install (it doesn't ship with the OS) and there is some minor configuration changes to make. You can see the instructions here and feel free to let me know if you have some questions. I'd recommend to download the RDC .msi (the details are linked in that KB article but here is the direct link for convenience) rather than installing from the Windows App Store

Kind regards as always,

Thanks, I'll look into that.