Bitcoin Core v25.0 Crashes

manfreddd commented at 1:54 pm on July 21, 2023: none

Is there an existing issue for this?

I have searched the existing issues

Current behaviour

Bitcoin Core keeps crashing and won’t stay up. I have been running a Bitcoin node on a Windows 10 computer for several years and had never experienced a Bitcoin Core crash before.

I had been running Bitcoin Core v0.21.1 since if first came out but left the node unattended for a few weeks this summer. I restarted it earlier this week and the Bitcoin Core log window showed its data base was several thousand blocks out of sync. The last I saw on the Bitcoin Core log window was that it had some 50 blocks to go to complete the synchronization. I do not know if the synchronization finished or not, but a few hours later I noticed the Bitcoin Core log window gone and the bitcoin-qt.exe process disappeared from the task manager process list.

I restarted Bitcoin Core and surprisingly the log window showed its data base was more than one thousand blocks out of sync. In other words, it lost a large number of blocks in the crash. I rebooted the windows computer and restarted Bitcoin Core three more times but it crashed within a few hours each time. I updated Bitcoin Core to v25.0 hoping that the latest version would fix the problem. Unfortunately, I tried v25.0 several times and it crashes within a few hours each time.

I reran Bitcoin Core from the command prompt window (bitcoind.exe) with the debug option and wrote its output to a file (bitcoinlog.txt), which I am including below to help identify the problem. I would really appreciate it if anyone would could give me some guidance on how to fix this problem, so I can get my Bitcoin node back up and running.

Expected behaviour

Expected my Bitcoin node to sync up to the Bitcoin blockchain and continue to load new blocks like it has reliably done for several years now.

Steps to reproduce

Restarted Bitcoin Core (bitcoin-qt.exe) after some 4 or 5 weeks offline.

Relevant log output

bitcoinlog.txt

How did you obtain Bitcoin Core

Pre-built binaries

What version of Bitcoin Core are you using?

v25.0

Operating system and version

Windows 10 Version 22H2

Machine specifications

Using a Windows 10 computer running Intel Core i7-8565 CPU with 8 GB RAM and 2 TB HDD.

maflcko commented at 2:13 pm on July 21, 2023: member

2023-07-21T03:41:15Z Setting file arg: dbcache = “4096”

Is there a reason why this is larger? IIRC, there is no data available that increasing it will improve performance on all available hardware. If other programs use 4 GB of memory, Bitcoin Core may run out of memory and crash.

Can you try again with less and then also check if block connection is faster? Currently it takes almost 2 minutes, which seems slow:

02023-07-21T05:59:12Z [bench] - Connect block: 45491.16ms [7951.41s (101941.10ms/blk)]

maflcko added the label Questions and Help on Jul 21, 2023

manfreddd commented at 8:03 pm on July 21, 2023: none

Thanks for the suggestion. I reran Bitcoin Core with dbcache=2048, but it crashed the same way after about 2.5 hours. Enclosing the logfile from this latest run. bitcoinlog.txt

besoeasy commented at 9:41 pm on July 21, 2023: none

@manfreddd can you share your CPU Usage screenshot ?

manfreddd commented at 10:11 pm on July 21, 2023: none

Sure, enclosing the Task Manager window screenshot (in Portuguese).

besoeasy commented at 11:07 pm on July 21, 2023: none

@manfreddd you using SSD ? your disc seems slow

your antivirus might be closing bitcoin process for p2p communication

manfreddd commented at 11:34 pm on July 21, 2023: none

Enclosing debug file from last Bitcoin Core run. debug.log

maflcko added the label Windows on Jul 22, 2023

maflcko commented at 5:58 am on July 22, 2023: member

Can you share the output of gettxoutsetinfo muhash, which would allow to compare the result to one on another machine to detect potential leveldb corruption.

manfreddd commented at 5:38 pm on July 22, 2023: none

I was not sure how best to get the gettxoutsetinfo muhash output. So, I ran Bitcoin Core three different ways:

Run from the command line with coinstatsindex option (Bitcoincore.org doc recommends it). debug CLI coinstatsindex.log
Run from the command line with no options. debug CLI.log
Run from the graphical user interface and gettxoutsetinfo muhash from command window (crashed within 10 minutes). debug GUI.log

maflcko added the label Data corruption on Jul 22, 2023

maflcko commented at 5:51 pm on July 22, 2023: member

Run from the graphical user interface and gettxoutsetinfo muhash from command window (crashed within 10 minutes).

It shouldn’t crash, so there may be data corruption that leads leveldb into a crash.

I am not sure how to debug crashes on Windows, so someone else will need to help you there. (Maybe gdb exists?)

Otherwise, you can discard the leveldb chainstate by doing a full -reindex-chainstate (takes a long time).

manfreddd commented at 6:37 pm on July 22, 2023: none

@MarcoFalke thank you for the support effort. Do I lose the Bitcoin data base loaded on my machine by discarding the leveldb chainstate?

russeree commented at 12:10 pm on July 23, 2023: contributor

Pretty sure this is the issue from your supplied ```Debug CLI.log"

2023-07-22T13:42:39Z Syncing coinstatsindex with block chain from height 0 2023-07-22T13:42:39Z ERROR: Commit: Failed to commit latest coinstatsindex state

adding the startup flag “-reindex-chainstate” should fix this issue. As per your previous concern you will be removing the levelDB indexes which are quite fast to rebuild. Approx ~7GB at hash 000000000000000000009b48061fe1b12f94ab54e71b289c5db97e0e5fd41874

manfreddd commented at 3:44 pm on July 23, 2023: none

@russeree thank you for joining the support effort. I ran Bitcoin Core with the option that you and @MarcoFalke recommended. Here is the command and command line error message produced.

C:\Users\xxxx>bitcoind -reindex-chainstate -debug Error: A fatal internal error occurred, see debug.log for details

This system won’t let me load the entire 365 MB debug.log file. So, I am displaying below the tail end of the file including the fatal error message.

2023-07-23T14:28:27Z [validation] BlockChecked: block hash=0000000000000a61ead02b42727201825ff0a8ff341efe2a955a8035a3230f2f state=Valid 2023-07-23T14:28:27Z [bench] - Connect total: 1.03ms [67.72s (0.38ms/blk)] 2023-07-23T14:28:27Z [bench] - Flush: 0.00ms [11.61s (0.07ms/blk)] 2023-07-23T14:28:27Z [bench] - Writing chainstate: 0.00ms [7.48s (0.04ms/blk)] 2023-07-23T14:28:27Z UpdateTip: new best=0000000000000a61ead02b42727201825ff0a8ff341efe2a955a8035a3230f2f height=178095 version=0x00000001 log2_work=68.070430 tx=2961131 date=‘2012-05-01T12:46:01Z’ progress=0.003461 cache=239.2MiB(1744167txo) 2023-07-23T14:28:27Z [bench] - Connect postprocess: 0.00ms [23.00s (0.13ms/blk)] 2023-07-23T14:28:27Z [bench] - Connect block: 2.57ms [709.32s (3.98ms/blk)] 2023-07-23T14:28:27Z [validation] Enqueuing BlockConnected: block hash=0000000000000a61ead02b42727201825ff0a8ff341efe2a955a8035a3230f2f block height=178095 2023-07-23T14:28:27Z [validation] Enqueuing UpdatedBlockTip: new block hash=0000000000000a61ead02b42727201825ff0a8ff341efe2a955a8035a3230f2f fork block hash=0000000000000516aebfa6b70f5aab82dde4a80d4fffc87a4a04debd0eb4dd0d (in IBD=true) 2023-07-23T14:28:38Z ERROR: ReadBlockFromDisk: Deserialize or I/O error - AutoFile::read: fread failed: iostream error at FlatFilePos(nFile=9, nPos=53762556) 2023-07-23T14:28:38Z *** Failed to read block 2023-07-23T14:28:38Z Error: A fatal internal error occurred, see debug.log for details 2023-07-23T14:28:38Z Failed to connect best block (Failed to read block) 2023-07-23T14:28:38Z loadblk thread exit 2023-07-23T14:28:38Z [validation] UpdatedBlockTip: new block hash=0000000000000afcd49292cd90ee17c114c65f705aa1d8589632e31742cd61f1 fork block hash=0000000000000a96ca9b83f0f145435c2c3e53c08a20bb4d1402ce807b671df7 (in IBD=true) 2023-07-23T14:28:38Z [net] received: pong (8 bytes) peer=17 2023-07-23T14:28:38Z [validation] BlockConnected: block hash=0000000000000516aebfa6b70f5aab82dde4a80d4fffc87a4a04debd0eb4dd0d block height=178094 2023-07-23T14:28:38Z [net] sending getheaders (1029 bytes) peer=17 2023-07-23T14:28:38Z [http] Interrupting HTTP server 2023-07-23T14:28:38Z [rpc] Interrupting HTTP RPC server 2023-07-23T14:28:38Z [rpc] Interrupting RPC 2023-07-23T14:28:38Z tor: Thread interrupt 2023-07-23T14:28:38Z opencon thread exit 2023-07-23T14:28:38Z addcon thread exit 2023-07-23T14:28:38Z [net] initial getheaders (798829) to peer=17 (startheight:799921) 2023-07-23T14:28:38Z torcontrol thread exit 2023-07-23T14:28:38Z msghand thread exit 2023-07-23T14:28:38Z [validation] UpdatedBlockTip: new block hash=0000000000000516aebfa6b70f5aab82dde4a80d4fffc87a4a04debd0eb4dd0d fork block hash=0000000000000afcd49292cd90ee17c114c65f705aa1d8589632e31742cd61f1 (in IBD=true) 2023-07-23T14:28:38Z [validation] BlockConnected: block hash=0000000000000a61ead02b42727201825ff0a8ff341efe2a955a8035a3230f2f block height=178095 2023-07-23T14:28:38Z net thread exit 2023-07-23T14:28:38Z [validation] UpdatedBlockTip: new block hash=0000000000000a61ead02b42727201825ff0a8ff341efe2a955a8035a3230f2f fork block hash=0000000000000516aebfa6b70f5aab82dde4a80d4fffc87a4a04debd0eb4dd0d (in IBD=true) 2023-07-23T14:28:38Z Shutdown: In progress… 2023-07-23T14:28:38Z [rpc] Stopping HTTP RPC server 2023-07-23T14:28:38Z [http] Unregistering HTTP handler for / (exactmatch 1) 2023-07-23T14:28:38Z [http] Unregistering HTTP handler for /wallet/ (exactmatch 0) 2023-07-23T14:28:38Z [rpc] Stopping RPC 2023-07-23T14:28:38Z [rpc] RPC stopped. 2023-07-23T14:28:38Z [http] Stopping HTTP server 2023-07-23T14:28:38Z [http] Waiting for HTTP worker threads to exit 2023-07-23T14:28:38Z [http] Waiting for HTTP event thread to exit 2023-07-23T14:28:38Z [http] Exited http event loop 2023-07-23T14:28:38Z [http] Stopped HTTP server 2023-07-23T14:28:39Z [net] Flushed 71865 addresses to peers.dat 249ms 2023-07-23T14:28:39Z DumpAnchors: Flush 2 outbound block-relay-only peer addresses to anchors.dat started 2023-07-23T14:28:39Z DumpAnchors: Flush 2 outbound block-relay-only peer addresses to anchors.dat completed (0.08s) 2023-07-23T14:28:39Z [net] disconnecting peer=0 2023-07-23T14:28:39Z [net] Cleared nodestate for peer=0 2023-07-23T14:28:39Z [net] disconnecting peer=1 2023-07-23T14:28:39Z [net] Cleared nodestate for peer=1 2023-07-23T14:28:39Z [net] disconnecting peer=7 2023-07-23T14:28:39Z [net] Cleared nodestate for peer=7 2023-07-23T14:28:39Z [net] disconnecting peer=12 2023-07-23T14:28:39Z [net] Cleared nodestate for peer=12 2023-07-23T14:28:39Z [net] disconnecting peer=13 2023-07-23T14:28:39Z [net] Cleared nodestate for peer=13 2023-07-23T14:28:39Z [net] disconnecting peer=14 2023-07-23T14:28:39Z [net] Cleared nodestate for peer=14 2023-07-23T14:28:39Z [net] disconnecting peer=17 2023-07-23T14:28:39Z [net] Cleared nodestate for peer=17 2023-07-23T14:28:39Z [net] disconnecting peer=18 2023-07-23T14:28:39Z [net] Cleared nodestate for peer=18 2023-07-23T14:28:39Z [net] disconnecting peer=19 2023-07-23T14:28:39Z [net] Cleared nodestate for peer=19 2023-07-23T14:28:39Z [net] disconnecting peer=20 2023-07-23T14:28:39Z [net] Cleared nodestate for peer=20 2023-07-23T14:28:39Z scheduler thread exit 2023-07-23T14:28:39Z [estimatefee] Recorded 0 unconfirmed txs from mempool in 0s 2023-07-23T14:28:39Z [bench] FlushStateToDisk: write block and undo data to disk started 2023-07-23T14:28:39Z [bench] FlushStateToDisk: write block and undo data to disk completed (70.58ms) 2023-07-23T14:28:39Z [bench] FlushStateToDisk: write block index to disk started 2023-07-23T14:28:39Z [leveldb] WriteBatch memory usage: db=index, before=0.0MiB, after=0.0MiB 2023-07-23T14:28:39Z [bench] FlushStateToDisk: write block index to disk completed (77.26ms) 2023-07-23T14:28:39Z [bench] FlushStateToDisk: write coins cache to disk (1744167 coins, 250827kB) started 2023-07-23T14:28:39Z [coindb] Writing partial batch of 16.00 MiB 2023-07-23T14:28:39Z [leveldb] WriteBatch memory usage: db=chainstate, before=0.0MiB, after=23.7MiB 2023-07-23T14:28:39Z [coindb] Writing partial batch of 16.00 MiB 2023-07-23T14:28:39Z [leveldb:debug] Level-0 table #8: started 2023-07-23T14:28:40Z [leveldb] WriteBatch memory usage: db=chainstate, before=23.7MiB, after=47.5MiB 2023-07-23T14:28:40Z [coindb] Writing partial batch of 16.00 MiB 2023-07-23T14:28:40Z [leveldb:debug] Current memtable full; waiting… 2023-07-23T14:28:41Z [leveldb:debug] Level-0 table #8: 15226868 bytes OK 2023-07-23T14:28:41Z [leveldb:debug] Delete type=0 #6 2023-07-23T14:28:41Z [leveldb:debug] Level-0 table #10: started 2023-07-23T14:28:41Z [leveldb] WriteBatch memory usage: db=chainstate, before=47.5MiB, after=47.9MiB 2023-07-23T14:28:41Z [coindb] Writing partial batch of 16.00 MiB 2023-07-23T14:28:41Z [leveldb:debug] Current memtable full; waiting… 2023-07-23T14:28:42Z [leveldb:debug] Level-0 table #10: 14843479 bytes OK 2023-07-23T14:28:42Z [leveldb:debug] Delete type=0 #7 2023-07-23T14:28:42Z [leveldb:debug] Compacting 1@1 + 1@2 files 2023-07-23T14:28:42Z [leveldb:debug] Level-0 table #13: started 2023-07-23T14:28:42Z [leveldb] WriteBatch memory usage: db=chainstate, before=47.9MiB, after=48.1MiB 2023-07-23T14:28:43Z [coindb] Writing partial batch of 16.00 MiB 2023-07-23T14:28:43Z [leveldb:debug] Current memtable full; waiting… 2023-07-23T14:28:43Z [leveldb:debug] Level-0 table #13: 16085920 bytes OK 2023-07-23T14:28:43Z [leveldb:debug] Delete type=0 #9 2023-07-23T14:28:43Z [leveldb:debug] Level-0 table #15: started 2023-07-23T14:28:44Z [leveldb] WriteBatch memory usage: db=chainstate, before=48.1MiB, after=47.6MiB 2023-07-23T14:28:44Z [coindb] Writing partial batch of 16.00 MiB 2023-07-23T14:28:44Z [leveldb:debug] Current memtable full; waiting… 2023-07-23T14:28:44Z [leveldb:debug] Level-0 table #15: 15214840 bytes OK 2023-07-23T14:28:44Z [leveldb:debug] Delete type=0 #11 2023-07-23T14:28:45Z [leveldb:debug] Level-0 table #17: started 2023-07-23T14:28:45Z [leveldb] WriteBatch memory usage: db=chainstate, before=47.6MiB, after=47.4MiB 2023-07-23T14:28:45Z [coindb] Writing final batch of 4.20 MiB 2023-07-23T14:28:45Z [leveldb:debug] Current memtable full; waiting… 2023-07-23T14:28:46Z [leveldb:debug] Level-0 table #17: 14420963 bytes OK 2023-07-23T14:28:46Z [leveldb:debug] Delete type=0 #14 2023-07-23T14:28:46Z [leveldb:debug] Level-0 table #19: started 2023-07-23T14:28:46Z [leveldb] WriteBatch memory usage: db=chainstate, before=47.4MiB, after=30.0MiB 2023-07-23T14:28:46Z [coindb] Committed 1744167 changed transaction outputs (out of 1744167) to coin database… 2023-07-23T14:28:46Z [bench] FlushStateToDisk: write coins cache to disk (1744167 coins, 250827kB) completed (7050.71ms) 2023-07-23T14:28:46Z [validation] Enqueuing ChainStateFlushed: block hash=0000000000000a61ead02b42727201825ff0a8ff341efe2a955a8035a3230f2f 2023-07-23T14:28:46Z [validation] ChainStateFlushed: block hash=0000000000000a61ead02b42727201825ff0a8ff341efe2a955a8035a3230f2f 2023-07-23T14:28:46Z [bench] FlushStateToDisk: write block and undo data to disk started 2023-07-23T14:28:46Z [bench] FlushStateToDisk: write block and undo data to disk completed (84.70ms) 2023-07-23T14:28:46Z [bench] FlushStateToDisk: write block index to disk started 2023-07-23T14:28:46Z [leveldb] WriteBatch memory usage: db=index, before=0.0MiB, after=0.0MiB 2023-07-23T14:28:46Z [bench] FlushStateToDisk: write block index to disk completed (130.45ms) 2023-07-23T14:28:46Z [bench] FlushStateToDisk: write coins cache to disk (0 coins, 23509kB) started 2023-07-23T14:28:46Z [coindb] Writing final batch of 0.00 MiB 2023-07-23T14:28:46Z [leveldb:debug] Current memtable full; waiting… 2023-07-23T14:28:47Z [leveldb:debug] Level-0 table #19: 15030435 bytes OK 2023-07-23T14:28:47Z [leveldb:debug] Delete type=0 #16 2023-07-23T14:28:47Z [leveldb:debug] Level-0 table #21: started 2023-07-23T14:28:47Z [leveldb] WriteBatch memory usage: db=chainstate, before=30.0MiB, after=6.2MiB 2023-07-23T14:28:47Z [coindb] Committed 0 changed transaction outputs (out of 0) to coin database… 2023-07-23T14:28:47Z [bench] FlushStateToDisk: write coins cache to disk (0 coins, 23509kB) completed (484.58ms) 2023-07-23T14:28:47Z [validation] Enqueuing ChainStateFlushed: block hash=0000000000000a61ead02b42727201825ff0a8ff341efe2a955a8035a3230f2f 2023-07-23T14:28:47Z [leveldb:debug] Level-0 table #21: 4255880 bytes OK 2023-07-23T14:28:47Z [leveldb:debug] compacted to: files[ 5 1 1 0 0 0 0 ] 2023-07-23T14:28:47Z Shutdown: done

russeree commented at 11:40 pm on July 23, 2023: contributor

Corrupted timechain or hardware issue.

02023-07-23T14:28:38Z ERROR: ReadBlockFromDisk: Deserialize or I/O error - AutoFile::read: fread failed: iostream error at FlatFilePos(nFile=9, nPos=53762556)
12023-07-23T14:28:38Z *** Failed to read block
22023-07-23T14:28:38Z Error: A fatal internal error occurred, see debug.log for details

The broken file is equal to nfile(number) which is your blk0009.dat. This could be a software or hardware issue.

To debug and fix this issue there are few possible solutions. An aside to this is the fact the none of these methods will resolve the issue if your disk is damaged and can’t store data properly. To quickly and easily diagnose a bad disk you can read the SMART info of your disk on Windows with a tool such as crystal disk mark. Post a screenshot if you have any trouble deciphering that information

Edit my answer is not recommended please see @MarcoFalke response below.

Here are the software fixes.

Delete all files blk0009.dat and greater. Then also delete rev0009.dat and every rev*.dat with a greater number. This method is essentially will force you to redownload the corrupt file and every block after. This should work with certainty.
Copy/rename your current blocks directory, delete all .dat and .rev files that are 9 and lower. Fire up bitcoin core wait until it has synced the 9th block file then. cut/copy files greater than blk0010.(dat/rev) and that should avoid a complete download of the timechain. As a note use -reindex=1 to ensure data consistency.

Please also make sure that your harddisk is not full as well.

Using the above methods if your disk is damaged may temporarily resolved the issue in the same manner that using duct tape to repair the head of a hammer that has fallen off. But eventually Bitcoin may try to write to the broken sector and you will face the same issue again. If the disk is damaged a new disk is very likely required.

maflcko commented at 6:26 am on July 24, 2023: member

Delete all files blk0009.dat and greater. Then also delete rev0009.dat and every rev*.dat with a greater number. This method is essentially will force you to redownload the corrupt file and every block after. This should work with certainty.

There is no need, nor recommendation, to do this manually. A simple -reindex (instead of -reindex-chainstate) is enough to do rewrite and check all block files on storage.

russeree commented at 6:45 am on July 24, 2023: contributor

Delete all files blk0009.dat and greater. Then also delete rev0009.dat and every rev*.dat with a greater number. This method is essentially will force you to redownload the corrupt file and every block after. This should work with certainty.

There is no need, nor recommendation, to do this manually. A simple -reindex (instead of -reindex-chainstate) is enough to do rewrite and check all block files on storage.

Does this still work if the actual disk sector is corrupt or would it still throw the fread failed: iostream error at FlatFilePos(nFile=9, nPos=53762556)

I have edited my response to reflect your answer.

maflcko commented at 6:57 am on July 24, 2023: member

Does this still work if the actual disk sector is corrupt or would it still throw the fread failed: iostream error at FlatFilePos(nFile=9, nPos=53762556)

Good point. This may actually still fail. I wonder if it makes sense to change that to make -reindex skip on exceptions instead of shutting down.

russeree commented at 10:17 am on July 24, 2023: contributor

What the file copy method solves in a way is the fact that when you copy and move that data you will likely get new sectors and as such if you have a bad secor you have a chance or not hitting it or at least hitting it with the same file.

Good point. This may actually still fail. I wonder if it makes sense to change that to make -reindex skip on exceptions instead of shutting down.

I would like to think about this for a bit before commenting further. With that said my first thought is that having a good solution to this even if it is as simple as very clear log level notifications would be a massive benefit to node runners while debugging failed disks or disk access requests from the OS.

Data consistency I assume is an issue if Core just skips over the worst case which is an invalid block on disk then that blkXXXX.{dat || rev} will not be valid until the device is replace or that data is moved to another sector. Another issue is how does the client know not to write data to that location again. These errors only show up when the reserved capacity of the drive has been used and it is not possible to allocate any more good sectors to replace the bad ones.

maflcko commented at 10:30 am on July 24, 2023: member

I would like to think about this for a bit before commenting further. With that said my first thought is that having a good solution to this even if it is as simple as very clear log level notifications would be a massive benefit to node runners while debugging failed disks or disk access requests from the OS.

Right. It may be better to adjust the error message to say that this is either a critical bug in the software, or a hardware issue. -reindex in both cases won’t solve the underlying problem. If the hardware is broken, the only solution is to run on hardware the is not broken. If there is a software bug, the only long term solution is to fix the bug.

manfreddd commented at 7:58 pm on July 24, 2023: none

I ran the wmic command “diskdrive get status” and came back with status “Ok”. I tried to run the CLI command “CHKDSK” but got message that disk was locked by another application. I reinitiated the computer and that included a disk repair job that ended with 100% completion. Also, I ran disk defragmentation, which hadn’t been done in a while and took forever to complete.

I did the above to try and eliminate or minimize the incidence of any disk issues in future Bitcoin Core runs. I started Bitcoin Core GUI and it is currently processing blocks on disk. This might take a while as it is processing blocks from 2014 or 5% progress at the moment.

russeree commented at 10:16 pm on July 24, 2023: contributor

Very good to hear. I believe this issue can be closed since you are now sycing and at 5% which means you would have more than the previous number of block files that was possible. Thus showing the Bitcoin Core software likely was not the issue but instead the issue existed at a hardware or OS level.

With that said I do believe there are improvements that could be implemented to make data access errors easier to debug. This issue is no uncommon especially amongst node runners that use second hard hardware.

manfreddd commented at 10:34 pm on July 24, 2023: none

Yes, I will just let it run and let you know the outcome. Thanks @russeree and @MarcoFalke for your guidance and support.

maflcko commented at 1:10 pm on July 26, 2023: member

Ok, closing for now. Let us know if this should be reopened.

maflcko closed this on Jul 26, 2023

Bitcoin Core v25.0 Crashes #28119