I can't get armory online and I am having difficulty migrating to another platfo

[newnube]

Hi there I am having trouble syncing and bringing online armory. Additionally I have used private keys to migrate most funds. however, some still remains on armory.

I am using:
Bitcoin Core v22.0
Armory 96.5
Windows 11 64-bit
For both armory and bitcoin core The blocks are pathed to the same external harddrive (hdd)


Armory is stuck on older blocks, it finishes syncing, and it shows wallets and balances up to around 6 years ago, likely where the old block that can't be synced beyond is. It can't seem to move past that point.

I don't think my bitcoin core blocks are pruned, that option on bitcoin core client is not selected. Maybe, I did do that briefly at some point in the past, but can't remember. The node has been used on a number of computers over the years.
I have not synced armory to the point of being online in a long time
Bitcoin core syncs fully, however armory won't, and it also remains offline when bitcoin core is running prior and during armory's syncing .


I have tried some of the usual fixes, found here on this forum:

Deleting armory data bases and running bitcoin core synced and then allowing armory to rebuild it's database in the usual place C:\Users\[Your Username\AppData\Roaming\Armory\databases

I don't think there is a compatibility issue with the blockchain, since I am running an old bitcoin core v22 (Which may be an issue security wise, however my wallets are on armory and not bitcoin core).
However, the log files are throwing out 'POLLERR error in readAndWrite' and 'FcgiSocket::writeAndRead FcgiError: unknown fcgi header request byte' .  So, I guess my antivirus may be causing problems, maybe a port conflict on 9001?





I have migrated most of my funds to another platform, by exporting private keys and then sending to a separate secured platform . Sadly this does not work for all my armory wallets. One address won't show any balance in it's corresponding private keys, on the platform used to migrate. However, on mempool.space , the public key still shows the up-to-date balance as it should be, that gives me hope that I haven't been compromised?
The address that won't migrate is a change received address on a segregated witness transaction. The change I received is an address type different from the usual public address, starting with a 3 rather than a 1.
My hope is, that since my armory is not fully synced, it is not producing the correct corresponding private key for the public address beginning with 3? But, I don't know why the private key would change if synced and online. (Note; I don't check the private keys while online).

I looked at the export of private keys in armory and tried the private base58 relating to the public key with that up-to-date balance. I also tried unused keys (omitting spaces). Nothing shows any value when imported to the migratory platform.

Is my only option to get armory to sync fully and hopefully the balance is there and I can then send the funds through armory with it's correctly generated private? Or have I potentially lost the funds that for whatever reason has nothing in its corresponding base58? I tried adding the prepend of p2wpkh-p2sh: ... In the migratory platform, I get told: 'invalid private key: only compressed public keys can be used with segwit scripts'.
No desired result using the other two prepends either.


I have not tried the rescan, rebuild or factory reset options in the armoury client.





My main concern is retrieving the funds. Ideally through it's private key.

Or syncing armory correctely to send that way, if the funds are there. If so how do I go about that (sorry, my tech savvyness is not good, slightly above average 🫩). If going with this option, what version of core should I use? I will use an external SSD rather than HDD, if resyncing the Blockchain, or maybe I should use ssd anyway?


Any advice would be much appreciated.

Thanks all for your time.







Some exerts from the log file is as follows, if more or full is required let me know:

...
Log file opened at 19:53:20.000: C:\Users\usele\AppData\Roaming\Armory\armorycpplog.txt
-ERROR - 20:37:02.000: (e:\users\goat\code\armory3\cppforswig\socketobject.cpp:447) POLLERR error in readAndWrite
-ERROR - 20:37:02.000: (e:\users\goat\code\armory3\cppforswig\stringsockets.cpp:359) POLLERR error in readAndWrite
-ERROR - 00:13:36.031: (e:\users\goat\code\armory3\cppforswig\stringsockets.cpp:351) FcgiSocket::writeAndRead FcgiError: unknown fcgi header request byte


Log file opened at 20:19:47.000: C:\Users\usele\AppData\Roaming\Armory\armorycpplog.txt
-ERROR - 04:00:57.391: (e:\users\goat\code\armory3\cppforswig\socketobject.cpp:447) POLLERR error in readAndWrite
-ERROR - 04:00:57.391: (e:\users\goat\code\armo...


...ta\Roaming\Armory\armorycpplog.txt


Log file opened at 14:54:07.000: C:\Users\usele\AppData\Roaming\Armory\armorycpplog.txt
-ERROR - 15:23:53.829: (e:\users\goat\code\armory3\cppforswig\socketobject.cpp:447) POLLERR error in readAndWrite
-ERROR - 15:23:53.844: (e:\users\goat\code\armory3\cppforswig\stringsockets.cpp:359) POLLERR error in readAndWrite


Log file opened at 06:43:02.000: C:\Users\usele\AppData\Roaming\Armory\armorycpplog.txt
-ERROR - 08:41:16.828: (e:\users\goat\code\armory3\cppforswig\socketobject.cpp:447) POLLERR error in readAndWrite
-ERROR - 08:41:16.828: (e:\users\goat\code\armory3\cppforswig\stringsockets.cpp:359) POLLERR error in readAndWrite


Log file opened at 09:10:43.000: C:\Users\usele\AppData\Roaming\Armory\armorycpplog.txt...


...Log file opened at 13:05:24.000: C:\Users\usele\AppData\Roaming\Armory\dbLog.txt
-INFO  - 13:05:24.000: (e:\users\goat\code\armory3\cppforswig\main.cpp:32) Running on 8 threads
-INFO  - 13:05:24.000: (e:\users\goat\code\armory3\cppforswig\main.cpp:33) Ram usage level: 50
-INFO  - 13:05:24.000: (e:\users\goat\code\armory3\cppforswig\blockutils.cpp:915) blkfile dir: D:\arm\Bitcoin\blocks
-INFO  - 13:05:24.000: (e:\users\goat\code\armory3\cppforswig\blockutils.cpp:916) lmdb dir: C:\Users\usele\AppData\Roaming\Armory\databases
-INFO  - 13:05:24.000: (e:\users\goat\code\armory3\cppforswig\lmdb_wrapper.cpp:388) Opening databases...
-INFO  - 13:05:24.110: (e:\users\goat\code\armory3\cppforswig\bdm_server.h:263) Listening on port 62386
-INFO  - 13:05:26.172: (e:\users\goat\code\armory3\cppforswig\bdm_server.cpp:1121) registered bdv: 7878326c7176b5671e52
-INFO  - 13:05:28.188: (e:\users\goat\code\armory3\cppforswig\blockutils.cpp:1108) Executing: doInitialSyncOnLoad
-INFO  - 13:05:39.891: (e:\users\goat\code\armory3\cppforswig\databasebuilder.cpp:199) Reading headers from db
-INFO  - 13:05:44.500: (e:\users\goat\code\armory3\cppforswig\databasebuilder.cpp:238) Found 860046 headers in db
-INFO  - 13:05:45.422: (e:\users\goat\code\armory3\cppforswig\bitcoinp2p.cpp:947) Connected to Bitcoin node
-INFO  - 13:05:47.266: (e:\users\goat\code\armory3\cppforswig\databasebuilder.cpp:64) Rewinding 100 blocks
-INFO  - 13:05:47.266: (e:\users\goat\code\armory3\cppforswig\databasebuilder.cpp:71) updating HEADERS db
-INFO  - 13:05:50.141: (e:\users\goat\code\armory3\cppforswig\databasebuilder.cpp:493) Found next block after skipping 1630196bytes
-INFO  - 13:06:41.657: (e:\users\goat\code\armory3\cppforswig\databasebuilder.cpp:281) parsed block file #4584
-ERROR - 13:06:46.407: (e:\users\goat\code\armory3\cppforswig\bitcoinp2p.cpp:1037) caught StopBlockingLoop in processDataStackThread
-INFO  - 13:06:46.407: (e:\users\goat\code\armory3\cppforswig\bitcoinp2p.cpp:969) Disconnected from Bitcoin node
-INFO  - 13:06:48.782: (e:\users\goat\code\armory3\cppforswig\databasebuilder.cpp:281) parsed block file #4588
-INFO  - 13:07:22.328: (e:\users\goat\code\armory3\cppforswig\databasebuilder.cpp:281) parsed block file #4589
-INFO  - 13:07:56.907: (e:\users\goat\code\armory3\cppforswig\databasebuilder.cpp:281) parsed block file #4592
-INFO  - 13:08:20.719: (e:\users\goat\code\armory3\cppforswig\databasebuilder.cpp:281) parsed block file #4596
-ERROR - 13:08:40.797: (e:\users\goat\code\armory3\cppforswig\socketobject.cpp:290) POLLERR error in readFromSocketThread
-ERROR - 13:08:40.797: (e:\users\goat\code\armory3\cppforswig\bitcoinp2p.cpp:1027) caught SocketError exception in processDataStackThread: POLLERR error in readFromSocketThread
-INFO  - 13:09:07.828: (e:\users\goat\code\armory3\cppforswig\databasebuilder.cpp:281) parsed block file #4597...




...e #5691
-INFO  - 16:21:04.594: (e:\users\goat\code\armory3\cppforswig\databasebuilder.cpp:281) parsed block file #5692
-INFO  - 16:22:25.141: (e:\users\goat\code\armory3\cppforswig\blockchain.cpp:248) Organizing chain
-INFO  - 18:18:15.735: (e:\users\goat\code\armory3\cppforswig\blockchain.cpp:370) Organized chain in 6949s
-INFO  - 18:18:15.750: (e:\users\goat\code\armory3\cppforswig\databasebuilder.cpp:76) updated HEADERS db in 18747s
-INFO  - 18:18:15.782: (e:\users\goat\code\armory3\cppforswig\lmdb_wrapper.cpp:388) Opening databases...
-INFO  - 18:18:15.797: (e:\users\goat\code\armory3\cppforswig\databasebuilder.cpp:1231) verifying txfilters integrity
-INFO  - 18:18:17.375: (e:\users\goat\code\armory3\cppforswig\databasebuilder.cpp:1256) no recorded block headers in file #1076...




...le #1177
-INFO  - 18:18:17.375: (e:\users\goat\code\armory3\cppforswig\databasebuilder.cpp:1257) skipping
-INFO  - 18:18:17.375: (e:\users\goat\code\armory3\cppforswig\databasebuilder.cpp:1256) no recorded block headers in file #1178
-INFO  - 18:18:17.375: (e:\users\goat\code\armory3\cppforswig\databasebuilder.cpp:1257) skipping
-INFO  - 18:18:25.578: (e:\users\goat\code\armory3\cppforswig\databasebuilder.cpp:1314) done checking txfilters
-INFO  - 18:18:25.610: (e:\users\goat\code\armory3\cppforswig\bdm_supportclasses.cpp:1891) Enabling zero-conf tracking
-INFO  - 20:14:38.125: (e:\users\goat\code\armory3\cppforswig\bdm_supportclasses.cpp:401) Starting address registration process
-INFO  - 20:14:47.500: (e:\users\goat\code\armory3\cppforswig\blockchainscanner.cpp:852) scanned from block #0 to #142691
-INFO  - 20:14:55.500: (e:\users\goat\code\armory3\cppforswig\blockchainscanner.cpp:852) scanned from block #142692 to #170004...





...59261 to #859581
-INFO  - 20:33:58.453: (e:\users\goat\code\armory3\cppforswig\blockchainscanner.cpp:852) scanned from block #859582 to #859891
-INFO  - 20:34:36.344: (e:\users\goat\code\armory3\cppforswig\blockchainscanner.cpp:852) scanned from block #859892 to #860035
-INFO  - 20:34:36.469: (e:\users\goat\code\armory3\cppforswig\blockchainscanner.cpp:214) scanned transaction history in 87598s
-INFO  - 20:34:39.250: (e:\users\goat\code\armory3\cppforswig\blockchainscanner.cpp:1789) resolving txhashes
-INFO  - 20:34:51.297: (e:\users\goat\code\armory3\cppforswig\blockchainscanner.cpp:1848) 24 blocks hit by tx filters
-INFO  - 20:34:55.000: (e:\users\goat\code\armory3\cppforswig\blockchainscanner.cpp:1937) found 20 missing hashes
-INFO  - 20:34:55.016: (e:\users\goat\code\armory3\cppforswig\blockchainscanner.cpp:1982) Resolved missing hashes in 15s
-INFO  - 20:34:55.078: (e:\users\goat\code\armory3\cppforswig\blockchainscanner.cpp:857) scanned block #860035

[goatpig]

-INFO  - 18:18:15.735: (e:\users\goat\code\armory3\cppforswig\blockchain.cpp:370) Organized chain in 6949s

...

-INFO  - 20:34:55.078: (e:\users\goat\code\armory3\cppforswig\blockchainscanner.cpp:857) scanned block #860035

Something looks very wrong with your blockchain data. Organizing chain should take ~60sec at most, even on old hardware. Your top block is over 100k behind current top.

Whether you resync the chain or not (SSD is preferable at any rate), try the release candidate for the new version first: https://github.com/goatpig/BitcoinArmory/releases

[newnube]

thanks

Yea I am not sure what went wrong.



I am getting somewhere with the migration. I think I need to sweep rather than import wit the correct prepend for the address beginning with 3.



If that doesn't work I will try the new version. And then maybe a rebuild 😣.



Thanks again for all the support over the years. I am glad to see this is all still going.

[goatpig]

Make sure to cleanup your armory databases folder before switching to the new version

[nc50lc]

-snip- I tried adding the prepend of p2wpkh-p2sh: ... In the migratory platform, I get told: 'invalid private key: only compressed public keys can be used with segwit scripts'.
No desired result using the other two prepends either.

This sounds like Electrum, are you using Electrum to import your private keys?
If so, those addresses from Armory that starts with '3' aren't "p2wpkh-p2sh" but "p2pk-p2sh",
but you can't use that prefix in Electrum since it's not supported by that wallet.

Also, your uncompressed WIF private keys (starts with '5') can't be used for any SegWit scripts (p2wpkh), so Electrum prevents that.
Else, it'll be soft-locked since it's non-standard.

I am getting somewhere with the migration. I think I need to sweep rather than import wit the correct prepend for the address beginning with 3.

The issue is that "p2pk-p2sh" script isn't famously used in other wallets (I only see it in Armory)
Electrum doesn't support that in either sweep or import private key options.
So, if you want to spend those, your best bet is to sync Armory instead of importing it to other wallets.

[newnube]

Yea you are right I was trying with electrum. The importing was bringing up different addresses than the one with funds. I didn't want to go as far as sweeping because I didn't want to bring the private key online. And I started to think that if I swept the key it might change the location or affect one part of the original address  and maybe lose funds (which probably isn't possible). In any rate, I shouldn't be messing around with the private keys.

If I was to convert the uncompressed private key to a compressed version of the key. And imported with the prefix "p2wpkh-p2sh", would it still not work, because the script that generated the uncompressed key on armory is different than what electrum (or most wallets) use to derive keys. Or would electrum pick up the correct 3 address using the compressed version of the private key?

In any rate, I shouldn't be messing around with the private keys. It seems each option with the keys creates more risks, even offline.


You are both right, I should try through armory.
I do have a question on that I will put in a following message.

Thanks for the clarification nc50lc

I will try the new test version 97.0 emptying the database folder prior to installation. And hope that maybe the new version can pick up the full node.

I was reading the notes for the new version and there is a new wallet format, requiring migration of wallets. I can do this wit the wallet file. But would that new wallet format still derive the same key as the older versions, specifically the one change address beginning with '3'. I guess it will since the notes say 'the new format does not affect what keys the wallet carries ', and armory will still use the same script to generate or search addresses.


Would the new version be more likely to sync to my node? Or is it better to rebuild the chain?


I presume it is better to check first as goatpig mentioned. If I can't navigate 97 then I guess I can re-install 96.5 and resync the chain.
It will be a week or so before I can dedicate some time to this, and I will post back any results...

Sorry, there is gaps in my understanding and my questions may not make sense or are way off the mark.
Thank you all for your time

[nc50lc]

If I was to convert the uncompressed private key to a compressed version of the key. And imported with the prefix "p2wpkh-p2sh", would it still not work, because the script that generated the uncompressed key on armory is different than what electrum (or most wallets) use to derive keys.

Yes, this wont work.
Since the WIF is uncompressed, the address derived from it are based from the uncompressed public key.
Compressed and uncompressed public keys are not interchangeable with each other, each will produce a different hash.

Additionally, that prefix "p2wpkh-p2sh:WIF" will tell Electrum to create an address with a script type p2wpkh-p2sh from the derived public key,
even if you force it to use the uncompressed public key (non-standard Nested SegWit), the address will still be different since it's a different script from p2pk-p2sh.
The underlying script that is wrapped in p2sh is different.

[newnube]

Ok great, thanks again for the clarification.

[newnube]

Tried the pre release 97

I am running the Bitcoin armory Qt client along with bitcoin core.

I migrated one wallet watch only.

There is a number of new files in the user/appdata/roaming/armory. Two new watch only wallets with a different name than the wallet I migrated. There are keyfiles. And there is new wallet lock files.
Also there are a number of wallet names with the new .imdb extension, This seems to have occurred for all wallets not just the one that I migrated.

The databases folder was emptied and  has new files

The one migrated wallet shows on the GUI. Preparing databases and scan transaction history remain blank and armory stays offline.

I will leave it overnight to see if there is an change

Armory dB is running at 1.5gb
Bitcoin armory Qt client running at 69mb. While scanning, if it is scanning

The wallet migration initial GI sometimes loads and it does not pick up the wallets. Exiting and loading again usually gets them.

The interface seems stable with the little features I have used.
I am probably not the best test user i am not sure if I want to go any further, like unlocking wallets, I don't really know what the program will do...


Log file as follows:

.

2026-06-22 14:59:02 (ERROR) -- CppBridge.py:273 - Socket error: [WinError 10054] An existing connection was forcibly closed by the remote host
2026-06-22 16:35:14 (INFO) -- ArmoryUtils.py:1104 - Named options/arguments to armoryengine.py:
2026-06-22 16:35:14 (INFO) -- ArmoryUtils.py:1106 -     settingsPath    : C:\Users\usele\AppData\Roaming\Armory\ArmorySettings.txt
2026-06-22 16:35:14 (INFO) -- ArmoryUtils.py:1106 -     datadir         : DEFAULT
2026-06-22 16:35:14 (INFO) -- ArmoryUtils.py:1106 -     satoshiHome     : DEFAULT
2026-06-22 16:35:14 (INFO) -- ArmoryUtils.py:1106 -     satoshiPort     : DEFAULT
2026-06-22 16:35:14 (INFO) -- ArmoryUtils.py:1106 -     satoshiRpcport  : DEFAULT
2026-06-22 16:35:14 (INFO) -- ArmoryUtils.py:1106 -     armoryDBDir     : DEFAULT
2026-06-22 16:35:14 (INFO) -- ArmoryUtils.py:1106 -     rpcport         : DEFAULT
2026-06-22 16:35:14 (INFO) -- ArmoryUtils.py:1106 -     rpcBindAddr     : ####
2026-06-22 16:35:14 (INFO) -- ArmoryUtils.py:1106 -     testnet         : False
2026-06-22 16:35:14 (INFO) -- ArmoryUtils.py:1106 -     regtest         : False
2026-06-22 16:35:14 (INFO) -- ArmoryUtils.py:1106 -     offline         : False
2026-06-22 16:35:14 (INFO) -- ArmoryUtils.py:1106 -     nettimeout      : 2
2026-06-22 16:35:14 (INFO) -- ArmoryUtils.py:1106 -     interport       : 8223
2026-06-22 16:35:14 (INFO) -- ArmoryUtils.py:1106 -     doDebug         : False
2026-06-22 16:35:14 (INFO) -- ArmoryUtils.py:1106 -     logDisable      : False
2026-06-22 16:35:14 (INFO) -- ArmoryUtils.py:1106 -     netlog          : False
2026-06-22 16:35:14 (INFO) -- ArmoryUtils.py:1106 -     logFile         : C:\Users\usele\AppData\Roaming\Armory\ArmoryQt.exe.log.txt
2026-06-22 16:35:14 (INFO) -- ArmoryUtils.py:1106 -     mtdebug         : False
2026-06-22 16:35:14 (INFO) -- ArmoryUtils.py:1106 -     forceOnline     : False
2026-06-22 16:35:14 (INFO) -- ArmoryUtils.py:1106 -     useTorSettings  : False
2026-06-22 16:35:14 (INFO) -- ArmoryUtils.py:1106 -     bip150Used      : False
2026-06-22 16:35:14 (INFO) -- ArmoryUtils.py:1106 -     bip151Used      : False
2026-06-22 16:35:14 (INFO) -- ArmoryUtils.py:1106 -     keypool         : 100
2026-06-22 16:35:14 (INFO) -- ArmoryUtils.py:1106 -     redownload      : False
2026-06-22 16:35:14 (INFO) -- ArmoryUtils.py:1106 -     rebuild         : False
2026-06-22 16:35:14 (INFO) -- ArmoryUtils.py:1106 -     rescan          : False
2026-06-22 16:35:14 (INFO) -- ArmoryUtils.py:1106 -     rescanBalance   : False
2026-06-22 16:35:14 (INFO) -- ArmoryUtils.py:1106 -     ignoreAllZC     : False
2026-06-22 16:35:14 (INFO) -- ArmoryUtils.py:1106 -     ignoreZC        : False
2026-06-22 16:35:14 (INFO) -- ArmoryUtils.py:1106 -     multisigFile    : DEFAULT
2026-06-22 16:35:14 (INFO) -- ArmoryUtils.py:1106 -     forceWalletCheck: False
2026-06-22 16:35:14 (INFO) -- ArmoryUtils.py:1106 -     disableWalletCheck: False
2026-06-22 16:35:14 (INFO) -- ArmoryUtils.py:1106 -     disableModules  : False
2026-06-22 16:35:14 (INFO) -- ArmoryUtils.py:1106 -     disableConfPermis: False
2026-06-22 16:35:14 (INFO) -- ArmoryUtils.py:1106 -     enableDetSign   : True
2026-06-22 16:35:14 (INFO) -- ArmoryUtils.py:1106 -     armorydb_ip     : ####
2026-06-22 16:35:14 (INFO) -- ArmoryUtils.py:1106 -     armorydb_port   : 9001
2026-06-22 16:35:14 (INFO) -- ArmoryUtils.py:1106 -     ram_usage       : -1
2026-06-22 16:35:14 (INFO) -- ArmoryUtils.py:1106 -     thread_count    : -1
2026-06-22 16:35:14 (INFO) -- ArmoryUtils.py:1106 -     db_type         : DB_FULL
2026-06-22 16:35:14 (INFO) -- ArmoryUtils.py:1106 -     language        : en
2026-06-22 16:35:14 (INFO) -- ArmoryUtils.py:1106 -     port            : None
2026-06-22 16:35:14 (INFO) -- ArmoryUtils.py:1106 -     verbosity       : None
2026-06-22 16:35:14 (INFO) -- ArmoryUtils.py:1106 -     coverageOutputDir: None
2026-06-22 16:35:14 (INFO) -- ArmoryUtils.py:1106 -     coverageInclude : None
2026-06-22 16:35:14 (INFO) -- ArmoryUtils.py:1106 -     clearMempool    : False
2026-06-22 16:35:14 (INFO) -- ArmoryUtils.py:1107 - Other arguments:
2026-06-22 16:35:14 (INFO) -- ArmoryUtils.py:1110 - ************************************************************
2026-06-22 16:35:14 (INFO) -- Settings.py:45 - Using settings file: C:\Users\usele\AppData\Roaming\Armory\ArmorySettings.txt
2026-06-22 16:35:14 (INFO) -- BDM.py:271 - Using the asynchronous/multi-threaded BlockDataManager.
2026-06-22 16:35:14 (INFO) -- BDM.py:272 - Blockchain operations will happen in the background.  
2026-06-22 16:35:14 (INFO) -- BDM.py:273 - Devs: check TheBDM.getState() before asking for data.
2026-06-22 16:35:14 (INFO) -- BDM.py:274 - Registering addresses during rescans will queue them for
2026-06-22 16:35:14 (INFO) -- BDM.py:275 - inclusion after the current scan is completed.
2026-06-22 16:35:15 (ERROR) -- Settings.py:202 - Unsupported language  specified. Defaulting to English (en)
2026-06-22 16:35:15 (INFO) -- Settings.py:204 - Using Language: en
2026-06-22 16:35:53 (INFO) -- DlgSetupManager.py:179 - No tested connection - attempting connection on accept
2026-06-22 16:35:53 (INFO) -- DlgSetupManager.py:484 - Initiating DB connection: scenario=Automate ArmoryDB
2026-06-22 16:35:53 (INFO) -- DlgSetupManager.py:504 - Calling automateDb: satoshiPath=D:\arm\Bitcoin, dbPath=C:\Users\usele\AppData\Roaming\Armory\databases
2026-06-22 16:35:57 (INFO) -- DlgSetupManager.py:514 - automateDb succeeded
2026-06-22 16:35:57 (INFO) -- DlgSetupManager.py:190 - Connection established on accept
2026-06-22 16:35:57 (INFO) -- WalletUtils.py:111 - Loading wallets...
2026-06-22 16:35:57 (INFO) -- WalletUtils.py:120 - Number of wallets read in: 1
2026-06-22 16:35:57 (INFO) -- WalletUtils.py:125 -    Wallet (#####):    "Restored - ####            "   (No Encryption)
2026-06-22 16:35:57 (INFO) -- ArmoryQt.py:275 - First load of new version: v0.96.99
2026-06-22 16:35:57 (INFO) -- ArmoryQt.py:1589 - acquiring process mutex...
2026-06-22 16:35:57 (INFO) -- ArmoryQt.py:1785 - Loading settings...
2026-06-22 16:35:57 (INFO) -- ArmoryQt.py:602 - Usermode: Standard
2026-06-22 16:35:57 (INFO) -- ArmoryQt.py:1525 - Changing usermode:
2026-06-22 16:35:57 (INFO) -- ArmoryQt.py:1526 -    From: Standard
2026-06-22 16:35:57 (INFO) -- ArmoryQt.py:1534 -      To: Standard
2026-06-22 16:35:57 (INFO) -- ArmoryQt.py:4194 - Dashboard switched to "Scanning" mode
2026-06-22 16:35:57 (INFO) -- ArmoryQt.py:4864 - DB connected by setup manager, registering wallets
2026-06-22 16:35:57 (INFO) -- ArmoryQt.py:4871 - Registering wallets with blockchain service
2026-06-22 16:35:57 (INFO) -- ArmoryQt.py:1652 - Setting netmode: 1
2026-06-22 16:35:57 (INFO) -- ArmoryQt.py:4880 - Finalizing blockchain setup
2026-06-22 16:35:57 (INFO) -- ArmoryQt.py:1640 - loadBlockchainIfNecessary
2026-06-22 16:35:57 (INFO) -- ArmoryQt.py:4194 - Dashboard switched to "Scanning" mode
2026-06-22 16:45:30 (ERROR) -- Traceback (most recent call last):
  File "ArmoryQt.py", line 3117, in exportLogFile
  File "ArmoryQt.py", line 3185, in saveCombinedLogFile
NameError: name 'getLastBytesOfFile' is not defined

[goatpig]

You do not need to unlock your original wallets. Do you see balances yet? So long as you see balances, you can create an offline transaction to sweep out the coins.

[newnube]

Oh ok. But sadly, balances as they would be 6 years ago. I am getting the same problem as before. Stays offline and sits at the old block that I can't get past.

So the GUI did start showing node and scanning progress, similar to 96. It took 4 hours or so before I noticed.
I think my external HDD is slowing things down a lot.


I am not sure where to go from here; there is other talk about reindexing core? Or do I need to redownload the Blockchain? Or a rebuild rescan of databases in armory, I thought that would happen with the delete of the content in the databases folder?


There is a new error in the log :


2026-06-22 23:33:10 (ERROR) -- Traceback (most recent call last):
  File "C:/msys64/home/goat/Code/BitcoinArmory/ui/QtExecuteSignal.py", line 44, in methodSlot
  File "ArmoryQt.py", line 4547, in handleCppNotification
TypeError: argument of type 'WalletMap' is not a container or iterable


I have not migrated the particular wallet with the balance yet.

Additionally the command window that runs along with 97 shows Manny errors:

'block deser except: block data smaller than expected '

'unknown header hash: ' with what looks like an address.



Log file:




2026-06-22 16:45:30 (ERROR) -- Traceback (most recent call last):
  File "ArmoryQt.py", line 3117, in exportLogFile
  File "ArmoryQt.py", line 3185, in saveCombinedLogFile
NameError: name 'getLastBytesOfFile' is not defined

2026-06-22 20:06:57 (INFO) -- ArmoryQt.py:4194 - Dashboard switched to "Scanning" mode

… this goes for many lines...

2026-06-22 22:40:29 (INFO) -- ArmoryQt.py:4194 - Dashboard switched to "Scanning" mode
2026-06-22 22:40:32 (ERROR) -- Traceback (most recent call last):
  File "C:/msys64/home/goat/Code/BitcoinArmory/ui/QtExecuteSignal.py", line 44, in methodSlot
  File "ArmoryQt.py", line 4547, in handleCppNotification
TypeError: argument of type 'WalletMap' is not a container or iterable

2026-06-22 23:33:10 (ERROR) -- Traceback (most recent call last):
  File "C:/msys64/home/goat/Code/BitcoinArmory/ui/QtExecuteSignal.py", line 44, in methodSlot
  File "ArmoryQt.py", line 4547, in handleCppNotification
TypeError: argument of type 'WalletMap' is not a container or iterable

… this goes for many lines...

2026-06-23 01:59:18 (ERROR) -- Traceback (most recent call last):
  File "C:/msys64/home/goat/Code/BitcoinArmory/ui/QtExecuteSignal.py", line 44, in methodSlot
  File "ArmoryQt.py", line 4547, in handleCppNotification
TypeError: argument of type 'WalletMap' is not a container or iterable

2026-06-23 02:00:58 (INFO) -- BDM.py:214 - BDM is ready!



I could pastebin the full stream of repitions if preferred?

[newnube]

Here is some additional logs from the command window that runs alongside 97.

I guess my Blockchain started doing it's own thing at some point?


I replaced the address (if they are address with ###adress###) 




-ERROR - 2026-06-22 - 22:40:51.174: (C:/msys64/home/goat/Code/BitcoinArmory/cppForSwig/Network/SocketObject.cpp:582) socket was closed: 10053
-ERROR - 2026-06-22 - 22:40:51.175: (C:/msys64/home/goat/Code/BitcoinArmory/cppForSwig/Node/BitcoinP2P.cpp:1444) caught StopBlockingLoop in processDataStackThread
-WARN  - 2026-06-22 - 23:33:10.251: (C:/msys64/home/goat/Code/BitcoinArmory/cppForSwig/BlockchainDatabase/Blockchain.cpp:261) Found a long orphan chain!
-WARN  - 2026-06-22 - 23:33:10.251: (C:/msys64/home/goat/Code/BitcoinArmory/cppForSwig/BlockchainDatabase/Blockchain.cpp:262)   file: 4580
-WARN  - 2026-06-22 - 23:33:10.251: (C:/msys64/home/goat/Code/BitcoinArmory/cppForSwig/BlockchainDatabase/Blockchain.cpp:263)   first header hash  : ###address###
-WARN  - 2026-06-22 - 23:33:10.252: (C:/msys64/home/goat/Code/BitcoinArmory/cppForSwig/BlockchainDatabase/Blockchain.cpp:264)   missing header hash: ###address###
-WARN  - 2026-06-22 - 23:33:10.252: (C:/msys64/home/goat/Code/BitcoinArmory/cppForSwig/BlockchainDatabase/Blockchain.cpp:265)   orphan chain length: 94791

[newnube]

An additional problem:

The wallets with any balance won't migrate.

The initial lobby gives the error:

'Failed to start migrationg: Legacy wallet missing extended data from bridge '

[nc50lc]

I am not sure where to go from here; there is other talk about reindexing core? Or do I need to redownload the Blockchain?

You should check Bitcoin Core's logs if this is really necessary.
Find the "debug.log" file inside your bitcoin datadir in your '/appdata/roaming' or '/appdata/local' folder. (if you're using the default paths)
There should be an error line indicating a corrupted file or non-matching hash if it needs to be reindexed.
That'll also tell if you need to reindex the full block database or just the chainstate or just a simpler command to proceed.

Where did you get that info by the way?
You might have shared more information there that lead them to suggest you to reindex Bitcoin Core.

[newnube]

So, I got the information from another post on here, not mine. A post by tez02843, where goatpig mention a potential fix of reindexing core.

I don't know if that fix will work in my case. Of course anything that will help access my funds, is necessary to me.

I will have a look "debug.log" when I get the chance.

[goatpig]

You will have to wait about a week. I have managed to get the orphan chain issue on my laptop, I'll start debugging it soon, at which point I'll push a new RC with a set of fixes. That should get your further along hopefully.

[newnube]

Ok great thanks goatpig. I will wait
Sorry, I seem to be causing more problems than I understand 😓.


And to nc50lc's point, I guess maybe not necessary if I were to restore from seed on a fresh system with a new full node. I will wait and see.

I am now somewhat concerned that my wallets are tied into the orphan chain, and maybe the change address won't populate with a fresh seed import, or my wallet will populate the same problem. Probably not possible. Again my ignorance is showing. Idiot windows user here; turn it off and on again has generally been my approach.


Thanks again for the support

[goatpig]

Sorry, I seem to be causing more problems than I understand 😓.

Nah it's me who's causing trouble by not pushing out updates fast enough. Don't worry, we'll get you out of this bind eventually (TM).

I am now somewhat concerned that my wallets are tied into the orphan chain,

This is not related to your wallet. Orphan chain in the ArmoryDB context means it found a bunch of headers that don't connect to the main branch. This either means your copy of the blockchain is missing the one header that connects this chunk to the main chain, or ArmoryDB is failing to pick up that header. Seeing as I'm experiencing the same issue and the parser code was just updated, it's very likely it's a bug on my end. Hang in there, I should fix it soon.

[newnube]

Alright, sounds good.

I think in any rate I should try and get a separate computer and download a new node ( I should have started that from the start 🤦‍♂️). For peace of mind it might be the safer option, to import the wallet with balance there.

[goatpig]

If you go for a fresh sync of the blockchain on whatever machine, make sure pruning is turned off.