WAD More Windows 10 woes

[nikbackm]

1. Cannot close TCC:

a. Open TCMD
b. Detach one of the TCC tabs.
c. Execute "exit" command in the detached TCC window => window will not exit and remain frozen, exit command never returns.

It works without issues from a fresh TCC window that was never attached to TCMD and from a TCC tab still running inside TCMD.

2. Pasting (Ctrl+V as well as Paste from the menu) will both paste AND execute the pasted command. In TCMD15 (on Windows 7) it was only pasted and you could proceed to edit it. I guess this is due to the console changes/improvements in Windows 10?

EDIT: This only occurs when the pasted text includes a line break, so I guess that is expected behavior. HOWEVER, commands like "echo sometext > CLIP:" will apparently add this line break automatically so that the pasted "sometext" is automatically executed. That did not happen before (TCMD15 and Windows7). It does happen with TCMD15 and Windows 10 though, so maybe TCMD:s/TCC:s interaction with the Windows clipboard was somehow changed in Windows 10?

Both of these issues occur in TCMD15 as well as the newest TCMD18.

 

[rconn]

EDIT: This only occurs when the pasted text includes a line break, so I guess that is expected behavior. HOWEVER, commands like "echo sometext > CLIP:" will apparently add this line break automatically so that the pasted "sometext" is automatically executed. That did not happen before (TCMD15 and Windows7). It does happen with TCMD15 and Windows 10 though, so maybe TCMD:s/TCC:s interaction with the Windows clipboard was somehow changed in Windows 10?

WAD (and nothing to do with TCC). In Windows 7, the clipboard is stripping trailing CR/LF's; in Windows 10 it isn't. I don't think it's the job of the command processor to police the Windows clipboard.

If you don't want a trailing CR/LF, use ECHOS.

 

[rconn]

1. Cannot close TCC:

a. Open TCMD
b. Detach one of the TCC tabs.
c. Execute "exit" command in the detached TCC window => window will not exit and remain frozen, exit command never returns.

It works without issues from a fresh TCC window that was never attached to TCMD and from a TCC tab still running inside TCMD.

Windows 10 bug -- it won't close a console window if any other process had opened a handle to the console buffer (even when the handle had been closed) until all the processes have exited. Doubtful that I can do anything about it other than report it to Microsoft. TCC has actually closed & exited, but conhost is still holding the window open.

 

[nikbackm]

WAD (and nothing to do with TCC). In Windows 7, the clipboard is stripping trailing CR/LF's; in Windows 10 it isn't. I don't think it's the job of the command processor to police the Windows clipboard.

If you don't want a trailing CR/LF, use ECHOS.

Of course. Thank you!

It's not a big deal for me, I usually paste the echo:ed CLIP: text elsewhere, but good to know the cause.

Windows 10 bug -- it won't close a console window if any other process had opened a handle to the console buffer (even when the handle had been closed) until all the processes have exited. Doubtful that I can do anything about it other than report it to Microsoft. TCC has actually closed & exited, but conhost is still holding the window open.

Ah well, hopefully Microsoft will fix this in due time then. Again, not a big deal for me, I hardly ever detach windows, that's usually done only for testing, and you can always X these zombie windows after the partial exit anyway. Still, again, good to know why it happens.

 

[nikbackm]

Well, while this thread is still on top, any idea what causes the extra CPU use for TCC processes only waiting for input?

Pretty sure it's a Windows 10 issue as well, even if I currently have no access to a Windows 7 system for comparing.

It's easier to see the CPU use in Process Explorer, the Windows 10 Task Manager does not seem to show the 1-2% CPU use for the TCC processes, but when you
have 10 of them open it will show the system (Core 2 Duo) using about 20% CPU in total.

If you run the TCC processes standalone instead of in TCMD the CPU use will be a little lower, but still around the 15% range.

 

[rconn]

10 TCC tabs use a total of less than 0.1% here (Windows 10 x64 & TCMD v18.00.30).

TCMD has to have some overhead, as it is scanning the hidden TCC windows continuously looking for changes. But you'd need an abysmally slow system to see the kind of overhead you're reporting.

Are you running any plugins? Any third-party apps that are injecting themselves into TCC's address space? (I.e., screen managers and/or security apps.)

 

[nikbackm]

I don't use any TCC/TCMD plug-ins and I don't see any third-party DLLs in the stacks of the TCC threads taking CPU.
I only use the security software that is included with Windows 10.

Software that might (just guessing here) perhaps have an effect is Apple (ituneshelper, ipodservice etc.) and itype.exe for Microsoft's keyboard.

TCC 15 stacks:

The first takes 1.6 - 1.8% CPU and the second 0.05 - 0.10%. The first one also differs from time to time a bit, I included a few others in the other visible CPU thread here on this forum.

ntdll.dll!ZwDelayExecution+0xa
KERNELBASE.dll!SleepEx+0xa7
TakeCmd.dll!AllocDup+0x48b
KERNEL32.DLL!BaseThreadInitThunk+0x22
ntdll.dll!RtlUserThreadStart+0x34

ntdll.dll!ZwDelayExecution+0xa
KERNELBASE.dll!SleepEx+0xa7
TakeCmd.dll!EatKeystrokes+0x8aa
TakeCmd.dll!egets+0x3bb
TakeCmd.dll!GetLine+0x6a
TCC.EXE!RegU+0x14ac
TCC.EXE!RegU+0x5330
KERNEL32.DLL!BaseThreadInitThunk+0x22
ntdll.dll!RtlUserThreadStart+0x34

TCC 18 (unreg) stacks:

CPU use about the same as for TCC 15.

KERNELBASE.dll!BaseGetNamedObjectDirectory+0x3
KERNELBASE.dll!BaseFormatObjectAttributes+0x54
KERNELBASE.dll!CreateSemaphoreExW+0x42
KERNELBASE.dll!CreateSemaphoreW+0x16
TakeCmd.dll!CompressNTFS+0x13f
TakeCmd.dll!AllocDup+0x558
KERNEL32.DLL!BaseThreadInitThunk+0x22
ntdll.dll!RtlUserThreadStart+0x34

ntdll.dll!ZwDelayExecution+0xa
KERNELBASE.dll!SleepEx+0xa7
TakeCmd.dll!EatKeystrokes+0x8b6
TakeCmd.dll!egets+0x45c
TakeCmd.dll!GetNextLine+0xa7
TCC.EXE!RegU+0x23cb
TCC.EXE!RegU+0x7230
KERNEL32.DLL!BaseThreadInitThunk+0x22
ntdll.dll!RtlUserThreadStart+0x34

TCMD itself also takes more CPU than I think it should with a single active TCC tab. About 0.6% CPU for TCMD15 and 0.8% CPU for TCMD18.

TCMD 15 stack:

tcmd.exe!ErrorMsgBox+0xea70
tcmd.exe!CallHtmlHelp+0x39c96
tcmd.exe!CallHtmlHelp+0x47f77
tcmd.exe!CallHtmlHelp+0x4801c
tcmd.exe!CallHtmlHelp+0x48876
tcmd.exe!CallHtmlHelp+0x309a4d
tcmd.exe!CallHtmlHelp+0x1c2fd4
KERNEL32.DLL!BaseThreadInitThunk+0x22
ntdll.dll!RtlUserThreadStart+0x34


TCMD 18 stack:

tcmd.exe!CPUUsage+0x53605
tcmd.exe!CPUUsage+0x421d1
tcmd.exe!CPUUsage+0x45d85
tcmd.exe!CPUUsage+0x52827
tcmd.exe!CPUUsage+0x528cc
tcmd.exe!CPUUsage+0x53102
tcmd.exe!CPUUsage+0x339add
tcmd.exe!CPUUsage+0x1d068c
KERNEL32.DLL!BaseThreadInitThunk+0x22
ntdll.dll!RtlUserThreadStart+0x34

Also, the associated conhost.exe process for each TCC process uses about 0.10% CPU.
That is for TCC tabs, for independent TCC windows it's down to 0.07%, while the conhost.exe for
separate cmd.exe windows is <0.01%.

All CPU measurements according to Process Explorer.

 

[rconn]

TCC will take 0% CPU when it's sitting at a prompt, because it's inside a Windows API waiting for input. If you see anything more than 0, then you've got something else hooking the process (or API) and eating CPU. (Or conhost is doing random unknowable things.)

TCMD will use a little CPU, because that's what it has to do in order to update the tab windows. It's a highly tuned display engine, and there is nowhere to make any measurable improvements. (I know, as I've had years to tweak it.) The display engine is identical in v15 and v18; if you're seeing a difference then you've got a different environment in the two processes, or you're getting invalid results from whatever is measuring CPU usage. (Not unusual, particularly with multiple cores.)

If < 1% CPU is too much for you, you can try one of the (slower) alternatives.

 

[nikbackm]

TCC will take 0% CPU when it's sitting at a prompt, because it's inside a Windows API waiting for input. If you see anything more than 0, then you've got something else hooking the process (or API) and eating CPU. (Or conhost is doing random unknowable things.)

I booted the system in Safe Mode as well, with the same results, TCC still eating CPU, both when in TCMD and when standalone.

And the stack using CPU looks to be a JP Software DLL (TakeCmd.dll) calling a function there (AllocDup).
Sometimes the CompressNTFS function from TakeCmd.dll is also included in that stack. Might be a clue?

Assuming you can trust the stack and thread listings from Process Explorer, corrupted stacks and such might perhaps make listings unreliable.
Nevertheless, since starting more and more TCC process clearly increase the overall CPU usage rather quickly, something is going on there at least.

Below is a listing of all DLLs loaded into the TCC (v15) process, looks to be only Windows and JP Software DLLs.

------------------------------------------------------------------------------
tcc.exe pid: 416
Command line: "C:\Program Files\JP Software\Take Command x64 15.0\TCC.EXE"

Base                Size      Path
0x0000000000400000  0x42000   C:\Program Files\JP Software\Take Command x64 15.0\TCC.EXE
0x00000000b14a0000  0x1c1000  C:\WINDOWS\SYSTEM32\ntdll.dll
0x0000000000100000  0xad000   C:\WINDOWS\system32\KERNEL32.DLL
0x00000000001b0000  0x1dd000  C:\WINDOWS\system32\KERNELBASE.dll
0x0000000002b50000  0x14e000  C:\WINDOWS\system32\USER32.dll
0x0000000003fc0000  0x186000  C:\WINDOWS\system32\GDI32.dll
0x0000000004150000  0x18a000  C:\WINDOWS\SYSTEM32\dbghelp.dll
0x00000000042e0000  0xa6000   C:\WINDOWS\system32\ADVAPI32.dll
0x0000000004390000  0x9d000   C:\WINDOWS\system32\msvcrt.dll
0x0000000000080000  0x5b000   C:\WINDOWS\system32\sechost.dll
0x0000000004430000  0x126000  C:\WINDOWS\system32\RPCRT4.dll
0x0000000010000000  0x2aa000  C:\Program Files\JP Software\Take Command x64 15.0\TakeCmd.dll
0x0000000004560000  0x1522000  C:\WINDOWS\system32\SHELL32.dll
0x0000000005a90000  0x1ee000  C:\Program Files\JP Software\Take Command x64 15.0\ipworks9.dll
0x0000000000390000  0x69000   C:\WINDOWS\system32\WS2_32.dll
0x0000000005c80000  0x8000    C:\WINDOWS\system32\NSI.dll
0x0000000005c90000  0xbe000   C:\WINDOWS\system32\OLEAUT32.dll
0x0000000005d50000  0x27c000  C:\WINDOWS\system32\combase.dll
0x0000000005fd0000  0x141000  C:\WINDOWS\system32\ole32.dll
0x0000000006220000  0x51000   C:\WINDOWS\system32\SHLWAPI.dll
0x0000000006280000  0x8000    C:\WINDOWS\system32\PSAPI.DLL
0x0000000006290000  0xd7000   C:\WINDOWS\system32\COMDLG32.dll
0x0000000006370000  0xb3000   C:\WINDOWS\system32\shcore.dll
0x0000000006430000  0x23000   C:\WINDOWS\SYSTEM32\WINMM.dll
0x0000000006460000  0x274000  C:\WINDOWS\WinSxS\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.10240.16384_none
_f41f7b285750ef43\COMCTL32.dll
0x00000000066e0000  0x9000    C:\WINDOWS\SYSTEM32\WSOCK32.dll
0x00000000066f0000  0x1f7000  C:\Program Files\JP Software\Take Command x64 15.0\ipworksssl9.dll
0x00000000068f0000  0xdc000   C:\Program Files\JP Software\Take Command x64 15.0\ipworksssh9.dll
0x00000000069d0000  0x15e000  C:\Program Files\JP Software\Take Command x64 15.0\ipworkszip9.dll
0x00000000718b0000  0x55000   C:\Program Files\JP Software\Take Command x64 15.0\onig.dll
0x0000000071890000  0x1e000   C:\Program Files\JP Software\Take Command x64 15.0\Everything.dll
0x0000000006b30000  0x84000   C:\WINDOWS\SYSTEM32\WINSPOOL.DRV
0x0000000006bd0000  0x2c000   C:\WINDOWS\SYSTEM32\WINMMBASE.dll
0x0000000006c00000  0x44000   C:\WINDOWS\system32\cfgmgr32.dll
0x0000000006c50000  0x28000   C:\WINDOWS\SYSTEM32\bcrypt.dll
0x0000000006c80000  0x27000   C:\WINDOWS\SYSTEM32\DEVOBJ.dll
0x0000000006cb0000  0x629000  C:\WINDOWS\system32\windows.storage.dll
0x00000000072e0000  0xf000    C:\WINDOWS\system32\kernel.appcore.dll
0x00000000072f0000  0x4a000   C:\WINDOWS\system32\powrprof.dll
0x0000000007340000  0x13000   C:\WINDOWS\system32\profapi.dll
0x0000000007370000  0x36000   C:\WINDOWS\system32\IMM32.DLL
0x0000000007550000  0x15c000  C:\WINDOWS\system32\MSCTF.dll
0x0000000008c80000  0x17000   C:\WINDOWS\SYSTEM32\netapi32.dll
0x0000000008ca0000  0x16000   C:\WINDOWS\SYSTEM32\wkscli.dll
0x0000000008cc0000  0x26000   C:\WINDOWS\SYSTEM32\srvcli.dll
0x0000000008cf0000  0xc000    C:\WINDOWS\SYSTEM32\netutils.dll
0x0000000008d00000  0x3e000   C:\WINDOWS\SYSTEM32\LOGONCLI.DLL
0x0000000008e40000  0x1c1000  C:\WINDOWS\system32\crypt32.dll
0x0000000008d40000  0x11000   C:\WINDOWS\system32\MSASN1.dll
0x0000000008d60000  0x4c000   C:\WINDOWS\SYSTEM32\qwave.dll
0x0000000008db0000  0xf000    C:\WINDOWS\SYSTEM32\TRAFFIC.dll
0x0000000008dc0000  0x38000   C:\WINDOWS\SYSTEM32\IPHLPAPI.DLL
0x0000000008e00000  0x11000   C:\WINDOWS\SYSTEM32\WMICLNT.dll
0x0000000008e20000  0xb000    C:\WINDOWS\SYSTEM32\WINNSI.DLL
0x0000000009030000  0xc000    C:\WINDOWS\SYSTEM32\secur32.dll
0x0000000009040000  0x2c000   C:\WINDOWS\SYSTEM32\SSPICLI.DLL
0x0000000009070000  0x3000    C:\WINDOWS\SYSTEM32\icmp.dll
0x0000000009200000  0x2a7000  C:\WINDOWS\SYSTEM32\wininet.dll
0x00000000094b0000  0x96000   C:\WINDOWS\system32\uxtheme.dll
0x0000000009110000  0x22000   C:\WINDOWS\system32\dwmapi.dll
0x0000000009cb0000  0x6b000   C:\WINDOWS\SYSTEM32\bcryptPrimitives.dll
0x0000000010380000  0x99000   C:\Program Files\JP Software\Take Command x64 15.0\English.dll
0x0000000010420000  0x63000   C:\Program Files\JP Software\Take Command x64 15.0\EnglishD.dll
0x0000000009140000  0x17000   C:\WINDOWS\SYSTEM32\CRYPTSP.dll
0x00000000091a0000  0x33000   C:\WINDOWS\system32\rsaenh.dll
0x0000000009160000  0x1f000   C:\WINDOWS\SYSTEM32\USERENV.dll
0x0000000009180000  0xa000    C:\WINDOWS\SYSTEM32\DPAPI.dll
0x00000000091e0000  0xb000    C:\WINDOWS\SYSTEM32\CRYPTBASE.dll
0x000000000c5a0000  0xa5000   C:\WINDOWS\system32\clbcatq.dll
0x000000000c680000  0x132000  C:\Program Files\JPSoft\TCMD18_x64\IsLicense50.dll
0x000000000c7d0000  0x69000   C:\WINDOWS\SYSTEM32\OLEACC.dll
0x000000000c910000  0x18000   C:\WINDOWS\SYSTEM32\SAMCLI.DLL
0x000000000c930000  0x1c000   C:\WINDOWS\SYSTEM32\SAMLIB.dll
0x0000000001830000  0x78000   C:\WINDOWS\system32\apphelp.dll

TCMD will use a little CPU, because that's what it has to do in order to update the tab windows. It's a highly tuned display engine, and there is nowhere to make any measurable improvements. (I know, as I've had years to tweak it.) The display engine is identical in v15 and v18; if you're seeing a difference then you've got a different environment in the two processes, or you're getting invalid results from whatever is measuring CPU usage. (Not unusual, particularly with multiple cores.)

If < 1% CPU is too much for you, you can try one of the (slower) alternatives.

TCMD CPU usage is a lesser issue, since there will only be one instance of that, I just thought it might perhaps be related, since close to 1%
for a single TCC tab seemed a bit much, and the function called in the thread taking the CPU (CallHtmlHelp on v15 and CPUUsage on v18) seemed
to be unrelated to updating the tabs to me.