Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Copy pasting from WSL to clipboard crashes the terminal and breaks copypaste system wide with very severe side effects #2807

Closed
Razumihin opened this issue Sep 19, 2019 · 11 comments · Fixed by #2927
Closed

Copy pasting from WSL to clipboard crashes the terminal and breaks copypaste system wide with very severe side effects #2807

Razumihin opened this issue Sep 19, 2019 · 11 comments · Fixed by #2927
Assignees
@carlos-zamora
Labels
Area-Interaction Interacting with the vintage console window (as opposed to driving via API or hooks) Area-Quality Stability, Performance, Etc. Issue-Bug It either shouldn't be doing this or needs an investigation. Needs-Attention The core contributors need to come back around and look at this ASAP. Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Product-Terminal The new Windows Terminal. Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release. Severity-Crash Crashes are real bad news.
Milestone
Terminal-1910

Comments

@Razumihin
Copy link

Environment

Windows version: 10.0.18362.0
Terminal version: 0.4.2382.0

ESET Endpoint Security Antivirus 7.1.2053.0
Razer Blade 2019 15" laptop with default drivers.

Steps to reproduce

Use WSL on the terminal and copy paste text back and forth from the terminal to other parts of the system. At some point the terminal will crash on copy.

Expected behavior

The string would be on the clipboard and windows would continue functioning properly.

Actual behavior

After the crash I'm fully unable to use Windows clipboard functionalities. Some places like explorer show both copy&paste disabled until restart but also clipboard actions from other software like vim are broken. At the same time radio boxes in Windows UI elements like installers stop working (wtf?) and some of the start menu shortcuts like windows+x also stop functioning until I restart the computer.

This seems rare, but I already reinstalled the system that I'm experiencing this on once, as I thought that some of the system files must be corrupt, but now I'm getting the same problem again. In both cases the first sign of trouble was the copy paste functionality of the terminal and everything else is fully working, so I think it might actually be related even though this seems very obscure.
@ghost ghost added Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Needs-Tag-Fix Doesn't match tag requirements labels Sep 19, 2019
@zadjii-msft
Copy link
Member

@carlos-zamora Is this the same as the other clipboard crash?

@Razumihin Razumihin changed the title Copy pasting from WSL to to clipboard crashes the terminal and breaks copypaste system wide with very severe side effects Copy pasting from WSL to clipboard crashes the terminal and breaks copypaste system wide with very severe side effects Sep 19, 2019
@carlos-zamora
Copy link
Member

@carlos-zamora Carlos Zamora FTE Is this the same as the other clipboard crash?

Sounds like it. Particularly the "both copy&paste disabled until restart" part. So, what is going on is that the clipboard stays open. Because it is "in use", no other application is suddently able to use it.

Just to be safe, mind submitting some additional feedback?

/feedback

@ghost
Copy link

ghost commented Sep 19, 2019

Hi there!

Can you please send us feedback with the Feedback Hub with this issue and paste the link here so we can more easily find your crash information on the back end?

Thanks!

image image

@ghost ghost added the Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something label Sep 19, 2019
@carlos-zamora carlos-zamora self-assigned this Sep 19, 2019
@carlos-zamora carlos-zamora added Area-Interaction Interacting with the vintage console window (as opposed to driving via API or hooks) Area-Quality Stability, Performance, Etc. Issue-Bug It either shouldn't be doing this or needs an investigation. Product-Terminal The new Windows Terminal. Severity-Crash Crashes are real bad news. and removed Needs-Tag-Fix Doesn't match tag requirements labels Sep 19, 2019
@carlos-zamora carlos-zamora added this to the Terminal-1910 milestone Sep 19, 2019
@Razumihin
Copy link
Author

Sorry about not having Feedback Hub link before, I had to do some work and the Feedback Hub UI is somewhat confusing. Here is a link for you anyway: https://aka.ms/AA63lsi

@ghost ghost added Needs-Attention The core contributors need to come back around and look at this ASAP. and removed Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something labels Sep 19, 2019
@DHowett-MSFT
Copy link
Contributor

Somebody remarked that this sounds like you're out of GDI handles. When this happens again, can you launch Task Manager, go to the Details tab, enable the "GDI objects" column and see what's taking up so many of them?

I bet it's not WT.

@DHowett-MSFT DHowett-MSFT added Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something and removed Needs-Attention The core contributors need to come back around and look at this ASAP. labels Sep 19, 2019
@Razumihin
Copy link
Author

I'll check for GDI objects next time. I'm not that optimistic about that being the reason, as I was not doing anything that would hog up GDI handles yesterday when this occurred.

@ghost ghost added Needs-Attention The core contributors need to come back around and look at this ASAP. and removed Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something labels Sep 20, 2019
@Razumihin
Copy link
Author

Okay, got it to crash again with the same symptoms. Most GDI objects were consumed by the task manager itself, so I don't think that's it.

image

DHowett-MSFT pushed a commit that referenced this issue Sep 27, 2019
@DHowett
teach wil about c++/winrt exceptions by including cppwinrt.h
c8f9bf8 
It turns out that if you CATCH_LOG without including this file, and you
end up catching a C++/WinRT hresult_exception, IT TURNS IT INTO A
FAILFAST.

Fixes #2591
Fixes #2881
Fixes #2807
@DHowett-MSFT DHowett-MSFT mentioned this issue Sep 27, 2019
Merged
5 tasks
@ghost ghost added the In-PR This issue has a related PR label Sep 27, 2019
@DHowett-MSFT DHowett-MSFT mentioned this issue Sep 27, 2019
Closed
DHowett-MSFT pushed a commit that referenced this issue Sep 30, 2019
@DHowett
teach wil about c++/winrt exceptions by including cppwinrt.h (#2927)
a2f8a94 
It turns out that if you CATCH_LOG without including this file, and you
end up catching a C++/WinRT hresult_exception, IT TURNS IT INTO A
FAILFAST.

Fixes #2591.
Fixes #2881.
Fixes #2807.
@ghost ghost added Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release. and removed In-PR This issue has a related PR labels Sep 30, 2019
DHowett-MSFT pushed a commit that referenced this issue Oct 3, 2019
@DHowett
teach wil about c++/winrt exceptions by including cppwinrt.h (#2927)
9461df9 
It turns out that if you CATCH_LOG without including this file, and you
end up catching a C++/WinRT hresult_exception, IT TURNS IT INTO A
FAILFAST.

Fixes #2591.
Fixes #2881.
Fixes #2807.
@ghost
Copy link

ghost commented Oct 4, 2019

🎉This issue was addressed in #2927, which has now been successfully released as Windows Terminal Preview v0.5.2762.0.:tada:

Handy links:

@torchesburn
Copy link

this still occurs!

@zadjii-msft
Copy link
Member

@torchesburn This original thread is over 3 years old now. If you're seeing something similar, I'd bet it's due to a different root cause. Mind filing a new issue, so we can follow up on the specifics of whatever you're seeing? Thanks!

@james1236
Copy link

All inside WSL, doing sudo apt-get remove xclip and then following the commands to install win32yank taken from here fixed it!

curl -sLo/tmp/win32yank.zip https://github.com/equalsraf/win32yank/releases/download/v0.0.4/win32yank-x64.zip
unzip -p /tmp/win32yank.zip win32yank.exe > /tmp/win32yank.exe
chmod +x /tmp/win32yank.exe
sudo mv /tmp/win32yank.exe /usr/local/bin/

Specifically for those using neovim, using the clipboard took about 500ms after this, so I had to set vim.opt.clipboard = "" in my config

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@carlos-zamora carlos-zamora

Labels
Area-Interaction Interacting with the vintage console window (as opposed to driving via API or hooks) Area-Quality Stability, Performance, Etc. Issue-Bug It either shouldn't be doing this or needs an investigation. Needs-Attention The core contributors need to come back around and look at this ASAP. Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Product-Terminal The new Windows Terminal. Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release. Severity-Crash Crashes are real bad news.
Projects
None yet
Milestone
Terminal-1910
Development

Successfully merging a pull request may close this issue.

teach wil about c++/winrt exceptions by including cppwinrt.h microsoft/terminal
6 participants
@carlos-zamora @Razumihin @DHowett-MSFT @zadjii-msft @james1236 @torchesburn