Inaccessible .RVT CentralFile - "missing many elements"

MakerJakes · ‎09-29-2021

[NOTE: I'm the techo, not intimately familiar with the nuances of the app/stack]

I'm trying to help recover work for a friend/colleague.

We've set up a NAS (RAID5 Synology with all the bells & whistles, taking daily snapshot) & everything has been working swimmingly for a few months now. Haven't had any issues until today.

Folks have been working together on their work-product - CentralFile(?) - until the wee hours of the morning (1am) and can see files closed & CMB/CIFS connections gracefully terminated around then, and the daily snapshot taken at 4:01am.

I can see these in their file/folder properties (right-click, restore previous version) & can roll back up to something like a month.

I have a VERY HIGH confidence that the server is good, otherwise I would've expected to get issues much, much sooner.

No matter which way we try to skin this cat, we simply cannot open the .rvt file, keep being presented with an error:

The model {FILENAME}.rvt is missing many elements, and it cannot be opened.

I've been following the journal/logs & get something of the nature of:

  ' 8:< ::257:: Delta VM: Avail -981 -> 134207736 MB, Used +1099 -> 3487 MB, Peak +79 -> 3487 MB; RAM: Avail -1295 -> 5733 MB, Used +1321 -> 3132 MB, Peak +135 -> 3132 MB 
  ' 8:< GUI Resource Usage GDI: Avail 9684, Used 316, User: Used 254 
  'C 29-Sep-2021 17:54:30.643;  Loaded elemStream#1: uncompSize=589586777, compSize=145432098, count=532448 
  'C 29-Sep-2021 17:54:30.643;  LoadLatestEpoch::loadLatestEpoch 0x000053854e4=thelper.currentPos() 0x0000de37306=thelper.targetPos() 
  ' 54.920387          8:<<<loadLatestVersion 
  'C 29-Sep-2021 17:54:30.714;  FileCheckDiagnostic 00000000-0000-0000-0000-000000000000: removing missing elements on load 
  'C 29-Sep-2021 17:54:30.714;  FileCheckDiagnostic 00000000-0000-0000-0000-000000000000: missing elem 1725144=id (1298 1671 1298=dates) 
  'C 29-Sep-2021 17:54:30.714;  FileCheckDiagnostic 00000000-0000-0000-0000-000000000000: missing elem 1725321=id (1298 1298 1298=dates) 
  'C 29-Sep-2021 17:54:30.715;  FileCheckDiagnostic 00000000-0000-0000-0000-000000000000: missing elem 1725322=id (1298 1298 1298=dates) 

...
etc
...

  'C 29-Sep-2021 17:54:30.720;  FileCheckDiagnostic 00000000-0000-0000-0000-000000000000: missing elem 1922934=id (1671 1671 -1=dates) 
  'C 29-Sep-2021 17:54:30.721;  FileCheckDiagnostic 00000000-0000-0000-0000-000000000000: missing elem 1922935=id (1671 1671 -1=dates) 
  'C 29-Sep-2021 17:54:30.721;  FileCheckDiagnostic 00000000-0000-0000-0000-000000000000: missing elem 1922936=id (1671 1671 -1=dates) 
  'C 29-Sep-2021 17:54:30.721;  FileCheckDiagnostic 00000000-0000-0000-0000-000000000000: suppress further reporting of missing elems 
  'C 29-Sep-2021 17:54:30.722;  FileCheckDiagnostic 00000000-0000-0000-0000-000000000000: 269 missing elements are removed 
  'C 29-Sep-2021 17:54:30.722;  An ArchiveException 126 is raised at line 550 of E:\Ship\2022_px64\Source\Revit\PersistenceDB\ElemTable\ElementStorageSwapout.cpp 
  'C 29-Sep-2021 17:54:30.723;  captureTryCrash 0xe06d7363 
  ' 7:< ::257:: Delta VM: Avail 134207736 MB, Used +2 -> 3489 MB, Peak +18 -> 3506 MB; RAM: Avail -36 -> 5697 MB, Used +43 -> 3175 MB, Peak +59 -> 3191 MB 
  ' 7:< GUI Resource Usage GDI: Avail 9681, Used 319, User: Used 254 

...

    'E 29-Sep-2021 17:54:37.884;   3:< 
    ' [Jrn.ModelOperation] Rvt.Attr.Scenario: ModelOpen COMMON.OS_VERSION:  Rvt.Attr.ModelVerEpisode: 05f7ac44-7940-47dd-809d-dfbcb4ed031d 154Rvt.Attr.ModelPath: RVT[4870731433127736083] Rvt.Attr.ModelSize: 0 Rvt.Attr.DetectDuration: -1 Rvt.Attr.Worksharing: WorkShared Rvt.Attr.ModelState: ElementsMissing 
  ' 3:< TaskDialog "The model {PROJECTNAME}.rvt is missing many elements, and it cannot be opened."
  'Id : TaskDialog_Too_Many_Missing_Elements
  'CommonButtons : Close
  'DefaultButton : Close 
    ' 3:< ::258:: Delta VM: Avail -9 -> 134209773 MB, Used +4 -> 1761 MB; RAM: Avail +25 -> 7683 MB, Used +12 -> 1240 MB 
    ' 3:< GUI Resource Usage GDI: Avail 9681, Used 319, User: Used 255 
    'H 29-Sep-2021 17:55:00.753;   3:< 
    Jrn.Data  _
            "TaskDialogResult"  , "The model {PROJECTNAME}.rvt is missing many elements, and it cannot be opened." ,  _
             "Close"  _
            , "IDCLOSE" 
  'C 29-Sep-2021 17:55:00.756;   3:< Load exception "CArchiveException", code=126: The file an unnamed file cannot be opened. There are too many elements missing in it. Please contact Autodesk Support. 
  ' 22.873653     3:<<exceptionsInOnOpenDocument reportSaveLoadException bSaving=no [C:\Users\64223\Documents\{PROJECTNAME}.rvt] 
  ' 2:< ::258:: Delta VM: Avail 134209773 MB, Used +1 -> 1762 MB; RAM: Avail -28 -> 7656 MB, Used 1240 MB

I've tried all the LMGTFY, but most/all assume you can open the **** thing to begin with & roll forward/back from there, which is not the case here.

Have managed to open the file's history & export all the increments, opening/importing with Audit options, detaching from central, new local copies, worksheets/workspaces disabled/detached, but issue persists.

Cleared & purged client-side temps, caches & %LOCALAPPDATA% - no dice.

What's really jumping out at me here (when it crashes), are these values:

"FileCheckDiagnostic 00000000-0000-0000-0000-000000000000: missing elem"

"ArchiveException 126 is raised at line 550 of E:\Ship\2022_px64\Source\Revit\PersistenceDB\ElemTable\ElementStorageSwapout.cpp"

I'm assuming those are meant to be hashed pointing to references (xref?), but simply seem very wrong.

"E:\Ship" refers to a path that simply does not exist, so my only guess is that someone could've loaded something from an external drive, which is odd for a binary, but I've been assured this is not the case..... (PIBKAC is my guess)

This all feels like bad refs - something I can easily fix if I know how, but I don't know which of how to access too that could open a 250MB archive so that I can interrogate & fix bad file refs.

What am I looking at here?

How can this be fixed?

What tools are available to admin to work with these datasets?
I don't care about the contents (I'm not an architect), just the container (OSI, OS, binaries, files, etc).

barthbradley · ‎09-29-2021

Find a user with a working local copy, or the most recent backup without the error, and move forward with the recovered model.

About Backup Files for Workshared Projects | Revit 2021 | Autodesk Knowledge Network

MakerJakes · ‎09-29-2021

Unfortunately no dice.

If I was contacted as soon as this happened, I would've taken snapshots of everything in play - client & server-side - and tried these.

As it is, they (understandably) tried to do what they could to recover before contacting me; most of the info online pointing to clearing/purging local cache & pulling the CentralFile from the server afresh, since the reasoning was that everything was copacetic then they checked their work in (Sync to Central?) before hitting the hay.

My understanding is that this is a state where another user should be able to connect to the same Central & pull a working copy so as to be on the same page as the rest of the project team?

From what I can see, this issue stems from links or references to bad or missing resources (elements?).

If I knew how to access these files/archives using some native tool that I could then interrogate, correct or remove bad pointers, I suspect this could move things forward.

In the OS file explorer, it looks like the preview renders OK, so I don't think it's a complete loss, but how to access the file without completely opening it?

Is it feasible/possible to create a new CentralFile and link/import aspects of the problematic one?

In some chunks, I don't even know what I'm looking at beyond my speculation above?

The log/journal is incredibly verbose, but doesn't actually provide any intelligible information for me to take appropriate action on.

ToanDN · ‎09-29-2021

What do you mean 'no dice'? Are all local files from all users went bad? None can open (without syncing)?

Have you run Restore Backups from within Revit?

If you take snapshot everyday at 4:01AM then shouldn't you be able to pull a backup the night before so that at the worst, they lose 1 day of work?

Finally, if nothing works, you can always send the corrupted central file to Autodesk and they maybe able to pull some magic to fix it.

MakerJakes · ‎09-29-2021

Thanks for the info, @ToanDN .

Yea - we tried that.

I could see 5 iterations of backups - I saved/extracted each of those in turn to what looks to me are their own RVT file with corresponding data dir - and tried that with a few snapshots on the server filesystem (restore a NAS snapshot, open & extract a backup), with identical results.

We've gone as far as uninstalling/removing Revit 2022 and purging all remnants (caches, working dirs, temps, etc - even some choice registry entries) to essentially have a client that's a fresh start.

no dice.

We've tried creating a new RVT & "linked to an existing project" (I think that was it? other options were CAD & DWG IIRC), hoping to access portions of the project file without loading the entire, possibly problematic archive, and extricate what can be had & loading them into a new set.

Is this the right way of trying this?

Is there another way that the work done can be extracted form the buggy project & reassembled in a new one?

I see a bunch of DAT & RWS files that could be set that could be C&P'd?

This simply doesn't add up - filesystem should be sweet; nothing has changed since lock-down started (set & forget - don't f&@# with a working production system) - and the client's affectively a clean slate.

If there was a permission of locking issue, I would've expected the log to give me that detail, but it simply looks like faulty references (00000000-0000-0000-0000-000000000000) that I cannot access to fix.

(That E:\...\ElementStorageSwapout.cpp file entry in log still bugs the hell out of me - something is trying to load a binary or a library that should not exist.)

I've attacked this from every angle, but I've run out of ideas & this is simply beyond me at this point.

Have asked them to escalate, but would still like to understand what's happening here, so it can be avoided in future, or useful to someone else that might encounter a similar predicament.

barthbradley · ‎09-29-2021

This thread reads like a script from the television show "CSI - Las Vegas". This must be the "No Dice" episode. he, he.

MakerJakes · ‎09-29-2021

nice try, but no cigar 😜

ToanDN · ‎09-29-2021

Forget about NAS and anything related to it.

- Go to a user workstation, open Revit.

- Run Restore Backups in Revit, navigate to the folder where the local file saved, there should be a backup folder the same name as the Revit file, with a backup suffix, open it.

- You will see nothing in there but don't panic, just click OK and let the Restore do its thing. You should see the list of backups similar to what I posted earlier.

- Select the latest one before the time you think when the model got corrupted and save it to a new file. Open it and see if you can.

- If not, repeat the Restore process but choose an older backup.

MakerJakes · ‎09-29-2021

Thanks for the detailed guidance.

We've followed that process, but have not been able to raise the dead.

I'm worried that the corruption could've been present far sooner than realised.

Found the "Code Blue, Dr. Revit!-How to Resuscitate Corrupt Revit Models" guide to make sense of the log & actually understand what's happening here, so hopefully that'll allow us to find the point of failure.

RDAOU · ‎09-30-2021

@MakerJakes

The best thing to do is what was suggested earlier (file a support ticket and Autodesk will for sure help you recover it) ... Last time I helped someone with checking the journals and recovering a model ended up with them being offended from the given solution but were so happy to take the same exact solution from an Autodesk Employee 🙂 ..

The masked snippet of the journal shared on this thread, in addition to not knowing their worksharing set up (on a local server, cloud and/or a mix of both) are not really sufficient to diagnose what is happening.

Is that Notepad you are using for reading the journals?

MakerJakes · ‎09-30-2021

@RDAOU - yea, I get where you coming from; been there myself.

Using Notepad++ for logs so I can follow new lines as they're generated during project file loads & able to do regex parsing.

(I'm attaching logs sanitised as best I could for future reference)

This really seems like edge-cases - the "FileCheckDiagnostic 00000000-0000-0000-0000-000000000000: missing elem" GUID entries seem incredibly anomalous. Few to no other references found online.

I've managed to figure out the {n}:\ship\...\*.cpp entry is a red herring.

Other projects & files on the same share work fine, so I feel I've banged my head enough on this problem.

Asked them to raise the ticket with Autodesk - I've already blown far too much time on something I'm not familiar enough to resolve in a reasonable amount of time.

I've learnt more than I would care to as a 'favour', such as compression, consolidation & other best-practices, and that "Dr.Revit" doc looks like the type of info I needed to make sense of this mess.

pyRevit was another good find - looks like the kind of tool that would come in handy to to slice & dice problems in future.

Is it reasonable to assume the Revit Server Administrator is designed to mitigate situations such as these? So that clients talk to the server via an API/protocol rather than filesystem directly?

I've managed to stand on up easily enough, but because I'm not a stack user (eg. don't even have a copy of Revit myself), these are all 'black boxes' to me that I'm herding.

If I hear back from them, I'll try to post back here.

RDAOU · ‎09-30-2021

@MakerJakes

filesystems and fileservers tell the one using that its a bad idea, they will get offended and you will be lectured that in a way you feel that the only bad/dumb idea was trying to help lol

I will look into that journal over the coffee break and will toss you a DM is I find anything.

In the meantime, they can check if they or someone linked a Docs/Cloud hosted model which is not published into their fileserver hosted central...that can cause a similar issue with missing elements. Publishing that link usually solves it

MakerJakes · ‎10-01-2021

Thanks for the time, effort & attention to this, @RDAOU .

Please don't spend any more than would support your curiosity.

I've been informed they've gotten something like a resolution from Autodesk doing some recovery-fu at their end on the file/archive; no technical details have been provided other than that a chunk of data is missing, but have asked them to send what they can so that we can update this post with something that looks like a resolution.

Community

Inaccessible .RVT CentralFile - &quot;missing many elements&quot;