IT Performance

Closing one program that Task Manager listed at 3% CPU dropped my CPU temperature by about 10°C. The program was OSCApplicationManager.exe , a helper process of LG's OnScreen Control monitor utility, and it had been holding one CPU core at 100% for the roughly 31.5 hours since boot. It was not malware. It was a correctly signed LG binary stuck in a busy loop. Every number below was measured on October 7, 2026 on one Windows 11 PC (AMD Ryzen 9 5950X, 16 cores / 32 threads) running OnScreen Control 9.43.0.0. The temperature change is what the monitoring tool on that PC reported. Your numbers will differ, but the checks work the same way. Symptom: a warm CPU on an idle machine I found it while looking for the cause of a slow PC. The slowness turned out to be something else (a hard disk at 100% active time); this was a side discovery. Total CPU usage was a relaxed 10–19%. The LG entries in Task Manager showed 0–3%, so nothing stood out. Why Task Manager says 3% Task Manager...

A local model taking two to three minutes to answer "introduce yourself in one sentence" is not normal, even on a mid-range GPU. On my AMD Radeon RX 6800 XT the cause turned out to be two stacked problems: the agent app was sending a ~20,000-token prompt with every message, and Ollama had silently fallen back from ROCm to Vulkan, where long prompts are processed very slowly. Fixing the second one took a 25,000-token prompt from about 9 minutes to about 30 seconds. Everything below was measured on one Windows 11 machine on 2026-09-28 with Ollama 0.34.4 and qwen3:8b / qwen3:14b (Q4_K_M). Your numbers will differ; the diagnostic steps will not. The symptom A desktop AI agent pointed at local Ollama showed "Worked for 2m 53s" for a one-line greeting. Cloud models in the same app answered in seconds, so the app itself looked fine. Short prompts typed directly into ollama run felt fast, which made the slowness look random. Before: a one-line greeting took 2 ...

Your Claude Code session eats through the 5-hour limit before lunch. Or the opposite: answers come back thin on a problem you know is hard. Both usually trace to one setting most people never open — effort . The symptom The usage meter (5h / 7d) climbs much faster than it used to, with no change in how much you type. Or: responses arrive fast but shallow on genuinely hard debugging, and you find yourself re-prompting three times. Switching models didn't fix it, and you can't find a "verbosity" or "quality" slider in the docs you read. The cause: effort is a per-turn reasoning budget Claude Code exposes a setting called effort that controls how much reasoning the model spends on each turn. Run /effort and you get a slider labelled Faster on the left and Smarter on the right, with five stops: low  ·  medium  ·  high  ·  xhigh  ·  max These are the descriptions the product itself attaches to each stop: Level What it means low Q...

A memory leak does not announce itself. The machine is fine in the morning, sluggish by mid-afternoon, and swapping to disk by evening — and a restart makes it all go away, which is exactly why the problem survives for months. Finding the process responsible takes about ten minutes with tools that are already free. Leak, or just a large cache? Not every process with a big memory footprint is leaking. Databases, browsers, and editors deliberately cache in RAM and release under pressure. A leak has a specific signature: memory that climbs steadily, never falls during idle periods, and only resets when the process restarts. The distinction matters because chasing a well-behaved cache wastes an afternoon. Measure over hours, not minutes. The three numbers that matter Counter What it measures Why it matters for leaks Working Set Physical RAM the process currently holds Falls when Windows trims under pressure — can hide a leak Private Bytes Memory committed to this process alone,...

The BitLocker recovery screen is one of the few Windows prompts that can genuinely lock you out of your own data. It appears after a firmware update, a hardware change, or a BIOS setting you did not think mattered — and it asks for a 48-digit key you do not remember ever seeing. The key almost certainly exists. This guide covers where Windows put it, how to use it, and what to do when it truly is gone. Why the recovery screen appears at all BitLocker seals the drive's encryption key to the state of the machine at the moment encryption was enabled — chiefly the TPM measurements of firmware and boot components. When that state changes, the TPM refuses to release the key automatically and BitLocker falls back to asking a human. Microsoft's BitLocker documentation describes the protection model in detail. Common triggers, in rough order of how often they catch people out: A UEFI/BIOS firmware update Turning Secure Boot on or off Adding, removing, or reseating a drive — som...

When a Windows PC crashes, the most useful evidence is almost always already on the machine. Windows records what happened in the event logs, and it keeps recording after the crash — the reboot, the driver that failed to load, the service that never came back. Most people never open Event Viewer because the first screen is a wall of warnings that look alarming and mean nothing. This guide is about ignoring that wall and going straight to the handful of entries that actually explain a crash. What Event Viewer actually stores Windows keeps separate logs for different sources. The two that matter for crash work are System (hardware, drivers, services, boot) and Application (individual programs failing). Everything else — Security, Setup, forwarded events — is noise for this purpose. Each entry carries a severity, a source, an Event ID, and a timestamp. The Event ID is the part worth learning: it is a stable number that means the same thing on every Windows machine, which makes it se...