Recovering Funds From Wallet.dat

jay · October 10, 2020, 1:52am

I’m running ZecFull Node and haven’t updated my computer in a while.
I stated my wallet and it wouldn’t sync with the network.
I copied my wallet.dat into a safe place, and updated the zec wallet.

When I try to open the wallet with the old wallet.dat file it’s refuses to work.
I get these errors:

CWallet::GenerateNewKey(): AddKey failed
CDB: Error -30972, can’t open database

This is the debug file:

Oct 09 20:49:26.288 INFO main: Zcash version v4.0.0-9786156 (2020-09-09 18:26:02 -0700)
Oct 09 20:49:26.296 INFO Init: main: Using OpenSSL version OpenSSL 1.1.1a 20 Nov 2018
Oct 09 20:49:26.296 INFO Init: main: Using BerkeleyDB version Berkeley DB 6.2.23: (March 28, 2016)
Oct 09 20:49:26.296 INFO Init: main: Default data directory C:\Users\AppData\Roaming\Zcash
Oct 09 20:49:26.296 INFO Init: main: Using data directory C:\Users\AppData\Roaming\Zcash
Oct 09 20:49:26.296 INFO Init: main: Using config file C:\Users\AppData\Roaming\Zcash\zcash.conf
Oct 09 20:49:26.296 INFO Init: main: Using at most 125 connections (2048 file descriptors available)
Oct 09 20:49:26.296 INFO Init: main: Using 4 threads for script verification
Oct 09 20:49:26.296 INFO main: scheduler thread start
Oct 09 20:49:26.297 INFO Init: main: Loading Sapling (Spend) parameters from C:\Users\AppData\Roaming\ZcashParams\sapling-spend.params
Oct 09 20:49:26.297 INFO Init: main: Loading Sapling (Output) parameters from C:\Users\AppData\Roaming\ZcashParams\sapling-output.params
Oct 09 20:49:26.297 INFO Init: main: Loading Sapling (Sprout Groth16) parameters from C:\Users\AppData\Roaming\ZcashParams\sprout-groth16.params
Oct 09 20:49:27.353 INFO Init: main: Loaded Sapling parameters in 1.056153s seconds.
Oct 09 20:49:27.356 INFO Init: main: HTTP: creating work queue of depth 16
Oct 09 20:49:27.356 INFO Init: main: Config options rpcuser and rpcpassword will soon be deprecated. Locally-run instances may remove rpcuser to use cookie-based auth, or may be replaced with rpcauth. Please see share/rpcuser for rpcauth auth generation.
Oct 09 20:49:27.356 INFO Init: main: HTTP: starting 4 worker threads
Oct 09 20:49:27.357 INFO Init: main: Using wallet wallet.dat
Oct 09 20:49:27.357 INFO Init: main: init message: Verifying wallet…
Oct 09 20:49:27.357 INFO Init: main: CDBEnv::Open: LogDir=C:\Users\AppData\Roaming\Zcash\database ErrorFile=C:\Users\joshu\AppData\Roaming\Zcash\db.log
Oct 09 20:49:27.360 INFO Init: main: Bound to [::]:8233
Oct 09 20:49:27.360 INFO Init: main: Bound to 0.0.0.0:8233
Oct 09 20:49:27.360 INFO Init: main: Cache configuration:
Oct 09 20:49:27.360 INFO Init: main: * Using 2.0MiB for block index database
Oct 09 20:49:27.360 INFO Init: main: * Using 120.0MiB for chain state database
Oct 09 20:49:27.360 INFO Init: main: * Using 328.0MiB for in-memory UTXO set
Oct 09 20:49:27.360 INFO Init: main: init message: Loading block index…
Oct 09 20:49:27.361 INFO Init: main: Opening LevelDB in C:\Users\AppData\Roaming\Zcash\blocks\index
Oct 09 20:49:27.393 INFO Init: main: Opened LevelDB successfully
Oct 09 20:49:27.393 INFO Init: main: Opening LevelDB in C:\Users\AppData\Roaming\Zcash\chainstate
Oct 09 20:49:28.091 INFO Init: main: Opened LevelDB successfully
Oct 09 20:49:31.267 INFO Init: main: LoadBlockIndexDB: last block file = 24
Oct 09 20:49:31.267 INFO Init: main: LoadBlockIndexDB: last block file info: CBlockFileInfo(blocks=381, size=110056132, heights=107754…108470, time=2017-05-03…2017-05-04)
Oct 09 20:49:31.267 INFO Init: main: Checking all blk files are present…
Oct 09 20:49:31.280 INFO Init: main: LoadBlockIndexDB: transaction index disabled
Oct 09 20:49:31.280 INFO Init: main: LoadBlockIndexDB: insight explorer disabled
Oct 09 20:49:31.280 INFO Init: main: LoadBlockIndexDB: light wallet daemon disabled
Oct 09 20:49:31.313 INFO Init: main: LoadBlockIndexDB: hashBestChain=0000000052f3ab593e92d43f09a793bfa2d5f9df8f3d27a3a43d7f970cdb487f height=108359 date=2017-05-04 19:06:54 progress=0.031257
Oct 09 20:49:31.313 INFO Init: main: init message: Rewinding blocks if needed…
Oct 09 20:49:33.706 INFO Init: main: init message: Verifying blocks…
Oct 09 20:49:33.706 INFO Init: main: Verifying last 288 blocks at level 3
Oct 09 20:49:36.379 INFO Init: main: No coin database inconsistencies in last 27 blocks (363 transactions)
Oct 09 20:49:36.794 INFO Init: main: block index 9434ms
Oct 09 20:49:36.794 INFO Init: main: init message: Loading wallet…
Oct 09 20:49:36.803 INFO Init: main: nFileVersion = 2010250
Oct 09 20:49:36.803 INFO Init: main: Keys: 103 plaintext, 0 encrypted, 103 w/ metadata, 103 total
Oct 09 20:49:36.803 INFO Init: main: ZKeys: 1 plaintext, 0 encrypted, 1 w/metadata, 1 total
Oct 09 20:49:36.807 INFO Init: main: wallet 13ms
Oct 09 20:49:36.808 INFO Init: main: init message: Rescanning…
Oct 09 20:49:36.808 INFO Init: main: Rescanning last 108359 blocks (from block 0)…
Oct 09 20:49:36.822 INFO Init: main: rescan 14ms
Oct 09 20:49:36.822 INFO Init: main: SetBestChain(): Couldn’t start atomic write
Oct 09 20:49:36.823 INFO Init: main: init message: Activating best chain…
Oct 09 20:49:36.823 INFO Init: main: mapBlockIndex.size() = 108360
Oct 09 20:49:36.823 INFO Init: main: nBestHeight = 108359
Oct 09 20:49:36.823 INFO Init: main: setKeyPool.size() = 101
Oct 09 20:49:36.823 INFO Init: main: mapWallet.size() = 2
Oct 09 20:49:36.823 INFO Init: main: mapAddressBook.size() = 1
Oct 09 20:49:36.823 INFO main: txnotify thread start
Oct 09 20:49:36.824 INFO Init: main: init message: Loading addresses…
Oct 09 20:49:36.824 INFO main: torcontrol thread start
Oct 09 20:49:36.852 INFO Init: main: Loaded 11025 addresses from peers.dat 28ms
Oct 09 20:49:36.860 INFO Init: main: AddLocal([2001:1970:55e6:0:ca09:a8ff:fe96:fb36]:8233,1)
Oct 09 20:49:36.860 INFO Init: main: Discover: DESKTOP-4BF5STN - 2001:1970:55e6:0:ca09:a8ff:fe96:fb36
Oct 09 20:49:36.860 INFO Init: main: AddLocal([2001:1970:55e6:0:829:6d09:af34:6fa]:8233,1)
Oct 09 20:49:36.860 INFO Init: main: Discover: DESKTOP-4BF5STN - 2001:1970:55e6:0:829:6d09:af34:6fa
Oct 09 20:49:36.860 INFO Init: main: AddLocal([2001:1970:55e6:0:ac44:deef:1efd:4b78]:8233,1)
Oct 09 20:49:36.860 INFO Init: main: Discover: DESKTOP-4BF5STN - 2001:1970:55e6:0:ac44:deef:1efd:4b78
Oct 09 20:49:36.860 INFO Init: main: init message: Done loading
Oct 09 20:49:36.860 INFO main: dnsseed thread start
Oct 09 20:49:36.860 ERROR Init: main: ContextualCheckTransaction(): overwinter is not active yet
Oct 09 20:49:36.860 ERROR Init: main: AcceptToMemoryPool: ContextualCheckTransaction failed
Oct 09 20:49:36.860 ERROR Init: main: ContextualCheckTransaction(): overwinter is not active yet
Oct 09 20:49:36.860 ERROR Init: main: AcceptToMemoryPool: ContextualCheckTransaction failed
Oct 09 20:49:36.860 INFO main: net thread start
Oct 09 20:49:36.861 INFO main: opencon thread start
Oct 09 20:49:36.861 INFO main: msghand thread start
Oct 09 20:49:36.861 INFO main: addcon thread start
Oct 09 20:49:47.874 INFO main: Loading addresses from DNS seeds (could take a while)
Oct 09 20:49:48.621 INFO main: 139 addresses found from DNS seeds
Oct 09 20:49:48.621 INFO main: dnsseed thread exit
Oct 09 20:49:48.825 INFO main: receive version message: /MagicBean:4.0.0/: version 170013, blocks=1001157, us=0.0.0.0:0, peer=1
Oct 09 20:49:48.825 INFO main: Added time data, samples 1, offset +0 (+0 minutes)
Oct 09 20:49:49.758 INFO main: receive version message: /MagicBean:4.0.0/: version 170013, blocks=1001157, us=[2001:1970:55e6:0:829:6d09:af34:6fa]:59370, peer=2
Oct 09 20:49:49.758 INFO main: Added time data, samples 2, offset +0 (+0 minutes)
Oct 09 20:49:53.251 INFO ProcessNewBlock: main: UpdateTip: new best hash=000000006482c356758d4ba84c13bf7ad7f39aee53cfbed782877f775667cdcb height=108360 bits=486573628 log2_work=49.464423 tx=566381 date=2017-05-04 19:10:28 progress=0.031258 cache=0.1MiB(24tx)
Oct 09 20:49:53.272 INFO ProcessNewBlock: main: UpdateTip: new best hash=00000000098ec784e61ac7ba7e569fd10149ed7aefbe920357e639e7a434bf8b height=108361 bits=486573252 log2_work=49.464439 tx=566382 date=2017-05-04 19:10:47 progress=0.031258 cache=0.1MiB(25tx)
Oct 09 20:49:53.293 INFO ProcessNewBlock: main: UpdateTip: new best hash=0000000027d703cec0307fe2d29b7a43b40bdf786c57c7b0ed09edb71e201ab4 height=108362 bits=486573295 log2_work=49.464454 tx=566390 date=2017-05-04 19:13:45 progress=0.031258 cache=0.2MiB(41tx)
Oct 09 20:49:53.529 INFO ProcessNewBlock: main: UpdateTip: new best hash=0000000028ba7d1dc760f8cb539aaa73ff017d31a8e698b630863129930fda21 height=108363 bits=478134380 log2_work=49.46447 tx=566404 date=2017-05-04 19:17:04 progress=0.031259 cache=9.8MiB(598tx)
Oct 09 20:49:53.545 INFO ProcessNewBlock: main: UpdateTip: new best hash=00000000166b68cff6a04ff930de5728abee21081ff82a1d402371a436245382 height=108364 bits=478012627 log2_work=49.464486 tx=566413 date=2017-05-04 19:20:51 progress=0.031260 cache=10.0MiB(620tx)
Oct 09 20:49:53.557 INFO ProcessNewBlock: main: UpdateTip: new best hash=000000001e284e5336b4ac654578ff3a7f0eea602c85a80d8fe42857c2415ef0 height=108365 bits=477969412 log2_work=49.464502 tx=566416 date=2017-05-04 19:22:20 progress=0.031260 cache=10.0MiB(625tx)
Oct 09 20:49:54.565 INFO ProcessNewBlock: main: Pre-allocating up to position 0xc00000 in rev00024.dat
Oct 09 20:49:54.812 INFO ProcessNewBlock: main: UpdateTip: new best hash=0000000074f7dbeecbdf2d635833ee5d40b39137121b38829364cf0a63f9d55d height=108366 bits=478072211 log2_work=49.464519 tx=566477 date=2017-05-04 19:24:58 progress=0.031263 cache=183.3MiB(11114tx)
Oct 09 20:49:54.924 INFO ProcessNewBlock: main: UpdateTip: new best hash=000000003b2f2bebe166746ff8bc401b470eebb897537d536a20b4d76e8d6319 height=108367 bits=478008371 log2_work=49.464535 tx=566495 date=2017-05-04 19:33:26 progress=0.031264 cache=189.5MiB(11517tx)
Oct 09 20:49:55.022 INFO ProcessNewBlock: main: UpdateTip: new best hash=000000001ad48933a6b1d62de7ceeafe86b7ca1726d5f3d508bb2ee65af8b2d5 height=108368 bits=477997181 log2_work=49.464551 tx=566502 date=2017-05-04 19:34:24 progress=0.031265 cache=194.9MiB(11865tx)
Oct 09 20:49:55.105 INFO ProcessNewBlock: main: UpdateTip: new best hash=000000003b4bf406797a93333ae312f221d16823bda22e675bfcb97e202a759d height=108369 bits=477860874 log2_work=49.464568 tx=566505 date=2017-05-04 19:34:35 progress=0.031265 cache=199.8MiB(12176tx)
Oct 09 20:49:55.131 INFO ProcessNewBlock: main: UpdateTip: new best hash=0000000054bad6983de3f9398f790d403b8a21cd781deaa31bdb2387f5b3f1e0 height=108370 bits=477835700 log2_work=49.464584 tx=566510 date=2017-05-04 19:36:40 progress=0.031265 cache=199.9MiB(12181tx)
Oct 09 20:49:55.146 INFO ProcessNewBlock: main: UpdateTip: new best hash=00000000128dc2087f3e8567c9cb7f09d34073d87a68b3034c1e7d35d713784c height=108371 bits=477673449 log2_work=49.464601 tx=566511 date=2017-05-04 19:38:30 progress=0.031265 cache=199.9MiB(12182tx)
Oct 09 20:49:55.223 INFO ProcessNewBlock: main: UpdateTip: new best hash=00000000747b2f80d95947753df5f6c835e6584463250eb3f6d1c73398e599e3 height=108372 bits=477730622 log2_work=49.464618 tx=566514 date=2017-05-04 19:38:47 progress=0.031265 cache=204.7MiB(12483tx)
Oct 09 20:49:55.237 INFO ProcessNewBlock: main: UpdateTip: new best hash=000000003cd405ec801c7b39f0675e9a2a8765e7bf3ed66ff36a1a7cb49c8cfc height=108373 bits=478073041 log2_work=49.464634 tx=566516 date=2017-05-04 19:40:24 progress=0.031265 cache=204.7MiB(12486tx)
Oct 09 20:49:55.310 INFO ProcessNewBlock: main: UpdateTip: new best hash=000000006538db4e874a00b49ae31817db46ec30f9558111abc02059b85d5c9a height=108374 bits=477951334 log2_work=49.46465 tx=566520 date=2017-05-04 19:40:36 progress=0.031266 cache=209.4MiB(12799tx)
Oct 09 20:49:55.419 INFO ProcessNewBlock: main: UpdateTip: new best hash=00000000700b468d59837c3a83be6ef61ca88d22129856eb0bd09cf69469cb40 height=108375 bits=477925582 log2_work=49.464667 tx=566530 date=2017-05-04 19:43:13 progress=0.031266 cache=214.4MiB(13111tx)
Oct 09 20:49:55.534 INFO ProcessNewBlock: main: UpdateTip: new best hash=000000005fab56d75e519f60dae28e33f0bce95d842af69a1e42bbe99b048ffa height=108376 bits=477975554 log2_work=49.464683 tx=566536 date=2017-05-04 19:43:42 progress=0.031266 cache=219.8MiB(13451tx)
Oct 09 20:49:55.553 INFO ProcessNewBlock: main: UpdateTip: new best hash=000000004895abd83e866d022c8843159c693cc68a0c2c0c86e6fc1fc0439700 height=108377 bits=477957724 log2_work=49.464699 tx=566539 date=2017-05-04 19:47:42 progress=0.031267 cache=219.9MiB(13457tx)
Oct 09 20:49:55.712 INFO ProcessNewBlock: main: UpdateTip: new best hash=000000004ad8cc009f5defda02e03c91492c6f8e089cb4b66e62dc5066054013 height=108378 bits=477925935 log2_work=49.464716 tx=566541 date=2017-05-04 19:49:24 progress=0.031267 cache=219.9MiB(13459tx)
Oct 09 20:49:55.774 INFO ProcessNewBlock: main: UpdateTip: new best hash=000000007c1bb4d5fd5fc88113d6dee0333a31672f7464e35f8a8993b537fb00 height=108379 bits=477901096 log2_work=49.464732 tx=566548 date=2017-05-04 19:50:06 progress=0.031267 cache=225.0MiB(13784tx)
Oct 09 20:49:55.798 INFO ProcessNewBlock: main: UpdateTip: new best hash=0000000009426c975bf349a9e5f2d3fc63b4f2d5f60d45d3ed21b2de6f187c21 height=108380 bits=477838832 log2_work=49.464749 tx=566558 date=2017-05-04 19:52:23 progress=0.031268 cache=225.1MiB(13802tx)
Oct 09 20:49:55.814 INFO ProcessNewBlock: main: UpdateTip: new best hash=0000000067484c2bfd37da6536b5231e6ea300eea3b14a9f212656d9e28e171f height=108381 bits=477655223 log2_work=49.464766 tx=566560 date=2017-05-04 19:53:55 progress=0.031268 cache=225.1MiB(13804tx)
Oct 09 20:49:56.901 INFO ProcessNewBlock: main: UpdateTip: new best hash=0000000003cd787d9795d391841eeb41e397c29544bffe94df29afafc77eb485 height=108382 bits=477631699 log2_work=49.464783 tx=566615 date=2017-05-04 19:54:03 progress=0.031271 cache=324.2MiB(20524tx)
Oct 09 20:49:58.239 INFO ProcessNewBlock: main: UpdateTip: new best hash=000000003c2755f7d05bf494f6b624639e46d2fa36d7f1f713b8deaa1df1827f height=108383 bits=477631605 log2_work=49.4648 tx=566620 date=2017-05-04 19:55:30 progress=0.031271 cache=8.8MiB(508tx)
Oct 09 20:49:58.292 INFO ProcessNewBlock: main: UpdateTip: new best hash=00000000290092b51dcc89a18d8f28fb62967f46d5508c761a1494427cd96191 height=108384 bits=477673156 log2_work=49.464817 tx=566633 date=2017-05-04 19:57:55 progress=0.031272 cache=16.5MiB(1013tx)
Oct 09 20:49:58.310 INFO ProcessNewBlock: main: UpdateTip: new best hash=000000006c6cc692d00e3acb0ce52bf4383b3f4e49d8a2f6fe0b981dc03b3129 height=108385 bits=477546213 log2_work=49.464834 tx=566635 date=2017-05-04 19:59:50 progress=0.031272 cache=16.5MiB(1016tx)
Oct 09 20:49:58.319 INFO main: receive version message: /MagicBean:4.0.0/: version 170013, blocks=1001157, us=24.150.179.254:59373, peer=3
Oct 09 20:49:58.319 INFO main: Added time data, samples 3, offset -1 (+0 minutes)
Oct 09 20:49:59.082 INFO ProcessNewBlock: main: Pre-allocating up to position 0xd00000 in rev00024.dat
Oct 09 20:49:59.288 INFO ProcessNewBlock: main: UpdateTip: new best hash=000000006cc604d4b3837eeaf9c21fdb47f27c597886aaed43d5e0c28335ff34 height=108386 bits=477473295 log2_work=49.464851 tx=566697 date=2017-05-04 20:03:33 progress=0.031275 cache=183.3MiB(11542tx)
Oct 09 20:49:59.302 INFO ProcessNewBlock: main: Pre-allocating up to position 0x8000000 in blk00024.dat
Oct 09 20:49:59.319 INFO ProcessNewBlock: main: UpdateTip: new best hash=00000000427ae0bcd35690d45ffc81d002d43bca9863ef6e56482898b7bd6b72 height=108387 bits=477344437 log2_work=49.464869 tx=566703 date=2017-05-04 20:04:53 progress=0.031276 cache=183.4MiB(11552tx)
Oct 09 20:49:59.392 INFO ProcessNewBlock: main: UpdateTip: new best hash=00000000603999f370bbe7d92d75ab115cfcaedf41488df63b7212bdfed4f6de height=108388 bits=477254413 log2_work=49.464887 tx=566707 date=2017-05-04 20:05:46 progress=0.031276 cache=188.1MiB(11854tx)
Oct 09 20:49:59.408 INFO ProcessNewBlock: main: UpdateTip: new best hash=0000000040001e0ab562e35a889667eae2c83f182c5b1ad9caad0f5dfe01c977 height=108389 bits=477175043 log2_work=49.464905 tx=566708 date=2017-05-04 20:06:09 progress=0.031276 cache=188.1MiB(11855tx)
Oct 09 20:49:59.635 INFO ProcessNewBlock: main: UpdateTip: new best hash=0000000019f2c46c5afcbb70dcabb1577b6a56e6d4e300c3ce140683aaa2e046 height=108390 bits=476861308 log2_work=49.464923 tx=566712 date=2017-05-04 20:06:40 progress=0.031276 cache=193.2MiB(12194tx)
Oct 09 20:50:00.520 INFO ProcessNewBlock: main: UpdateTip: new best hash=00000000169e85e6c8bc7d6f0661a35c52a85ed85437df79aa121e4295802953 height=108391 bits=476840778 log2_work=49.464942 tx=566769 date=2017-05-04 20:08:00 progress=0.031279 cache=298.4MiB(19164tx)
Oct 09 20:50:01.460 INFO main: tor: Thread interrupt
Oct 09 20:50:01.460 INFO main: torcontrol thread exit
Oct 09 20:50:01.460 INFO main: scheduler thread interrupt
Oct 09 20:50:01.460 INFO main: addcon thread interrupt
Oct 09 20:50:01.522 INFO main: net thread interrupt
Oct 09 20:50:01.604 INFO main: msghand thread interrupt
Oct 09 20:50:01.941 INFO main: txnotify thread interrupt
Oct 09 20:50:03.707 INFO main: opencon thread interrupt
Oct 09 20:50:03.708 INFO Shutdown: main: StopRPC: waiting for async rpc workers to stop
Oct 09 20:50:03.709 INFO Shutdown: main: StopNode()

jay · October 10, 2020, 2:21am

I really don’t care about getting the wallet to work I just want to extract my funds.
It’s only been 6 months since I updated my wallet so I’m not sure why Zcash Wallets are so volatile.

Also here’s the db file:

BDB2506 file wallet.dat has LSN 1/175835, past end of log at 1/167
BDB2507 Commonly caused by moving a database from one database environment
BDB2508 to another without clearing the database LSNs, or by removing all of
BDB2509 the log files from a database environment
BDB2516 DB_ENV->log_flush: LSN of 1/175835 past current end-of-log of 1/167
BDB2517 Database environment corrupt; the wrong log files may have been removed or incompatible database files imported from another environment
BDB3027 wallet.dat: unable to flush page: 13
BDB4519 txn_checkpoint: failed to flush the buffer cache: BDB0087 DB_RUNRECOVERY: Fatal error, run database recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery
BDB0060 PANIC: fatal region error detected; run recovery

artkor · October 10, 2020, 8:03am

Hello! If wallet.dat file the only thing that You have (private keys are missing), then You may try the recovery method that helped me - Как я восстановил wallet.dat который выдавал ошибку чтения

Autotunafish · October 10, 2020, 3:21pm

Always check to see if theres a new version, they’re released often because unlike some other projects the Zcash protocol is being actively developed. Your idea of wallet volatility is based on less dynamic projects then this.
Running the latest version should work (perhaps with a reindex)

jay · October 10, 2020, 5:18pm

That’s exactly what broke my access to my funds.
I can’t even access the wallet after updating, and I’ve tried reindexing and resyncing

jay · October 10, 2020, 5:19pm

Is there an English thread?

Autotunafish · October 10, 2020, 5:38pm

Does running Zcashd manually give these errors?

jay · October 10, 2020, 5:53pm

I couldn’t find documentation on running zcashd on windows manually. All I could find is linux docs.
The ones I found for windows were
zcashd.exe -rescan
zcashd.exe -reindex

But even these are useless because I can’t find the place to run them. Even if I go to were the zcash wallet is installed it can’t the this zcashd program

I think it has something to do with the LSN of my wallet.dat after reading the error messages and debug files. I just don’t know how to update.

Autotunafish · October 10, 2020, 11:20pm

Sry phone died, zcashd is in resources\bin\win of your zecwallet directory

jay · October 10, 2020, 11:57pm

I started the resync, what happens when it finishes?
Should I be able to open the fullnode app?

Autotunafish · October 11, 2020, 1:31am

Zecwallet should connect to the external zcashd instance but if its syncing you might leave it be for now and see if fails again and then you’ll have a better idea (it wouldn’t be the gui). It says in your db file this happens when the wallet environment changes and is further supported by the fatal region error, is this device environment different from the native one you backed up from?

jay · October 11, 2020, 1:50am

Yes it’s on my laptop my desktop was giving me issues so I decided to do a fresh install of Zec wallet on my laptop.

Just to give you a better idea, the wallet GUI doesn’t even start. It goes straight to the error and doesn’t even connect to the main network. I cleared the chain and database files as well as the logs and resynced, but every time the wallet.dat is added it crashes the wallet. before the sync starts or after the chain is finished.

Autotunafish · October 11, 2020, 2:17am

Is your LAN and ToR configured the same? It looks like the first thing to stop, the troubleshooting does mention possibly ports being mislabeled and seems like one of the variables that could differ significantly but idk. You could alway file an issue, the developer @adityapk00 is on here too.
Importing your private keys (if you wrote them down) to a fresh instance is another option. If your desktop is updated and synced you could also send to a fresh instance, workarounds but should work.

jay · October 11, 2020, 2:52am

That’s my problem I can’t access my private keys. I’m trying to access my keys through the GUI and export them but can’t because the GUI won’t start. If there’s a way to get the keys from wallet.dat without the GUI I’m all ears too.

But yes all configs are the same haven’t changed them from one machine to the other.

4 hours in I’m at 27% synced so I think it should be done in the next 12 or so hours.

Autotunafish · October 11, 2020, 2:57am

Heres a google translated version of that thread

Foreword. I am not a programmer, not a system administrator, my knowledge of databases is minimal, but I was able to restore my broken wallet.dat. And therefore I will describe the procedure here in simple words that an ordinary user can understand.

I was looking for a solution for about 3 days, re-read many articles on the forums, numerous threads on github about how zcashd works. Learned what Berkeley DB is and more. But nevertheless, I did not find any instructions on how to restore the wallet, and the correspondence on the forums in search of solutions that I came across ended in nothing.

The ZecWallet developer told me in a correspondence that with the errors that I received, this was basically impossible to do. But logic pushed me to search.

I slept very little, but I’m very glad that everything worked out for me. Hope my experience will help someone in a similar unpleasant situation.

Attention! First of all, make a few backups of your wallet.dat (or renamed wallet.000000.bak) - how to find it is written below. Copy it to backup directories or to a USB stick. Without this file, nothing will work. Read the entire text to the end and only then perform any manipulations with the wallet.

First, let’s define what error we are talking about, how I got it and how to understand that you have it.

How I got it. Those who use the ZecWallet FullNode wallet may have come across a situation where the update of blocks for some reason stops and whatever you do the wallet will give a connection error until you reindex.

I use ZecWallet FullNode on MAC OS and after version 9.1 I noticed that it became impossible to re-index from the program itself, since the corresponding tab with this function was removed after version 8.3.

I kept version 8.3 in order to re-index from it, if necessary, in an understandable graphical interface (a week ago I did not even know how to start zcashd manually with attributes from the MAC OS terminal).

After another problematic situation (perhaps my macbook was discharged and went out with the wallet turned on), I should have re-indexed, but this process is so long (it takes me exactly more than 14 hours) that I decided to just replace the blocks and chainstate folders in the directory: ~ / Library / Application Support / Zcash /

I always have a full node open on a Windows PC and I previously did such a trick that solved the connection problem - but this time something went wrong …

FullNode version 8.3 (old graphical interface) - gave an error:
“Zcashd said: Error: wallet.dat corrupt, salvage failed”

FullNode version 9.1 and higher (new graphical interface) - gave an error:
"Failed to start zcashd. Giving up! Please file an issue with Zecwallet "

The wallet was restarted as if nothing had happened, but with completely new empty addresses.

I described the primary visual symptoms, now about what happens inside the / Zcash / folder, which is located in:
• Windows:% HOMEPATH% \ AppData \ Roaming \ Zcash \ debug.log
• macOS: ~ / Library / Application Support / Zcash / debug.log
• Linux: ~ / .zcash / debug.log

It will contain your damaged wallet.0000000.bak file (any numbers), which is saved with the .bak extension and a new wallet.dat is created

The log files (located here) will contain the following entries:

debug.log

020-04-26 05:25:14 Renamed wallet.dat to wallet.1587878714.bak
2020-04-26 05:25:14 CDBEnv :: Salvage: Database salvage found errors, all data may not be recoverable.
2020-04-26 05:25:14 Salvage (aggressive) found no records in wallet.1587878714.bak.

db.log

BDB2506 file unknown has LSN 448/450072, past end of log at 1/204362
BDB2507 Commonly caused by moving a database from one database environment
BDB2508 to another without clearing the database LSNs, or by removing all of
BDB2509 the log files from a database environment
BDB0522 Page 0: metadata page corrupted
BDB0523 Page 0: could not check metadata page
wallet.dat: BDB0090 DB_VERIFY_BAD: Database verification failed
BDB2506 file unknown has LSN 448/450072, past end of log at 1/205410
BDB2507 Commonly caused by moving a database from one database environment
BDB2508 to another without clearing the database LSNs, or by removing all of
BDB2509 the log files from a database environment
wallet.1587877729.bak: BDB0090 DB_VERIFY_BAD: Database verification failed

Awareness of the problem

In general, the situation did not bother me until this moment. I assumed that walled.dat might have undergone some kind of unsuccessful operation that damaged it, but for this case I had a wallet.dat backup 1 month old, which contained all my active addresses. I created it via a standard function in the FullNode 8.3 GUI and burned it to disk.

I copied my backup to the \ Zcash folder with a simple replacement, saving the broken version in advance. Looking ahead, I will write that I was able to restore the broken version too - we must save it, because you may not have a backup.

After restarting ZecWallet, the error did not go away. My backup was also not accepted by the wallet and the internal zcashd handler logged all the same errors.

The logical action was to rename the Zcash folder to a temporary one, uninstall all wallets, erase all folders with the internal data of the wallet, reinstall everything again, download a new backup and re-index the entire database.

I did just that - no result, both my wallet.dat and “corrupted” and backup were not accepted by zcashd and again and again gave an error: Salvage: Database salvage found errors, all data may not be recoverable.

Possible causes

I noticed that both my wallet.dat files were unusually large for such files, not that I had many transactions on my addresses, but my Z-address was listed on the zecpages.com service and therefore I regularly received mailing list with a large amount of encrypted information in memo-fields.

Since wallet.dat contains all the information about all transactions made on addresses, as well as information received in memo-fields, its volume has grown significantly every day. The zecpages.com service was launched in February. So, my backup for March 22 wallet.dat weighed 15.6 MB, and the damaged version from April 23 was already 36 MB. And this, it seems to me, is a reason to think. For the sake of fairness, I note that the flow of information in mailing lists was large: 5-8 messages loaded with information daily in the form of z2z transactions.

I cannot name this as a reason, at least my current recovered wallet.dat also has a weight of more than 36 MB and this does not prevent it from being loaded onto the newly installed wallet. However, this led me to believe that wallet.dat backups are not a reliable backup method. I will write about this in PS.

Standard recovery methods.

So, we figured out the symptoms, now I will describe the standard recommended recovery methods that did not help me in any way.

There is documentation that describes various attributes and commands for executable files - clients that allow a node to interact with the network (blockchain), receive and send commands, and perform operations with databases.

Information with conditionally up-to-date documentation is here -
Troubleshooting Issues - ZecWallet Docs 3
Wallet Backup Instructions — Zcash Documentation 5.2.0 documentation 1

Why “conditionally relevant”? Because some of the current ZecWallet FullNode versions may not contain separate executable files:
Zcashd.exe
zcash-cli.exe

In addition, you may not always be able to find documentation for your operating system, since it is written primarily for people who understand the interaction architecture. And as a rule, the development environment is Linux - not the most popular operating system among ordinary users, you must agree. This is also due to the fact that the official wallet for a long time existed only for Linux.

I will not duplicate the documentation. I’ll just write that recovery attempts should start with simple commands in the command line with the executing client zcashd, the documentation is here - Troubleshooting Issues - ZecWallet Docs 3

Commands:

zcashd -rescan
zcashd -reindex
zcashd -salvage

How to start:

Windows

cmd / C ““ C: \ Program Files (x86) \ zecwallet \ zcashd.exe ”-rescan”

MacOS

In Finder, open the programs, find ZecWallet FullNode, right-click to bring up the context menu, “Show Package Contents”, inside go to “Contnets”, and there in “Mac OS”. Open a terminal window, drag zcashd there, add a command attribute, for example, -reindex

By the way, if you do not find it in the current version of ZecWallet FullNode, then download the special version, which definitely has it, two options:

Zecwallet Special Build (master branch zcashd) - https://www.zecwallet.co/masterzcashd.html 1
ZecWallet FullNode v.0.8.3 - Release zcashd update · ZcashFoundation/zecwallet · GitHub 2

It is also recommended to delete the folder with parameters, so that in case of failure of these databases, the wallet can be reinstalled:
• Windows:% HOMEPATH% \ AppData \ Roaming \ ZcashParams
• macOS: ~ / Library / Application Support / ZcashParams /
• Linux: ~ / .zcash-params /

Delete the entire folder, do not hesitate, the wallet will restore it automatically the next time you start ZecWallet.

Actually, this is where the entire standardized arsenal of tools ends.

But be sure, if your wallet.dat is corrupted, the logs will contain the same wording “CDBEnv :: Salvage: Database salvage found errors, all data may not be recoverable.” and all manipulations will be performed with the newly created wallet.dat, and your wallet.dat will be renamed with the * .bak extension (and in some cases it is simply deleted in case of an unsuccessful backup, so always make a backup copy).

Non-standard recovery method

I got to the most interesting place for which I wrote this long post.
Even after reading the hopeless predictions, my logic told me: Ok, even if my current file was broken, then a backup? Why is the backup not loaded?

I created a backup in my sane mind and sober memory;

I clearly remember how I did it;

I made it standard functionality ZecWallet FullNode v.0.8.3;

the node was fully synchronized;

the binary copy of this file continued to work successfully after the backup - simply because the backup operation is a banal wallet.dat copy-paste with a new name.

Why is zcashd spitting it out now?

I started by simply viewing my backup wallet.dat with a text editor
As I scrolled back and forth through this meaningless set of characters, I found that the file had a clear structure. That is, most likely it is a database.
And since FullNode does not support encryption, it is also an unencrypted database.

Having no idea how everything works there, I assumed that wallet.dat is not always an independent database where keys and transactions are stored, but interacts precisely with the block structure that was at the time of its relevance (that is, as of the state and date backup) and if any process is incomplete, it is saved in some “open” position, which further prevents it from acting as a backup copy.

Thus, I thought that I needed to know exactly the moment of the backup and see in the logs what block it was in order to somehow rewind to it - however, I quickly realized that this was anrial and abandoned this attempt, but thanks to this I was more attentive studied all the available logs.

Among other things, in the logs I saw the line
Using BerkeleyDB version Berkeley DB 6.2.23: (March 28, 2016).
And that was the lead.

So, the first thing you need to do is download the source code for working in the environment for Berkeley databases, they are here - Oracle Berkeley DB Downloads 1

I chose the closest release to Berkeley DB version 6.2.23, it is 12cR1 Releases
Berkeley DB 12cR1 (12.1.6.2.38) - https://download.oracle.com/otn/berkeley-db/db-6.2.38_64.msi 2 link for Windows 64. By the way, to download you have to register on the site Oracle.

I will not bore you with a story about all unsuccessful attempts, I will write specifically the commands that helped me, and I hope they will help you too.

There are only three of them:

db_verify (description - db_verify man page - libdb-utils - General Commands) - allows you to check the wallet.bak structure for integrity

db_dump (description - db_dump man page - libdb-utils - General Commands | ManKier) - allows you to decompile wallet.bak

db_load (description - db_load man page - libdb-utils - General Commands | ManKier) - allows you to compile wallet.dat back

After installing the Berkeley DB package, this joy is located in the C: \ Program Files \ Oracle \ Berkeley DB 12cR1 6.2.38 \ bin folder

Open PowerShell in this folder (in the window of the Windows folder in the context menu, right-click with the pressed Shift).

Let’s say your file is called wallet.bak - move it to this \ bin folder where all these exe-files are located, then the commands with attributes will be like this (in the PowerShell terminal, be careful with extensions):

db_verify wallet.bak

And if the answer sounds: “BDB5105 Verification of wallet.bak succeeded” - you can already send someone for wine

db_dump -f 1.txt wallet.bak
which means to decompile your wallet.bak to 1.txt file
By the way, by opening it in the viewer, you can enjoy the clear structure of the records.

db_load -f 1.txt wallet.dat
which means reverse compilation of wallet.dat from 1.txt

Copy the resulting file back to the Zcash folder (where we store the block structure and logs).

Start the wallet, if you see familiar addresses, but of course there will be a zero balance (since you now have a new file structure), then you are at the finish line - do the re-index from the command line (or MAC OS terminal):
zcashd -reindex

After re-indexing, you will see your balances

Such a really not tricky operation somehow corrects the structure of wallet.dat, which, as a result, is remarkably readable by zcashd and even loses a little weight.

If db_verify does not return a successful result, it means that your wallet is really seriously damaged. In this case, try the command db_recover man page - libdb-utils - General Commands
On the forums of 1C programmers (1C, Karl - I was even there), I read that this command helps to correct the tables.

Conclusion.

After long ordeals and the restoration of my wallet, I was able to experience very pleasant feelings of relief and joy.

And if you feel them too, you can let me know about it:

zs1f2hlu6vzl65256mr0k2nh3n49wtrtj2vvalathwvzxt9asn6v0xtda2nfwgukvaaeuvcq3gpzqv
Thanks!

PS in order not to face all this smut,

I recommend using ZecWallet Lite for transactions - Zecwallet Lite - Fully featured Zcash wallet 2
because unlike FullNode:
• It has a recovery seed-phrase, by which you will restore all your created addresses, and not only those that you had at the time of the wallet backup;
• will not force you to carry out many hours of reindexing in case of improper shutdown;
• allows you to encrypt your wallet.dat

Always pull private keys from FullNode if you still want to have one.

This is a good write-up, I’m sorry I didnt translate sooner

jay · October 12, 2020, 1:47am

So I read the writeup and followed what applied to me, and I also completed what you told me to do.

github.com/ZcashFoundation/zecwallet

[ERROR] CWallet::GenerateNewKey(): AddKey failed

opened 02:34AM - 10 Oct 20 UTC

closed 10:57PM - 10 Oct 20 UTC

D3vRandom

Upgraded from a previous version of your wallet and now when I replace the walle…t.dat file in the Zcash directory the wallet doesn't start BDB2506 file wallet.dat has LSN 1/175835, past end of log at 1/167 BDB2507 Commonly caused by moving a database from one database environment BDB2508 to another without clearing the database LSNs, or by removing all of BDB2509 the log files from a database environment BDB2516 DB_ENV->log_flush: LSN of 1/175835 past current end-of-log of 1/167 BDB2517 Database environment corrupt; the wrong log files may have been removed or incompatible database files imported from another environment BDB3027 wallet.dat: unable to flush page: 13 BDB4519 txn_checkpoint: failed to flush the buffer cache: BDB0087 DB_RUNRECOVERY: Fatal error, run database recovery BDB0060 PANIC: fatal region error detected; run recovery BDB0060 PANIC: fatal region error detected; run recovery

I still can’t start the wallet, I don’t think it’s an issue with Zcashd.
I think it’s an issue with the wallet being able to read my wallet.dat file or something.

adityapk00 · October 12, 2020, 2:08am

Note that zecwallet doesn’t have any control over the wallet.dat. The wallet is controlled by and read by zcashd.

You should try to dump the wallet with zcashd.

jay · October 12, 2020, 2:31am

How would I do that?

zcashd -dump?

What would that even produce?

Autotunafish · October 12, 2020, 3:53am

?

([Shakes fist at sky] damn you Windows 95! You ruined me! lol)

jay · October 12, 2020, 6:18am

Thanks everyone for your help although the zcashd doesn’t seem to want to cooperate. I have opened an issue on the zcashd github so maybe they can get to the bottom of this.