About PC Fixes

Why I started PC Fixes

I was debugging a friend’s laptop in a coffee shop, watching them tap their fingers on the table every time another error popped up.

The screen was full of red text—‘DISM failed’, ‘Windows Update stuck at 99%’, ‘BSOD again’—and every time, they’d sigh and say, *‘I just want to know how to fix this without pulling my hair out.’* That’s when I realised most people don’t need a manual; they need a translator.

Someone to turn ‘0x80070002’ into ‘try this, then that, and if it still breaks, here’s the *real* problem.’

So I started writing. Not just dry steps, but the *why* behind them—the shortcuts that work, the pitfalls that trip up beginners, and the moments when a ‘fix’ actually makes things worse. This isn’t for experts.

It’s for the person who Googled ‘blue screen’ at 2 AM and got hit with forum threads that assume you already know what a registry key is. Here, you’ll find answers that don’t assume you’re fluent in tech-speak. The terminal’s first command?

It’s not just `help`—it’s *‘I’m lost, but I’m willing to learn.’*

Meet the founder

The machine that started it all is still in my basement, though it hasn’t turned on in years. The power supply fried after I accidentally shorted the motherboard while swapping RAM—something I *still* do wrong half the time.

But I keep it there, not as a relic, but as proof that the real ‘fix’ isn’t always technical. Sometimes it’s just knowing when to admit you’ve made a mistake and start over.

What I *do* still do is what my dad did when I’d bring him a problem: I’d open the case, point at the relevant part, and say, *‘This is what’s broken.

Now let’s see if we can’t fix it without breaking anything else.’* That’s the rhythm of every guide here—diagnose, test, adjust. No jargon, no hand-waving. If I don’t know the answer, I’ll say so. But I’ll also tell you how to find it.

I work from a repurposed server rack in my living room, where the cables are a tangled mess and the monitor flickers when I forget to update the drivers. (Yes, I’ve written about that too.) The light is bad—just a desk lamp and the glow of three screens—but that’s where the best fixes usually happen: in the mess, not the manual.

You’ll notice I never say ‘just’ when talking about solutions. *‘Just reboot’* isn’t a fix. *‘Just run this command’* isn’t always safe. Every ‘just’ hides a caveat, and we’ll name it. That’s the only rule: if there’s a risk, we’ll tell you. If there’s a shortcut, we’ll mark it.

And if all else fails? We’ll tell you how to ask for help without sounding like you’ve never touched a keyboard.

My first computer was a clunky desktop my dad built from parts in his garage, and I spent hours tinkering with it—mostly just crashing the system until he’d sigh and reboot it for me. That machine taught me two things: tech can be intimidating, but with the right guidance, anyone can master it.

Dolores Alvarado, Founder & Editor

Meet the mascot

The first sketch was on a napkin during a three-hour wait at the DMV—because even bureaucracies can’t break a tech writer’s habit of doodling. I drew a terminal window with a cursor blinking at a command prompt, but the ‘error’ line kept turning into a question mark.

Then I realised: the mascot needed to look like it was *mid-debug*, not mid-typing. So I gave it a coffee cup (for the all-nighters) and a ‘404 Not Found’ floating above its head (because half the fixes start with admitting you’re lost).

The drawn version had too many details—the terminal had tabs, the cursor had a face, the error message was in Comic Sans. So I stripped it down: one window, one line of text, one glitch (the ‘|’ cursor that’s *always* moving).

The name? ‘Glitch’, because every error’s a lesson in disguise. And it had to fit on a browser tab without looking like a placeholder. Mission accomplished.

Glitch doesn’t have a backstory. It’s not a hero. It’s just the face of the site’s philosophy: tech problems aren’t failures—they’re puzzles. And like any puzzle, the first step is usually the simplest: *‘What’s actually broken here?’*

What I promise you

You’ll never leave a page thinking, *‘I still don’t get it.’* If a step is unclear, we’ll rephrase it. If a command’s dangerous, we’ll warn you. And if the fix doesn’t work? We’ll tell you *why*—and what to try next.

How I create a guide

A guide starts with a real problem—mine or someone else’s. Not a hypothetical, not a ‘common issue,’ but the exact error message, the exact behavior, the exact frustration. I’ll reproduce it on a fresh install if I can, or at least on the same OS version the reader’s using.

No ‘it works on my machine’ excuses.

The ‘test it’ phase

First, I run the ‘obvious’ fixes—the ones that pop up in every forum thread. If they work, great. If not, I’ll note why (e.g., ‘This only works if the file isn’t already corrupted’).

Then I dig deeper: I’ll check event logs, monitor resource usage, and—if it’s hardware—use diagnostic tools like `msinfo32` or `dxdiag`. The goal isn’t to find *a* fix; it’s to find the *right* one for 80% of cases.

I time everything. A ‘wait 10 minutes’ step becomes ‘wait exactly 9 minutes and 47 seconds, then check Task Manager.’ If the fix is time-sensitive, I’ll say so. And if the system behaves differently after the second try? That’s a red flag—and it’ll be in the guide.

No ‘just wait’ without a deadline.

The ‘fix it properly’ phase

If the first pass fails, I’ll isolate variables. Is it the OS? The hardware? A conflicting program? I’ll test on a VM, a different machine, or even a live USB if needed.

The worst ‘fix’ is a temporary band-aid, so I’ll push until I find the root cause—or at least the most reliable workaround. If the solution involves editing the registry, I’ll back up first. If it involves third-party tools, I’ll link to trusted sources.

Every guide ends with a ‘What If This Doesn’t Work?’ section. Not ‘good luck,’ but a clear next step. Because the real fix isn’t just solving the problem—it’s making sure the reader can solve it themselves next time.

How a page gets onto PC Fixes

The first draft is written while the fix is still fresh in my mind—sometimes in a text file, sometimes scribbled on a notepad. I’ll include every dead end, every ‘wait, that didn’t work’ moment.

Then I’ll cut the fluff: no ‘as you may know,’ no ‘in today’s digital age.’ If it’s not useful, it’s gone. The second read is for clarity. Does the reader know *why* they’re doing each step? If not, I’ll add it.

Pages get rewritten months later when I stumble across a better method—or when a reader points out a gap. (We have a ‘Report a Fix’ button for that.) And if a guide hasn’t been updated in a year? It’s either archived or rewritten from scratch. Tech moves fast.

So do I.

Write to me

I love hearing about the fixes that worked (or didn’t), the problems we missed, or the ‘how did you even find that?’ moments. Did a guide save you hours? Did a step not apply to your setup? The contact page is where to tell me—and yes, I’ll read every message.

No spam, no sales pitches, just real feedback. (And if you’ve got a tech problem that’s stumped you for days? Send it. I might write a guide about it.)

Thanks for trusting PC Fixes with your fixes. If there’s one thing I’ve learned from years of debugging, it’s this: the best solutions come from real problems—and the best guides come from real readers. So keep sending them.