The good thing is, it's only the "UTXO Set" that's corrupted so the possible solution is the faster -reindex-chainstate.

If he'll delete the said file, Bitcoin Core will return with an error and will prompt him to -reindex instead.

There's something that's causing your transactions to get rejected from your own mempool.
There are a few reasons and the most common in not-yet-synced client is if at least one of the input of the transaction is invalid.

You can also try to manually broadcast it and see what mempool-related error you'll get:

• In the transactions tab, right-click on one of the transactions, then select: "Copy raw transaction"
• Open the console (Window->Console), then type: sendrawtransaction "Your_Copied_RAW_Transaction"
• And it should return with an error which should be the reason why those aren't successfully sent.

If it somehow proceed, then there could be in your setting that's preventing txn broadcast..

This only affects compatibility between the raw transactions exported by versions lower than 4.x and the newest.
So, it mainly affects Cold-Storage and MultiSig Electrum wallets that have different versions.

If you're using an outdated wallet for either 1 of the cosigners, update them all fist, then create the transaction.

Yeah, last time I zero-filled a 500GB WD Hard Drive, it took more or less 3 hours if my memory serves me right (that was 3 years ago).
Double that for a 1TB same speed HDD; although, the amount of time is still inconsequential if you want to re-use the disk.

You second~ed the replies yet you've countered their points :/

Anyways, what they meant by "writing 0's" is to 'low-level format' the drives which will turn all of the data on the drive into 0's (binary: 0 or 1).
There's nothing recoverable after that, your example software can only restore deleted files or a formatted drive, those are files which aren't really deleted but flagged as "overwritable".

It means that Armory cannot communicate with Bitcoin Core, you might need to add this to your Bitcoin Core's config file,
bitcoin.conf:

BTW, in that state, you wont be able to broadcast transactions using Armory.

That's problematic and indeed the cause of the corruption as seen in the logs.
My best guess is your Disk is having a hard time keeping up with the I/O, next is your RAM may be full.

When that happens, freeing-up some other processes may unfreeze Bitcoin Core since it should still be running in the background.

I think what you need to do is to find the cause why it's freezing in the first place.
Try to use as little "page file" as possible since Bitcoin Core itself will use lots of HDD processes.
To do that, you'll need to free some RAM space by reducing your background processes or add more RAM.
You can also read this: github.com/bitcoin/bitcoin/blob/master/doc/reduce-memory.md

Lastly, the wallet suggested above is a good alternative if you want to use other clients.

The yellow-highlighted ones are your "Change Addresses", those are addresses reserved to receive the change of your transactions.
Those will not appear in your 'receive' tab if you're using the tab.

That is quite the wrong place to do research.
You may need to go to somewhere else reputable, like the websites "The Bitcoin Wiki" and "Learn Me a Bitcoin".
Links:

• Bitcoin Wiki: https://en.bitcoin.it/wiki/Main_Page
• learnmeabitcoin: https://learnmeabitcoin.com/technical/

For example: Bitcoin Wiki has an entry about 'fee rate' under "Miner Fees" article - https://en.bitcoin.it/wiki/Miner_fees#Feerates

This is quite a relatively manageable error since you wont be needing to redownload the whole blockchain unless your node is pruned.
The 'fix' is to launch Bitcoin Core with -reindex-chainstate, then wait for it to finish (may take hours).

To start Bitcoin Core with that parameter:

• Go to the directory where Bitcoin Core is installed, usually C:/Program Files/Bitcoin
• 'Shift+RightClick' on an empty space in that folder (make sure nothing is highlighted), and select "Open PowerShell Window Here" or "Open CMD....".
• 'PowerShell' will open, type: ./bitcoin-qt -reindex-chainstate (remove "./" if you use CMD)
• Bitcoin Core will open and start the reindex process.

Note: To prevent that from happening, make sure to properly close Bitcoin Core everytime you need to close it.
Do not force-close it or shutdown the PC while it's running.

You can set it in bitcoin-qt's setting or in the config file.
Since you're using QT: Open the menu "Settings->Options...", then put a reasonable value in "Size of database cache".
More or less half of your RAM, depending on the usage.

That requires you to restart Bitcoin core as the red message below the setting will say.

The log should be in your Bitcoin data directory.
If you didn't set a custom one, it should be in: https://en.bitcoin.it/wiki/Data_directory#Default_Location (check your OS)
If you set a custom data directory, just open that folder and the debug.log file should be there.

Normally, you'd copy the wallet file from %appdata%/electrum/wallets and paste it to the same directory of the new Electrum.
The you can open it with the menu "File->Open". That's to preserve the wallet data that the seed phrase can't restore.

However, you said that you've been phished in that wallet so, it's safe not to import anything from that wallet.
Let's just hope that the hacker didn't stored your seed/keys and haven't stolen the newly sent coins.

You should start cmd in the directory where bitcoin-qt is located or change the working directory using "cd" command.
eg.:
Then enter the command vv181 instructed you to use.

The error may be logged before you opened bitcoind with reindex, have you experienced the same error after -reindex?
Yes you can, there's nothing in the debug log that can compromise your private keys, only some privacy-related info.

• (CMIIAW) I think you can delete the last block file and Bitcoin Core will detect it and issue -reindex then it will sync starting from the last valid block.
  However, if your blockchain is pruned, it will sync from start if you do that.
• Yes, but not just the blockchain, if you're going to back it up, you may as well backup the whole data directory.

If the error persist after reaching the height where you've encountered the error, your blockchain may have been corrupted by the sudden shutdown.
If so, you can open your "debug.log" file from bitcoin data directory (default location) to check for errors related to the corrupted block or for possible other issues.

If there's no error and you've reached the tip of the blockchain, then it's good.

Or use BTCRecover instead?
It has a seedrecover.py script that can bruteforce your 2 missing words; however, you'll need to provide an address or the master public key as reference.

Links:

• btcrecover: https://github.com/3rdIteration/btcrecover
• seedrecover quick start guide: https://github.com/3rdIteration/btcrecover/blob/master/docs/Seedrecover_Quick_Start_Guide.md

Use restore instead of create.
Example:
Enter the wallet name after the "-w" argument, and the private key(s) (with script type) after "restore".

The good thing is, there actually is a setting for that (start parameter or bitcoin.conf entry):
maxtxfee = sets the maximum transaction fee in BTC that your node can broadcast/relay,
The default is 0.1BTC, still too high but at least it can prevent >1BTC disasters.

Bitcoin-qt - 'Help->Command-line options', under "Debugging/Testing options:":

Test the "-l" argument first to see if your GPU is supported:

If yes, you just have to add the argument -gpu when searching for a vanity prefix.