wez
commented
4 years ago Thanks for the detailed information!
RDP does something "funny" with GPU availability; back in https://github.com/wez/wezterm/issues/40 I added some logic to fall back to the software renderer when the app is opened in an RDP session. Based on the output you shared, I think the more recent changes to WGL/EGL initialization may now have made it possible to get a working OpenGL context in that environment.
The panic message sounds like the RDP OpenGL context may not have enough VRAM to support the screen size at disconnect; I'm assuming that the disconnect results in an excessively large screen size (perhaps due to it being tiled/maximized?) that isn't supportable in that environment. However, if the app is started with access to the true display it has access to the full VRAM available and that might explain why the app survives in that case.
I've pushed 3484478ba261191dc69376f5945d378c031d806d that attempts to recover from a failed attempt to allocate vertex buffers. It should log the old and new dimensions to help us understand a bit better what is going on. I'm not sure if the recovery attempt will prevent a later panic, but I'm hoping that we can at least learn a bit more, and if we're lucky, it will keep things running until you next attach to the session and trigger a resize where it will succeed.
I'd appreciate it if you could try out the windows build associated with that commit once the CI has finished; it should be downloadable from here https://github.com/wez/wezterm/actions/runs/252069384 within ~30 minutes of this comment being posted.
If it is still crashy and getting in your way, a workaround would be to set this in the wezterm.lua file on the remote machine:
return {
front_end = "Software",
}that will set the renderer to the Software renderer unconditionally; it will have degraded performance and different visual characteristics that you'll remember from https://github.com/wez/wezterm/issues/235, but should at least keep running.
hgkamath
"Your Remote Desktop Services session has ended, possibly for one of the following reasons: The administrator has ended the session, an error occurred while the connection was being established, a network problem occurred."
For the time-being, I did not want to complicate the machine's settings so I undid the setting and did not troubleshoot what else I need to enable to get it working. Perhaps needs more prior research as to how many and what changes exactly to get RDP working that way. RDP worked on reboot after reverting gpedit setting.
prabirshrestha
github-actions[bot]
priority: important, affects usability
Describe the bug
Wezterm is started in a RDP session and is put into a left-tiled/right tiled or maximized state, the RDP session is disconnected. When the RDP session is subsequently reconnected, wezterm will have crashed. edit: The regular resizable window is also affected, but it will be in a frozen state, movable, alt-tab-able, until something triggers it to crash. This is perhaps caused by the 'screen resize adjustments'/'allocation of fresh screen' as the RDP session ends between remote and local machines Happens when Wezterm is started inside the RDP session, and not when wezterm is already started before the RDPsession. ergo, a workaround exists and is described later.
Use case: Using wezterm in an RDP session may be a common use case
Environment (please complete the following information):
RDP client version, C:\windows\system32\mstsc.exe Windows RDP client: 10.0.19041.423 (builtin) 8/12/2020
wezterm -Vwezterm 20200909-002054-4c9af461The RDP-remotemachine Machine2 has a resolution of 2160x1440 The RDP local machine Machine1 has a resolution of 1920x1080 No desktop dpi-scaling (desktop font scaling) in either machine (this is set in Settings/Display) Note that in my case, the wezterm started inside RDP discovers a larger screen-size upon disconnect.
To Reproduce
Steps to reproduce the behavior (1)
Steps to reproduce the behavior (2)
2020-09-12T19:14:30.770Z ERROR window::os::windows::wgl > failed to created extended OpenGL context (CreateContextAttribsARB failed), fall back to basicConfiguration
Nothing unusual
Expected behavior
Wezterm should handle RDP screen-size changes and more importantly never crash
Screenshots
NA
Session Recording
NA, can't do wt-record in windows
If the issue is with the way that escape sequences are processed it can be helpful to capture the terminal output using the
wt-recordscript to runweztermand record a transcript. This requires thescriptutility to be installed on your system (this is part of macOS and available in theutil-linuxpackage on linux systems).In the example below a file named
20180225161026.tgzis produced. Please attach that file to this issue, or if it contains private or sensitive issue that you don't want the public to see on GitHub, please find some other way to get that file to a project contributor (perhaps Dropbox or email?).You can use
wt-replay 20180225161026.tgzto replay that file.wt-recordcan only record the terminal output; it cannot record the input events going in to the terminal, so if you are having an issue with input, please be sure to describe it below!RUST_LOG
with set RUST_LOG=info
with set RUST_BACKTRACE=1
with set RUST_BACKTRACE=full (seems identical to previous)
When pre-starting wezterm, as mentioned in the workaround, that is running wezterm locally in direct login on Machine 2, tiling wezterm, and then from Machine1 trying RDP connect, disconnect, reconnect, no error log messages appear beyond the initial opengl init, and wezterm silently survives the reconnect.
I ran the the westerm exe, timing it with date commands. After disconnecting, I gave a 2 minute pause, in order to determine whether the crash happens at disconnect, reconnect/local-login. After reconnecting, I immediately, manually, gave the 3rd date command after RDP reconnection. The below log confirms that the crash happens at disconnect.
WGL_INFO
running wglinfo64.exe inside RDP session on Machine2 wglinfo_remote_in_RDP.txt running wglinfo64.exe on direct login on Machine2. Seems like no difference wglinfo_machine2_directlogin.txt wglinfo on machine 1 same as in bug #235 Possibly, depending on how RDP works, opengl on machine-1 may not matter to opengl process on machine-2.
Additional context
Add any other context about the problem here.
Misc
One wonders how wezterm might behave under other non-microsoft RDP clients. On Linux, Linux RDP clients, Remmina and Vinagre, allow more control over the RDP session inside the client-window. For example, the remote machine's RDP-session display-size is preconfigurable.
Workaround
Rather that starting wezterm inside the RDP-session, login locally on Machine2 and pre-start wezterm before remote-RDP-ing into it. Started that way, wezterm is resilient to the RDP disconnection,