Upgrading to 8.5 - Project Restore

Hello,

we are currently in the process of upgrading customers to version 8.5.

We are now facing constant problems when we try to execute task 30 of the upgrade workplan (All Web, page 12).

This is the the step of restoring the v8.5 project backup into the VFS.

Beside the fact that this is and always was painfully slow because of the fact that we are mimicking file system access by doing db access in reality, we now are never able to complete the process in AA due to out of memory exceptions.

We have tried the process on several machines (win 10 21h1 client, Server 2019) in combination with SQL server versions from 2014 to 2019 using several native client versions, but with no success.

We tried to work stepwise, means deleting the old VFS remains in VFS explorer, then closing AA, than restore the project backup, but this just lets the out of memory exception occur somewhat later in the process.

Needless to say that all machines are well equipped with RAM, which does not seem to be the reason for that problem.

Our devs suspect, that we face managed heap fragmentation because of large numbers of allocated objects surviving the garbage collects.

It seems to be a problem in AA and the way project restore is implemented in version 8.5.

Anyone out there with the same problem?

PS: The problem does not occur when restoring to a local workspace.

But this is not what the upgrade workplan demands, beside the fact that running the site from a local workspace is not recommended as well (even though it's faster).

Regards, W. Andreas

Find more posts tagged with

Infor CRM - Developer General Discussions

Accepted answers

All comments

unknown

The out of memory error in Application Architect is crippling. It makes trying to do anything such a PITA. I am currently trying for the 6th time to restore a project backup into a client system. What should take a few minutes is taking hours.

xena-olson

AA due to out of memory exceptions are continuously happening when trying to add our customizations. I had a new server built, am Installing 8.5, instead of upgrading, and then going to bring our customizations over slowly, one at a time. Currently infor is working on trying to bring our customizations over as well, but it has been months and they have not yet been able to fix the root of the problem, which is the out of memory exception. We are still waiting and as we wait, we are just going to try a different, much longer and time consuming route, but we are stuck as to what else to do.

winfried-andreas

Hello,

i guess we found a feasible workaround for the project restore problem.

KB entry 1939097 describes the commandline-tool "ProjectBackupRestore.exe" which is located in the installation root (eg "Program Files (x86)Saleslogix").

Contrary to what is written in the KB article, the current version of this tool is able to restore into the VFS, not only local Workspaces.

We fiddled around with a decompiler and found after some attempts, that the following commandline works for us (Path and filenames to be adjusted to your needs):

ProjectBackupRestore.exe /ProjectPath:VFS:Model /BackupFileName:"P:ICRM v8.5.0 Project.Backup.zip" /Operation:restore /ConfigFileName:"P:Restore.xml"

Important is to set the ProjectPath-Argument to "VFS:Model", not just to "VFS:", otherwise the project structure get corupted.

"Restore.xml" ist the file to configure the options of the operation, database connection string and so on:

<?xml version="1.0" encoding="utf-8"?>
<BackupRestoreConfiguration xmlns:xsi="">www.w3.org/.../XMLSchema-instance" xmlns:xsd="">www.w3.org/.../XMLSchema">
<ConnectionString>Provider=SLXOLEDB.1;Persist Security Info=True;Initial Catalog=SLX;Data Source=SERVER;User ID=Admin; Password="";Extended Properties=";PORT=1706;LOG=OFF;CASEINSENSITIVEFIND=ON;AUTOINCBATCHSIZE=1;SVRCERT=12345;ACTIVITYSECURITY=OFF;TIMEZONE=NONE";</ConnectionString>
<BackupDescription>Restore Infor CRM v85 - Original</BackupDescription>
<IncludeDeletedItemsInBackup>true</IncludeDeletedItemsInBackup>
<RebuildDatabase>true</RebuildDatabase>
</BackupRestoreConfiguration>

Here connection infos need to be adjusted,

We ran the tool several times now, memory consumption constantly increases throughout execution, but we did not see out of memory exceptions.

You should rund the tool from the commandline "As Administrator".

Regards, W. Andreas

winfried-andreas

The name and the path of the config-file, here "Restore.xml" is arbitrary, as long as you set it to an existing xml-file in the commandline everything is okay.

xena-olson

Do you have customizations you are bringing over as well?

winfried-andreas

No and Yes.

No, because in the particular step above we just intended to upgrade the project to the o-o-t-b Infor standard of version 8.5. So, no customizations at this time.

Yes, because in later steps we planned to upgrade our existing customizations (coming from v8.4) - as usual - in the development system according to the upgrade workplan. We usually have a diff-bundle from the old system, adjust what is needed in a local workspace on our dev system, test and evaluate that system. Then, in the last step we used to backup the customized LFS into a backup.zip-file to be then restored including the customizations in the upgraded productive environment.

This has worked relatively well all the past years. But with the problems we already had with the standard-project-backup from Infor we were in doubt that this procedure would work with the even bigger customized backup.

After experimenting with the commandline tool I am now quite confident, that this will work. As written above, we tried a number of runs per commandline, none of those runs failed.

winfried-andreas

Hello,

just as a refresh on the subject.

As stated above, we were indeed able to restore the project-backup with the commandline tool, without facing obvious errors during the copy process.

Unluckily something with the VFS state after the restore seems to be wrong/corrupted.. We were able to build from VFS, but not able to deploy without errors.

Restoring from the same project backup into a local files system based workspace worked, build and deploy worked es well.

Maybe this is still worth a try from your side, but I suspect that using the commandline tool is no real solution for the problem, sorry. In essence, it's up to Infor to fix the instability of AA.

Regards, W. Andreas

xena-olson

Thank you for letting me know. I am going to install 8.5 and slowly bring our customizations over. I will let you know how it works out. I appreciate your insight and sharing of information. I will keep you posted.

winfried-andreas

Hello,

one more update/info:

You might have already noticed the Infor KB entry 2201482, issued yesterday. This article deals with the subject of project backups and restore and introduces some major changes to the customization process.

One of the contained packages refers to KB entry 2195156 (fixes for the 'Upgrade Safe feature') from may, which I personally have completely missed until now. The fix contains a bunch of updated DLL's working together with AA.

After reading the article I was hoping that applying this fix maybe also has an impact on the 'out of memory'-exceptions in AA, so I applied it on my dev box and gave it another try.

Unluckily it had no impact on the problem for me as well. The exceptions still happen when restoring the ICRM v8.5.0 Project Backup.zip into VFS. more or less at the same points of the restoring process.

Regards, W. Andreas

winfried-andreas

Just in case Infor Dev or support staff is reading posts here:

Our devs ran a "restore project " in AA on a dev box (after applying all fixes described in KB 2201482) with an attached memory profiler (jetbrains dotMemory) and took several memory snapshots during the ran.

What we see is an ever increasing number of objects remaining in Gen2 and on the LOH. Especially the state of the LOH seems fragment the longer the process runs, with some pinned objects staying here,

The process usually dies with the OOM exception after copying larger files (which internally are binary serialized). In that situation we see a significant memory usage on the LOH and we suspect that, combined with the fact that the LOH gets easily fragemented, there is simply not enough contiguous address space left to allocate new objects here. This seems to cause the OOM then.

Overall a large number of objects seem to survive all GC-Collects, most of them stored as references in an object-Array connected to the VirtualFileSystem-"Drivers". Types/Members involved in the Calltree are VFSConfiguration/VFSCache.

This constructs seem to hold a lot of references which are still "active" even after finishing the restore task and a forced GC collect. You may leak references here.

As a final info:

We could finish one of the "restore tasks" in AA to completion with the memory profiler attached, because we manually forced regular GC's from within the profiler GUI while the task was running. The special function provided by the profiler calls the GC frrom native code and is usually able to free more memory on the heap. This proves the fact that memory management inside AA, especially in the context of VFS access causes this.

Regards, W. Andreas

winfried-andreas

Small Update on the subject.

Other as suspected, the project restore into VFS using the commandline tool really works.The restored project itself is not corrupted. So you may give this a try.

It just does not help very much either, because almost any possible operation in AA reacts unpredictable/instable, as long as the project is VFS based. In most of the cases operations either end in the dreaded out of memory exception or in more cryptic data access/DB-Provider failures.

Very often the OOM happens when trying to copy the XBar-Setup in the Supportfiles-folder. The Setup-File is big (bigger than 60 megs), so this seems to confirm problems with allocations on the .net managed heap, especially the large object heap (LOH). Even when exporting to a local file system at least in our environments exactly this file never is copied and is later on missing in the local folder. You then see related errors in the output windows of AA, mostly DB-Access errors, not directly OOM's.

Other things that do not work or work instable from my present experience: Project backup/restore to/from VFS, deployment from VFS (even stepwise per portal, as suggested by support), sometimes even a rebuild from VFS fails, bundle creation from project difference runs into OLEDB-related errors when started in a modified VFS-project.

Performance in AA is another problem, a lot of the above mentioned operations are much slower in 8.5 compared to 8.4..0.4. Deletion of a single project-item in one case took 5 minutes with heavy activity on the SQL server and loads of single queries of the virtual file system-tables

This all seems to be connected to the new "Upgrade safe"-feature.

Things turn out to get worse especially when there are project modifications present. The data in VFS is then stored in two different tables, VIRTUALFILSYSTEM (as in all previous version) and VFSDATA. All customized items seem to be stored in VFSDATA, leaving VIRTUALFILESYSTEM untouched. The glue to stitch this together is the view "VIRTUALFILESYSTEMVIEW".

Whenever there are customizations present in VFSDATA, things get worse, copy operations are much slower, OOM-exceptions seem to occur more frequently.

For example, copying the unmodified project from VFS into a local workspace takes roughly about the same amount of time as in 8.4 (under 10 minutes on a dev box). With even just a small number of customizations present copying takes 3 or 4 times longer (roughly half an hour or longer).

Regards, W. Andreas

Copyright © 2025 Infor. All rights reserved.