I have some bad experiences with btrfs and timeshift schedules. I have laptops seen freeze for minutes when creating a btrfs snapshot. I have not specifically looked if you are using this combination but it is something to check.

Do you have a Ryzen CPU by any chance? I had an issue like this for ages and it turns out it was a faulty Ryzen power state that was disabled by default on Windows, but not on Linux. If this happens to be your issue, there are ways you can disable the power state in software: https://wiki.archlinux.org/title/Ryzen#Soft_lock_freezing

There are many good answers here already, just wanted to add to it.

It sounds very much like what you’re seeing could be either a driver fault or a memory-related issue. Both can manifest as hard system freezes where nothing responds, not even Ctrl+Alt+Fx or SysRq. You mentioned this briefly before, and that still fits the pattern.

If it’s a driver issue, it’s often GPU or storage related. A kernel module crashing without proper recovery can hang the whole system—especially graphics drivers like NVIDIA or AMD, or low-level I/O drivers handling your SSD or SATA controller. Checking dmesg -T and journalctl -b -1 after reboot for GPU resets, I/O errors, or kernel oops messages might reveal clues.

If it’s memory pressure or the OOM killer, that can also lock a machine solid, depending on what’s being killed. When the kernel runs out of allocatable memory, it starts terminating processes to free RAM. If the wrong process goes first—say, something core to the display stack or a driver thread—you’ll see a full freeze. You can verify this by searching the logs for “Out of memory” or “Killed process” messages.

A failing DIMM or a bad memory map region could also behave like this, even if Windows seems fine. Linux tends to exercise RAM differently, especially with heavy caching and different scheduling. Running a memtest86+ overnight is worth doing just to eliminate that angle.

If your live USB sits idle for hours without freezing, that strongly hints it’s a driver or kernel module loaded in your main install, not a hardware fault. If it does freeze even from live media, you’re probably looking at a low-level memory or hardware instability.

The key next steps:

Check system logs after reboot for OOM or GPU-related kernel messages.

Run memtest86+ for several passes.

Try a newer (or older) kernel to rule out regression.

If it’s indeed a driver or OOM event, both would explain the “total lockup” behavior and why Windows remains unaffected. Linux’s memory management and driver model are simply less forgiving when something goes sideways.

Maybe easier to another suggestion, you're probably using a systemd based distros -

journalctl -b -1 will show you the logs from the previous boot, so you could check that after resetting to see if anything was logged

For some other ideas to narrow down where the issue is...

If you're stuck in the frozen state, you can Ctrl+alt+delete 7+ times quickly to tell systemd to try to restart the system. If this works, it means init was still able to process messages

If that doesn't work, you could enable Magic Sysrq Key (if disabled in your distro), and then use the key sequence REISUB to try to see if the kernel is still responding and can reset the system

https://wiki.archlinux.org/title/Intel_graphics#Baytrail_complete_freeze

Go to 6.15, there is your solution. I had the same very problem and with this it got solved.

the /var/log/ folder would be the best place to start.

1. When a random freeze occurs note the time. Try to be as accurate and close to the time it happened as you can, including day, hour, and minute.
         A. If possible, do this for multiple instances of this happening

2. Check various log files starting with syslog and look at the times noted above. Look for any relevant errors being thrown by the system at these times.

If it's freezing regularly, you could try booting a live usb of any Linux distro and see if it does the same thing. That will tell you relatively quickly if it's a hardware problem or a software problem.

Sounds to me like your swap is to small. I had similar behaviour on two systems. One with 8gb of ram and one with 16 gb.

this is important, and will help you find solutions much more specific than just "system freeze"

• Right after a crash, once you reboot, run journalctl -b -1 and scroll to the bottom. Look for any big red text, all of that will be very helpful to diagnose this issue

Otherwise,

• Does it freeze permanently, requiring a reboot, or for a few seconds?
  • If it's just for a few seconds, and you're on an AMD system, it would sound like an fTPM stutter. A BIOS update would likely fix that, it was a widespread issue.
• Are you using an AMD or NVIDIA GPU?
• Do you play any games or use any software that uses OpenGL? (Blender and minecraft are some I've had problems in before)

Others have already given some good advice, but rather than let it sit and wait to error, use the program "stress"

It'll work specific components hard which can help locate whether it's a CPU/Heat problem, or Memory, or disk.

And if it still fails on random things, take a long hard look at your PSU and measure voltages if you can. But if everything else checks out, motherboard could be it. Tiny cracks/dry joints, even inside the pcb layers, can lead to occasional problems that come and go with heat or vibration and are impossible to accurately diagnose beyond swapping it out.

dmesg/journalctl, then udev (udevadm monitor) and lsusb/lspci might be helpful too. Places to look at (only if you fiddled with them): /etc/fstab for mount options and do you maybe have a weird rule in /etc/udev, /etc/modprobe.d or /etc/sysctl?

I've had something similar a while ago. Trying a different distro or doing stuff on the software side didn't help.

What fixed the issue was getting a new hard drive because the old one was breaking down.

But maybe try other approaches first

Command line is your friend. It might not seem like it at first, but it is very helpful.

Use the journalctl command in a terminal.

Command Purpose Example
journalctl -u [SERVICE] View logs for a specific systemd unit/service. journalctl -u nginx.service
journalctl -b Show logs from the current boot. journalctl -b
journalctl -b -[N] Show logs from a previous boot (ee.g., -1 for the last boot). journalctl -b -1
journalctl --list-boots List all recorded boot sessions. journalctl --list-boots
journalctl -p [PRIORITY] Filter by priority level or a range. Levels are 0 (emerg) to 7 (debug). journalctl -p err..warning (shows errors, critical, alerts, and warnings)
journalctl --since="[TIME]" --until="[TIME]" Filter by time range. Supports absolute (YYYY-MM-DD HH:MM:SS) and relative times (1 hour ago, yesterday). journalctl --since "20 min ago"
journalctl -n [LINES] Show only the last N entries. journalctl -n 20
journalctl -k Show only kernel messages (equivalent to dmesg output). journalctl -k```

I spent a couple of days trying to figure out why I couldn't install any variant of Arch Linux or Fedora Linux on my laptop.  That command helped me narrow things down.

Had the same issue and it was my mouse causing the USB ports to stop working I realized that the clock was still working and it would go into hibernate. Just wouldn't respond to mouse or kb.

My guess... you have some hardware that Linux and Windows communicate with differently.

Either the hardware or the Linux driver is potentially broken.

If you're able to (hard with a laptop, I know), disconnect as many things as you can - even take out the Windows hardrive - and see if that helps.

For all the suggestions about the journal, you will see random things at the very end, but see if there's anything common from earlier in the boot process.

sudo journalctl -xe may be helpful here.

• sudo to ensure you're seeing the entire journal
• x adds additional explanations
• e jumps to the end (again, probably look further back)

Which distro are you on?

Was there a kernel update recently by chance? Have you tried falling back to an earlier version? Got any timeshift backups?

Unrelated, but I had something relatively similar once with my Inspiron 7520 laptop. In theory, that machine only supports 8GB of RAM, but technically I could put 16 into it and worked fine. Later I upgraded to a different machine and put this laptop aside, but sometimes I set it up if I go to friends place and need a PC to do some light multiplayer lan parties or such.

For a while, the laptop has a strange locking up issue when I booted 64 bit OSs. Or I don't know, after my testings, it seemed that booting a 64 bit OS would crash my machine sooner or later. Maybe even right after boot, maybe after when I logged in or used it for some time. Booting into Memtest also locked up eventually the laptop (but running the 32 bit version of Memtest didn't). Pulling out either memory stick (2x8GB) solved the issue, it worked with both sticks on both slots, if I used only one. The two sticks together on the other hand made my machine crash after boot, no matter which stick went to which slot.

Difference is that every OS did this, not just Debian, though Windows seemed to keep up longer in this case, but it also crashed on me.

Now I don't have this problem. It just... disappeared after not using the laptop for a while again.

So... if it's not software issue, maybe try to reseat your RAM sticks. Or use some compressed air to clean up the slots, maybe check the contacts of the sticks and clean them with some isopropyl and a soft brush.

It also can be storage issue, if your Windows install works fine on a different drive. Once I had an Ubuntu installed to the same laptop I mentioned and its HDD was failing hard, but the system kept up for a while, just had some really weird issues popping up here and there. But then eventually failed completely. Amongst the weird happenings, random freezes were also a thing with my bad HDD.

When your system freezes, can you still switch TTYs with e.g. Ctrl+Alt+F3 to debug?

On one of my systems Plasma occasionally hangs, but I can still switch to a different tty and kill it.

One thing that I did when distro hopping was to have /home be separate like you have, but I would back it up elsewhere and let it be a clean start which I could bring over what I wanted from the backup.

It was easier than hunting down which dotfile the new distro didn't like.

Explain how "freezed" are the system

• is the freeze sudden or does the system gets progressively slower?
• does the mouse cursor respond?
• does the audio keep playing in the background? does it repeat a short time interval over and over again?
• does the system respond to ping requests?
• does the system accept incoming ssh connections?
• how random is it? what time interval?
• is the location random (think consistent wifi / bluetooth devices nearby)
• is the freeze happening after going to sleep / hibernation / screen blank?
• does this happen if you aggressively open a lot of apps at the same time? Try it.

What to do before next system freeze

• update and upgrade the system
• create a working directory somewhere where you write down your findings. Does not have to be pretty or anything. Just for your own convenience.
• Configure REISUB. check files in /etc/sysctl.d/*.conf and look for kernel.sysrq=0. Change it to 1.
• Enable ctrl+alt+del spam reboot. Update /etc/systemd/system.conf so that you have a line looking like this:

CtrlAltDelBurstAction=reboot-force

• Reboot
• Try spamming ctrl+alt+del quickly. Does the system reboot?
• On next boot try switching to a random tty ctrl+alt+fN where N in {1..12}. You should see a login prompt. Try the REISUB sequence. Press and hold alt+print screen (might require some fn key combination on a laptop) then press, hold and release following letters one at a time: R E I S U B. You should see kernel messages appear on the screen each time you press a button. Don't try to press them all at once or type them before the output is finished. Your system should reboot after this. Does it work?
• make sure you can ping your computer from another computer.
• Configure TCPKeepAlive=no for my-faulty-pc in your ssh config before connecting to avoid having the connection dropped. then run ssh my-faulty-pc journalctl -b0 -k -f > waiting_for_crash.log on another system that will capture the log

reproduce Here is the easiest part. Make the system hang. Preferably with reproducible steps.

System is now freezed

• Go quickly through the first list
• from the remote host that monitors the logs through ssh. You can close the ssh connection and inspect some of the last lines in the file. Don't upload it anywhere before sanitizing it to avoid doxing yourself.
• from the remote system try ssh and pinging.
• on the frozen host try ctrl+alt+del burst first
• then try REISUB combo if the burst didn't work.

What to do now This part depends a bit on what the outcomes were. At least we'll know how "deep" the hang is and where it's worth modifying stuff.

You say in your post that you've tried ctrl+alt+del spam. But did you check that it works when the system is working as intended?

Edit: minor typo