The things we got wrong
This page is a log of corrections—not a list of successes. Every site makes mistakes, but most never admit them publicly. Here, you’ll find the ones we caught, the ones we fixed, and the rules we wrote to stop them happening again.
The reader gets two things: a way to judge whether we take our own work seriously, and proof that we do. If we’re wrong about something important, we say so. If we’re wrong about something small, we still say so.
The difference is in how long it took us to notice.
Three we had to fix
These are the corrections that changed how we work. They’re listed in order of consequence, not chronology. The first was the worst.
The wrong troubleshooting steps for Windows 11’s ‘blue screen’
- 1A guide that sent users to the wrong fix
We published a step-by-step for resolving the ‘CRITICAL_PROCESS_DIED’ error in Windows 11, but the first three solutions assumed a corrupted system file—when the real cause was a third-party driver conflict. The guide stayed live for six weeks before a reader flagged it. By then, hundreds of users had followed the wrong path and wasted hours. Bridget Alvarado spotted the error when reviewing analytics: the same support ticket kept coming in with the exact same misdiagnosis. She rewrote the entire guide in 48 hours, tested it on three different setups, and pushed an update with a clear warning at the top.
- 2A Linux distro review with outdated package versions
Our review of Fedora 39 praised its ‘cutting-edge’ software stack—but the screenshots were from Fedora 38, and the benchmarks used an old kernel. The review had gone viral in tech forums, so the damage was already done. Bridget Alvarado pulled the article, re-tested every benchmark with the correct ISO, and added a note about how quickly Linux distributions can change. The new version included a checklist for readers to verify their own installations.
- 3A ‘quick fix’ for Outlook that bricked attachments
A tip titled *‘How to Recover Deleted Outlook Emails in 2 Minutes’* included a PowerShell script that worked—but only if the user hadn’t already run the built-in Outlook repair tool. The script overwrote the recovery folder, making emails permanently lost for some readers. It took three complaints before we caught it. Bridget Alvarado traced the issue to a forum post we’d cited without testing the full workflow.
What those three changed
These failures led to three rules we now follow: 1) Every troubleshooting guide must include a ‘verify your symptoms’ section before solutions. 2) Software reviews must list exact versions tested, with a note on how often updates break compatibility. 3) Scripts or automated fixes require a manual alternative and a disclaimer about potential data loss.
The log exists so we don’t forget why these rules matter.
Rules that came from mistakes
- 1) Test fixes on three different setups (from the *Windows 11 blue screen* guide). Now every ‘solution’ in a troubleshooting article is verified on a fresh install, an older OS version, and a non-standard configuration.
- 2) List exact software versions in reviews (from the *Fedora 39* review). Distro/OS versions, kernel numbers, and even browser versions are now pinned to the article’s metadata—and updated if they change mid-cycle.
- 3) Never assume a ‘quick fix’ is safe (from the *Outlook script* debacle). Automated steps now include a ‘last resort’ manual method, and a bolded warning about backing up first.
The people behind this
Bridget Alvarado is the founder and editor of Inbox Fix. You’ve just met her through the mistakes she fixed—first as the person who caught them, then as the one who rewrote the work to stop them happening again. That’s how this site operates: the log is the real introduction.
Keeping a public list of corrections is uncomfortable. It means admitting that even the things you’re proud of might be wrong, and that the people reading them will notice. But the alternative—pretending everything is perfect—is worse.
The only way to earn trust is to show where you’ve failed, and how you fixed it.
There’s a smaller mistake Bridget won’t put in the log because it was never public.
Early on, she wrote a guide on *‘How to Reset a Forgotten Windows Password’* that included a step to boot from a USB drive—without mentioning that most laptops ship with Secure Boot enabled, which blocks unsigned tools.
A reader messaged her privately to say they’d bricked their work machine trying it. She fixed the guide immediately, but the embarrassment stayed with her. That’s why the log exists: so the next time, the fix happens before anyone else gets hurt.
If you find something we got wrong, don’t just point it out. Use the contact page to tell us how it broke your workflow, what you expected instead, and whether you lost data or time because of it. The details matter—and they’ll help us make the next correction better.
There will be a next one
This list isn’t finished. We’ll add to it whenever we find something we missed, or when a reader helps us spot a flaw in our own work. The goal isn’t perfection—it’s honesty. If you’ve used Inbox Fix and something didn’t work as described, the contact page is where to tell us.
No shame, no silence: just the chance to fix it before someone else gets stuck.
The guides are grouped by category: App, Coding, Hardware, Operating System, Outlook and PowerPoint.