This article helps fix an issue where applications crash or become unresponsive if another user logs off a Remote Desktop session.
Posted by rburbridge: “Windows 10 Remote Desktop crashing LogonUI.exe on target machine, driv”. Microsofts Remote Desktop crashes when the option 'allowchannels' is set to true. It seems that whatever xrdp is sending is not something that should be there. Changing any of the channels to false doesn't solve the problem.
Moreover, my Surface 3, running Windows 10 (but also not yet updated) can successfully connect to the same target PC. To be clear, the connection goes through. But, invariably, within 30 seconds the Remote Desktop Connection app crashes on the machine running the Fall Creators Update. 1.Go to Microsoft Remote Desktop preferences General Tab uncheck “use system proxy configurations “ and Also uncheck “Use hardware acceleration ” This is one suggestion shared in another thread and many users reported that if fixed their issues.
Applies to: Windows Server 2012 R2
Original KB number: 2536487
Symptoms
When you run an application from a mapped drive, the application becomes unresponsive or crashes for a user (or multiple users) when another user logs off. This issue occurs in Windows Server 2012 R2, Windows Server 2012, Windows Server 2008 R2 Service Pack 1 (SP1), and Windows Server 2008.For example, this issue may occur in the following scenario:
One server is a file server and another is a Remote Session Host server (terminal server).
A folder on the file server is mapped for use by remote users connecting to the RDS server.
An application on the mapped share is launched by multiple users.
One user logs off. This causes the other users of the application to experience an application crash or unresponsiveness. Depending on the OS version, this issue occurs when either the first or last user of the application logs off, as follows:
- In Windows Server 2012 R2, Windows Server 2012, and Windows Server 2008, this issue occurs when the first user who logged on logs off.
- In Windows Server 2008 R2 SP1, this issue occurs when the last user who logged on logs off.
Note
In Windows Server 2008 R2 SP1, this behavior changes to the same as that of Windows Server 2012 R2, Windows Server 2012, and Windows Server 2008 after you install hotfix 2559767.
Cause
This issue occurs because of the way that the redirector handles the File Control Block (FCB) for the binary in question.
Microsoft Remote Desktop App
In Windows Server 2012 R2, Windows Server 2012, and Windows Server 2008, the FCB is owned by the first user who opened the file, and this FCB is used by subsequent users. When the first user logs off, the FCB is orphaned. This causes the application to crash or become unresponsive on subsequent uses.
In Windows Server 2008 R2, the FCB is owned by the last user who opened the file, and previous users experience the issue when the last user logs off.
Technically the FCB is not owned by any specific user. It's just a shared structure that represents a file. The FCB is created when the first handle to the file is opened, and it's destroyed when the last handle to the file is closed. Therefore, it is not tied to a user.
The orphaned entity is the file object that belongs to the user who logs off. If that file object backs the file system cache or a mapped section, you experience these I/O errors.
Resolution
To resolve this issue, upgrade to Windows Server 2016. The issue is fixed in this version of Windows Server.
Workaround
To work around this issue, use one of the following methods:
Microsoft Remote Desktop Crashes 2019
- Do not run shared applications from a mapped folder. Instead, install the shared application locally on the terminal server.
- Use WebDAV shares instead of mapped folders if remote binary sharing is required.
- Compile the application by using the Swap run from network linker setting:
- This setting is described here: https://msdn.microsoft.com/library/chzz5ts6(v=vs.71).aspx
- If the application is a managed app, use the Shadow Copy feature.
Note
Microsoft Remote Desktop Crashes
We don't recommend that you run binaries remotely. In situations such as this, we recommend that you use the first workaround.