Boot loop on Suface Pro 8

[oskeith]

Checklist

• I have searched for existing issues/discussions and didn't find any similar ones.
• I haven't used any other scripts, tools or programs that might have caused this issue.

Windows version

Windows 11 25H2

Script mode/options

Default Mode

Describe the issue

I had a clean install of windows on Jul 22, 2026 on a Surface Pro 8. After debloating, Windows crashes shortly after log in (either on the log in screen or right after) and boot loops.

Steps to reproduce

1. Clean install Windows 11 on Surface Pro 8
2. Run tool (Release 2026.07.11) in default mode

Error output

No response

Additional context

I realize it might be hard to diagnose, but I don't really know how to get any error logs given that I cant use the computer.

[HetCreep]

Sorry you're stuck -- let's get the machine back first; figuring out the exact cause comes after. One important piece of good news up front: Default mode automatically creates a System Restore point before changing anything (it's the first thing in the Default preset), so unless restore-point creation failed on your machine, you have a way back that doesn't need Windows to boot.

1. Get into recovery (WinRE)

Since Windows crashes at/after login, force the recovery environment: power the tablet off during the Windows logo (hold the power button ~10s), and repeat that 2-3 times -- Windows will boot into "Preparing Automatic Repair" -> Advanced options. (Surface alternative: with the device off, hold Volume-Up + Power until the Surface logo, release, then it boots to recovery options.)

2. Recovery ladder, in order

1. System Restore (Troubleshoot -> Advanced options -> System Restore): pick the restore point from the day you ran the tool (created just before it applied anything) and restore. This is the intended escape hatch and should get you booting again.
2. Safe Mode (Advanced options -> Startup Settings -> Restart -> press 4): if Safe Mode logs in fine, that alone is useful information -- and from there you can also run System Restore, or the tool's own Restore Backup (registry) from its GUI.
3. Startup Repair -- rarely fixes crash-after-login, but it's free to try.
4. Last resort if none of the above work: Reset this PC -> Keep my files.

3. Pulling logs without a working Windows (your question)

From WinRE: Troubleshoot -> Advanced options -> Command Prompt, plug in a USB stick, then copy these (note: inside WinRE your Windows drive may show as D: instead of C:, and the USB gets its own letter -- dir around to confirm):

• The tool's own run log + backups (from the folder you extracted the script to): Logs\Win11Debloat.log and the whole Backups\ folder -- these tell us exactly what was applied.
• Windows event logs: \Windows\System32\winevt\Logs\System.evtx and Application.evtx
• Crash dumps, if the crash is a BSOD: everything in \Windows\Minidump\

Example copy: copy D:\Windows\System32\winevt\Logs\System.evtx E:\

If you end up deciding to just clean-install again instead of restoring: please grab the logs above first -- or at minimum, install without formatting the partition, so the old system lands in C:\Windows.old (event logs, minidumps, and the tool's Logs/Backups folders all remain recoverable under it for about 10 days). A format wipes the evidence for good, and then there's nothing left to diagnose with.

4. Four answers that will pin this down

1. Is the crash a blue screen with a stop code (if so, which code), or a silent reboot?
2. Does Safe Mode survive login without crashing?
3. After the System Restore: is the machine stable again? That single data point does a lot of work -- stable-after-restore points at something in the applied changes; still-crashing-after-restore points away from them.
4. What prompted the clean install on Jul 22 in the first place? If the machine already had symptoms before it (random crashes, instability), that history matters a lot -- a clean install can't fix hardware/firmware/driver-level problems on a 2021-era device, and a crash-at-login on a Surface is a pattern that also shows up from display-driver/firmware issues entirely on its own. If it was just a routine fresh start with no prior symptoms, that's equally useful to know.

No verdict from me yet on whether the tool's changes are the cause -- Default mode only writes registry values, removes selected Store apps, and disables some scheduled tasks (no driver/servicing operations, which are the classic boot-loop makers), so the logs above are what will actually settle it. Post them here when you have them and we can dig in.

[oskeith]

Thanks for the detailed response!

Unfortunately, I needed to get the machine running asap again and had no data on it so I just did another clean install. I know it isn't helpful that I don't have logs, but I thought it might be a surface specific issue and opened an issue just to have it noted if anyone else has seen/sees this in the future.

To answer some of your questions though:

• the crash was a black screen with "Your device ran into a problem and needs to restart." I was not smart or quick enough to take a picture unfortunately.
• I did a clean install because I got it from a friend and the machine was running a Linux distro before.
• I haven't used the machine that much, but over the several hours (10 ish?) that I used it before and after, it has been stable.

[HetCreep]

Thanks for coming back with all four answers -- that's genuinely useful even without logs, and honestly, needing the machine back fast was the right call.

The Linux history changes the picture in an important way. Surface devices get their firmware and device drivers through Windows Update -- and a machine that ran Linux for a long time never received any of those. So right after your first clean install, Windows Update was almost certainly still pulling Surface firmware/driver updates in the background for quite a while. If the debloat run (and its Explorer restart / reboot) landed while that firmware/driver wave was still installing, a crash-loop from the collision is a very plausible story -- and it would have nothing to do with any specific setting the script changed. That would also explain why your second install has been stable for ~10 hours: by now the update wave has largely settled.

That's a hypothesis, not a verdict -- without the logs it can't be proven. But it fits every data point you gave: BSOD (driver/firmware-level, not a settings-level failure mode), Linux-before history, crash right after an early-life debloat run, stability now.

If you decide to try the script again, a sequence that de-risks it:

1. Let Windows Update run to fully clean first -- check for updates, install, reboot, repeat until nothing is offered (on a Surface this includes firmware; it can take several rounds).
2. While you're at it, glance at the Surface UEFI settings -- if Secure Boot was disabled for Linux, re-enable it.
3. Run the script only after that, and leave the restore point option checked (it's on by default in Default mode).
4. If it crashes again: this time the machine will have a restore point to roll back to, and the log-collection steps above will turn it into a fully diagnosable report -- a photo of the stop code alone would be gold.

And if you'd rather not re-run it at all, that's completely fine too -- this issue being on record with the Surface + fresh-install + Linux-history context is exactly the kind of breadcrumb that helps the next person who hits something similar.

[oskeith]

Ah yeah! That was an important detail I meant to include but forgot while writing. When I shut off the computer after debloating, there was a Windows update applied. That makes sense.

(And secure boot was re-enabled at the time.)

Thank you for your insight and this tool!

[HetCreep]

That detail settles it -- an update applying at shutdown right after the debloat run is exactly the collision window. Thanks for confirming; glad the machine's back. For the record: this case motivated #723 (a pre-flight check so the script warns when an update is mid-install or a reboot is pending), so your report is already paying forward. From my side this can be closed whenever @Raphire sees fit.