CPU usage spikes from Windows services

Question

I've been having a sudden issue come up recently on a laptop with Windows 10. To make things short, I noticed that the fans would speed up and become noticeably loud for short periods of time (about 10-15 seconds), and in about a frequency of once every 5 minutes or so. After trying to pin down the issue, I checked the CPU performance while this happened, and sure enough the CPU usage would bump from around 10% to 22~25% for these brief periods of time, specifically it was because of the Services and Controller App (so services.exe).

After trying to find the issue in Process Manager, I found that the address for this was !RtlUserThreadStart, which as I understand is a function from Windows that is involved in the initialization of threads. There's several of these running, but it's always one that has a particularly high CPU usage. Here's a screenshot during one of these spikes

Following some help from here and here, and using the Windows Performance Analyzer, I created a log (screenshot) right when this issue was happening, and it's apparent just how much the usage increases just because of this single process. But also the stack trace is a quite hard for me to follow, as an example I'll leave a little snippet here since it's extremely long.

I don't know what could be causing this. But if it's useful: I first started noticing this after I ran a Windows debloat script. I'm not sure if it is the cause, though, because before that the CPU usage would spike far more often because of many other processes (Windows update, other services running in the background, etc), so maybe it was already happening and I just didn't notice because it got mixed among other processes. Also this is the first computer I've seen that had this issue after running the script, which makes me more dubious.

I'd appreciate any help trying to pin down the problem, I'll also add any additional information that could be needed.

EDIT: I've made some more accurate measures, and it seems that the CPU spike lasts for somewhere between 15~16 seconds, and then goes inactive for 5 minutes (on the clock) before starting again. Given how regular it is I figured it could have something to do with scheduled tasks, but none of them seem to fit this behavior. Also, I found the following excerpt from the stack trace:

 - rpcrt4.dll!Invoke
    |- services.exe!REnumServicesStatusExW
    |    services.exe!REnumServiceGroupHelp
    |    |- services.exe!ScGetServiceDisplayName
    |    |    |- services.exe!ScReadAndTranslateString
    |    |    |    |- services.exe!ScReadStringIndirect
    |    |    |    |    |- services.exe!ScGetInfString
    |    |    |    |    |    |- spinf.dll!SpInfGetIndirectString
    |    |    |    |    |    |    spinf.dll!LoadIndirectInfString
    |    |    |    |    |    |    |- spinf.dll!SpInfLoadInfFile
    |    |    |    |    |    |    |    |- spinf.dll!ParseNewInf
    |    |    |    |    |    |    |    |    |- spinf.dll!ParseGenericLine
    |    |    |    |    |    |    |    |    |    |- spinf.dll!ParseValuesLine
    |    |    |    |    |    |    |    |    |    |    |- spinf.dll!_pSpUtilsStringTableAddString
    |    |    |    |    |    |    |    |    |    |    |    |- spinf.dll!_pSpUtilsStringTableLookUpString
    |    |    |    |    |    |    |    |    |    |    |    |    |- spinf.dll!_ComputeHashValue
    |    |    |    |    |    |    |    |    |    |    |    |    |    |- spinf.dll!pSpUtilsCharLower
    |    |    |    |    |    |    |    |    |    |    |    |    |    |    |- KernelBase.dll!LCMapStringW
    |    |    |    |    |    |    |    |    |    |    |    |    |    |    |    |- KernelBase.dll!LCMapStringEx
    |    |    |    |    |    |    |    |    |    |    |    |    |    |    |    |    |- KernelBase.dll!LCMapStringEx<itself>

And it is followed by an enormous list of KernelBase.dll!LCMapStringEx with weight 0. I find this particular excerpt of interest because almost the entire weight of the services.exe process is found in these few lines (5.07% out of 5.3%), so I'm guessing this is where the core of the problem is.