Drawing Repair (AUDIT/RECOVER) — Use AUDIT and RECOVER to check and repair drawings (intro)

Historical Context & Motivation

Since Autodesk released the first version of AutoCAD in 1982, the DWG file format has served as the de facto standard for two-dimensional and three-dimensional computer-aided design data. As drawings grew in complexity—incorporating external references, custom objects, proxy entities, and third-party plug-in data—the probability of file corruption increased correspondingly. Power failures during save operations, network interruptions on shared drives, and incompatible object enablers all contributed to a class of failures that could render weeks of design work inaccessible. The engineering and architecture industries needed a reliable mechanism to detect and, where possible, repair these inconsistencies without resorting to a complete redraw.

Autodesk responded by embedding diagnostic and recovery utilities directly into the AutoCAD application. Over successive releases, these utilities evolved from simple database consistency checks into sophisticated repair pipelines capable of salvaging drawings that would otherwise refuse to open. Understanding the lineage of these tools is essential for any practitioner who manages CAD files at scale, because the repair strategies available today reflect decades of accumulated knowledge about how DWG databases can fail.

The central question that these tools address is deceptively simple: how can a software application verify the internal consistency of a complex binary database and, when inconsistencies are found, correct them without introducing new errors? The AUDIT and RECOVER commands represent two complementary answers to that question, each optimized for a different failure scenario.

Core Principles & Definitions

Before diving into command syntax, it is important to establish the foundational concepts that underpin drawing repair in AutoCAD. A DWG file is not a flat list of geometric primitives; it is a hierarchical object database with symbol tables, dictionaries, block definitions, and entity records linked by internal handles. Corruption occurs when these linkages become inconsistent—when a handle references a non-existent object, when a symbol table entry points to the wrong block record, or when the file's header metadata disagrees with the actual data content. Understanding the nature of these inconsistencies is the first step toward effective repair.

Visual Explanation — The Repair Decision Tree

Choosing the right repair strategy depends on the symptom. The following flowchart maps common failure modes to the appropriate AutoCAD command, guiding you from initial symptom through diagnosis to resolution.

Notice the asymmetry in the flowchart: AUDIT is a non-destructive inspection that operates on an already-loaded database, whereas RECOVER performs a fresh parse of the on-disk binary, bypassing any in-memory state that might itself be corrupt. This distinction mirrors the difference between checking a running process's heap integrity versus reloading the binary from its executable image—a concept familiar from operating-systems coursework.

How AUDIT and RECOVER Work Internally

While AutoCAD does not expose the full source code of its repair algorithms, the behavior of AUDIT and RECOVER can be understood through the lens of database consistency checking—a topic well-studied in computer science. The DWG file can be modeled as a directed acyclic graph (DAG) of objects, where each node is an entity or table record and each edge is a handle reference. Corruption corresponds to dangling pointers, cyclic references in an ostensibly acyclic structure, or mismatched checksums in the file header.

AUDIT Algorithm (Conceptual Model)

1. Phase 1 — Header Validation: Verify the DWG version signature, variable counts, and table offsets. Flag mismatches between declared and actual counts.
2. Phase 2 — Symbol Table Walk: Iterate through layer, linetype, block, dimension style, and text style tables. Confirm each entry's handle resolves correctly and its owner pointer matches the table's handle.
3. Phase 3 — Entity Traversal: Walk every entity in model space and paper space. Validate geometric data ranges (e.g., coordinates within ±10²⁰), verify layer and linetype references, and check block insert nesting depth.
4. Phase 4 — Dictionary Check: Inspect named object dictionaries (ACAD_GROUP, ACAD_MLINESTYLE, etc.). Ensure dictionary entries have valid key-value pairings.
5. Phase 5 — Report and Optional Repair: Output error count to the command line. If the user chose 'Yes' to fix errors, apply corrections such as re-creating missing symbol table entries or deleting orphaned entities.

RECOVER Algorithm (Conceptual Model)

RECOVER operates at a lower level. Rather than traversing the in-memory object graph, it re-reads the binary DWG file from the first byte, parsing each section according to the DWG specification. It reconstructs the object map (a lookup table mapping handles to file offsets), rebuilds symbol tables from the ground up, and then performs the equivalent of a full AUDIT on the reconstructed database. Any object whose binary data cannot be parsed is logged and discarded rather than allowed to corrupt adjacent records. This is conceptually similar to how e2fsck -y in Linux rebuilds an ext4 journal: the tool trusts the raw on-disk data over any cached metadata.

Command Syntax & Related Utilities

AutoCAD provides several commands in the drawing repair family. The table below catalogs each command's syntax, when to use it, and what it does under the hood. Mastering these distinctions will allow you to select the minimum-invasive repair for any given failure scenario—a principle analogous to choosing the least-privilege operation in systems security.

Worked Example — Repairing a Corrupt Drawing

Consider the following scenario: you receive a DWG file from a colleague. When you open it, AutoCAD displays a "Drawing file is not valid" error and refuses to load. The file is 12 MB—large enough to contain significant work. Your goal is to recover as much data as possible.

AUDIT vs. RECOVER — Strengths & Limitations

Both AUDIT and RECOVER target the same goal—database integrity—but they approach it from different angles and have different trade-offs. Understanding these trade-offs is critical for selecting the right tool and for knowing when neither tool will suffice.

Connection to Advanced File Management

AUDIT and RECOVER are entry-level repair tools, but they exist within a broader ecosystem of file management and quality control practices. Understanding how these introductory commands connect to advanced strategies will prepare you for enterprise-scale CAD administration, where thousands of drawings must be maintained across multi-year projects.

If you are coming from a computer science background, think of AUDIT and RECOVER as the manual debugging tools in a toolchain that also includes automated CI/CD-style pipelines. Just as a developer might start with gdb before investing in a full test suite, a CAD administrator starts with AUDIT before building batch scripts that enforce drawing quality across an entire project. The advanced techniques—AutoLISP scripting, .NET plug-in development, and integration with Autodesk Vault—are covered in subsequent lessons on CAD automation and enterprise workflows.

Practice Problems

Lesson Summary