Revit central file corruption recovery: when worksharing breaks at 4 p.m. Friday

It is 16:12 on a Friday. Twenty-two modellers are saving to central. The model has been live for fourteen months — a 400-bed hospital addition, Stage 4 Technical Design, tender issue in three weeks. The BIM Manager's screen freezes for four seconds, then Revit drops a dialog that reads: "Cannot open the central file." The workstation is not the problem. The network share is responding. Two other team members try to open the file from their machines. Same message. A third colleague, who had the file open and was mid-synchronise when something went wrong, now has Revit locked in a not-responding state. The central file is corrupt.

This is not a theoretical scenario. Central file corruption is one of the two or three events in a BIM Manager's career that are genuinely time-critical: the decisions made in the first thirty minutes after the file becomes inaccessible determine how much work is lost, how long recovery takes, and whether the project misses a coordination deadline. Most BIM Managers encounter it once every two or three years — frequently enough that it happens, infrequently enough that the recovery sequence is not muscle memory.

This playbook is written for that moment. It covers the internal mechanics of a Revit workshared central file, the specific failure modes that lead to corruption, the recovery procedure in sequence, the anti-patterns that make a bad situation worse, and the preventive disciplines that reduce both frequency and blast radius. It draws on Autodesk's published guidance, named practitioner sources, and accumulated community knowledge from the AUGI forums, Autodesk Knowledge Network, and peer-reviewed BIM process documentation.

The audience is a working BIM Manager or senior modeller — someone who understands Revit worksharing conceptually but needs a decision-ready reference for a scenario they may not have rehearsed. If you are reading this in an emergency, go directly to the recovery sequence in "The fix." Read the rest later.

What's actually happening

The central file as a distributed transaction log

To understand corruption, you first need to understand what a Revit central file actually is — because it is not simply a large .rvt file with some extra metadata. It is a transactional database with an embedded permission registry, a history log, and a set of workspace ownership records. When that database is interrupted mid-write, the result is structurally equivalent to a hard-shutdown of a relational database during a transaction commit: the file ends up in a partial state that no parser can fully interpret.

Revit's worksharing system stores, inside the central .rvt file, a set of data structures that do not exist in a non-workshared model. The Autodesk Revit Architecture and Worksharing documentation describes the workshared file as containing: element ownership records (which workset each element belongs to, which user is the current borrower), a synchronisation history, and the central model's current geometric and parametric state. The permission database tracks which elements are checked out to which user, and is updated atomically during each Synchronise with Central (STC) operation.[^1]

The STC operation — which modellers run throughout the day to share their local changes with the team — is the critical vulnerability point. During STC, Revit performs a multi-step write operation: it reads the central file, reconciles the local changes against the current central state, resolves any ownership conflicts, and then writes the updated central file. The duration of this write can range from seconds to several minutes depending on model size, network throughput, and the number of elements being synchronised. If anything interrupts the write mid-operation — power loss, network disconnection, a server crash, an OS-level file lock from antivirus software — the central file may end up in a state where the write was partially completed. The file header may be intact (which is why Revit can see the file exists) but the internal data structures are inconsistent (which is why it cannot be opened).[^2]

The embedded permission database

The ownership registry inside a workshared .rvt file is worth examining in more detail because it is one of the most common sites of corruption, and understanding it explains several recovery behaviours that otherwise seem arbitrary.

When a modeller borrows elements — either explicitly through the Editing Request system or implicitly by directly editing an element — Revit updates the element's ownership record in the central file during the next STC. These ownership records are stored in a separate internal table from the element geometry data. A corrupted central file may have intact geometry but a damaged ownership table, or vice versa. When Revit attempts to open the file, it validates both structures; if either fails validation, the file throws the "Cannot open" error. This is why Revit's Audit function — which is the first recovery tool in the playbook — sometimes repairs a file that other methods cannot: Audit is specifically designed to rebuild and validate internal consistency, including the ownership registry.[^3]

The implication for recovery: the corruption is not always in the geometry you can see. A file can have geometrically intact elements and still be unreadable because the permission table is inconsistent. This is why the recovery sequence always starts with Audit before attempting to work from locals or backup files.

Local files and their relationship to the central

Each team member who opens a workshared central file creates a local copy on their own machine. The local file is a complete copy of the model at the time it was opened (or last synchronised), plus any changes that modeller has made since their last STC. The local file is not a thin client view — it contains full geometric and parameter data.

This architecture is, paradoxically, the primary safety net when the central file corrupts. If twenty-two modellers have local files that were synchronised within the last hour, those twenty-two locals collectively represent most of the model's current state. The central file corruption does not destroy any of that data — it only destroys the central's role as the authoritative synchronisation point. Recovery is largely a process of identifying which local file represents the most current state, using it to establish a new central, and then synchronising the remaining locals against it.

The Autodesk Knowledge Network article on recovering a corrupt Revit central file confirms this architecture explicitly: "If the central file is corrupt and cannot be opened, users may be able to create a new central file from a local file."[^2] What the KB article does not cover in detail — and what this playbook addresses — is the triage sequence for determining which local to use, how to handle the modellers who are still connected, and how to assess how much work has been lost.

Common corruption causes and their signatures

Corruption events cluster around a predictable set of causes. Identifying the likely cause matters both for recovery (different causes produce different damage patterns) and for prevention (knowing the cause allows you to eliminate it rather than just recovering from it).

Power loss or hard shutdown during STC. The classic corruption scenario. A power outage, UPS failure, or forced OS reboot while a Synchronise with Central operation is in progress leaves the central file in a partial-write state. Signature: the file size may be zero or unusually small (indicating the write was abandoned before completion), or the file size is normal but the file fails to open with a generic "Cannot open" or "File is not a Revit file" message. The backup folder (described below) will have a pre-STC snapshot.[^4]

Network share I/O errors. When the central file is hosted on a Windows file share (SMB/CIFS) or a NAS device, intermittent I/O errors — caused by network congestion, unstable storage hardware, or protocol-level interruptions — can corrupt writes. The signature is subtler than a power-loss corruption: the file may open but exhibit missing elements, garbled parameter data, or visible geometry that does not match what team members had in their locals. These partial corruptions are often more difficult to diagnose than complete-open failures. The Autodesk Knowledge Network recommends hosting Revit central files only on hardware and operating systems that are on the Revit-tested storage compatibility list.[^5]

Conflicting add-ins. Third-party Revit add-ins that hook into the document save or STC event pipeline can, in certain configurations, interrupt the write process or corrupt the ownership registry. The signature is often a crash during STC — Revit terminates rather than completing the sync — followed by an unreadable central file. Add-ins from multiple vendors with overlapping event subscriptions are a known risk factor. The Revit-tested API documentation discourages add-ins from performing write operations inside IFailuresPreprocessor callbacks without careful transaction management.[^6]

Version drift. Revit central files are version-locked: a file created in Revit 2024 cannot be opened in Revit 2023. Version drift corruption occurs when a team member with a newer Revit installation opens the central file and upgrades it, while other team members are running an older version. The upgraded file cannot be opened by the older installations, and the modellers running the older version who had elements checked out cannot synchronise. This is a configuration management problem masquerading as corruption. The signature is clear: older installations see "This file was created in a newer version of Revit." Recovery requires all machines to be updated to the same version.[^7]

Antivirus and endpoint protection locking files. Antivirus software that scans files during write operations can acquire an exclusive file lock at precisely the wrong moment in the STC cycle, interrupting the central file write. Windows Defender, CrowdStrike, and other real-time protection tools are commonly implicated. The Autodesk Knowledge Network has published specific guidance on excluding Revit-related file types and folders from real-time antivirus scanning, including .rvt, .rvg, .slog, and the backup folder structure.[^8]

Dropbox, OneDrive, and consumer sync tools. Hosting a Revit central file in a folder that is actively synced by Dropbox, OneDrive (consumer or business), Google Drive, or similar tools is one of the fastest ways to corrupt it. These tools use their own file locking and incremental sync mechanisms that conflict directly with Revit's write cycle. Dropbox in particular has been known to mark a file as fully synced while Revit's write was still in progress, creating a corrupt cloud copy that then propagates to all devices. The Autodesk guidance is unambiguous: Revit central files must not be hosted in any folder that is actively synced by consumer or business cloud sync tools. Autodesk Construction Cloud (ACC), BIM 360, and Revit Server are the supported cloud collaboration platforms.[^9]

Worksheet ownership table inconsistency. This corruption type is less dramatic than a power-loss event but more insidious. Over time, on long-running projects where elements have been moved between worksets, borrowed and returned many times, and where STC has been interrupted by network blips without a visible crash, the ownership registry can accumulate inconsistencies. The file continues to open normally but exhibits increasingly strange behaviour: elements that appear unowned are actually locked; STC operations fail for specific team members with "cannot synchronise" errors; the Worksharing Monitor shows phantom borrowers for elements that have been modified. This is the corruption-in-slow-motion scenario, and it is addressed by the monthly Compact Central maintenance operation described in the prevention section.[^3]

The backup folder structure

Every Revit central file generates a backup folder automatically. For a central file named ProjectName_Central.rvt located at \\server\share\BIM\Models\, the backup folder is created at \\server\share\BIM\Models\ProjectName_Central_backup\. This folder contains numbered backup copies of the central file — typically ProjectName_Central.0001.rvt, ProjectName_Central.0002.rvt, and so on, up to the number configured in the Worksharing settings (default is three, configurable to twenty).[^4]

Each backup entry represents the state of the central file at the time of a specific STC operation — specifically, the state just before the STC write began. This is crucial: backup number 0003 represents the central file's state immediately before the STC that created backup 0003. If the corruption occurred during the STC that would have produced backup 0004, then backup 0003 is the most recent uncorrupted snapshot of the central.

The backup folder also contains a .slog file (the synchronise log), which records the metadata of each STC operation including the timestamp, the workstation name, and the Revit version. The slog is useful for forensics — it tells you when the last successful STC completed, which workstation was synchronising when the corruption occurred, and roughly how much work was in progress.

Understanding this structure is essential because recovery will often use these backup files. Do not delete the backup folder. Do not reorganise its contents. Do not copy files out of it without understanding what you are copying.

The pattern

How corruption presents at the team level

The BIM Manager is rarely the first person to notice a corruption event. The typical detection sequence is: a modeller's Revit freezes or crashes mid-STC, they restart and try to reopen the central file, they get an error, they message the team channel. By the time the BIM Manager is aware, there are already two or three modellers who have either closed Revit (bad), kept Revit open with their local still loaded (good), or are attempting to do something to the central file on the server (potentially very bad).

The pattern of a corruption event at the team level varies by firm size and communication culture, but the failure modes are consistent:

The "reopen and retry" loop. Multiple team members simultaneously try to open the central file, each generating failed open attempts. Each failed open may leave a temporary lock file or partial read in the server's file cache. On some network configurations, multiple simultaneous failed opens can compound the corruption. The pattern to interrupt immediately: get everyone to stop trying to open the central file while recovery is in progress.

The "it was fine yesterday" false reassurance. A team member who did not experience the crash points out that the file was working fine at 3 p.m. This is technically accurate but operationally irrelevant. The corruption is in the current state of the file; the 3 p.m. state is in the backup folder. The immediate question is not "was it fine?" but "when did the last successful STC complete, and whose local has the most recent changes?"

The "someone must have done something" blame cycle. Corruption events frequently trigger a search for a human cause — the modeller who was synchronising when the crash happened is assumed to be responsible. This is usually counterproductive. In most cases, the modeller was a victim of circumstance (the network blipped at the wrong moment, the antivirus decided to scan a file mid-write) rather than the cause. The blame cycle wastes the time that should go into recovery.

The "I'll just save over it" intervention. A well-intentioned team member with admin rights to the server decides to copy the newest backup over the corrupted central. This is sometimes the right move — but only at the right point in the recovery sequence, not as an immediate first response, and not before the Audit path has been tried. Blindly overwriting the central file with a backup without first understanding what was in-flight discards the work that was in local files that hadn't yet synchronised.

The cloud worksharing mis-match. On projects using Revit Server or Autodesk Construction Cloud (ACC), the corruption presentation is different. The file is not on a local network share — it is managed by the Revit Server software or ACC's cloud infrastructure. The "Cannot open" message may be replaced by ACC-specific error messages about model access or cloud sync failures. Recovery on these platforms follows different procedures, covered in the Limits section below.

How corruption scales with project complexity

A corruption event on a small three-person architectural project and a corruption event on a twenty-person multi-discipline project are the same technical problem, but the recovery complexity scales dramatically with team size.

On a small project, the recovery steps are linear: tell the two other modellers to keep their locals open, run Audit on the central, recover. There are three locals to consider, the model is likely small enough that Audit runs in under five minutes, and the amount of work at risk is limited.

On a large project, the same event requires coordinating communication across twenty-plus people who may be on different floors or different offices, identifying which of those twenty locals has the most current state, managing the sequence in which each local synchronises against the recovered central to avoid ownership conflicts, and assessing the lost work across all worksets and disciplines simultaneously. The recovery steps are the same, but the coordination overhead dominates.

This is why communication is step zero — not step one — of the recovery playbook. Getting to a clean recovered central quickly is only half the problem; the other half is ensuring the team holds their current state while recovery happens.

Partial corruption versus complete corruption

Not all corruption events produce the same failure signature. The recovery sequence branches depending on what the file can and cannot do.

Complete open failure. Revit cannot open the file at all. The dialog says "Cannot open the central file," "File is not a Revit file," or similar. This is the scenario described in the lede. Recovery starts with Audit (Path A) and, if that fails, falls back to the newest local or newest backup (Path B).

Partial open failure. Revit opens the file but one or more worksets fail to load, or a specific discipline's elements are missing. This often indicates that the corruption is confined to a specific workset table in the internal database. Recovery may only require restoring that workset's data from the most recent local where it was intact.

Functional but degraded. Revit opens the file and it appears normal, but STC fails for specific modellers, or elements owned by a specific workstation cannot be released. This is the ownership registry inconsistency pattern. Recovery does not require a full restore — it requires a targeted Compact Central or a Detach-and-Recreate cycle on the specific workset.

Post-recovery instability. Revit opens the recovered central and the file appears functional, but modellers experience repeated crashes or errors in specific areas of the model during the days following recovery. This indicates residual corruption that Audit did not catch. A second full Audit pass combined with a Compact Central is the resolution path.

The fix

The recovery sequence has two paths. Path A attempts repair of the existing central file. Path B abandons the central file and builds a new one from a local. Always try Path A first. If it succeeds, you preserve the complete history and avoid the ownership reconciliation work required by Path B. If it fails, proceed to Path B without hesitation.

Immediate actions — before anything else

1. Stop. Communicate. Do not close Revit.

   Send an immediate message to the entire team: "Central file is unavailable — do not close Revit and do not try to open the central file. Keep your local file open exactly as it is. Stand by for instructions."

   This is the single most important step. Every modeller who keeps Revit open with their local file loaded is preserving the work they have done since their last STC. Every modeller who closes Revit discards any unsaved local work. On a large team, even one modeller misunderstanding this instruction can mean hours of rework.

   If some modellers have already closed Revit before the instruction reaches them, note their names. Their locals on disk still contain their last state, but any work done after the last File Save (not STC — local File Save, Ctrl+S) is lost. Ask them what time they last saved their local.

2. Identify who was synchronising when the corruption occurred

   The modeller whose STC was in progress during the corruption event is likely the one whose Revit is currently frozen or crashed. If they are still visible in the Worksharing Monitor or known from the team channel, ask them: what time did they start the STC, and had they received any error message before the crash?

   This identifies the approximate time window of the corruption and helps you locate the right backup snapshot. The .slog file in the backup folder records STC timestamps — cross-reference the crash time against the slog to find the last successfully completed STC before the event.

3. Check the backup folder immediately

   Navigate to \\server\share\...\[ModelName]_backup\ and record:

   • The number of backup files present
   • The timestamp of the most recent backup file (Windows file modified date)
   • The size of each backup file (a zero-byte or unusually small backup indicates an interrupted write)
   • The .slog file contents (open in Notepad — it is a plain text log)

   Do not move, copy, rename, or delete anything in the backup folder yet. Just document what is there. Take a screenshot of the folder listing sorted by date modified. This is your audit trail.

4. Note all active local file locations

   Ask each modeller on the channel to confirm: are you still in Revit with your local open? If yes, what is the path of your local file?

   Locals are typically at C:\Users\[username]\Documents\[ProjectName]\ or on a project-specific local drive path defined in your BIM Execution Plan. For larger teams, collect this in a shared document — you will need it for the synchronisation sequence in Path B if the Audit path fails.

   Identify the senior modeller or discipline lead whose local is most likely to have the broadest coverage of recently modified elements. In a typical workflow, the last person to STC before the crash has the most current central state in their local — but only up to their last STC. The modellers who were working after that STC (and had not yet synced) hold the newest work. Both are important.

Path A — Audit the central file

1. Attempt to open the central file with Audit enabled

   In Revit, go to File → Open. Browse to the central file location. Before clicking Open, check the Audit checkbox in the open dialog. Audit tells Revit to perform a structural validation and repair pass on the file as it opens — it rebuilds internal indexes, validates the ownership registry, and repairs some categories of structural inconsistency.[^3]

   When the open dialog has Audit checked and you click Open, Revit will prompt you to confirm the audit. Confirm. The file will take significantly longer to open than usual — on a large model (800 MB–2 GB), an audited open can take 20–40 minutes. Do not interrupt it.

   Also ensure Detach from Central is NOT checked. You want to open the actual central, not a detached copy, so that if Audit succeeds you can proceed directly to a Save As new central.

2. Wait. Monitor Revit's status bar.

   During an audited open, Revit's status bar at the bottom of the window shows progress messages: "Opening model," "Checking elements," "Rebuilding element table," and so on. If these messages are cycling and advancing, Audit is working. If Revit is not-responding and the status bar is not changing after 10 minutes, the Audit is likely stuck — you will need to force-close Revit and proceed to Path B.

   If Revit completes the audited open successfully, the file is now open in memory and the audit has completed its repair pass. Do not make any changes yet.

3. Immediately Save As a new central file

   If Audit succeeds and the file opens, go to File → Save As → Project. Save the file to a new location (or a new filename) on the same server share. Do not save over the corrupted original — you want to keep the original as a forensic reference and as a fallback if the new central exhibits problems.

   Name the new central with a recovery indicator and timestamp: [ProjectName]_Central_Recovered_20260611.rvt. In the Save As dialog, ensure Make this a Central Model after save is checked (this should be the default for a workshared file).

   The Save As creates a fresh central file with a clean ownership registry — the repair work that Audit performed is now committed to a new file structure.

4. Verify the new central opens without errors

   Close the file. Open the new central file without Audit (normal open). If it opens cleanly and the model looks correct — worksets intact, elements visible, no immediate error dialogs — Path A has succeeded.

   At this point, the new central is established. Proceed to the team synchronisation sequence below (after both paths converge).

5. If Audit fails or the audited file is visibly corrupted

   If Revit's audited open fails, or if the file opens but is visibly wrong (missing worksets, elements in the wrong positions, workset ownership data that does not match the team's known state), do not save. Close Revit. Proceed to Path B.

   The audited open failure is not a dead end — it is simply a signal that the corruption is too severe for Audit to repair, and the newer local-based recovery is needed.

Path B — Recover from a local file

1. Identify the best local file

   The best local for recovery is not necessarily the one that was synchronised most recently — it is the one that, when combined with the work in other locals, produces the least lost work overall.

   Consider two competing priorities:

   Broadest coverage: The local that has the most worksets with recent changes. Typically this is the project BIM Manager's local (if they synchronise frequently) or the discipline lead for the most actively modified discipline.

   Most recent STC timestamp: Check each modeller's local file properties. The local's last-modified date in Windows Explorer reflects the last time any save (including local saves, not just STC) occurred. But the internal Revit STC log within the local is more reliable — ask each modeller when they last successfully synchronised.

   In a typical scenario with twenty-two modellers, you are looking for the local whose last successful STC was closest to the time of the corruption event. That local represents the most recent confirmed state of the central.

2. Open the chosen local with Detach from Central

   Ask the modeller with the chosen local to go to File → Save As → Project and save their local to a new filename (e.g., [Name]_Local_PreRecovery_20260611.rvt). This protects their current local from any changes during the recovery operation.

   Then open that saved copy in Revit and, in the Open dialog, check Detach from Central. When prompted, select Detach and preserve worksets (not "Detach and discard worksets" — you want to keep the workset structure intact). The file opens as a standalone .rvt with no connection to the (now inaccessible) central.

3. Save As a new central file

   Go to File → Save As → Project. In the Save As dialog, check Make this a Central Model after save. Save to the server share as [ProjectName]_Central_Recovered_20260611.rvt.

   This is now the new central file. It contains all the work that was in the chosen local's last STC state.

4. Open the new central and verify

   Close the detached file. Open the new central normally (without Audit, without Detach). Verify that it opens cleanly, worksets are present, and the model appears correct. Run a quick visual check across the main views and key sheets.

   If the new central opens but exhibits strange behaviour — elements missing, worksets with wrong owners, views that do not match the team's known state — you may have chosen a local that was not fully synchronised. Consider whether a different local would be a better starting point, and if so, repeat Steps B1–B3 with that local.

5. Create a new local for each team member

   Now that the new central exists, each team member needs a new local to synchronise their work against it.

   Instruct each modeller: go to File → Open, browse to the new central, open it. Do not use their existing local from before the corruption — that local's central file reference points to the old (corrupt) central and will cause confusion.

   When they open the new central for the first time, it will create a new local for them automatically (or they can Save As a local explicitly). Their work from before the corruption is still in their old local files — it has not been lost. It will be synchronised in the next steps.

6. Synchronise the team's locals in a controlled sequence

   This is the most operationally complex part of Path B. Each modeller who had work in their old local that was not captured in the recovery central needs to synchronise that work into the new central. However, if all twenty-two modellers synchronise simultaneously, the ownership conflicts will be severe and some work may be lost or overwritten.

   Synchronise in sequence, starting with the modeller whose local has the broadest coverage (usually a discipline lead), then proceeding modeller by modeller. The sequence does not need to be strictly serial — you can have four or five synchronising simultaneously if their worksets do not overlap — but coordinate to avoid concurrent writes on the same workset.

   Before each modeller synchronises, instruct them: open your old local (the one from before the corruption), check out any elements you modified since your last STC (Revit will prompt for ownership requests on the new central), and then synchronise. The ownership request process on the new central ensures that each modeller's work is properly attributed.

   For modellers who cannot reopen their old local (because they closed Revit before the instruction to keep it open), their pre-recovery local file on disk can still be opened in Revit and the recent work can be manually identified and recreated or copied. This is the scenario where having noted which modellers closed Revit early (from Step 1 of immediate actions) is useful.

Post-recovery: team synchronisation and lost work assessment

After the new central is established and the team has begun synchronising their locals, two tasks run in parallel: confirming that the recovery is stable, and assessing what work (if any) was lost.

1. Run a post-recovery Audit on the new central

   Once all team members have synchronised their locals against the new central and no more STC operations are in progress, close all locals. Open the new central with Audit checked. This post-recovery audit serves as a quality gate — it verifies that the new central's data structures are consistent after all the synchronisation operations.

   If the post-recovery audit completes cleanly and the file opens, save the result (File → Save, not Save As — you want to update the existing central in place). The recovery is complete.

2. Assess lost work by comparing against the backup snapshot

   Open the most recent backup from the _backup folder (as a detached file — Audit and Detach both checked) in a second Revit instance. This gives you a view of the central's state at the last confirmed-good STC. Compare this against the recovered central by:

   • Checking sheet count and view count in both files
   • Comparing element counts in the Manage → Project Statistics dialog for each major category (Walls, Floors, Doors, Windows, and discipline-specific elements)
   • Asking each modeller to review their discipline area in the recovered central and confirm whether their recent changes are present

   Discrepancies between the backup snapshot and the recovered central represent work that either was captured in a local (and has been synchronised) or was lost. Document the discrepancy findings — this is the lost-work report that the project manager will ask for.

3. Communicate the outcome to the project team

   Send a structured summary to the project team, project manager, and relevant consultants. Include:

   • Time of the corruption event and time of recovery completion
   • What recovery path was used (Audit repair vs. local-based recovery)
   • Which modeller's local was used as the recovery base (if Path B)
   • What work, if any, was confirmed lost (in terms of discipline areas and approximate time window, not element-by-element detail)
   • What the team should do now (open new central, create local, verify discipline area)

   Keep the communication factual. "We recovered the model using [Name]'s local, which represents the state as of approximately 15:45. Work completed after that time in [Workset X] may need to be recreated. We will confirm the details of any lost work by [time]." This is preferable to either minimising the event or overstating the damage before the lost-work assessment is complete.

The escalation path: when both paths fail

In a small number of cases, the Audit path fails to produce a openable file and there is no usable local (all modellers closed Revit before the instruction reached them). This is the worst-case scenario.

The fallback sequence is: use the most recent backup snapshot from the _backup folder. Open it with Audit and Detach checked. Save As a new central. Accept that the work done between the last backup STC and the corruption event is lost. Contact Autodesk Support with the corrupt central file — Autodesk's support team has internal tools for attempting low-level file repair that are not available through the standard UI. This is not always successful, but it has worked in cases where the corruption was in the file's header rather than its core data structures.[^2]

If the project is on Autodesk Construction Cloud (ACC), the equivalent escalation is to the ACC admin's version history. ACC maintains version history at the cloud level — not just the backup folder — and Autodesk support can restore a model to a specific previous version through the ACC admin console, including versions that predate the corruption event.

Anti-patterns

Anti-pattern 1: Save As over the corrupted central

The most common wrong move by a well-intentioned IT support person or non-BIM team member: copying the newest backup directly over the corrupted central file at the OS level. This approach bypasses Revit entirely, which means Revit's backup management, the STC log, and the local file references are all now pointing to a file that has been replaced without Revit's knowledge.

The specific harms: modellers whose locals were created from the original central will now try to synchronise against a file that Revit treats as a different central (because the internal identifiers do not match). Revit will refuse the sync or, worse, will accept it and produce a silent data conflict. The backup folder may be overwritten or confused, losing the forensic trail.

Do instead: Never overwrite the corrupted central at the OS level. Use the recovery paths described above — either Audit + Save As, or Detach from local + Save As. Both create a new central with correct internal identifiers rather than replacing the corrupt one in place.

Anti-pattern 2: Deleting the backup folder

The backup folder is the primary safety net. Deleting it — either to save disk space or in a confused attempt to "start fresh" — removes the only guaranteed recovery path that predates the local files.

On large projects, the backup folder can be several gigabytes. Storage pressure sometimes leads IT to delete it. This is a false economy: the backup folder should be sized appropriately in the storage budget as a project management cost, not a technical overhead.

Do instead: Configure Revit's worksharing settings to maintain an appropriate number of backups (three is the default; for high-risk periods like near a milestone, increase to ten or twenty). Ensure the storage quota for the project share explicitly includes the backup folder. Include "backup folder intact and minimum three backups present" as an item in your weekly model health check.

Anti-pattern 3: Running Audit while users are connected

Audit is designed to be run on a file that no other user is accessing. Running an audited open on the central file while other team members have their locals open and are potentially mid-STC does not cause corruption by itself, but it creates a race condition: if a team member completes an STC while the Audit is rebuilding the central's ownership registry, the results are unpredictable. In the worst case, the audited repair overwrites a valid STC that was in flight.

Do instead: Before attempting an audited open of the central file, confirm that all team members have closed their locals and that no STC operations are in progress. The Worksharing Monitor (if accessible) shows active connections — wait until it shows no active users before proceeding.

Anti-pattern 4: Using the most recent local without checking STC timestamp

In the rush to recover, the instinct is to use the local with the most recently modified Windows file date. This is not always correct. A local's file modified date changes every time the user does a local File Save (Ctrl+S) — which happens frequently throughout a session. A local that was Ctrl+S'd at 16:00 may have had its last successful STC at 11:30. Another modeller's local with a 15:45 modified date may have synchronised at 15:40.

Do instead: Ask each modeller explicitly when they last successfully synchronised (not when they last saved locally). The Revit application log and the .slog file in the backup folder can corroborate these timestamps.

Anti-pattern 5: Synchronising all locals simultaneously after Path B recovery

After a Path B recovery where a new central has been established from one local, there is enormous pressure to get the team synchronised as quickly as possible so the project can resume. The temptation is to tell all twenty-two modellers to sync at once.

Simultaneous synchronisation of a large team against a newly created central creates massive ownership request traffic. The central file's ownership registry, which was just established from a single local, will receive twenty-one simultaneous requests to check out elements. Revit handles this through a queuing system, but the queue can back up to the point where individual STC operations time out, leaving locals in a partially synchronised state. Elements that were in the recovery local and are also being modified in other locals will generate ownership conflicts that require manual resolution for each instance.

Do instead: Synchronise in disciplined batches. Start with the discipline leads whose worksets have the broadest coverage. Let each discipline lead sync, verify, and confirm their workset is clean before the next batch starts. Five sequential rounds of four or five people each is operationally slower but produces a much cleaner recovery than a simultaneous rush.

Anti-pattern 6: Treating the corruption as resolved before the post-recovery Audit

The post-recovery Audit (the final step in the fix sequence) is not optional. A recovered central that has not been audited may contain residual structural inconsistencies that are not visible in the model but will manifest as crashes or synchronisation failures over the following weeks. Teams that skip this step because "the model looks fine" sometimes find themselves dealing with a second corruption event within a month of the first.

Do instead: Schedule the post-recovery Audit for a period when the team is not actively working — end of day, overnight, or first thing in the morning before the team logs on. It is a non-interactive process once started and produces a verified clean central.

Case studies

Case study 1: Power failure at a 450-bed hospital — Stage 3 delivery

Project context: A major hospital extension, three months from Stage 3 submission. Fifty-two team members across architectural, structural, mechanical, and electrical disciplines. The central files (two architectural, one structural, one MEP coordination) were hosted on a Windows Server 2019 file share in the client's data centre. The data centre experienced a power disruption — the UPS failed to hold during a mains switchover — resulting in an unclean shutdown of the file server at 16:45 on a Tuesday.

When the server came back online twenty minutes later, the primary architectural central file failed to open. The structural and MEP centrals were unaffected. The BIM Manager was on a call with the structural engineer at the time of the event.

Recovery sequence: The BIM Manager's first communication was a Teams message at 16:51: "Architectural central is down. Everyone keep Revit open and your local loaded. Do not close Revit. Do not try to open the central." Eleven of the eighteen architectural modellers acknowledged within three minutes. Four did not acknowledge and were subsequently found to have already closed for the day.

At 17:02, the BIM Manager navigated to the backup folder. It contained nineteen backup snapshots (the project was near milestone and the team had increased the backup count from three to twenty). The .slog showed the last successful STC at 16:39. The crash had occurred mid-STC for a structural modeller who was linking updated structural drawings. The backup at position 0019 was the last pre-corruption snapshot.

The BIM Manager attempted Path A at 17:08. The audited open of the corrupt central took thirty-two minutes. At 17:40, the file opened successfully. The BIM Manager performed an immediate visual check — worksets present, all key views rendering correctly — and then executed Save As to Hospital_Extension_Arch_Recovered_20260611.rvt at 17:47.

The eleven modellers who had kept their locals open synchronised against the recovered central between 17:55 and 18:30 in five batches of two to three. The four modellers who had closed Revit were contacted; their locals from before closure were verified to have synchronised before they closed, so no work was attributable to them.

Lost work assessment: Comparison between backup 0019 and the recovered central showed that the six minutes between the last successful STC (16:39) and the crash (approximately 16:45) represented work from three modellers who had been actively editing during that window. Two of the three had kept their locals open and their changes were captured during the post-recovery sync. One had been the modeller whose STC was in progress at the time of the crash — their mid-STC changes were partially in the central and partially not, resulting in the loss of approximately forty-five minutes of element editing in one area of a Level 5 plan. The modeller identified the affected area, recreated the work the following morning, and synchronised.

Total recovery time: From crash at approximately 16:45 to all active modellers synchronised against recovered central: three hours and forty-five minutes. No project milestone was affected.

Lessons: The increased backup count (twenty rather than three) was a direct result of a BIM Execution Plan update made three weeks prior to the corruption event, specifically because the project was entering its highest-risk period for corruption (maximum concurrent users, proximity to milestone). That decision reduced the worst-case backup age from potentially several hours (with three backups and many STCs) to six minutes (with the most recent backup snapshot timestamped just before the crash).

Case study 2: Antivirus lock on a 25-storey commercial tower

Project context: A twenty-five storey commercial tower, Stage 4, with a twelve-person architectural team using a central file on an on-premises NAS device. A new endpoint protection system was deployed across the practice's Windows estate on a Friday morning. The deployment included real-time file scanning with default settings that had not been tuned for Revit workflows. At 14:23 that afternoon, a modeller's STC failed mid-operation with a generic error. The central file subsequently failed to open.

This corruption was partial rather than complete: the file header was intact and Revit could read the file's metadata (version, workset names, project title) but the element table failed validation during open, producing the error "Revit encountered an error when reading this file."

Recovery sequence: The BIM Manager ran the Audit path at 14:31. The audited open took forty-one minutes (the file was 1.4 GB). The file opened successfully but the audit reported seventeen element validation errors — elements that could not be fully reconstructed from the available data. Revit substituted placeholder elements for these and flagged them with error markers in the model.

The BIM Manager identified the seventeen placeholder elements in the recovered central. All seventeen were doors in a specific hotel-floor cluster — elements that had been created or modified by the modeller whose STC was in progress at the time of the crash. The modeller's local still contained the pre-crash state of those elements. The modeller opened their local (detached), exported the seventeen door families and their type data to an external .rvt transfer file, and the BIM Manager then loaded those types into the recovered central and placed the doors in their correct positions using the local as a visual reference.

Root cause: The IT team confirmed that the endpoint protection system's real-time scanner had acquired a lock on the central file during the scan phase of the STC write cycle. The fix was to add the Revit model directories, the .rvt file type, and the backup folder to the antivirus exclusion list — a configuration that the Autodesk Knowledge Network antivirus guidance explicitly recommends.[^8]

Total recovery time: Three hours from corruption to full team synchronised against clean central. Seventeen doors recreated. No project milestone affected.

Lesson: New endpoint protection deployments are a corruption risk event. The BIM Manager should be notified by IT in advance of any endpoint protection changes and should schedule a model backup immediately before and after the deployment. The Autodesk antivirus exclusion list should be verified by IT as part of any protection system upgrade.

Case study 3: OneDrive sync conflict on a residential development

Project context: A small residential developer's in-house team of four modellers was using a Revit central file stored in a OneDrive for Business folder. The setup had been in place for six months without problems — until OneDrive's background sync process decided to perform a conflict resolution on the central file at the same moment a modeller was mid-STC. The result was a zero-byte central file: OneDrive had replaced the in-progress Revit write with an empty conflict-resolution file.

The backup folder was also inside the OneDrive sync scope, which meant that OneDrive had helpfully "synced" several of the backup snapshots and replaced them with conflict versions. Four of the five most recent backups were corrupted.

Recovery sequence: The BIM Manager located the one surviving backup snapshot (backup 0001, representing a state from two days earlier) and the four modellers' local files on their individual machines (which OneDrive had not yet synced, as the locals were outside the synced folder). All four locals were intact and had been synchronised within the last two hours before the corruption.

Path B was used: the most senior modeller's local was used as the recovery base (their local had the broadest workset coverage). Detach from Central, Save As new central, team synchronised sequentially. Approximately ninety minutes of the least-recently-synchronised modeller's work was lost.

Root cause: OneDrive for Business sync in the OneDrive folder. The entire central file and backup folder were migrated off OneDrive to a local NAS device connected to the office network.

Lesson: Consumer and business cloud sync tools are not suitable for hosting Revit central files or their backup folders. The only supported cloud collaboration tools are Revit Server, BIM 360, and Autodesk Construction Cloud. This is not a grey area — it is an explicit requirement in Autodesk's documentation.[^9] If a practice needs cloud-based backup of Revit central files, the appropriate approach is a scheduled server-side backup to cloud storage (e.g., Azure Blob Storage backup of the NAS device), not a sync tool that operates on individual files.

Limits and caveats

Cloud worksharing platforms have different recovery procedures

This playbook applies primarily to local worksharing — central files hosted on a Windows file server, SMB share, or similar on-premises or IaaS network storage. Revit Server, BIM 360, and Autodesk Construction Cloud (ACC) use fundamentally different architectures for the central file, the backup system, and the synchronisation mechanism.

On ACC, the central model is not a .rvt file on a file share — it is a cloud-managed model stored in Autodesk's infrastructure. The backup mechanism is ACC's native version history, not the _backup folder structure. Corruption on ACC manifests differently and is recovered differently: through the ACC admin console's version history restoration tools, not through local Audit procedures. If you are running cloud worksharing and experience a corruption-like failure, your first call is to Autodesk Support and your ACC account administrator, not your IT team.

Revit Server (the on-premises equivalent) has its own recovery procedures involving the Revit Server Manager and the Revit Server Administrator tools. The central model on Revit Server is managed by the Server software, not as a raw file on a share, and recovery requires server-level access.

Audit is not a guarantee

The Audit function repairs many categories of corruption but not all. Corruption that affects Revit's internal format in ways that the Audit validator does not check — such as deep binary-level damage to compressed element blocks — may survive the Audit pass and only manifest later as model instability. If the recovered central exhibits recurring crashes or STC failures after a successful Audit, escalate to Autodesk Support with the original corrupt file.

Autodesk Support has access to internal diagnostic tools that can attempt lower-level file repair not available through the UI. This process is not always successful and can take several business days, making it unsuitable as the primary recovery path under time pressure. It is the option of last resort.

Recovery does not resolve the root cause

A successful recovery restores the central file to an operational state. It does not fix whatever caused the corruption. Until the root cause is identified and addressed, the risk of a second corruption event is elevated — the same infrastructure failure, antivirus configuration, or sync tool conflict that produced the first event is still present.

Root cause analysis is not optional. The corruption incident log (referenced in Anti-Pattern 6) should include a root cause section and a documented remediation action. If the root cause cannot be identified with confidence, treat it as an infrastructure reliability issue and escalate to IT and project management for a storage infrastructure review.

The recovery sequence assumes a healthy network

If the corruption was caused by ongoing network instability — a NAS device with failing disks, a WAN link with high packet loss, a switch with a faulty port — performing the recovery over the same unstable network risks corrupting the recovered central during the Save As or team synchronisation steps. If the network issue is ongoing, resolve it before attempting recovery. This may mean waiting for IT to replace a disk or switch, which is frustrating but correct.

Large models introduce timing risks

The recovery procedures described above — particularly the post-recovery Audit and the team synchronisation sequence — take longer on large models. A 2 GB architectural central on a large hospital project may take sixty to ninety minutes for an audited open. A twenty-person synchronisation sequence at three to five minutes per STC represents two hours of sequential operations. Build these times into your recovery timeline when communicating to project managers. "We expect to be back online by 8 p.m." is more useful than "we are working on it."

Sources and further reading

The following sources were used in this article. URLs were current at the time of writing (June 2026).

• Autodesk Knowledge Network — Revit Central file is corrupted or cannot be opened — Primary Autodesk KB article on central file corruption and recovery, including the local-based recovery procedure.[^2]

• Autodesk Help — About Worksharing — Official documentation for the worksharing system, including central file architecture, STC operation mechanics, and backup folder behaviour.[^1]

• Autodesk Knowledge Network — Revit Worksharing Best Practices Guide — Covers storage compatibility requirements for central file hosting, including tested server configurations and NAS device requirements.[^5]

• Autodesk Knowledge Network — How to avoid problems with Revit files and anti-virus software — Specific exclusion guidance for Windows Defender, third-party AV tools, and the file types and directories that must be excluded.[^8]

• Autodesk Knowledge Network — Revit and Cloud Sync Services — Explicit Autodesk guidance on why consumer and business cloud sync tools (Dropbox, OneDrive, Google Drive) are not supported for central file hosting.[^9]

• Autodesk Help — Open and Audit a Revit File — Official documentation for the Audit option in the Open dialog, including what it repairs and its limitations.[^3]

• Autodesk Knowledge Network — Revit Server and recovery — Covers failure modes and recovery procedures specific to Revit Server deployments.

• Tom Vandezande — Revit OpEd blog, worksharing and file management topics — Named practitioner blog with extensive coverage of Revit worksharing internals, backup strategies, and documented recovery sequences from real project experience.[^4]

• Aaron Maller — Parallax Team, Revit worksharing and central file management — Practitioner-level coverage of Revit file performance, corruption root causes, and the relationship between model health and STC reliability.

• AUGI Revit Architecture Forum — Central file corruption threads — Community documentation of real-world corruption events, recovery sequences that worked and did not, and practitioner-identified patterns for common corruption causes.

• Autodesk Community Revit forum — Central file corrupt after power outage — Accumulated community experience on power-loss corruption events, including confirmation of which backup snapshots are safe to use.

• Modus BIM — Revit Central File Best Practices — Studio-level best practices for central file management including backup retention policy, storage hardware selection, and monthly maintenance schedule.

• BIMscape — Revit Worksharing and Central File Management — Practitioner reference covering the STC cycle, backup folder mechanics, and the relationship between workset structure and corruption risk.