block checksum issue

Hey everyone, I've been running into these "block checksum mismatch" errors for about a week and a half now. Today's November 13, 2025, by the way. Restarting bitcoin-qt helps for a bit, but then the error pops back up, always pointing to chainstate/1284467.ldb. When I delete that file, it forces a resync, which usually does the trick... until a few hours later. My debug.log then throws a Fatal LevelDB error saying: Corruption: block checksum mismatch: I:\bitcoin\chainstate/1284467.ldb. I'm on bitcoin-core 30.0 running on Windows 11 25H2. My blockchain's stored on a 1Tb internal NVMe SSD, formatted with NTFS and 4k blocks (WDC WDS100T2B0C-00PXH0). S.M.A.R.T. says my SSD is in good condition. I even wiped the SSD using diskpart clean and tested it by moving an 800gb random data file to the SSD to verify everything matched. No issues there... I also ran memtest86 and it found no problems. I keep a backup of the blockchain on a NAS. When I hit the error, that chainstate on the NAS was about two weeks behind and didn’t have the 1284467.ldb file yet. I copied the backup to the SSD and fired up bitcoin-qt again. After syncing, the same error showed up on 1284467.ldb again after a couple hours. I’m not using any antivirus software, and I've set the built-in one to ignore the \bitcoin\* folder and bitcoin-qt.exe. Even if it was causing issues, those files would likely be deleted or quarantined, right? I feel like I'm out of options for troubleshooting, so I'm hoping someone here can help me figure out what the root of the problem is. Besides a full resync, which could take forever, I don't know what else to do. Thanks a ton for any help or suggestions.

This is because you did unnecessary steps. You already identified the issue which is just a corrupted file in your UTXO set. All you had to do is start Bitcoin Core with --reindex-chainstate command line arg and it'll rebuild it from your existing block files. But if your node is in prune mode, it'll have to redo IBD anyways. It's hard to associate this with Windows update. It's usually caused by sudden shutdown or anything that can corrupt the data while it's being written to disk / already written to disk. But that's also a possibility if it's caused any of the above.

Hello, thank you for your reply. "Just a corrupted file", is indeed what it was. But this shouldn't happen in a system running without hardly any error. (In my 40+ years of working with windows systems the odd hangup is usually contributed to bad software so I've become desensitized to blaming the hardware. Which it ultimately turned out to be.) I have tried -reindex-chainstate multiple times. Yet still, after a couple of hours, the error would come up again. Hence the steps I took. After that everything seemed to be ok. Seemed ... Until I found out that when verifying a backup (of unrelated data) errors also emanated. (a single bit in about 2TB worth of data) This made me run memtest86 again, and again and again. Only after the third pass, errors started occurring. Always the same memory range, always the same bits. (Which lead me to think one chip is failing.) When I turned of XMP (or D.O.C.P in AMD parlance) in the BIOS and ran memtest86 again three times in a row, the errors no longer occurred. :: So, to conclude: - It was/is a hardware problem after all, but because it only showed up under certain conditions very difficult to pinpoint. The next step is to replace the memory (reseating won't work, since it is clearly a single chip that is at fault and not a bad connection.) Anyway, again, thanks for your reply.

Yeah I built over 1000 pc's and ram can be wrong. BUT it can be more complex. Let's pretend you have 2 sticks of 16gb ram stick a shows an issue that repeats. If can be that stick a is bad and just replace the stick. If you  have 2 sticks pull 1 and do a lot of mem tests. If an error appears move the stick to the other slot If the error appears then it's the stick and a weak chip. But if the fault never shows you more likely have a micro fracture in the mobo. Or an intermittent short in the mobo. Or a bad slot which counts as the mobo. At times ì have had to make sure the mobo floats to the case ie a lot of nylon washers under the mobo connections to the case. It's rare but does happen.

In my case the error always occurred in the 0x04c0000000 to 0x4d000000 range, and always the third bit of the word. Moving sticks around would only hide the error to non-used regions, and is not a solution. Because of the specific address, it cannot be a motherboard problem, it must be individual chip related. I now (better) understand Linus Torvald's fulmination that ECC memory should be used in "customer grade" appliances per default. Having to remove chassis ground from motherboard ground is an effect of bad design and is prone to introduce other errors. Please don't do this. At worst, it might kill people.

Bitcoin Core warns about this when running for the first time: I've seen many topics about this over the years, even though I've never encountered these hardware problems myself.

Try to avoid using overclocking or otherwise tuned profiles for the RAM when you operate Bitcoin Core or other important pieces of software on that PC. Sometimes also the RAM manufacturer for some of those fancy (gamer?) RAM modules do silly things. Performance obsession sometimes comes with a prize (not what you wished...). I wish ECC RAM would be an easy option for any system. Intermittent or sporadic RAM errors are the worst...

True ... The thing is, the system I run bitcoin-qt on has been running for 5 years, up until now without problems. Just goes to show the age-old paradigm: "All hardware sucks, all software sucks." Don't put all your trust in them.

It's great to see that you already did almost all of the troubleshooting, isolating the cause of the issue to your machine's memory. Posting a reply containing the results is also a good thing for those who are in the same situation. Most of the posters here often leave their "issue" threads without explaining how it's solved.

Any chance it's filled with dust by now?

Well, what exactly does this tell us? Has this system been running Bitcoin Core in the past 5 years? If not, it doesn't say much in the context of your issues with Bitcoin Core. Good when it's fairly stable for the most part, the devil is in the details. Other applications might not have triggered your specific RAM failure because they simply have a different access pattern and utilisation of RAM. Certain RAM issues can be triggered by literally hammering the RAM, some fancy exploit techniques use some of these access stressing stuff. I don't try to squeeze the last ns out of theses day's PC RAM. I avoid the gamer stuff and try to use quality DRAM modules, nothing fancy, nothing from some unknown brands. I want stable RAM when it hasn't ECC and no too aggressive timings that might shoot me in the foot. From time to time I run the extensive and lengthy Memtest86+ checks in the hopes that it would spot RAM hardware issues of my various computers I use in my homelab. I agree with nc50lc that it's a welcome difference to some other posters who sometimes conclude just with "Solved it" and nothing more    which is ... (I have no kind words for such a behavior in a forum when other users tried their best to help and assist).