Switching Proposals Error then Frozen Application "invalid stoi argument"

[ceethreedee.com]

Im in 2019.3 and i have a few projects that just wont let me switch proposals.

When i first try it brings up the "log view" and states 

unhandled exception: invalid stoi argument

unhandled exception: invalid stoi argument The next time i try it freezes completely.

I have attempted both of these KB articles neither works.
https://knowledge.autodesk.com/support/infraworks/troubleshooting/caas/sfdcarticles/sfdcarticles/Inf...

https://knowledge.autodesk.com/support/infraworks/troubleshooting/caas/sfdcarticles/sfdcarticles/How...

[Karsten.Saenger]

Hi @ceethreedee.com ,

is it possible to share the InfraWorks log file from path %appdata%\Autodesk\Autodesk InfraWorks\logs ?

I hope to see more details aboit the error there?

Regards,

Karsten.

[bkanther]

See attached

[bkanther]

Although i think this is the initial crash after I restored the project. to its "pre christmas state". Not sure what happened over christmas period. But all of our infraworks projects are doing this now.

2020-01-07T23:14:13Z [21176]: d:\iwdrprod\git_source\desktop\source\alx\coreapi\data\coremodel.cpp(1704): timing: Retrieve Data Import Configs spent: 30 ms
2020-01-07T23:14:22Z [21176]: d:\iwdrprod\git_source\desktop\source\alx\studio\visibility\surfacelayertreemodelbase.cpp(89): debug: onDataChanged
2020-01-07T23:14:22Z [21176]: d:\iwdrprod\git_source\desktop\source\alx\studio\visibility\surfacelayertreemodelbase.cpp(89): debug: onDataChanged
2020-01-07T23:14:23Z [21176]: d:\iwdrprod\git_source\desktop\source\alx\studio\visibility\surfacelayertreemodelbase.cpp(89): debug: onDataChanged
2020-01-07T23:14:23Z [21176]: d:\iwdrprod\git_source\desktop\source\alx\studio\visibility\surfacelayertreemodelbase.cpp(89): debug: onDataChanged
2020-01-07T23:14:29Z [21176]: d:\iwdrprod\git_source\desktop\source\alx\studio\visibility\gsvmodel.cpp(126): debug: reloading data while having unsaved changes!
2020-01-07T23:14:29Z [21176]: d:\iwdrprod\git_source\desktop\source\alx\coreapi\data\coremodel.cpp(1704): timing: Retrieve Data Import Configs spent: 31 ms
2020-01-07T23:14:29Z [21176]: d:\iwdrprod\git_source\desktop\source\alx\coreapi\data\coremodel.cpp(1704): timing: Retrieve Data Import Configs spent: 38 ms
2020-01-07T23:14:44Z [21176]: d:\iwdrprod\git_source\desktop\source\alx\coreapi\data\coremodel.cpp(1704): timing: Retrieve Data Import Configs spent: 31 ms
2020-01-07T23:14:53Z [21176]: d:\iwdrprod\git_source\desktop\source\alx\coreapi\data\coremodel.cpp(1704): timing: Retrieve Data Import Configs spent: 24 ms
2020-01-07T23:15:00Z [21176]: d:\iwdrprod\git_source\desktop\source\alx\coreapi\data\coremodel.cpp(1704): timing: Retrieve Data Import Configs spent: 35 ms
2020-01-07T23:15:05Z [21176]: d:\iwdrprod\git_source\desktop\source\alx\studio\visibility\surfacelayertreemodelbase.cpp(89): debug: onDataChanged
2020-01-07T23:15:05Z [21176]: d:\iwdrprod\git_source\desktop\source\alx\studio\visibility\surfacelayertreemodelbase.cpp(89): debug: onDataChanged
2020-01-07T23:15:07Z [21176]: d:\iwdrprod\git_source\desktop\source\alx\studio\visibility\surfacelayertreemodelbase.cpp(89): debug: onDataChanged
2020-01-07T23:15:07Z [21176]: d:\iwdrprod\git_source\desktop\source\alx\studio\visibility\surfacelayertreemodelbase.cpp(89): debug: onDataChanged
2020-01-07T23:15:13Z [21176]: d:\iwdrprod\git_source\desktop\source\alx\studio\visibility\gsvmodel.cpp(126): debug: reloading data while having unsaved changes!
2020-01-07T23:15:13Z [21176]: d:\iwdrprod\git_source\desktop\source\alx\coreapi\data\coremodel.cpp(1704): timing: Retrieve Data Import Configs spent: 31 ms
2020-01-07T23:15:13Z [21176]: d:\iwdrprod\git_source\desktop\source\alx\coreapi\data\coremodel.cpp(1704): timing: Retrieve Data Import Configs spent: 34 ms
2020-01-07T23:15:20Z [21176]: d:\iwdrprod\git_source\desktop\source\alx\coreapi\data\coremodel.cpp(1704): timing: Retrieve Data Import Configs spent: 42 ms
2020-01-07T23:15:29Z [21176]: d:\iwdrprod\git_source\desktop\source\alx\coreapi\data\coremodel.cpp(1704): timing: Retrieve Data Import Configs spent: 32 ms
2020-01-07T23:15:30Z [21176]: d:\iwdrprod\git_source\desktop\source\alx\coreapi\data\coremodel.cpp(1704): timing: Retrieve Data Import Configs spent: 26 ms
2020-01-07T23:15:44Z [21176]: d:\iwdrprod\git_source\desktop\source\alx\coreapi\data\coremodel.cpp(1704): timing: Retrieve Data Import Configs spent: 30 ms
2020-01-07T23:15:50Z [21176]: d:\iwdrprod\git_source\desktop\source\alx\coreapi\data\coremodel.cpp(1704): timing: Retrieve Data Import Configs spent: 25 ms
2020-01-07T23:15:51Z [21176]: d:\iwdrprod\git_source\desktop\source\alx\coreapi\data\coremodel.cpp(1704): timing: Retrieve Data Import Configs spent: 24 ms
2020-01-07T23:16:00Z [21176]: d:\iwdrprod\git_source\desktop\source\alx\coreapi\data\coremodel.cpp(1704): timing: Retrieve Data Import Configs spent: 29 ms
2020-01-07T23:16:03Z [21176]: d:\iwdrprod\git_source\desktop\source\alx\framework\alxapplication.cpp(2865): fatal: unhandled exception: invalid stoi argument
2020-01-07T23:17:34Z [21176]: d:\iwdrprod\git_source\desktop\source\alx\framework\alxmainwindow.cpp(525): info: Request closing of the application
2020-01-07T23:17:34Z [21176]: d:\iwdrprod\git_source\desktop\source\alx\application\core\isession.cpp(185): debug: [session] ending session: AlxModelSession

[Karsten.Saenger]

Hi @bkanther .

your first log files shows problems during model upgrade to InfraWorks version 2020.1.

The second log file is from InfraWorks 2019.3.

My first question is what kind of drive is B:/ ? Is it a local drive in the Windows Network or is it a files server, mapped cloud drive or similar?

Regards,

Karsten.

[bkanther · Accepted solution]

All good found the problem, B drive is a file server and we found that a file backup program called HUBSTOR (https://www.hubstor.net/) was creating these little hidden files called ".hubstorinfo" in our directories every time a backup was run.
You can only see them if you tick "Hide protected files" off in folder options in explorer.
Hide proected files turn off

Hubstor info files in directories.

It creates one in every directory it is backing up and was the reason we couldn't upgrade or change proposals in a project. We kept getting this error.

invalid stoi argument

As soon as i deleted them all it was working again.

[Karsten.Saenger]

Hi @ceethreedee.com ,

I am happy to hear you could find the explanation and a solution.

I would like to mention that the only way supported way to place InfraWorks models on a network or the cloud is by using Bim360 docs for collaboration (- and backup) or a Microsoft Windows network drive, for example a folder on another computer or drive.

Any other mapped cloud network drive or a local server possibly corrupts the model database. The main reason is that the git part of the models has files with a filename (no extension) only or files with an extension only (no filename). Some technologies don't like that and tend to remove those data or rename it - with the result of a corrupt model.
If you don't experience that behavior with hubstore, then all good, though.

Regards,

Karsten.

[ceethreedee.com]

Just to be clear. We are on a windows network file server. So it all works fine. HUBSTOR is a thirdparty backup solutution. When HUBSTOR runs over all the directories on the file server it creates ".hubstorinfo" files in every directory as "Hidden Protected Files". Its these files that cause the error in infraworks.