[WediBlino]

An old manager of mine once spent the day trying to kill a process that was running at 99% on Windows box.

When I finally got round to see what he was doing I was disappointed to find he was attempting to kill the 'system idle' process.

[Twirrim]

Years ago I worked for a company that provided managed hosting services. That included some level of alarm watching for customers.

We used to rotate the "person of contact" (POC) each shift, and they were responsible for reaching out to customers, and doing initial ticket triage.

One customer kept having a CPU usage alarm go off on their Windows instances not long after midnight. The overnight POC reached out to the customer to let them know that they had investigated and noticed that "system idle processes" were taking up 99% of CPU time and the customer should probably investigate, and then closed the ticket.

I saw the ticket within a minute or two of it reopening as the customer responded with a barely diplomatic message to the tune of "WTF". I picked up that ticket, and within 2 minutes had figured out the high CPU alarm was being caused by the backup service we provided, apologised to the customer and had that ticket closed... but not before someone not in the team saw the ticket and started sharing it around.

I would love to say that particular support staff never lived that incident down, but sadly that particular incident was par for the course with them, and the team spent inordinate amount of time doing damage control with customers.

[panarky]

In the 90s I worked for a retail chain where the CIO proposed to spend millions to upgrade the point-of-sale hardware. The old hardware was only a year old, but the CPU was pegged at 100% on every device and scanning barcodes was very sluggish.

He justified the capex by saying if cashiers could scan products faster, customers would spend less time in line and sales would go up.

A little digging showed that the CIO wrote the point-of-sale software himself in an ancient version of Visual Basic.

I didn't know VB, but it didn't take long to find the loops that do nothing except count to large numbers to soak up CPU cycles since VB didn't have a sleep() function.

[m463]

That's what managers do.

Silly idle process.

If you've got time for leanin', you've got time for cleanin'

[cassepipe]

I abandonned Windows 8 for linux because of an bug (?) where my HDD was showing it was 99% busy all the time. I had removed every startup program that could be and analysed thouroughly for any viruses, to no avail. Had no debugging skills at the time and wasn't sure the hardware could stand windows 10. That's how linux got me.

[ryandrake]

Recent Linux distributions are quickly catching up to Windows and macOS. Do a fresh install of your favorite distribution and then use 'ps' to look at what's running. Dozens of processes doing who knows what? They're probably not pegging your CPU at 100%, which is good, but it seems that gone are the days when you could turn on your computer and it was truly idle until you commanded it to actually do something. That's a special use case now, I suppose.

[margana]

Why is this such a huge issue if it merely shows it's busy, but the performance of it indicates that it actually isn't? Switching to Linux can be a good choice for a lot of people, the reason just seems a bit odd here. Maybe it was simply the straw that broke the camel's back.

[saintfire]

I had this happen with an nvme drive. Tried changing just about every setting that affected the slot.

Everything worked fine on my Linux install ootb

[BizarroLand]

Windows 8/8.1/10 had an issue for a while where when it was run on spinning rust HDD it would peg it out and slow the system to a crawl.

The only solution was to swap over to a SSD.

[nullhole]

To be fair, it is a really poorly named "process". The computer equivalent of the "everything's ok" alarm.

[chowells]

Long enough ago (win95 era) it wasn't part of Windows to sleep the CPU when there was no work to be done. It always assigned some task to the CPU. The system idle process was a way to do this that played nicely with all of the other process management systems. I don't remember when they finally added CPU power management. SP3? Win98? Win98SE? Eh, it was somewhere in there.

[Agentus]

reminds of when i was a kid and noticed a virus had taken over a registry. from that point forward i attempted to delete every single registry file, not quite understanding. Between that and excessive bad website viewing, I dunno how i ever managed to not brick my operating system, unlike my grandma who seemed to brick her desktop in a timely fashion before each of the many monthly visits to her place.

[bornfreddy]

The things grandmas do to see their grandsons regularly. Smart. :-)

[_ea1k]

I worked at a government site with a government machine at one time. I had an issue, so I took it to the IT desk. They were able to get that sorted, but then said I had another issue. "Your CPU is running at 100% all the time, because some sort of unkillable process is consuming all your cpu".

Yep, that was "System Idle" that was doing it. They had the best people.

[belter]

Did he have a pointy hair?

[mrmuagi]

I wonder if you make a process with idle in it you could end up in the reverse track where users ignore it. Is there anything preventing an executable being named System Idle.

[kernal]

You're keeping us in suspense. Did he ever manage to kill the System Idle process?

[marcosdumay]

Windows used to have that habit of making the processes CPU starved, and yet claiming the CPU was idle all the time.

Since the Microsoft response to the bug was denying and gaslighting the affected people, we can't tell for sure what caused it. But several people were in a situation where their computer couldn't finish any work, and the task-manager claimed all of the CPU time was spent on that line item.

[nerdile]

As a former Windows OS engineer, based on the short statement here, my assumption would be that your programs are IO-bound, not CPU-bound, and that the next step would be to gather data (using a profiler) to investigate the bottlenecks. This is something any Win32 developer should learn how to do.

Although I can understand how "Please provide data to demonstrate that this is an OS scheduling issue since app bottlenecks are much more likely in our experience" could come across as "denying and gaslighting" to less experienced engineers and layfolk

[RajT88]

> Since the Microsoft response to the bug was denying and gaslighting the affected people

Well. I wouldn't go that far. Any busy dev team is incentivized to make you run the gauntlet:

1. It's not an issue (you have to prove to me it's an issue)

2. It's not my issue (you have to prove to me it's my issue)

3. It's not that important (you have to prove it has significant business value to fix it)

4. It's not that time sensitive (you have to prove it's worth fixing soon)

It was exactly like this at my last few companies. Microsoft is quite a lot like this as well.

If you have an assigned CSAM, they can help run the gauntlet. That's what they are there for.

See also: The 6 stages of developer realization:

https://www.amazon.com/Panvola-Debugging-Computer-Programmer...

[gruez]

I've never heard of this. How do you know it's windows "gaslighting" users, and not something dumb like thermal throttling or page faults?

[fifilura]

To be fair, there are worse mistakes. It does say 99% CPU.