block checksum mismatch

[vulcancoins]

Hello,

I also started getting "block checksum mismatch" errors about a week-and-a-half ago. (today is 13 november 2025)
Restarting bitcoin-qt seems to alleviate the problem ... for a while.

Until it errors out again, always on chainstate/1284467.ldb
Deleting this file causes a resync, which seems to work ...

Until a few hours later ... debug.log shows:
Fatal LevelDB error: Corruption: block checksum mismatch: I:\bitcoin\chainstate/1284467.ldb

I am using bitcoin-core 30.0 on win11 25H2.
The blockchain is located on an (internal) 1Tb nvme sdd, ntfs 4k blocks. (WDC WDS100T2B0C-00PXH0)

s.m.a.r.t. claims my ssd is healthy.
I cleaned the ssd (using diskpart clean) and tested it by copying an 800gb file of random data file to the sdd and comparing it with the original.
No errors ...

I ran memtest86, no errors.

I keep a copy of the blockchain on a nas.
When the error occurred the chainstate on the nas was about two weeks old, 1284467.ldb did not yet exist.

I copied the backup to the sdd and launched bitcoin-qt again.
After synchronizing, some hours later the error reoccurred on the same file: 1284467.ldb

I am not using any virusscanner, and the built-in one I set to ignore the \bitcoin\* folder and bitcoin-qt.exe.
(And even if it was that, the file would/should be deleted/quarantined, not modified.)

I am at the end of my "troubleshooting-fu", hence my post here, hoping someone can shed some light as to what the underlying problem might be.

Apart from a complete resync, which might take weeks, I don't know what else to try.

Thanks in advance, for any pointers or clues.

PS This behaviour started shortly after the win11 update to 25H2, so I am assuming I'm not alone?


Update:

 I have run bitcoin-qt directly from the nas.

And the exact same error occurs:
Fatal LevelDB error: Corruption: block checksum mismatch: z:\bitcoin\chainstate/1284467.ldb

Which leads me to think it is not a hardware problem.


I have deleted everything in \chainstate
I have deleted everything in \blocks\index
I have deleted from \blocks all .rev files, and all blocks after blk05216.dat.

 bitcoin-qt claimed resynching was necessary, only 10 hours to  ...

[nc50lc]

I have deleted everything in \chainstate
I have deleted everything in \blocks\index
I have deleted from \blocks all .rev files, and all blocks after blk05216.dat.

 bitcoin-qt claimed resynching was necessary, only 10 hours to  ...

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.

PS This behaviour started shortly after the win11 update to 25H2, so I am assuming I'm not alone?

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.

[vulcancoins]

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.

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.

[philipma1957]

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.

[vulcancoins]

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.

[LoyceV]

(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.)

Bitcoin Core warns about this when running for the first time:

This initial synchronisation is very demanding, and may expose hardware problems with your computer that had previously gone unnoticed.

I've seen many topics about this over the years, even though I've never encountered these hardware problems myself.

[Cricktor]

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.

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...

[vulcancoins]

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.

[nc50lc]

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.)

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.

[LoyceV]

The thing is, the system I run bitcoin-qt on has been running for 5 years, up until now without problems.

Any chance it's filled with dust by now?

[Cricktor]

The thing is, the system I run bitcoin-qt on has been running for 5 years, up until now without problems.

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).