MS Teams Helper using up >100% of CPU MacBook

I renamed my teams to slack.exe and is working better now.

Hi,

thanks for this.

I had the same issue and renaming the file solved the issue.

Would really be great if there'd be an official fix for that, instead of manipulating the teams installation.

Regards

Okay, I found a solution on my Mac (16'' 2021 M1 Max, Monterey).

Mouse: Roccat Kone EMP (wired)

Solution first:

sudo mv "/Applications/Microsoft Teams.app/Contents/Resources/app.asar.unpacked/node_modules/media-hid/build/Release/media-hid.node" "/Applications/Microsoft Teams.app/Contents/Resources/app.asar.unpacked/node_modules/media-hid/build/Release/media-hid.node.bak"

Debugging steps:

When opening teams without the Mouse everything worked normal, joining a call was no problem.

As soon as the mouse was involved (USB-HUB or direct) CPU usage skyrockets.

Specifically: the presence of the mouse is not affecting teams. But as soon as you move it the CPU usage skyrockets. For that effect the mouse does not have to hover over the window btw., just moving it some pixels on another screen is enough.

Edit: CPU skyrocketing means that one of the "Renderer" processes increases to 50%-100% initially and then stays at ~50% forever. Which points at some continuous loop keep the system busy. So the mouse movement "changes" something in the process, it does not calm down after some seconds.

After finally having a simple test to see the behavior I took process dumps before and after; and you could visually spot the difference immediately.

The following block caught my attention:

+                                     2174 __IOHIDDeviceInputReportWithTimeStampCallback  (in IOKit) + 140  [0x19db8b608]
    +                                       2174 CFSetApplyFunction  (in CoreFoundation) + 328  [0x19b11f5cc]
    +                                         2174 CFBasicHashApply  (in CoreFoundation) + 148  [0x19b11f688]
    +                                           2174 __CFSetApplyFunction_block_invoke  (in CoreFoundation) + 28  [0x19b11f860]
    +                                             2174 __IOHIDDeviceInputReportApplier  (in IOKit) + 72  [0x19db8b718]
    +                                               2173 hid::DeviceImpl::reportCallback(int, void*, IOHIDReportType, unsigned int, unsigned char*, long)  (in media-hid.node) + 48  [0x113619140]
    +                                               ! 2166 hid::DeviceImpl::modifiedElementsWithReportID(unsigned int)  (in media-hid.node) + 32  [0x113619550]
    +                                               ! : 1422 hid::DeviceImpl::elementsWithReportID(unsigned int)  (in media-hid.node) + 100  [0x113619628]
    +                                               ! : | 1411 hid::DeviceImpl::CopyElementsUsingFilter(__CFDictionary const*, std::__1::vector<hid::OSElement<__IOHIDElement*>, std::__1::allocator<hid::OSElement<__IOHIDElement*> > >&)  (in media-hid.node) + 52  [0x1136196e4]
    +                                               ! : | + 1410 IOHIDDeviceCopyMatchingElements  (in IOKit) + 60  [0x19db88dbc]

After some digging around I figured that the block references "media-hid.node" which is found in the Teams folder. In a desperate attempt I renamed it so that Teams cannot load it, and to my surprise Teams does still start.

It seems that some outer error handling is not considering that library vital (yay!).

Thanks to the previous poster hinting at the gaming mouse, I would have never even remotely thought about that!

Can confirm with Roccat KONE Amo

Can confirm it as well (Roccat Kone EMP).

Wow.. this is really weird.