Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

CPU Usage

M

Mark S

Feb
8
0
I am running Take Command/TCC 13.03.41 on Windows 7 x64 inside a VMWare Workstation VM. As I open for TCC instances inside Take Command CPU utilization goes up. Each TCC instance takes around 3% or 4% with each corresponding conhost taking another 1% to 2%. Take Command's CPU utilization starts around 2% with one instance and will be up to about 10% by the time I have 5 or 6 instances open, so the total CPU usage will got from about 5% to 8% with nothing but process explorer running. When I open Take Command with 6 TCC instances CPU usage goes to about 55%. This is with everything idle.

According to Process Explorer:
* the thread taking the CPU in TCC shows TakeCmd.dll!?AllocDup@@YGPA_WPA_W@Z+0x1c8
* the thread taking the CPU in Take Command show tcmd.exe!?CallHtmlHelp@@YGHPA_W@Z+0x131a57
Is there any other info that would help?
 
TCC wll use 0% CPU when it's sitting at a prompt, because it's inside a Windows API waiting for a key to be pressed.

Take Command might use 1-3% per TCC instance (particularly on an especially slow system or a VM maimed by memory & cpu limitations), because Take Command has to continually scan the hidden console windows in order to update the TCMD tab windows. (There is no way around that.)

If you see some CPU time being used by a stand-alone TCC session that is sitting at the prompt, you've got some other app that's injected a dll into TCC's address space and that is doing something (not unusual for antivirus & screen manager apps).
 
It is in a VM, but I have made sure the VM has plenty of memory. Virus scan is disabled. Here'e the call stack from the thread in the TCC instance that is taking the CPU time:
ntoskrnl.exe!memset+0x64a
ntoskrnl.exe!ExfReleasePushLock+0x8ec
ntoskrnl.exe!__misaligned_access+0x331
ntoskrnl.exe!__misaligned_access+0x17e7
ntoskrnl.exe!KeWaitForMultipleObjects+0xf5d
ntoskrnl.exe!KeDelayExecutionThread+0x186
ntoskrnl.exe!NtWaitForSingleObject+0x16e
ntoskrnl.exe!KeSynchronizeExecution+0x3a43
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x6c0
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x56b
wow64.dll!Wow64SystemServiceEx+0x1ce
wow64.dll!Wow64LdrpInitialize+0x429
ntdll.dll!RtlIsDosDeviceName_U+0x24c87
ntdll.dll!LdrInitializeThunk+0xe
ntdll.dll!ZwDelayExecution+0x15
KERNELBASE.dll!Sleep+0xf
TakeCmd.dll!?AllocDup@@YGPA_WPA_W@Z+0x1c8
There are four thread and none of the other stacks have any third party DLLs either. Here's the stack from the thread in Take Command that is using the CPU:
ntoskrnl.exe!memset+0x64a
ntoskrnl.exe!ExfReleasePushLock+0x8ec
ntoskrnl.exe!__misaligned_access+0x331
ntoskrnl.exe!__misaligned_access+0x17e7
ntoskrnl.exe!KeWaitForMultipleObjects+0xf5d
ntoskrnl.exe!KeWaitForMutexObject+0x19f
win32k.sys!memset+0x7ac7
win32k.sys!memset+0x7b69
win32k.sys!memset+0x61a0
win32k.sys!memset+0x62a5
win32k.sys!memset+0x7c95
ntoskrnl.exe!KeSynchronizeExecution+0x3a43
wow64win.dll+0x3fe3a
wow64win.dll+0x1aea8
wow64.dll!Wow64SystemServiceEx+0xd7
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x2d
wow64.dll!Wow64SystemServiceEx+0x1ce
wow64.dll!Wow64LdrpInitialize+0x429
ntdll.dll!RtlUniform+0x6e6
ntdll.dll!RtlCreateTagHeap+0xa7
ntdll.dll!LdrInitializeThunk+0xe
USER32.dll!DispatchMessageW+0x5c
tcmd.exe!?CallHtmlHelp@@YGHPA_W@Z+0x3cd03
tcmd.exe!?CallHtmlHelp@@YGHPA_W@Z+0x2557cd
tcmd.exe!?CallHtmlHelp@@YGHPA_W@Z+0x131a57
ntdll.dll!RtlInitializeExceptionChain+0x63
ntdll.dll!RtlInitializeExceptionChain+0x36
According to Process Explorer:
* VM:
* 1.2 GB to System Commit
* 1.4 GB Physical Memory used.
* 2 GB Memory total
* Host:
* 5.6 GB to System Commit
* 6.5 GB Physical Memory used
* 8 GB Memory total
* CPU utilization is around 50% with ~20% of that from this VM

I just tried on the host and each TCC instance take 1.5% to 2% and Take Command takes about 4%. Again, this is with the prompts just sitting there.

Is there anything else I could look at or try?

Thank you for looking at this.

Mark
 
Your stack trace is showing Windows doing *something* when it's supposed to be doing nothing. What VM software are you using?

I just built a 2Gb VM running Windows 7 and VMWare Fusion, started TCMD, and loaded 6 TCC tab windows. Total CPU usage after everything loaded averages about 4%.

Have you tried a stand-alone TCC window, or running TCMD in Windows (not in a VM)?
 
I am using VMWare Workstation 7.1. Both the host and guest are Windows 7 x64.

When I run TCMD on the Host I still get some CPU usage but not as much. Each TCC instance uses around 2% with TCMD using about 4%.

Running TCC (not LE) stand alone, also showed the ~4% CPU usage each.

One thing I thought of that may make a difference (though I don't know how) is I am running TCMD elevated, though I ran TCC stand alone normal and not elevated.

On a different VM running under VMWare ESXi (not workstation), Multiple instances of TCC LE are around .1% each, which is what I expected.

Also, I am getting different numbers from Process Explorer (from sysinternals.com) and task manager. Apparently TaskMan doesn't show everything that uses the CPU while ProcExp does. I tend to believe ProcExp because my builds take longer when I have many TCC tabs open. This is how I noticed this.

Thank you for your time,
Mark
 
Mark S said:
Running TCC (not LE) stand alone, also showed the ~4% CPU usage each.
Click to expand...

Something in your system is hooking the TCC process; it is simply impossible for TCC itself to be using any CPU when it's sitting at the prompt. (TCC is sitting in a Windows WaitForSingleObject API call -- Windows *might* use ~.001% CPU periodically checking the keyboard state, but only if you've got the worst keyboard driver ever!) At a minimum, I suspect ProcExp itself is going to be injecting code. Do you see any CPU usage when running CMD.EXE?

Do you have any plugins loaded in TCC?
[/quote]
 
Mark S said:
I am using VMWare Workstation 7.1. Both the host and guest are Windows 7 x64.
Click to expand...

I'm 99% sure that you either have an unsuspected app hooking the rest of your system, or there's a bug in VMWare. (The fact that each conhost is eating up 1-2% is pretty conclusive evidence that it's not TCC related.)

I put a test build on the ftp site at ftp.jpsoft.com/beta/tcmdx64.exe. Try downloading that and let me know if the CPU usage changes.
 
CMD.EXE has 0 CPU usage at idle as does the associated conhost.exe. I have fractional values turned on and I still get 0% usage.

I hadn't installed 64 bit TCMD so I installed the currently released version and verified I got the same behavior. Then I installed the beta from your FTP site and also got the same behavior.

If there are plugins loaded in TCC, they came with the main installer. I have not installed anything else.

Looking through the call stacks in ProcExp I didn't see any non-windows DLL.

Let me know what else I can try.

Thanks,
Mark
 
Thanks; that eliminates one possibility.

I've uploaded another beta build (13.03.43) to ftp.jpsoft.com/beta/tcmdx64.exe; download and install that and let me know if the CPU usage changes.

If it is still showing any CPU usage, let me know what the stack looks like (I replaced the Windows API calls that are broken on your system with an alternate set).
 
Here's a call stack from the thread inTCC that shows any CPU usage:
ntoskrnl.exe!memset+0x64a
ntoskrnl.exe!ExfReleasePushLock+0x8ec
ntoskrnl.exe!_misaligned_access+0x331
ntoskrnl.exe!_misaligned_access+0x17e7
ntoskrnl.exe!_misaligned_access+0x1a97
ntoskrnl.exe!KeSynchronizeExecution+0x3a88
ntdll.dll!ZwCreateSemaphore+0xa
KERNELBASE.dll!CreateSemaphoreExW+0x5a
kernel32.dll!CreateSemaphoreW+0x19
TakeCmd.dll!AllocDup+0x4b4
kernel32.dll!BaseThreadInitThunk+0xd
ntdll.dll!RtlUserThreadStart+0x21
I see something about misiligned access. So if it matters, I have a Intel Core 2 6600.

Here's the thread in TCMD that's using the CPU:
ntoskrnl.exe!memset+0x64a
ntoskrnl.exe!ExfReleasePushLock+0x8ec
ntoskrnl.exe!_misaligned_access+0x331
ntoskrnl.exe!_misaligned_access+0x17e7
ntoskrnl.exe!KeWaitForMultipleObjects+0xf5d
ntoskrnl.exe!KeWaitForSingleObject+0x19f
win32k.sys!memset+0x7ac7
win32k.sys!memset+0x7b69
win32k.sys!memset+0x61a0
win32k.sys!memset+0x62a5
win32k.sys!memset+0x7c95
ntoskrnl.exe!KeSynchronizeExecution+0x3a43
USER32.dll!SfmDxSetSwapChainStats+0x1a
USER32.dll!GetMessageW+0x2a
tcmd.exe!CallHtmlHelp+0x49df0
tcmd.exe!CallHtmlHelp+0x499f7
tcmd.exe!CallHtmlHelp+0x2d6c9b
tcmd.exe!CallHtmlHelp+0x18f924
kernel32.dll!BaseThreadInitThunk+0xd
ntdll.dll!RtlUserThreadStart+0x21
Here I see the _misaligned_access as well but also see something about CallHtmlHelp? I'm not doing anything and all the prompts are just sitting there.

Thanks,
Mark
 
Something is seriously awry with your system -- there is definitely no call to CallHtmlHelp() anywhere in TCMD unless you explicitly invoke the help. (And the only place that can be done in TCMD is from the menu or with F1 while in a TCMD dialog.)

And in TCC, there is definitely never any call to AllocDup or CreateSemaphore while it's sitting at the prompt.

Is that stack with 13.03.43? And if so, what was the CPU usage?
 
Yes, that is with 13.03.43 and the usage was about the same: 3-4% per TCC and with 6 TCC's open, TCMD was 8-10%

Where is TCMD.INI? I don't see it next to TCMD.EXE.

I will go through other installed applications and see if any look suspicious and uninstall them.

Thanks,
Mark
 
One more thing to try -- I'd really like to know just who is calling CallHtmlHelp (and why!). I uploaded a test build of takecmd.dll; download that and copy it over your existing takecmd.dll. It will pop up a message box if anyone calls CallHtmlHelp, and display the requested topic.

(Also, I presume you're not using the PRE_INPUT alias to do something tedious?)
 
Looking at the stack traces a bit closer, I don't think CallHtmlHelp is the culprit. If you look at one of the offsets, unless CallHtmlHelp compiles to > 2MB, this call is not in CallHtmlHelp. I don't have access to the map files, but I will email support a Dependency Walker Profile log that has everything that loaded and at what address when TCMD ran. If you can figure out from that what DLL is being called there, that will help track down the culprit.

I am not using PRE_INPUT or any other aliased in 64 bit. I do have some aliases in 32 bit but none of them use PRE_INPUT.

-Mark
 
rconn, what does it mean when Process Explorer tells me tcc.exe is taking ~0.42 % of CPU usage while cmd.exe takes "" (= 0 %) and 4NT takes 0.02 %?

You mentioned that hidden console windows need to be continually scanned. Can this be disabled? Even small usage results in lots of heat waste on my computer...
 
distill said:
rconn, what does it mean when Process Explorer tells me tcc.exe is taking ~0.42 % of CPU usage while cmd.exe takes "" (= 0 %) and 4NT takes 0.02 %?

You mentioned that hidden console windows need to be continually scanned. Can this be disabled? Even small usage results in lots of heat waste on my computer...
Click to expand...

The only way to disable this would be to turn off TCMD. If it can't scan the hidden console windows, it can't display their output, so there's no reason to run it.
 
rconn said:
The only way to disable this would be to turn off TCMD. If it can't scan the hidden console windows, it can't display their output, so there's no reason to run it.
Click to expand...
I'm sorry, but what do you mean by turning off TCMD? I use only the tcc.exe console and not TCMD. I tried renaming tcmd.exe to something else but that didn't make a difference.
 
distill said:
I'm sorry, but what do you mean by turning off TCMD? I use only the tcc.exe console and not TCMD. I tried renaming tcmd.exe to something else but that didn't make a difference.
Click to expand...

If you're not running Take Command, then it isn't scanning your console buffers.
 
distill said:
How much CPU is tcc.exe (solely) supposed to use when open but idle?
Click to expand...
Virtually none. Here's TCC and it's associated CONHOST.EXE after 7+ minutes.
Code: 
v:\> pstat
PID:  3520
Module:  g:\tc17\tcc.exe
Started:  2015-04-12 16:47:43
Running:  7 minutes 41 seconds
User CPU:  0.0312002 sec
Kernel CPU:  0.0780005 sec
Total CPU:  0.1092007 sec (0.02%)
Working Set:  15520 KB
Virtual Mem:  17236 KB
Priority class: NORMAL


v:\> pstat 2712
PID:  2712
Module:  C:\Windows\system32\conhost.exe
Started:  2015-04-12 16:47:43
Running:  7 minutes 44 seconds
User CPU:  0.0312002 sec
Kernel CPU:  0.0624004 sec
Total CPU:  0.0936006 sec (0.02%)
Working Set:  6852 KB
Virtual Mem:  3368 KB
Priority class: NORMAL
 
And here's TCMD after 10 (mostly idle) minutes, hosting 5 (mostly idle) TCCs.
Code: 
v:\> pstat 1860
PID:  1860
Module:  G:\TC17\tcmd.exe
Started:  2015-04-12 19:55:09
Running:  10 minutes 8 seconds
User CPU:  0.4368028 sec
Kernel CPU:  0.3276021 sec
Total CPU:  0.7644049 sec (0.13%)
Working Set:  21664 KB
Virtual Mem:  17012 KB
Priority class: NORMAL
 
I don't get it. I have now tried the SYSUTILS plugin pstat, ProcessExplorer and Windows Task Manager CPU Usage on two different computers and two different versions of tcc.exe. I get much more than 0.13 % or 0.02 % and my computers are quite fast (i7-3930K). My results:

tcc.exe (v16 and v17.00.77) = pstat ~2.00–5.00 %, ProcessExplorer ~0.5 %, Task Manager 0 or 1 % (no decimals shown). Tried after 0 and after 10 min.

As mentioned, at the same time 4NT is nearly 0.00 %.

I tried a clean install on a quite new installation of Windows, so it is unlikely that I have installed anything that should interfere with this. Why is the usage so high on idle?
 
Hijacking this thread since the subject is still relevant.

I get about 2% constant CPU usage for all TCC instances, both standalone and running inside Take Command.

Stack traces for the relevant thread:

ntdll.dll!SbSelectProcedure+0xb0
KERNELBASE.dll!CloseHandle+0x32
TakeCmd.dll!AllocDup+0x7f9
KERNEL32.DLL!BaseThreadInitThunk+0x22
ntdll.dll!RtlUserThreadStart+0x34

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


I still use TCC/TCMD 15.00.34, but I did upgrade from Windows 7 to Windows 10 a few days ago, might that have been a cause?
Not sure that this did not occur with W7 as well though, maybe I just paid more attention due to the W10 upgrade.

Just downloaded the 18.00.29 x64 trial version as well, it has the same behavior. The stack trace is a bit different though.

KERNELBASE.dll!BaseGetNamedObjectDirectory+0xb2
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

But if varies depending on when you use Process Explorer to "take" it of course.
 
Last edited:
Also, TCMD displays higher than normal CPU usage as well, on both v15 and v18. About 0,5 - 0.7 % with a single TCC tab, a little higher on v18 than on v15.

Call stack on v18:
tcmd.exe!CPUUsage+0x3ffcb
tcmd.exe!CPUUsage+0x40b50
USER32.dll!DispatchMessageW+0x68c
USER32.dll!SendMessageW+0x395
USER32.dll!SendMessageW+0xfb
tcmd.exe!CPUUsage+0x3a9cd
tcmd.exe!CPUUsage+0x3b7a1
tcmd.exe!RegU+0x19153
tcmd.exe!CPUUsage+0x45ec2
tcmd.exe!CPUUsage+0x52843
tcmd.exe!CPUUsage+0x528e8
tcmd.exe!CPUUsage+0x5311e
tcmd.exe!CPUUsage+0x339ad9
tcmd.exe!CPUUsage+0x1d0610
KERNEL32.DLL!BaseThreadInitThunk+0x22
ntdll.dll!RtlUserThreadStart+0x34

Call stack on v15:
tcmd.exe!CallHtmlHelp+0x48cfb
tcmd.exe!CallHtmlHelp+0x360ad
tcmd.exe!CallHtmlHelp+0x39c81
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

Call stack snapshots taken with Process Explorer just after starting the TCMD:s.
 
nikbackm said:
Hijacking this thread since the subject is still relevant.

I get about 2% constant CPU usage for all TCC instances, both standalone and running inside Take Command.
Click to expand...
I see similar effects with around 2 to 3% CPU usage for a stand-alone TCC instance (this is TCC 16.03.55). Most of the context switches are indeed in thread "TakeCmd.dll!AllocDup+0x440"... actually around 80 million switches per update! (I use a tool called ProcessHacker and it updates about once per second.)
These numbers surely are completely bogus and something else must be going on here. When I start many instances of TCC (~350), the CPU usage per process drops to ~0.15% and the context switch count to ~10 million. Even with those 350 instances of TCC/conhost (and some other stuff) running ProcessHacker shows still ~60% for the idle process.
So I think those measurements are WAY off. I also tested this on an older WinXP machine, there's absolutely no such effect.
 
thomasl said:
I see similar effects with around 2 to 3% CPU usage for a stand-alone TCC instance (this is TCC 16.03.55). Most of the context switches are indeed in thread "TakeCmd.dll!AllocDup+0x440"... actually around 80 million switches per update! (I use a tool called ProcessHacker and it updates about once per second.)
These numbers surely are completely bogus and something else must be going on here. When I start many instances of TCC (~350), the CPU usage per process drops to ~0.15% and the context switch count to ~10 million. Even with those 350 instances of TCC/conhost (and some other stuff) running ProcessHacker shows still ~60% for the idle process.
So I think those measurements are WAY off. I also tested this on an older WinXP machine, there's absolutely no such effect.
Click to expand...

Might be it goes down a little per process when you start more processes.

I started 50 stand-alone TCC instances and the CPU use according to Windows task manager was then 45-50%, and the processor frequency was raised from 1,95Ghz to 2,77Ghz. (Core 2 Duo 3Ghz processor).

If each process took close to 2% then 50% should take almost 100%, but then again, the raised clock frequency might have accounted for that, not sure if Task Manager takes it into account when calculating CPU % usage.
 
Seems that TCC processes consumes "extra" CPU on my Windows 7 work computer as well. But there they only take 0.2% CPU while idling at the prompt as opposed to 2% at my home Windows 10 computer.

Maybe the difference between a Core i7 processor and the older Core 2 Duo?

Call stack (v15, no v18 demo at the work computer) is similar:

ntoskrnl.exe!memset+0x61a
ntoskrnl.exe!KeWaitForMultipleObjects+0xd52
ntoskrnl.exe!KeWaitForMutexObject+0x19f
ntoskrnl.exe!PoStartNextPowerIrp+0xba4
ntoskrnl.exe!PoStartNextPowerIrp+0x1821
ntoskrnl.exe!KeWaitForMultipleObjects+0xf5d
ntoskrnl.exe!KeDelayExecutionThread+0x186
ntoskrnl.exe!NtWaitForSingleObject+0x16e
ntoskrnl.exe!KeSynchronizeExecution+0x3a23
ntdll.dll!ZwDelayExecution+0xa
KERNELBASE.dll!SleepEx+0xb3
TakeCmd.dll!AllocDup+0x48b
kernel32.dll!BaseThreadInitThunk+0xd
ntdll.dll!RtlUserThreadStart+0x21

What is this AllocDup function really supposed to do?
 
You must log in or register to reply here.
Back
Top
[FOX] Ultimate Translator
Translate