Windows Gui becomes non responsive after "Done loading" #10646

fresheneesz commented at 7:48 PM on June 21, 2017: none

Describe the issue

When I opened the Bitcoin Core program, the GUI gets to "Done loading" and then hangs for about 5 minutes.

Can you reliably reproduce the issue?

Yes. After getting through the non responsiveness and shutting down bitcoin core properly, and restarting, I get the same behavior (attempted repro twice so far).

If so, please list the steps to reproduce below:

Open Bitcoin Core - Note that my state is having caught up with 66.43% of the blockchain and having just installed v0.14.2 over v0.14.1

Expected behaviour

The GUI should continue to be responsive. It should only say "Done loading" when its actually done loading (ie the main GUI should open immediately).

Actual behaviour

About 2 minutes 30 seconds after "Done loading" appears, the GUI locks up (Not responding listed in the task manager). The "Done loading" message remains there until the main GUI appears.

What version of bitcoin-core are you using?

Bitcoin Core version v0.14.2 (64-bit), official

Machine specs:

OS: Windows 8.1 64-bit
CPU: Intel Core i7-4702HQ @ 2.2 GHz
RAM: 8 GB
Disk size: 4TB HD for the blockchain, 250 GB SSD for the program and other (smaller) data
Network Speed: 50 Mbps

Any extra information that might be useful in the debugging process.

Here's my debug.log I grabbed while it's non responsive. Note that I did notice some logs were written while the GUI is unresponsive (note the weird empty space is exactly as it was in the log):

2017-06-21 19:40:25 



















2017-06-21 19:40:25 Bitcoin version v0.14.2
2017-06-21 19:40:25 InitParameterInteraction: parameter interaction: -whitelistforcerelay=1 -> setting -whitelistrelay=1
2017-06-21 19:40:25 Assuming ancestors of block 00000000000000000013176bf8d7dfeab4e1db31dc93bc311b436e82ab226b90 have valid signatures.
2017-06-21 19:40:25 GUI: "registerShutdownBlockReason: Successfully registered: Bitcoin Core didn't yet exit safely..."
2017-06-21 19:40:25 Default data directory C:\Users\fresheneesz\AppData\Roaming\Bitcoin
2017-06-21 19:40:25 Using data directory H:\Bitcoin
2017-06-21 19:40:25 Using config file H:\Bitcoin\bitcoin.conf
2017-06-21 19:40:25 Using at most 125 automatic connections (2048 file descriptors available)
2017-06-21 19:40:25 Using 32 MiB out of 32 requested for signature cache, able to store 1048576 elements
2017-06-21 19:40:25 Using 4 threads for script verification
2017-06-21 19:40:25 Using BerkeleyDB version Berkeley DB 4.8.30: (April  9, 2010)
2017-06-21 19:40:25 scheduler thread start
2017-06-21 19:40:25 Using wallet wallet.dat
2017-06-21 19:40:25 init message: Verifying wallet...
2017-06-21 19:40:25 CDBEnv::Open: LogDir=H:\Bitcoin\database ErrorFile=H:\Bitcoin\db.log
2017-06-21 19:40:26 Bound to [::]:8333
2017-06-21 19:40:26 Bound to 0.0.0.0:8333
2017-06-21 19:40:26 Cache configuration:
2017-06-21 19:40:26 * Using 2.0MiB for block index database
2017-06-21 19:40:26 * Using 8.0MiB for chain state database
2017-06-21 19:40:26 * Using 440.0MiB for in-memory UTXO set (plus up to 286.1MiB of unused mempool space)
2017-06-21 19:40:26 init message: Loading block index...
2017-06-21 19:40:26 Opening LevelDB in H:\Bitcoin\blocks\index
2017-06-21 19:40:26 Opened LevelDB successfully
2017-06-21 19:40:26 Using obfuscation key for H:\Bitcoin\blocks\index: 0000000000000000
2017-06-21 19:40:26 Opening LevelDB in H:\Bitcoin\chainstate
2017-06-21 19:40:26 Opened LevelDB successfully
2017-06-21 19:40:26 Using obfuscation key for H:\Bitcoin\chainstate: 2e24172acafd25a5
2017-06-21 19:40:31 LoadBlockIndexDB: last block file = 614
2017-06-21 19:40:31 LoadBlockIndexDB: last block file info: CBlockFileInfo(blocks=156, size=118252833, heights=427663...428149, time=2016-08-31...2016-09-03)
2017-06-21 19:40:31 Checking all blk files are present...
2017-06-21 19:40:31 LoadBlockIndexDB: transaction index disabled
2017-06-21 19:40:31 LoadBlockIndexDB: hashBestChain=00000000000000000251276de9928a6720e7d8485ed1dcea93fc59cd481d57e2 height=428062 date=2016-09-03 05:45:28 progress=0.664302
2017-06-21 19:40:31 init message: Rewinding blocks...
2017-06-21 19:40:33 init message: Verifying blocks...
2017-06-21 19:40:33 Verifying last 6 blocks at level 3
2017-06-21 19:40:33 [0%]...[16%]...[33%]...[50%]...[66%]...[83%]...[99%]...[DONE].
2017-06-21 19:40:34 No coin database inconsistencies in last 7 blocks (5026 transactions)
2017-06-21 19:40:34  block index            8006ms
2017-06-21 19:40:34 init message: Loading wallet...
2017-06-21 19:40:34 nFileVersion = 140200
2017-06-21 19:40:34 Keys: 102 plaintext, 0 encrypted, 102 w/ metadata, 102 total
2017-06-21 19:40:34  wallet                   55ms
2017-06-21 19:40:34 setKeyPool.size() = 100
2017-06-21 19:40:34 mapWallet.size() = 0
2017-06-21 19:40:34 mapAddressBook.size() = 1
2017-06-21 19:40:34 mapBlockIndex.size() = 472291
2017-06-21 19:40:34 nBestHeight = 428062
2017-06-21 19:40:34 torcontrol thread start
2017-06-21 19:40:34 AddLocal([2001:0:9d38:90d7:204a:599:b399:e59e]:8333,1)
2017-06-21 19:40:34 Discover: btbot - 2001:0:9d38:90d7:204a:599:b399:e59e
2017-06-21 19:40:34 init message: Loading addresses...
2017-06-21 19:40:34 UpdateTip: new best=000000000000000002acb7baee528ca1ceb1baa1e353f0128c79c19da41f061f height=428063 version=0x20000000 log2_work=85.218671 tx=153600730 date='2016-09-03 05:50:12' progress=0.664304 cache=1.1MiB(1192tx)
2017-06-21 19:40:34 Loaded 59995 addresses from peers.dat  345ms
2017-06-21 19:40:34 init message: Loading banlist...
2017-06-21 19:40:34 init message: Starting network threads...
2017-06-21 19:40:34 net thread start
2017-06-21 19:40:34 addcon thread start
2017-06-21 19:40:34 dnsseed thread start
2017-06-21 19:40:34 init message: Done loading
2017-06-21 19:40:34 msghand thread start
2017-06-21 19:40:34 opencon thread start
2017-06-21 19:40:35 UpdateTip: new best=000000000000000002504642e6ff9b1577af550c269f4537ad5b6e7f77247c25 height=428064 version=0x20000000 log2_work=85.218702 tx=153603533 date='2016-09-03 06:45:03' progress=0.664316 cache=5.8MiB(6990tx)
2017-06-21 19:40:35 GUI: Platform customization: "windows"
2017-06-21 19:40:35 GUI: PaymentServer::LoadRootCAs: Loaded  37  root certificates
2017-06-21 19:40:45 Loading addresses from DNS seeds (could take a while)
2017-06-21 19:40:51 95 addresses found from DNS seeds
2017-06-21 19:40:51 dnsseed thread exit
2017-06-21 19:41:36 UpdateTip: new best=0000000000000000024f493cccb8b4bb3491a2d15188188ebc773d36b2297946 height=428065 version=0x20000000 log2_work=85.218732 tx=153604452 date='2016-09-03 06:48:58' progress=0.664319 cache=7.7MiB(13053tx)

After the GUI became responsive again, I checked the logs again and found these additional ones:

2017-06-21 19:42:02 UpdateTip: new best=0000000000000000021fa6cb9f756d3e47bac8dc6c037132281e4c314469479b height=428066 version=0x20000000 log2_work=85.218763 tx=153606092 date='2016-09-03 07:05:13' progress=0.664326 cache=14.4MiB(16353tx)
2017-06-21 19:42:02 receive version message: /Satoshi:0.14.0/: version 70015, blocks=472292, us=76.102.26.97:55513, peer=0
2017-06-21 19:42:38 version handshake timeout from 1
2017-06-21 19:42:44 UpdateTip: new best=000000000000000001bef2c3fb53729c1ce61d6dd4bba3607432ec02760a4e4c height=428067 version=0x20000000 log2_work=85.218793 tx=153607101 date='2016-09-03 07:11:05' progress=0.664330 cache=18.4MiB(19877tx)
2017-06-21 19:43:22 UpdateTip: new best=0000000000000000007f9759c9eee376e3432e300b43aea53d1371e1fb143961 height=428068 version=0x20000000 log2_work=85.218823 tx=153607814 date='2016-09-03 07:16:39' progress=0.664333 cache=34.2MiB(22708tx)
2017-06-21 19:43:22 socket recv error An established connection was aborted by the software in your host machine.  (10053)
2017-06-21 19:43:30 UpdateTip: new best=000000000000000000194febb05d8d50e27721589815c29e9079a0c6ce84dca4 height=428069 version=0x20000000 log2_work=85.218854 tx=153608278 date='2016-09-03 07:20:14' progress=0.664335 cache=34.4MiB(23422tx)
2017-06-21 19:43:51 version handshake timeout from 3
2017-06-21 19:44:13 Pre-allocating up to position 0x800000 in rev00614.dat
2017-06-21 19:44:14 UpdateTip: new best=000000000000000001b5744ee46b55e194dfbfab4e04d2551c35e759bcada36b height=428070 version=0x20000000 log2_work=85.218884 tx=153610301 date='2016-09-03 07:41:36' progress=0.664343 cache=37.0MiB(27896tx)
2017-06-21 19:44:14 receive version message: /Satoshi:0.14.1(UASF-SegWit-BIP148)/: version 70015, blocks=472292, us=76.102.26.97:55649, peer=3
2017-06-21 19:44:14 receive version message: /Satoshi:0.13.99/: version 70014, blocks=472292, us=[2001:0:9d38:90d7:204a:599:b399:e59e]:55709, peer=4
2017-06-21 19:44:44 GUI:   OpenType support missing for script 11
2017-06-21 19:44:44 GUI:   OpenType support missing for script 11
2017-06-21 19:44:44 GUI:   OpenType support missing for script 11
2017-06-21 19:44:44 GUI:   OpenType support missing for script 11
2017-06-21 19:44:44 GUI:   OpenType support missing for script 11
2017-06-21 19:44:44 GUI:   OpenType support missing for script 11
2017-06-21 19:44:44 GUI:   OpenType support missing for script 16
2017-06-21 19:44:44 GUI:   OpenType support missing for script 16
2017-06-21 19:44:44 GUI:   OpenType support missing for script 16
2017-06-21 19:44:44 GUI:   OpenType support missing for script 16
2017-06-21 19:44:44 GUI:   OpenType support missing for script 16
2017-06-21 19:44:44 GUI:   OpenType support missing for script 16
2017-06-21 19:45:02 UpdateTip: new best=0000000000000000037dd64902467e3acb6430345e7fdbfef4f083ef94902a06 height=428071 version=0x20000000 log2_work=85.218914 tx=153611882 date='2016-09-03 07:51:29' progress=0.664350 cache=42.0MiB(32552tx)
2017-06-21 19:45:02 version handshake timeout from 5
2017-06-21 19:45:08 UpdateTip: new best=000000000000000003a3764345d934547c9ac733f56ff4935c98937a6b1a355c height=428072 version=0x20000000 log2_work=85.218945 tx=153612228 date='2016-09-03 07:53:22' progress=0.664351 cache=42.5MiB(33203tx)
2017-06-21 19:45:08 receive version message: /Satoshi:0.14.1/: version 70015, blocks=472292, us=76.102.26.97:55806, peer=6
2017-06-21 19:45:32 version handshake timeout from 6
2017-06-21 19:45:46 UpdateTip: new best=00000000000000000029fd454e3a6012529caeab947a2a2a4e9aa4f92ac0acf0 height=428073 version=0x20000000 log2_work=85.218975 tx=153613209 date='2016-09-03 07:59:02' progress=0.664355 cache=46.4MiB(36600tx)
2017-06-21 19:46:02 UpdateTip: new best=0000000000000000000d4c504f9826e1b1afb428f7ad3eb902ca988072d2f4b9 height=428074 version=0x20000000 log2_work=85.219006 tx=153613749 date='2016-09-03 08:01:38' progress=0.664357 cache=51.0MiB(38258tx)
2017-06-21 19:46:23 UpdateTip: new best=000000000000000004f973fa814cb6649cf1c6cb6a188ff726d4d4209cd71ee9 height=428075 version=0x20000000 log2_work=85.219036 tx=153614068 date='2016-09-03 08:03:24' progress=0.664358 cache=54.2MiB(39269tx)
2017-06-21 19:46:23 version handshake timeout from 7
2017-06-21 19:46:24 UpdateTip: new best=0000000000000000035fa95ebe65921b4401dc15d6579398b13df118539f58da height=428076 version=0x20000000 log2_work=85.219066 tx=153614136 date='2016-09-03 08:03:39' progress=0.664359 cache=54.3MiB(39406tx)
2017-06-21 19:46:24 receive version message: /Satoshi:0.14.1/: version 70015, blocks=472292, us=76.102.26.97:55861, peer=7
2017-06-21 19:47:16 UpdateTip: new best=00000000000000000349363ff458bd004a3c68b210685b440e51e7ef03453a3f height=428077 version=0x30000000 log2_work=85.219097 tx=153616131 date='2016-09-03 08:27:53' progress=0.664367 cache=56.9MiB(44652tx)

fresheneesz renamed this:
~~Gui becomes non responsive after "Done loading"~~
Windows Gui becomes non responsive after "Done loading"
on Jun 21, 2017

litebito commented at 9:48 PM on June 26, 2017: none

Hi,

I've a similar issue:

Describe the issue

When I opened the Bitcoin Core program, the GUI gets to "Done loading" and then hangs about 5 min. This was happening the last few days (v0.14.0). After continuing, it will start catching up/syncing (it is now 2 days behind). After a some time (I don't know exactly) the Bitcoin Core client freezes again, and it hangs indefenitly.

Can you reliably reproduce the issue?

Yes. At this moment, after killing the unresponsive Bitcoin Core, it now behaves the same every time: start, verifying blocks, at the moment I see "Done Loading" it hangs about 5 minutes, then continues, starts catching up, and freezes again after ? minutes. Restarted the PC a few times, restarted Bitcoin Core about 6 times already. I've upgraded from v0.14.0 to v0.14.2, no change in the behaviour.

If so, please list the steps to reproduce below: 1.Open Bitcoin Core - 2.Wait

Expected behaviour

The GUI should continue to be responsive. It should only say "Done loading" when its actually done loading (ie the main GUI should open immediately).

Actual behaviour

About 5 minutes after "Done loading" appears, the GUI locks up (Not responding listed in the task manager). The "Done loading" message remains there until the main GUI appears.

What version of bitcoin-core are you using?

Bitcoin Core version v0.14.2 (64-bit), official

Machine specs: •OS: Windows 8.1 64-bit •CPU: Intel Core i7 •RAM: 32 GB •Disk size: 4TB HD SATA 6GB/S (WD RED) with still 600GB free for the blockchain, 500 GB SSD for the program and other (smaller) data •Network Speed: 150 Mbps

laanwj commented at 8:16 AM on June 27, 2017: member

The UI never appears. It seems to get stuck at "Done loading"

This seems a duplicate of #10005.

laanwj added the label Windows on Aug 24, 2017

laanwj added the label GUI on Aug 24, 2017

Sjors commented at 5:15 PM on December 27, 2017: member

I'm seeing this on MacOS as well where "Done Loading" appears for several minutes and the activity monitor says the app is no longer responding

It's not during IBD. Once it unfreezes it starts syncing headers and downloading remaining blocks, e.g. a few days. This tends to be quite slow as well after the freeze, e.g. sync headers takes 30-60 seconds, then it takes several minutes before the blocks remaining count decreases. It then thinks it will take 22 hours to sync, though it speeds up after a while.

There's other applications, including btcd, bitcoind (not the same network as QT) and Eclair, in the background probably doing a lot of disk I/O and I set dbcache=5000 (on a 16 GB system).

This is the #11403 branch; I haven't tried on a release tag.

Sjors commented at 5:22 PM on December 27, 2017: member

@laanwj indeed this seems a duplicate of #10005, although that one is closed. I can copy-paste there if preferred.

It may also be the same as #11600. From @TheBlueMatt comment there "This happens when bitcoind isnt allowed to shut down cleanly after connecting many blocks with a large dbcache." - that might be the case for me as well. But the claim there that "the GUI problem has been solved" is certainly not the case here. It would be nice if the UI could someone tell the user what's going on, if we can detect it.

Sjors commented at 5:27 PM on December 27, 2017: member

According to the Activity Monitor QT is reading and writing several gigabytes of data without the "number of blocks left" changing substantially. CPU use is ~3% and memory a modest 340 MB. Is this "Rolling forward" process something that uses a lot of disk I/O without much memory and CPU?

Sjors commented at 6:30 PM on December 27, 2017: member

Some logs: https://gist.github.com/Sjors/a9a383175a6c00e126e090df61dd39e8 (note the block index 369541ms on line 44, which I think is where the UI stalled).

Important to mention txindex=1 for this node (I reindexed it a while ago for that).

skimanner commented at 8:57 PM on January 21, 2018: none

I’m having the same issue. Says done loading and then nothing happens, if I try to click the bitcoin core GUI it then changes to not responding in windows. Although like others have said it is using cpu/memory and heavy disk read/write as if it’s working on blocks.

After I let it just sit there for a long time it eventually just worked

MarcoFalke deleted a comment on Jan 21, 2018

mmatrosov commented at 5:53 PM on July 7, 2019: none

Same issue on v0.18.0. After the window with "Done loading" goes away and the main window is opened, the client starts to sync blocks as usual, but it happens VERY SLOW. Around 30 seconds per block. While before the problem it was syncing thousands of blocks per second.

Sieish commented at 7:17 AM on July 10, 2019: none

Having the same issue with bitcoin Core 17.1

Sieish commented at 7:18 AM on July 10, 2019: none

On a side note the hard drive is running a lil hot.

mmatrosov commented at 10:54 AM on July 13, 2019: none

Any workarounds to this at least? Is full resync going to help?

iperov commented at 11:53 AM on March 16, 2020: none

same issue 0.19.1

Slx-hub commented at 9:43 PM on March 16, 2020: none

Same for me. Takes seconds for each block and being unresponsive while syncing a block. Hard drive is at 100%

carlosmassa commented at 5:52 AM on April 9, 2020: none

Same issue with Bitcoin Core 0.19.1 and macOS High Sierra 10.13.6

mmortal03 commented at 10:51 AM on April 18, 2020: none

I just saw this same issue while testing 0.20.0rc1 on Windows. Mind you, this was after being about three weeks behind on downloading the blockchain on a low end machine, but whatever is causing this, it should ideally never be locking up the GUI thread, even on a slow machine, right? Anyway, I'll report back after syncing is complete and I can restart the GUI and test the GUI startup again.

Edit: Yep, looks like it's happening when you're behind by a good amount, as fully synced it didn't go non responsive at startup.

AndrewSav commented at 10:39 PM on July 5, 2020: none

Same issue v0.20.0 on windows

israelidanny commented at 1:58 PM on October 28, 2020: none

Same issue on 0.20.1 on Windows

Davideak commented at 8:02 AM on November 21, 2020: none

This happened to me on 0.20.1 the moment I added the following to my bitcoin.conf dbcache=2048 Although it did not actually increase the memory usage which is about 315mb

kidigital101 commented at 1:56 PM on January 7, 2021: none

had bad shutdown attempting to fix the loopback for another program that blockchain file is hefty 343GB now takes time to read that index and make sure everything is in order bad drives or bad spots on drives cause headaches, so does unreliable memory, heat is an issue, add fans run chkdsk <drive> /f /r /x as admin at cmd prompt and next reboot you should have it check and fix the drive after drive is repaired if loading still takes forever then reindex

Drjay84 commented at 5:54 PM on January 11, 2021: none

I too have this problem. Current version. Had just transferred to the wallet prior to it freezing up.

leviable commented at 4:59 PM on February 16, 2021: none

I had this issue, and the root cause appears to be the crummy, old, non-SSD hard drive I was attempting to use. Read/Write speeds were causing it to bog down, and thus the GUI bogged down. Switching my directory to a nice, newish SSD and copying over the bock and chainstate from the older HD immediately fixed everything.

fresheneesz commented at 8:27 PM on February 16, 2021: none

The program's UI should be on a separate thread from any process reading the hard drive. UI issues will be a huge problem until that happens.

dscotese commented at 6:48 PM on June 2, 2021: contributor

This might be a clue to solving this issue: Something in the Windows 10 OS I'm using causes the USB port to become unrecognizable every so often. This causes Bitcoin-qt to throw errors and shut down. Some hours later, I notice and start it again, and the condition described in this issue happens. Bitcoin-QT does something before it shuts down, and whatever that is seems to prevent the problem. If the program left some sort of marker when it starts that says "shutdown ops have not been completed" and then switched it to "Shutdown ops have been completed" when it completes them, it could report this whenever it starts and that marker is already present: "Previous shutdown was not clean, re[whatever]ing," and if possible, some estimation of how long the process will take, and maybe a warning that the importance of the cleanup operation requires that the GUI be ignored, so the user can expect the OS to report that the program is "not responding," and also rest assured that it is working to get back up to speed.

mmortal03 commented at 8:09 PM on June 2, 2021: none

Something in the Windows 10 OS I'm using causes the USB port to become unrecognizable every so often. This causes Bitcoin-qt to throw errors and shut down. Some hours later, I notice and start it again, and the condition described in this issue happens.

Devs are going to tell you that USB external hard drives are not a supported configuration, however, I also doubt the underlying issue here is just with USB external hard drives.

dscotese commented at 8:21 PM on June 2, 2021: contributor

Hopefully they back up the claim with some reasoning. My scanty computer science memory suggests that the external USB drive and the way the software uses it are designed to be orthogonal.

hebasto commented at 7:47 AM on October 3, 2021: member

Describe the issue

When I opened the Bitcoin Core program, the GUI gets to "Done loading" and then hangs for about 5 minutes.

It seems this is a duplicate of https://github.com/bitcoin-core/gui/issues/247.

Should be fixed now by https://github.com/bitcoin-core/gui/pull/342.

Closing?

MarcoFalke added this to the milestone 23.0 on Oct 4, 2021

MarcoFalke commented at 9:00 AM on October 4, 2021: member

Should be fixed in 23.0. Let us know if this is still an issue after the release of 23.0

MarcoFalke closed this on Oct 4, 2021

DrahtBot locked this on Oct 30, 2022