Sometimes debugging starts with a neat error message, a useful stack trace and a reasonably obvious place to start looking.
This was not one of those times.
My Windows laptop had entered a restart cycle. Windows Automatic Repair would start, attempt to diagnose the problem, and ultimately tell me that it couldn't find anything wrong.
Which was particularly helpful considering Windows was very clearly not working.
Somewhere during all of this I had also encountered a warning relating to the Windows Recycle Bin and possible corruption. That immediately made the situation look considerably worse than it eventually turned out to be.
Thankfully, there were several very important signs that this wasn't catastrophic.
I could access Safe Mode.
BitLocker was working and I had access to my recovery keys.
My C:\ drive could still be mounted.
And, most importantly, my files appeared to be readable.
So before trying increasingly invasive repairs, I made a decision:
Don't fix anything yet. Get the data somewhere safe first.
And thus began what I have since affectionately named:
The 48-Hour Robocopy Adventure™
My plan sounded simple enough.
I had an external HDD available, formatted as exFAT, so I decided to use Robocopy from Safe Mode to copy the contents of C:\ onto it.
This wasn't intended to repair Windows.
It was insurance.
If I was going to start changing drivers, Windows configuration or anything else that could potentially make the situation worse, I wanted my data somewhere else first.
ChatGPT became my troubleshooting companion throughout this process. Rather than throwing random commands at Windows, I could describe what I was seeing, work through what each result meant, and decide what the next low-risk diagnostic step should be.
And at first, Robocopy behaved exactly as expected.
Files appeared.
Directories appeared.
More files appeared.
Then more directories.
And then I began discovering exactly how much stuff accumulates on a Windows development machine.
Robocopy Will Happily Show You Everything You've Forgotten About
There is something slightly surreal about watching an entire Windows installation scroll past you.
System32.
Program Files.
Steam.
Git.
VS Code history.
AppData.
Downloads.
Pictures.
npm caches.
Minecraft.
Temporary files.
And, naturally:
WinSxS.
So much WinSxS.
At various points I would see Robocopy apparently slow down and wonder whether something had gone wrong.
Usually the answer was:
No. It had just found something enormous.
One particularly memorable discovery was an Android virtual-device image weighing in at hundreds of gigabytes.
Ah.
That would explain the pause.
This was also not an entirely smooth 48-hour operation. At one point I had to interrupt a stalled copy and recover from it. At another point, several hours into the process, I realised something fairly important:
I hadn't made absolutely certain the laptop wouldn't go to sleep.
Nothing quite captures the glamour of software development like being several hours into a disaster-recovery copy and suddenly thinking:
"Wait. Can Windows still sleep?"
Back to PowerShell.
Back to ChatGPT.
Check the relevant power configuration, disable sleep and hibernation for the duration of the operation, and continue.
The copy marched onwards.
Meanwhile, My Development Environment Was... Fine
There was another realisation during all of this which made the situation considerably less frightening.
My laptop might have been having a terrible time.
My development environment wasn't.
I'd already structured my setup so that the important parts of my development environment lived on an external SSD: projects and the applications and tooling I need to get myself working again quickly.
That wasn't something I'd done specifically in preparation for this incident.
But suddenly its value became extremely obvious.
Had the laptop actually been unrecoverable, replacing the physical machine would have been annoying and potentially expensive.
It wouldn't, however, have meant reconstructing my entire development environment from memory.
That gave me one of the biggest lessons from the whole incident:
Your computer, your data and your development environment do not have to be the same thing.
The laptop is replaceable hardware.
My projects and data are not.
And my development environment should ideally be portable enough that losing one machine doesn't mean losing days rebuilding everything required to work.
BitLocker Wasn't the Problem Either
Seeing BitLocker during a failed Windows boot can initially add another layer of anxiety.
In my case, however, BitLocker was doing exactly what it was supposed to do.
I had my recovery keys.
The drive could be unlocked.
Safe Mode could access it.
And the files were readable.
Encryption hadn't caused the problem, and it wasn't preventing recovery.
That distinction became important:
Encryption and recoverability aren't opposites.
BitLocker protecting a drive is fine.
BitLocker protecting a drive when you've lost every recovery key is a very different situation.
This incident gave me a newfound appreciation for knowing where those keys are before you need them.
The Strange Recycle Bin Corruption Message
The corruption warning I'd encountered earlier was still sitting in the back of my mind.
At first it had sounded ominous.
A restart cycle plus Windows talking about corruption is exactly the sort of combination that makes you start imagining filesystem failure, damaged Windows components or dying storage.
But the evidence increasingly didn't support that theory.
The drive mounted.
Files were readable.
Safe Mode worked.
Robocopy was successfully reading huge portions of the filesystem.
Windows Automatic Repair hadn't identified the cause.
So rather than treating the word "corruption" as the diagnosis, I started treating it as what it actually was:
one symptom among several.
That turned out to be rather important.
Preservation Before Repair
By this stage I'd effectively separated the incident into two different jobs.
Job 1: Protect the data
Robocopy.
External drive.
Verify that the important files exist somewhere other than the affected machine.
Job 2: Find out why Windows won't boot
Only once Job 1 was sufficiently under control did I feel comfortable becoming more aggressive with Job 2.
This changed the psychology of troubleshooting considerably.
Instead of every experiment carrying the thought:
"What if this destroys something important?"
I had a recovery path.
That's something I'll carry into future incidents:
Before trying to repair a system, decide whether you first need to preserve the system.
Those aren't necessarily the same operation.
And Then We Found aswNetHub
After nearly two days of Robocopy, Safe Mode, Windows diagnostics, filesystem observations and general investigation, the actual root cause turned out to be rather less dramatic than the journey getting there.
The investigation eventually led to:
aswNetHub
This is an Avast network-related driver.
More importantly, it was configured as a system-start driver.
That immediately made it interesting.
Normal Windows startup loaded it.
Safe Mode didn't behave the same way.
Safe Mode worked.
Normal Windows didn't.
That difference gave us something useful to investigate.
I disabled aswNetHub.
Then came the slightly terrifying bit.
Reboot.
Windows started.
There was initially a black screen for a few minutes, which wasn't exactly reassuring after everything that had happened.
Then the wallpaper appeared.
Then the taskbar.
Then Windows was back.
The restart cycle was gone.
After approximately 48 hours of recovery work, the ultimate culprit was one network driver.
Of course it was.
So Was the 48-Hour Robocopy Pointless?
No.
And I think that's probably the most important part of this entire story.
If I'd known at the beginning that aswNetHub was responsible, I could have disabled it almost immediately.
But that's not how root-cause analysis works.
You don't begin an investigation knowing the root cause.
You gather evidence.
You eliminate possibilities.
You protect the things that matter.
You make increasingly informed decisions.
And you try very hard not to turn one problem into three new ones.
Robocopy didn't fix my computer.
What Robocopy did was give me the confidence to continue diagnosing the computer without putting my data unnecessarily at risk.
I didn't spend 48 hours fixing a driver.
I spent 48 hours making sure I could afford to be wrong while figuring out which driver needed fixing.
That's a rather different thing.
ChatGPT's Role in the Recovery
There's another part of this experience worth talking about because AI-assisted development and troubleshooting is becoming increasingly normal.
I used ChatGPT throughout the incident.
But I wouldn't describe what happened as:
"ChatGPT fixed my laptop."
That's not really accurate.
It was closer to having an interactive technical rubber duck sitting beside me for two days.
I could report:
- what Windows was doing;
- what Safe Mode showed;
- what Robocopy was currently copying;
- what commands returned;
- whether networking was behaving differently;
- what changed after a reboot.
Then we could reason about the next step.
That distinction matters to me.
I was still sitting at the machine.
I was still deciding which commands to execute.
I could stop when something didn't look right.
I could challenge a suggestion.
And because the conversation retained the context of the incident, I didn't have to reconstruct the entire situation for every individual question.
For an incident that stretched across roughly 48 hours, that continuity was genuinely useful.
AI didn't replace understanding the machine.
It helped me maintain a structured investigation while I was tired, staring at Safe Mode and watching several hundred gigabytes crawl through Robocopy.
Things I Would Do Differently Next Time
The experience definitely changed how I'd approach another Windows failure.
For starters, I probably wouldn't immediately Robocopy the entire Windows drive again.
Watching WinSxS, caches, temporary files, installed applications and enormous Android images consume time and disk space taught me that lesson fairly effectively.
I'd prioritise irreplaceable data first:
- personal files;
- development projects not already backed up;
- configuration files;
- PowerShell profiles and scripts;
- credentials and recovery material that can safely be backed up;
- anything else that cannot simply be downloaded or reinstalled.
Only after securing those would I consider whether a complete drive-level copy was actually useful.
I'd also make sure my recovery keys remain organised and accessible independently of the affected computer.
And I'm keeping the external development SSD strategy.
That one proved itself.
One More Backup Before Calling It Done
Once Windows was working again, there was one particularly important little file I wanted copied somewhere safe:
my PowerShell $PROFILE.
After everything we'd just been through, losing a heavily customised PowerShell environment because it existed in only one place suddenly seemed like an unnecessarily exciting future adventure.
So that got Robocopied over to the external SSD too.
Because apparently once you've spent 48 hours using Robocopy, eventually you start using it for everything.
What I Took Away From the Incident
The obvious lesson is that a third-party driver can cause surprisingly dramatic Windows startup failures.
But that isn't actually the lesson I value most.
The bigger ones are these:
A scary error isn't necessarily the root cause.
The Recycle Bin corruption warning looked significant. It wasn't the thing ultimately preventing Windows from starting.
Safe Mode is evidence, not merely a recovery button.
The fact that Safe Mode worked while normal startup didn't gave us information about where the problem might be.
Protect your data before performing risky repairs.
Diagnosis is easier when every experiment isn't gambling your files.
Keep recovery credentials somewhere recoverable.
BitLocker wasn't a problem because I still had the keys required to access my own drive.
Separate your development environment from the physical machine where practical.
My laptop temporarily becoming unusable didn't mean my entire development setup disappeared with it.
And perhaps most importantly:
Root-cause analysis is allowed to take you down paths that don't ultimately contain the root cause.
Those paths aren't necessarily wasted effort.
Sometimes they're what make the next diagnostic step safe.
The Five-Minute Fix That Took 48 Hours to Find
Looking back, there's something rather funny about the scale difference.
The failure looked catastrophic.
The recovery copy took nearly two days.
Windows Automatic Repair couldn't diagnose it.
I went through Safe Mode, BitLocker, Robocopy, power settings, filesystem concerns, enormous Android images, external storage and enough Windows directories to last me quite happily for several years.
And then:
aswNetHub
Disable one problematic driver.
Reboot.
Hello, desktop.
If I'd known the answer at the beginning, this would have been a five-minute story.
But I didn't.
And that's debugging.
