Clipboard is locked for 10s when copying clipboard data

[AloisKraus]

When a WPF application tries to update the clipboard all running vtm instances listen to WM_CLIPBOARDUPDATE

 while (!::OpenClipboard(hwnd)) // Waiting clipboard access.
 {
      if (os::error() != ERROR_ACCESS_DENIED)
      {
               auto error = utf::concat("::OpenClipboard()", os::unexpected, " code ", os::error());
               sync(error, mime::textonly);
               return (LRESULT) NULL;
      }
      std::this_thread::yield();
}

This can cause races when multiple vtm instances are running resulting in hundreds of thousands of context switches. The bad thing is that WPF has also retry mechanism to open the clipboard so you are locking each other out.
Instead of
std::this_thread::yield();

a Thread sleep for 15ms would be much better to give everyone a chance. Why 15ms? Because the default clock tick rate is 15ms to conserve energy. You are waiting anyway for 15ms even if you sleep just for 1ms.

[o-sdn-o]

Thanks for pointing out this flaw. I'll add the required timeout.

[o-sdn-o]

I fixed the waiting for the clipboard as you suggested. Could you please check how it works.

[Alois-xx]

Sure will do

[Alois-xx]

There seem to be default configs missing.
I have not configured anything and then it comes up like this

[o-sdn-o]

This is something very strange, vtm itself does not create such windows. I can not reproduce such behavior yet. Something additionally starts during launching C:\WINDOWS\System32\cmd.exe. I need to investigate this further.

[AloisKraus]

Last good version was v0.9.74. Later ones either crash or show that distored window.

[o-sdn-o]

Could you check the properties (who owns it?) of this strange window using C:\Program Files\Microsoft Visual Studio\2022\Community\Common7\Tools\spyxx.exe (Ctrl+W to show Process List Window) (https://learn.microsoft.com/en-us/visualstudio/debugger/introducing-spy-increment?view=vs-2022)?

[AloisKraus]

It is a top level window which seesm to be somehow distorted:

[AloisKraus]

The process list looks like this:

Process wise it looks like this:

[o-sdn-o]

There may be some inconsistencies with vtm in Windows 11. I'll play with Windows 11 in this direction. I need time, since my working setup is still Windows 10.

[Alois-xx]

I also have Windows 10 where it looks the same. I have two security engines running but neither one seems to inject dlls into vtm. I do not want to rule out any security software blocking things now.

[Alois-xx]

In procmon I get one invalid device request, but I am not sure if that is related:

[o-sdn-o]

vtm is a console server itself and conhost.exe is not involved in starting vtm's child console processes.

[o-sdn-o]

Last good version was v0.9.74. Later ones either crash...

One possible cause of the crashes could be unsynchronized multithreaded access to the configuration instance by the vtm GUI window and the vtm TUI manager. I tried to fix it in v0.9.99.23.

[o-sdn-o]

I have not configured anything and then it comes up like this (distored window)

Is it possible that something starts with cmd.exe using the autorun registry setting HKCU\Software\Microsoft\Command Processor\AutoRun?

Something like

reg add "HKCU\Software\Microsoft\Command Processor" /v AutoRun /t REG_EXPAND_SZ /d "calc.exe" /f

[o-sdn-o]

There seem to be default configs missing.
I have not configured anything and then it comes up like this

I found some clues with this weird window. It seems to be a window from OneNote, but it is unknown how it is activated when vtm is launched.

[AloisKraus]

I have not configured anything and then it comes up like this (distored window)

Is it possible that something starts with cmd.exe using the autorun registry setting HKCU\Software\Microsoft\Command Processor\AutoRun?

Something like

reg add "HKCU\Software\Microsoft\Command Processor" /v AutoRun /t REG_EXPAND_SZ /d "calc.exe" /f

No there is no such registry key there. The strange window might be an update issue.
It would be good if you provide pdbs for your builds so one can debug what is happening.
Without symbols one would need to rebuild everything and debug on its own.

[o-sdn-o]

I'll add pdb’s to release builds.

[o-sdn-o]

I added pdb's for releases (vtm_pdb_windows_*.zip) starting from v0.9.99.24.

[o-sdn-o]

I added a random delay (150 to 650 ms) to the clipboard sync to mitigate conflicts with other applications and to reduce alerts like this:

[Alois-xx]

I added a random delay (150 to 650 ms) to the clipboard sync to mitigate conflicts with other applications and to reduce alerts like this:

Yes that is a good addition. I think the main problem is that vtm -r cmd is broken. It always creates a new window.
If you start a new Windows Terminal Window and the type inside vtm -r cmd.exe it will create a new window which is not what I need to get a scroll bar inside Windows Terminal.

[o-sdn-o]

It always creates a new window.

Perhaps you can specify vtm --tui --run cmd/vtm -t -r cmd to run inside an existing terminal.

I made the vtm default mode graphical (vtm -g) because so far few (actually no one yet) terminals support character geometry.

[AloisKraus]

When I do this I do not get

vtm --tui --run cmd

vtm -t -r cmd

This way I do no longer get scrollbars in Windows Terminal which is my main reason to use vtm.

[o-sdn-o]

vtm --tui --run cmd runs raw console (teletype). This is short for vtm --tui --run vtty cmd.

vtm --tui --run term cmd runs terminal console with extra UI (with window menu containing Wrap button etc).

[AloisKraus]

ahh this was a change. I see you already did update

microsoft/terminal#1860

I will update accordingly.

[AloisKraus]

This command line in Windows Terminal works now:

"C:\Users\..\vtm.exe" -c %userprofile%\.config\config.xml --tui --run term cmd

Thanks for the patience! I was not aware of the change of the command line switch.