Pablo #1: My SSD started snitching on itself

Sep 29, 2026· 6 min read

Part 1 of the Pablo saga, in five parts. This continues My SSD Suddenly Scared Me Out..., written mid-incident in July - same drive, full story. Next: Pablo #2: 98% Healthy, Apparently.

July 2026 - When a laptop started misbehaving and the logs started talking.

My first laptop was an inherited HP EliteBook 840 G2.

A fifth-generation Intel processor. 8 GB of DDR3L RAM. A 1366 × 768 TN display. And a 256 GB SATA SSD from CONSISTENT.

By modern standards, this thing was practically a museum exhibit. But to me, it was an entire world of possibilities - networking, Windows experiments, Linux, GitHub projects, a future in cybersecurity, all without doing everything on a phone.

I had plans for this machine.

Unfortunately, the machine had plans of its own.

The first sign of trouble

It didn't start with a dramatic blue screen. No explosion, no smoke, no cinematic cut to black.

Windows simply started acting weird. Sometimes I'd get stuck on the "Please wait" screen during login. Other times the wallpaper would appear but the desktop wouldn't behave. Occasionally a lock-screen loop before eventually getting in.

Eventually the desktop would load and the machine would become usable again.

Which was almost more annoying than a complete failure. If it had died outright, at least I'd have known something was wrong. Instead it worked just well enough to make me question whether anything serious was happening.

Windows had receipts

My first move was Event Viewer - the digital equivalent of reading someone's diary to figure out why they've been acting weird.

In the System log, disk-related events. Then I found it.

Event ID 7 - Source: disk.

The device, \Device\Harddisk0\DR0, has a bad block.

Not a one-off. The same error had appeared on:

• April 5, 2026
• May 17, 2026
• July 5, 2026
• July 27, 2026 - twice

The laptop had been leaving clues for months. Windows had been keeping receipts. I just hadn't checked them.

Enter SMART

The next question was what the SSD itself was reporting. I already had MonSMART (formerly Diskwatch) - one of my little Windows utilities, not built for this incident, and certainly not anticipating that it would become central to investigating a failing drive.

My initial data looked like this:

{
  "health": "PASSED",
  "endurance": 98,
  "attrs": {
    "5": 40,
    "9": 1617,
    "197": 40,
    "198": 30
  }
}

At first glance, PASSED and 98% looked comforting. Then I looked at the individual attributes:

Forty reallocated sectors. Forty pending sectors. Thirty offline uncorrectable sectors. I wasn't going to pretend I could decode every firmware detail from those numbers alone. But a drive reporting counters like these, with Windows already logging bad-block errors on top, was not something to wave away just because a utility printed a reassuring word.

Something wasn't adding up - and the 98% figure, as I'd soon learn at length, was measuring something narrower than it looked. More on that in Part 2.

Pablo enters the story

Eventually, I gave the SSD a name.

Pablo.

Because apparently, when a storage device starts behaving like a criminal mastermind, giving it a name makes the situation more manageable.

Pablo was a 256 GB CONSISTENT S6 SSD. At the time, I had no idea how quickly its counters would change, how many times I'd end up checking SMART output, or that the BIOS would eventually report an imminent drive failure.

For now, Pablo was simply the suspect.

And I wanted answers.

The BIOS warning

Then the laptop gave me something I really didn't want to see:

SMART Hard Disk Error Hard Disk 1 (301) SMART has detected an imminent failure.

An imminent failure. Not a vague Windows warning - the laptop's own firmware telling me the storage device was at risk. Suddenly those Event ID 7 errors going back to April made a lot more sense.

I went back to the diagnostics:

smartctl -a /dev/sda

smartctl -x /dev/sda

The second one asks for everything. And at one point the report said it plainly:

SMART overall-health self-assessment test result: FAILED!
Drive failure expected in less than 24 hours.

Less than 24 hours. There was an immediate practical problem attached to that sentence: my data was on that drive. Documents, projects, configs, password databases - everything I'd been accumulating. A replacement drive was one problem. Losing access to the data was an entirely different one.

And I wasn't going to gamble with the second one.

Here's the thing that made the entire situation so surreal: the SSD was still working. Windows booted. Applications ran. A failing storage device can keep going right up until the moment it doesn't, and every successful boot tempted me to treat the crisis as passed.

It wasn't. By this point I had three concrete pieces of evidence - unpredictable login behavior, months of bad-block errors, and sector counters climbing behind a PASSED status - and one decision was already clear:

I couldn't rely on Pablo.