#1790 - [GH-ISSUE #1053] When the local computer enables the text capture feature of Youdao Translation, the RDP session will unresponsive. | 当本地计算机启用网易有道翻译的取词功能后，在操作远程RDP会假死 - starred/1Remote

kerem commented

2026-02-28 12:06:40 +03:00

Owner

Originally created by @zhouxinshuo on GitHub (Jan 5, 2026).
Original GitHub issue: https://github.com/1Remote/1Remote/issues/1053

Originally assigned to: @VShawn on GitHub.

Describe the bug
当本地计算机启用网易有道翻译的取词功能后，在操作远程的计算机会出现假死或崩溃现象，表现为程序无响应、过一会直接退出。

To Reproduce
1.打开网易有道翻译软件，并进入设置界面启用“取词功能”。置于后台。
2. 鼠标操作远程计算机界面。
3. 程序立即出现假死或崩溃现象。

Expected behavior
找到崩溃原因，修正bug

Screenshots

Desktop (please complete the following information):

OS: [e.g. Win11]
1Remote 1.2.0

Originally created by @zhouxinshuo on GitHub (Jan 5, 2026). Original GitHub issue: https://github.com/1Remote/1Remote/issues/1053 Originally assigned to: @VShawn on GitHub. **Describe the bug** 当本地计算机启用网易有道翻译的取词功能后，在操作远程的计算机会出现假死或崩溃现象，表现为程序无响应、过一会直接退出。 **To Reproduce** 1.打开网易有道翻译软件，并进入设置界面启用“取词功能”。置于后台。 2. 鼠标操作远程计算机界面。 3. 程序立即出现假死或崩溃现象。 **Expected behavior** 找到崩溃原因，修正bug **Screenshots** <img width="952" height="768" alt="Image" src="https://github.com/user-attachments/assets/53aeab0a-bcc2-4597-9b65-389e65fc38cd" /> **Desktop (please complete the following information):** - OS: [e.g. Win11] - 1Remote 1.2.0

kerem

2026-02-28 12:06:40 +03:00

closed this issue
added the
bug
label

kerem commented

2026-02-28 12:06:41 +03:00

Author

Owner

@VShawn commented on GitHub (Jan 5, 2026):

bug confirm. 但我不确定能否修复这个问题，总之先记录

@VShawn commented on GitHub (Jan 5, 2026): bug confirm. 但我不确定能否修复这个问题，总之先记录

kerem commented

2026-02-28 12:06:41 +03:00

Author

Owner

@VShawn commented on GitHub (Jan 6, 2026):

After some investigation, I found that this bug has existed from the very beginning. It already causes the interface to freeze in the version tested PRemoteM.0.5.7.2101121716.7z.

@VShawn commented on GitHub (Jan 6, 2026): After some investigation, I found that this bug has existed from the very beginning. It already causes the interface to freeze in the version tested [PRemoteM.0.5.7.2101121716.7z](https://github.com/1Remote/1Remote/releases/download/0.5.7.2012240828/PRemoteM.0.5.7.2101121716.7z).

kerem commented

2026-02-28 12:06:41 +03:00

Author

Owner

@VShawn commented on GitHub (Jan 9, 2026):

I wrote a minimal RDP program and didn’t encounter this bug, so it’s likely that a setting (or a WIN32 function call) causing the issue.

I even suspect that Dragablz might be causing the bug. Eh...not sure... We may need to comment out each module one by one to pinpoint the root cause.

@VShawn commented on GitHub (Jan 9, 2026): I wrote a minimal RDP program and didn’t encounter this bug, so it’s likely that a setting (or a WIN32 function call) causing the issue. I even suspect that Dragablz might be causing the bug. Eh...not sure... We may need to comment out each module one by one to pinpoint the root cause.

kerem commented

2026-02-28 12:06:41 +03:00

Author

Owner

@VShawn commented on GitHub (Jan 12, 2026):

Bad news: I tried using a new window to host RDP (that is, without using Dragablz), and in this case, 1Remote did not freeze. In other words, the issue of RDP freezing due to youdao dictionary word lookup is not related to AxMsRdpClient09Host.

@VShawn commented on GitHub (Jan 12, 2026): <img width="533" height="385" alt="Image" src="https://github.com/user-attachments/assets/44bad30e-203f-48c0-992c-afd2b415980a" /> Bad news: I tried using a new window to host RDP (that is, without using Dragablz), and in this case, 1Remote did not freeze. In other words, the issue of RDP freezing due to youdao dictionary word lookup is not related to AxMsRdpClient09Host.

kerem commented

2026-02-28 12:06:41 +03:00

Author

Owner

@VShawn commented on GitHub (Jan 13, 2026):

Bad news: I tried using a new window to host RDP (that is, without using Dragablz), and in this case, 1Remote did not freeze. In other words, the issue of RDP freezing due to youdao dictionary word lookup is not related to AxMsRdpClient09Host.

Additional testing: I found that if RDP remote desktop is launched in full-screen mode (without using the Dragablz interface), 1Remote does not crash. This indirectly confirms that the problem lies with Dragablz. So, I conducted a minimal unit test by hosting an RDP session with Dragablz, removing all other timers and such, and 1Remote crashed.

@VShawn commented on GitHub (Jan 13, 2026): > Bad news: I tried using a new window to host RDP (that is, without using Dragablz), and in this case, 1Remote did not freeze. In other words, the issue of RDP freezing due to youdao dictionary word lookup is not related to AxMsRdpClient09Host. Additional testing: I found that if RDP remote desktop is launched in full-screen mode (without using the Dragablz interface), 1Remote does not crash. This indirectly confirms that the problem lies with Dragablz. So, I conducted a minimal unit test by hosting an RDP session with Dragablz, removing all other timers and such, and 1Remote crashed. <img width="1184" height="743" alt="Image" src="https://github.com/user-attachments/assets/6102b1ba-274c-4b89-ba11-dd026178f766" />

kerem commented

2026-02-28 12:06:41 +03:00

Author

Owner

@VShawn commented on GitHub (Jan 14, 2026):

A further testing confirmed that the RDP freezing issue is not related to Dragablz, but rather to the way the RDP control is initialized:

The structure of my test app is shown below:

When I set the content of DesktopContent to RDP within the win.Loaded event, the software freezes when text capture in the dictionary.

var win = new Window1();
var s = new _1RM.Model.Protocol.RDP()
{
	DisplayName = "390",
	Address = "172.20.XXX",
	Port = "3389",
	UserName = "administrator",
	Password = "XXXX",
};
var rdp = AxMsRdpClient09Host.Create(s);
win.Loaded += (o, args) =>
{
	win.SetContent(rdp); // makes RDP crash when translate app's text capture is on
	rdp.Conn();
};
win.ShowDialog();

However, if I set ContentControl.Content = rdp before creating window1, the software does not freeze.

var win = new Window1();
var s = new _1RM.Model.Protocol.RDP()
{
	DisplayName = "390",
	Address = "172.20.XXX",
	Port = "3389",
	UserName = "administrator",
	Password = "XXXX",
};
var rdp = AxMsRdpClient09Host.Create(s);
win.SetContent(rdp);
win.Loaded += (o, args) =>
{
	rdp.Conn();
};
win.ShowDialog();

In summary, setting the RDP into the ContentControl after the window is loaded causes the RDP to freeze. However, I’m not sure about the root cause of this bug.

Since 1Remote currently:

switches between fullscreen and windowed modes by moving the RDP control between the ContentControls of the Tab and the fullscreen window
and because when multiple Tabs exist, the subsequent RDP instances are inevitably created after the window has loaded

it’s unavoidable to set the Content after the window has loaded. Therefore, there’s no Easy way to work around this issue.

@itagagaki, do you have any suggestions regarding this problem for me?

One solution I thought of is an experimental branch I worked on earlier: https://github.com/1Remote/1Remote/tree/RDP_based_on_winform. In this branch, RDP is hosted within a Window, and the Tab View treats it like a third-party window similar to Putty to control its size. This avoids switching the ContentControl. However, the code in this branch is quite outdated and incomplete, so implementing this solution would require a significant amount of rewriting.

@VShawn commented on GitHub (Jan 14, 2026): A further testing confirmed that the RDP freezing issue is not related to Dragablz, but rather to the way the RDP control is initialized: The structure of my test app is shown below: <img width="598" height="433" alt="Image" src="https://github.com/user-attachments/assets/a28c78a1-de14-4b2f-bad4-d15ecfb315b5" /> When I set the content of DesktopContent to RDP within the win.Loaded event, the software freezes when text capture in the dictionary. ``` C# var win = new Window1(); var s = new _1RM.Model.Protocol.RDP() { DisplayName = "390", Address = "172.20.XXX", Port = "3389", UserName = "administrator", Password = "XXXX", }; var rdp = AxMsRdpClient09Host.Create(s); win.Loaded += (o, args) => { win.SetContent(rdp); // makes RDP crash when translate app's text capture is on rdp.Conn(); }; win.ShowDialog(); ``` However, if I set ContentControl.Content = rdp before creating window1, the software does not freeze. ``` C# var win = new Window1(); var s = new _1RM.Model.Protocol.RDP() { DisplayName = "390", Address = "172.20.XXX", Port = "3389", UserName = "administrator", Password = "XXXX", }; var rdp = AxMsRdpClient09Host.Create(s); win.SetContent(rdp); win.Loaded += (o, args) => { rdp.Conn(); }; win.ShowDialog(); ``` In summary, setting the RDP into the ContentControl after the window is loaded causes the RDP to freeze. However, I’m not sure about the root cause of this bug. Since 1Remote currently: - switches between fullscreen and windowed modes by moving the RDP control between the ContentControls of the Tab and the fullscreen window - and because when multiple Tabs exist, the subsequent RDP instances are inevitably created after the window has loaded it’s unavoidable to set the Content after the window has loaded. Therefore, there’s no Easy way to work around this issue. @itagagaki, do you have any suggestions regarding this problem for me? One solution I thought of is an experimental branch I worked on earlier: https://github.com/1Remote/1Remote/tree/RDP_based_on_winform. In this branch, RDP is hosted within a Window, and the Tab View treats it like a third-party window similar to Putty to control its size. This avoids switching the ContentControl. However, the code in this branch is quite outdated and incomplete, so implementing this solution would require a significant amount of rewriting.

kerem commented

2026-02-28 12:06:41 +03:00

Author

Owner

@itagagaki commented on GitHub (Jan 16, 2026):

I'll take a look when I have some free time.

@itagagaki commented on GitHub (Jan 16, 2026): I'll take a look when I have some free time.

kerem commented

2026-02-28 12:06:41 +03:00

Author

Owner

@itagagaki commented on GitHub (Jan 17, 2026):

This might be off the mark, but I wondered if the issue I mentioned in the comment below could be related.
https://github.com/1Remote/1Remote/issues/1052#issuecomment-3717868463

@itagagaki commented on GitHub (Jan 17, 2026): This might be off the mark, but I wondered if the issue I mentioned in the comment below could be related. https://github.com/1Remote/1Remote/issues/1052#issuecomment-3717868463

kerem commented

2026-02-28 12:06:41 +03:00

Author

Owner

@VShawn commented on GitHub (Jan 19, 2026):

This might be off the mark, but I wondered if the issue I mentioned in the comment below could be related.

I can confirm it’s unrelated because I didn’t use 1Remote for testing. Instead, I start a new standalone WPF application to test how RDP would freeze. Although I reused the AxMsRdpClient09Host control, I didn’t perform any focus-switching operations, nor did I use the Dragablz control.

@VShawn commented on GitHub (Jan 19, 2026): > This might be off the mark, but I wondered if the issue I mentioned in the comment below could be related. I can confirm it’s unrelated because I didn’t use 1Remote for testing. Instead, I start a new standalone WPF application to test how RDP would freeze. Although I reused the AxMsRdpClient09Host control, I didn’t perform any focus-switching operations, nor did I use the Dragablz control.

kerem commented

2026-02-28 12:06:41 +03:00

Author

Owner

@itagagaki commented on GitHub (Jan 20, 2026):

The Loaded event occurs when the element is laid out, rendered, and ready for interaction.

My guess is that calling SetContent() within it will initiate the layout of elements within the new content. Once this preparation is complete, the Loaded event will be triggered. Thus, it is an infinitely recursive loop.

@itagagaki commented on GitHub (Jan 20, 2026): The `Loaded` event occurs when the element is laid out, rendered, and ready for interaction. My guess is that calling `SetContent()` within it will initiate the layout of elements within the new content. Once this preparation is complete, the `Loaded` event will be triggered. Thus, it is an infinitely recursive loop.

kerem commented

2026-02-28 12:06:41 +03:00

Author

Owner

@VShawn commented on GitHub (Jan 22, 2026):

This bug only occurs when the dictionary word capture feature is enabled. So, I don’t think it’s "an infinitely recursive loop."

when I disabled the feature, RDP works fine where ever win.SetContent(rdp); is placed

@VShawn commented on GitHub (Jan 22, 2026): This bug only occurs when the dictionary **word capture feature** is enabled. So, I don’t think it’s "an infinitely recursive loop." when I disabled the feature, RDP works fine where ever `win.SetContent(rdp);` is placed

kerem commented

2026-02-28 12:06:41 +03:00

Author

Owner

@itagagaki commented on GitHub (Jan 22, 2026):

I can't test the word capture feature, but it might be a good idea to log the event that occurred at the very beginning of the Loaded handler.

@itagagaki commented on GitHub (Jan 22, 2026): I can't test the word capture feature, but it might be a good idea to log the event that occurred at the very beginning of the `Loaded` handler.

kerem commented

2026-02-28 12:06:41 +03:00

Author

Owner

@itagagaki commented on GitHub (Jan 23, 2026):

I figured out how to reproduce the issue, so I did some research.

As I moved the mouse pointer within the RDP window, I noticed that a WM_NCHITTEST (132) message being sent to AxMsRdpClient9NotSafeForScriptingEx.WndProc(). Several WM_GETOBJECT (61) messages followed, sometimes arriving before the WndProc() returned.
After that, it froze.

These messages are not sent when Youdao is not running.

@itagagaki commented on GitHub (Jan 23, 2026): I figured out how to reproduce the issue, so I did some research. As I moved the mouse pointer within the RDP window, I noticed that a `WM_NCHITTEST` (132) message being sent to `AxMsRdpClient9NotSafeForScriptingEx.WndProc()`. Several `WM_GETOBJECT` (61) messages followed, sometimes arriving before the `WndProc()` returned. After that, it froze. These messages are not sent when Youdao is not running.

kerem commented

2026-02-28 12:06:41 +03:00

Author

Owner

@itagagaki commented on GitHub (Jan 23, 2026):

The cause of this problem must be WM_GETOBJECT.
The problem does not occur if both of the following are removed. Freezing occurs if either is left in place.

myHwndSource?.AddHook(new HwndSourceHook(AdditionalWndProc)); in the TabWindowView constructor
Overriding WndProc() in AxMsRdpClient9NotSafeForScriptingEx

@itagagaki commented on GitHub (Jan 23, 2026): 1. The cause of this problem must be `WM_GETOBJECT`. 2. The problem does not occur if both of the following are removed. Freezing occurs if either is left in place. - `myHwndSource?.AddHook(new HwndSourceHook(AdditionalWndProc));` in the `TabWindowView` constructor - Overriding `WndProc()` in `AxMsRdpClient9NotSafeForScriptingEx`

kerem commented

2026-02-28 12:06:41 +03:00

Author

Owner

@itagagaki commented on GitHub (Jan 23, 2026):

No, changing the those things only makes it less likely to happen. If I click rapidly about 10 or 20 times, it freezes.
In any case, the problem appears to be related to WM_GETOBJECT.

@itagagaki commented on GitHub (Jan 23, 2026): No, changing the those things only makes it less likely to happen. If I click rapidly about 10 or 20 times, it freezes. In any case, the problem appears to be related to WM_GETOBJECT.

kerem commented

2026-02-28 12:06:41 +03:00

Author

Owner

@itagagaki commented on GitHub (Jan 23, 2026):

WM_GETOBJECT is definitely caused by Youdao's word capture feature. When the method is set to Alt + mouse, WM_GETOBJECT no longer occurs even how quickly I click within the window, and the 1Remote does not freeze. However, simply moving the mouse while holding down the Alt key triggers WM_GETOBJECT and causes it to freeze.

@itagagaki commented on GitHub (Jan 23, 2026): `WM_GETOBJECT` is definitely caused by Youdao's word capture feature. When the method is set to Alt + mouse, `WM_GETOBJECT` no longer occurs even how quickly I click within the window, and the 1Remote does not freeze. However, simply moving the mouse while holding down the Alt key triggers `WM_GETOBJECT` and causes it to freeze. <img width="611" height="410" alt="Image" src="https://github.com/user-attachments/assets/9d6187d0-e224-4540-a107-526c805d9a65" />

kerem commented

2026-02-28 12:06:41 +03:00

Author

Owner

@itagagaki commented on GitHub (Jan 24, 2026):

I can't explain why it worked, so this might not be the correct solution. However, it did prevent the freeze.

@itagagaki commented on GitHub (Jan 24, 2026): I can't explain why it worked, so this might not be the correct solution. However, it did prevent the freeze.

kerem commented

2026-02-28 12:06:41 +03:00

Author

Owner

@VShawn commented on GitHub (Jan 26, 2026):

A productive piece of work! 🎆 As I hadn’t thought to analyze the messages from the window

Although it still can’t explain why the position of win.SetContent(rdp); affects the test results, at least this workaround bypasses the issue. Thank you.

The concern is if blocking WM_GETOBJECT will affect other RDP functionalities.

I will conduct usage tests on the latest nightly build.

@VShawn commented on GitHub (Jan 26, 2026): A productive piece of work! 🎆 As I hadn’t thought to analyze the messages from the window Although it still can’t explain why the position of `win.SetContent(rdp);` affects the test results, at least this workaround bypasses the issue. Thank you. The concern is if blocking WM_GETOBJECT will affect other RDP functionalities. I will conduct usage tests on the latest nightly build.

kerem commented

2026-02-28 12:06:41 +03:00

Author

Owner

@VShawn commented on GitHub (Jan 26, 2026):

BTH, I am still considering the option to rewrite the entire RDP into a WinForm window, because

it can solve this issue without introducing other risks, and
it can reduce the coupling between the tab and the RDP page.

The challenge with this approach lies in the large amount of code rewrite and the extensive testing required.

@VShawn commented on GitHub (Jan 26, 2026): BTH, I am still considering the option to rewrite the entire RDP into a WinForm window, because 1) it can solve this issue without introducing other risks, and 2) it can reduce the coupling between the tab and the RDP page. The challenge with this approach lies in the large amount of code rewrite and the extensive testing required.

Rows
Columns

[GH-ISSUE #1053] When the local computer enables the text capture feature of Youdao Translation, the RDP session will unresponsive. | 当本地计算机启用网易有道翻译的取词功能后，在操作远程RDP会假死 #1790