Btw, Pieter Wuille states on stackexchange that:
http://bitcoin.stackexchange.com/questions/41524/what-does-activating-best-chain-meanAt startup, it is possible that the first database contains blocks that could be valid but aren't part of the snapshot the second database represents. This can happen when you manually overwrite the block index (restoring from a backup, for example), but more commonly: because Bitcoin crashed after downloading some blocks that ended up being written to the block index, but the resulting chain state was never dumped to disk. When this happens, we will activate the best chain, loading blocks from the second database and applying them to the first (while doing full validation on them in the process).
Since Bitcoin Core heavily caches the chain state in memory, it is possible that there are hundreds or thousands of blocks missing from the chain state after an unclean shutdown. It can take a while to validate them again.
TL;DR: It's verifying blocks that were downloaded already but not processed yet (because the result of processing wasn't properly written to disk, most likely).
I wonder what cases exist currently where this issue occurs even after a supposed *clean* shutdown. Maybe there is some buggy behavior still present? I know, for instance, there was a bug fix following 0.12.0rc3, as pruned nodes were discovered to not be shutting down in the right state (and it was not due to unclean shutdowns, but simply due to a bug).
There's the following bug report, for others experiencing getting stuck at "activating best chain":
https://github.com/bitcoin/bitcoin/issues/7038I've also noticed that the "checkblocks" scan that occurs on every startup can be slow for people running particular configurations. At least that issue can be worked around by configuring bitcoin.conf (with checkblocks and checklevel), and it also gives us some sort of progress indication in Qt.