Field Investigation · Mobile Silicon

The Case of the Cold Processor That Would Not Run

A Dell Latitude 5520 kept collapsing to 389 MHz under full load. The die was at 56 °C. Every suspect the internet names had an alibi, the clue that broke the case was a correlation running backwards, and the fix that appeared to work did not. The one that did was suggested by the machine’s owner.

IThe complaint

The symptom was the kind that makes you doubt your own senses. A Dell Latitude 5520, docked and driving three external panels, would intermittently become treacle. Not slow in the way a machine is slow when something is chewing the CPU — slow in the way a machine is slow when the CPU has stopped trying. Task Manager showed clock speeds in the hundreds of megahertz. Then, a minute or two later, it would be fine again.

The owner had already done the obvious homework. ThrottleStop was installed and running, which helped enough to be noticeable and not enough to be a fix. The battery report showed a pack at 44% of its original capacity. Every forum thread on the subject converges on the same two answers — repaste it, or replace the battery — and the question put to me was simply which one to buy.

That framing is worth dwelling on, because it is the trap. Both answers are plausible, both are cheap enough to try, and trying them is how you end up sixty dollars poorer with an unchanged machine and no new information. The useful question is not which fix but what is the mechanism, and mechanisms leave evidence.

IIThe suspect everyone names

The battery had motive and opportunity. A pack at 44% health has elevated internal resistance, and on a laptop the battery is not merely a reserve — it is a buffer. Turbo transients on a Tiger Lake chip can exceed what the adapter supplies on its own for tens of milliseconds at a time, and the pack covers the difference. If it can no longer do that, the embedded controller has every reason to clamp the processor. This is a real failure mode. It is also, as it turns out, not this one.

The test is straightforward: apply a load that will demand every watt the platform can deliver, and watch the pack while it happens. I ran eight compute-bound worker threads for ninety seconds with a fifteen-second idle baseline on either side, polling root\wmi BatteryStatus throughout for voltage, charge rate and discharge rate.

The pack is worn. It holds 27,512 mWh against a design capacity of 62,366 mWh, and it is worth replacing for the three hours of unplugged runtime that would restore. But it is not throttling anything, and the reason to say so firmly is that replacing it would have appeared to work — the fault is intermittent, and any intervention followed by a good afternoon looks like a cure.

IIIBuilding an instrument

An intermittent fault that clears itself in ninety seconds cannot be caught by watching. It has to be caught by something that never blinks, and it has to be caught with enough surrounding context that the cause is visible in the same frame as the effect. Four instruments ran in parallel.

Two traps worth flagging

The first is the nominal frequency trap. Windows reports processor speed as % Processor Performance, a percentage of a nominal that is not the base clock and not the turbo clock. On this machine SMBIOS declares 1,498 MHz, so a chip running 4.0 GHz reports 267%. Any tool that naively multiplies a percentage by a base clock will be wrong in both directions. The CPPC table from powercfg /energy is what anchors the arithmetic:

That first row matters: 389 MHz is a legitimate architectural state, not a misreading or a broken sensor. The platform declares a lowest-performance level of 26%, and 26% of 1,498 is 389. The question was never whether the number was real. It was why a fully loaded processor was being held there.

The second trap is the observer effect. My first watcher polled WMI every three seconds and never once recorded a clock below 1.09 GHz, which briefly convinced me the machine had a high idle floor. It does not. Get-CimInstance is expensive enough to wake cores; the instrument was manufacturing the floor it measured. Re-running with native typeperf and the watcher stopped told a different story. Any measurement of idle behaviour has to account for the cost of measuring.

IVThe dog that did not bark

Before catching the fault live, the sleep study produced something unexpected. Across seven days and 48 recorded scenario instances, every single Modern Standby session reported “No CS Phase” at 100%. The screen went off. The machine underneath never entered its low-power phase. Not once, in 92.85 hours.

Then, buried in the per-session blockers, a step change with a date on it.

This does not explain the throttling by itself. What it explains is the conditions. A laptop that never sleeps, sitting in a dock, driving three DisplayLink panels — which compress framebuffers in software, on the CPU — is a laptop whose chassis never gets a chance to shed heat. Seven hours of that overnight, and the machine you sit down to in the morning is not cold. It only looks cold, because the fan has been quiet.

VCaught in the act

At 15:40:28 the watcher fired.

[15:40:28] STALL  389 MHz  busy=100%  pctPerf=26  battV=16100mV  chg=0mW  batt=100%  AC=True
[15:40:39] STALL  719 MHz  busy=100%  pctPerf=48  battV=16101mV  chg=0mW
[15:40:44] STALL  689 MHz  busy=92%   pctPerf=46  battV=16101mV  chg=0mW
[15:40:49] STALL  839 MHz  busy=76%   pctPerf=56  battV=16100mV  chg=0mW
[15:40:53] STALL  809 MHz  busy=100%  pctPerf=54  battV=16101mV  chg=0mW
[15:40:57] recovered to 1183 MHz after 5 consecutive stall samples

389 MHz at 100% CPU load. Not an idle reading — the machine had work in front of it and was running at its architectural floor. And the battery, throughout: 16,100 mV, 100% charged, 0 mW in either direction. The alibi held under the actual event, which is the only place an alibi counts.

The corresponding ThrottleStop rows are where the case turns.

TIME       CLOCK      C0%    TEMP   POWER   FLAGS
15:49:20   0.87 GHz   95.5%   56C    8.4W    PL1
15:49:21   0.99 GHz   97.5%   57C    8.4W    PL1
15:49:24   0.96 GHz   96.9%   56C    8.5W    PL1
15:49:28   1.00 GHz   95.5%   56C    8.3W    PL1
15:49:36   1.04 GHz   96.9%   56C    9.3W    PL1

The processor is 96% busy. The die is at 56 °C, forty-four degrees below its junction limit. The package is drawing 8.4 watts — less than a third of this chip’s configured base TDP. And the reason code is not TEMP. It is PL1: the sustained power limit.

An hour earlier, the same chip on the same cooler had sustained 38.7 W at 100 °C without complaint. The cooling system is not the constraint. Something moved the ceiling.

VIThe clue that runs backwards

Here is the observation that settles what kind of fault this is. Take every heavily-loaded sample from the afternoon — 744 of them, all above 80% core residency — and bucket them by die temperature. Then ask what power and what clock each bucket received.

This single chart eliminates an entire branch of the diagnostic tree. Dried thermal paste, a clogged heatsink, a failing fan — every mechanical cooling fault produces the opposite signature, because they all work by making the chip hotter at a given power. Here the chip is cool because it is throttled, not throttled because it is hot.

The transition is visible minute to minute. These are consecutive:

One minute apart. The clock fell by a factor of six, the power by a factor of four, and the die got thirty-two degrees cooler across the transition. No thermal model produces that.

VIIA ceiling that ratchets down

Plotting the sustained power ceiling across the afternoon shows this is not a binary fault that trips and clears. It is a ceiling that degrades with uptime, punches through the floor, recovers partially, and degrades again.

That intermittency is the whole reason this fault survives casual diagnosis. Any benchmark run during a good window returns a healthy number. Any benchmark run during a bad window looks like a broken cooler. The only way to see the shape of it is to log continuously for hours and look at the distribution rather than the peak.

VIIINaming the mechanism

Something with authority over PL1 is lowering it. On an Intel mobile platform there is a short list of candidates, and the top of it is Intel Dynamic Tuning Technology — the modern name for DPTF. It runs as esifsvc plus a kernel driver, and it enumerates a set of ACPI participants that feed a thermal policy. On this machine:

IXThe arrest that failed

Having named a suspect, the obvious next step is to remove it and see whether the symptom follows. Disable Intel DTT, re-run the load, compare. This is where the investigation stopped being tidy.

> Disable-PnpDevice -InstanceId 'ACPI\INTC1043\TSKN' -Confirm:$false
  FAILED: Not supported
> Disable-PnpDevice -InstanceId 'ACPI\INTC1040\2&DABA3FF&0' -Confirm:$false
  FAILED: Not supported
  ... identical for AMBF, HTPP, TGPU, TMEM

All six participants are flagged non-disableable by the platform, which means Device Manager’s Disable option is greyed out as well. The registry fallback was no better: ConfigFlags was already 1 on every device, so setting the disable bit changed nothing, and Windows is plainly not honouring that bit for ACPI-enumerated participants anyway.

What did succeed was stopping esifsvc and setting it to Disabled. That removes the user-mode policy engine and leaves the kernel driver and the ACPI tables underneath it fully intact. The immediate effect on sustained power was 19.4 W to 18.9 W — within noise.

XPreliminary results

Two interventions landed within a few minutes of each other. Corsair iCUE was closed and removed from startup — it had accumulated 8,042 seconds of CPU time since 15 July and was holding the platform timer at 4 ms, which blocks deep idle states. And esifsvc was stopped and disabled.

Over the following two hours the machine behaved impeccably. Hour-by-hour figures for loaded samples went from 1.63 GHz and 13.2 W in the 15:00 hour to 3.32 GHz and 29.4 W by 18:00, with TEMP replacing PL1 as the dominant flag — the healthy failure mode, a chip drawing everything it wants until the die gets hot. Its owner described it, unprompted, as feeling “like a normal computer” after weeks of jumping all over the place.

Critically, the machine had not rebooted. Uptime was 274 hours, so none of this could be explained by a restart clearing the heat soak — the confound I had been most worried about. Everything pointed to a genuine fix.

XIThe retest that overturned it

The 17:00 and 18:00 hours contained nine and eleven loaded samples respectively. That is not a measurement, it is a rumour. Before writing any of this up as a success I ran the same controlled 60-second all-core load used earlier in the day.

This is the trap the whole investigation had been circling, and I walked into it anyway. Ordinary desktop work is bursty. A browser repaint, a file open, an application launch — these draw hard for a fraction of a second and finish inside the turbo budget, well before the sustained power window closes. They feel fast because they are fast. The clamp only engages on work that stays on the processor for more than about four seconds, and after the synthetic load tests stopped, nothing on that machine did.

Two and a half hours of subjective improvement, a clean hour-by-hour table trending in the right direction, and a plausible mechanism — all of it was an artefact of nobody asking the processor to do sustained work.

Which left one variable nobody had touched. Every measurement in Exhibit G was taken on a machine that had been powered on continuously for eleven days.

XIIThe variable nobody had touched

The owner suggested it, and the reasoning was better than mine: if a service had been writing a low power limit and the service was then stopped, nothing would have restored the register. It would simply keep whatever value was last written. Stop the writer, and you freeze the damage rather than undo it.

That specific mechanism turned out to be wrong, and the way it was wrong is informative. If the register were frozen, the ceiling would be constant. It was not — between 18:24 and 18:32 it moved from 9 W to 17.4 W with esifsvc stopped and disabled throughout. Something below the user-mode service was still actively writing power limits. That is a more interesting answer than a stale value, and it narrows the field to the kernel driver or the embedded controller.

The test was worth running regardless, because it addressed the confound that had been sitting untested all day. The staging mattered: the service already disabled so it could never start, no other startup changes in flight, and a logon task to bring ThrottleStop back so the machine could measure itself. One variable, no BIOS changes.

The processor came up with no user-mode thermal policy running at all. Then the same sixty-second load, for the fourteenth time that day.

A processor limited by TEMP at 99 °C is a processor spending its entire power budget and being stopped by physics. A processor limited by PL1 at 76 °C is a processor being stopped by an opinion. The first is how a thin laptop is supposed to behave under sustained load; the second is the fault. Across every loaded sample after the reboot, PL1 does not appear a single time — the census over 1191 samples reads 68% TEMP and zero PL1.

XIIIThe days after

Two hours of uptime is not eleven days, and this investigation had already declared victory once on evidence that looked better than it was. So the machine was simply left running, with logging on, and measured again the next morning at twelve and a half hours — including a repeat of the four-minute soak, so the comparison would be exact rather than approximate.

It held. So the machine was left alone for another two days and measured a third time, and that is where this stops being a promising result and becomes an answer. The fault used to need uptime; the final check has 66.5 hours of it.

And then the number that settles it. Not from the load tests — from everything. Every sample logged since the reboot, loaded and idle, working hours and small hours alike:

Zero. The flag that appeared on 83% of loaded samples before the reboot has not appeared once since, in any state, in a quarter of a million measurements. The symptom that started this — a fully loaded processor sitting at 389 MHz — has no instances at all: not one loaded sample in sixty-six hours fell below 1.5 GHz, and the slowest was 2.95 GHz. Overnight, idling, the minimum clock never dropped below 1.25 GHz and the package sat at 3.9 W.

The uptime column in the table below is the one to read. Before the fix, the ceiling fell as uptime rose — that was the fault’s defining behaviour. After it, the two are simply unrelated: the 66.5 hour reading is the highest of the whole series.

That distinction is the whole finding, and it is worth being precise about, because “turn it off and on again” is exactly the advice this article would be worthless if it ended on. The machine had rebooted many times over five years and the fault always came back. What had never happened before was booting with the thermal policy service disabled from the start, so that no user-mode policy ever ran and dptf_acpi never loaded at all. Stopping the service mid-session was not equivalent, and the measurements say so: it moved the ceiling from 9 W to 17.4 W and left PL1 binding on 93% of samples. Only the clean boot removed it entirely.

XIVThe machine was not alone

With a mechanism identified, the literature becomes searchable in a way it was not at the start. The owner had spent years looking for this under BD PROCHOT and “ThrottleStop,” which is where the internet points you and which is why he never found anything. Searching instead for Intel Dynamic Tuning and power-limit throttling turns up a cluster of reports on precisely this chassis generation — the Latitude 5420, 5520, 7420 and 7520, all Tiger Lake, all 2021.

One post on Dell’s own community forum describes cores “capped at 0,39Ghz” — the same 389 MHz, reported by a stranger on a sibling machine — and notes that Dell’s hardware diagnostic found nothing and the fan never spun, because the die was never hot. The issue attracted enough attention that Dell deleted a forum thread about it after it was linked from Hacker News.

An important caveat, because it would be easy to overclaim: nearly all of those reports are from Linux users, and several of them say explicitly that on Windows it works correctly. Their complaint is that Windows’ DTT driver handles these tight trip points properly and the open-source thermal daemon does not. This machine is running Windows, and it did not work correctly. So this is not the same bug. What carries across is the platform ingredient: a chassis whose thermal participants have very little margin, so whatever consumes them has very little room for error.

There is no fix waiting to be installed, either. The Intel Dynamic Tuning driver on this machine is version 8.7.10802.26924, dated April 2022. That is not neglect — it is the newest build Dell ships for the 5520, still listed in the Windows 11 driver pack revised in July 2024. Intel’s 9.0 branch went to later platforms. The system BIOS, by contrast, is from March 2026. The machine is running a thermal policy engine that was frozen four years ago against firmware that has been revised many times since.

One last measurement, prompted by all of this. If the participants are the mechanism, then the policy engine should be harmless without them — and it is testable, because after the reboot those six devices never bound to a driver at all. Restarting esifsvc by hand puts the policy engine back in memory while its sensors stay unavailable. Windows will not re-enumerate a device that failed at boot, so the six participants stayed in an error state no matter how hard they were prodded.

Identical, to the tenth of a watt. The policy engine running with no sensors does not clamp anything. That does not prove the sensors are faulty — a correct sensor feeding an over-eager policy produces the same result — but it does narrow the mechanism by one level. The problem is not that this software exists. It is what this software does once it can see the participants.

XVWhat is still unknown

—Reproduce this on your own machine

If your laptop shows the same symptom, the diagnostic sequence below will tell you within an hour whether you are looking at the same fault. None of it requires purchasing anything.

1. Establish whether the battery is involved. Run a sustained all-core load and watch the pack. If discharge rate stays at zero and voltage moves by single-digit millivolts, the battery is not your problem regardless of its health percentage.

# poll while a load runs in another window
Get-CimInstance -Namespace root\wmi -ClassName BatteryStatus |
  Select-Object Voltage, ChargeRate, DischargeRate, PowerOnline

2. Log the processor’s own reason codes. This is the step most people skip, and it is the one that matters. ThrottleStop’s log records whether a slow clock was caused by TEMP, PL1, EDP or BD PROCHOT. Guessing between them is what sends people to the thermal paste unnecessarily.

3. Bucket your loaded samples by temperature. The decisive test. If low power correlates with high temperature you have a cooling fault and a repaste is justified. If it correlates with low temperature, you have a power policy problem and no amount of thermal paste will touch it.

# $rows parsed from the ThrottleStop log; Temp in C, PkgW in watts
$rows | Where-Object { $_.C0 -gt 80 } |
  Group-Object { [math]::Floor($_.Temp/10)*10 } |
  Sort-Object { [int]$_.Name } |
  ForEach-Object {
    "{0,3}C : {1,4} samples  avg {2,5} W  avg {3,5} GHz" -f $_.Name, $_.Count,
      [math]::Round(($_.Group | Measure-Object PkgW -Average).Average,1),
      [math]::Round(($_.Group | Measure-Object GHz  -Average).Average,2)
  }

4. Check whether the machine actually sleeps. Run powercfg /sleepstudy and look for “No CS Phase” in the blocker list. If it reads 100%, your laptop has been awake the entire time you thought it was asleep, and its chassis has been heat-soaking accordingly.

5. Enumerate your thermal participants. If TSKN appears, your platform has a skin-temperature policy with authority over your power limits.

Get-PnpDevice | Where-Object { $_.InstanceId -match 'INTC1040|INTC1043' } |
  Select-Object Status, FriendlyName, InstanceId