Recovering a damaged CAD file: 91% comes back, 8.5% does not

Four in the afternoon, the package goes out at five, and the structural plan refuses to open. The first feeling is that everything is gone. In practice recovering a damaged CAD file almost always gets the drawing back, and almost never gets all of it back.

This article does the thing other guides skip: it breaks a real drawing on purpose, repairs it, and then counts what is left. The whole discipline of managing a drawing set is taught properly on our AutoCAD for Construction course.

Three different questions asked in the same words

People describe all three of these the same way, yet they have three different causes and three different fixes.

Only the first row is really about recovering a damaged CAD file; the other two are permission problems wearing the same clothes. Getting the group wrong wastes an afternoon. Running RECOVER on a read-only file repairs nothing, because nothing is broken. Changing the write permission on a genuinely damaged file rescues nothing either.

Where the recover command and the audit command live

The table below was read from the acad.cuix interface file and the acad.pgp alias file of the 2027 release on the machine, not copied from documentation.

The first three have no alias at all, which sets them apart from almost every drawing command. Only DRAWINGRECOVERY has one, DRM.

Run the audit command on a healthy drawing and the program's own log records this, word for word.

Command: _.AUDIT
Fix any errors detected? [Yes/No] <N>: y
Auditing Header
Auditing Tables
Auditing Entities Pass 1
Pass 1 16600   objects audited
Auditing Entities Pass 2
Pass 2 16600   objects audited
Auditing Blocks
 523     Blocks audited
Auditing AcDsRecords
Total errors found 0 fixed 0
Erased 0 objects

Note the angle brackets on the second line. <N> is the default, so pressing Enter to hurry through means the drawing is checked but not repaired. Type Y first, then Enter.

A drawing that will not open: how much the recover command gets back

This is the part no guide answers with a number.

The test file is a real structural plan, 674,660 bytes, holding 4,686 objects in model space. Two identical copies were made. In the second, 64 bytes at offset 303,597 — roughly mid-file — were overwritten. Then RECOVER was run on both.

The dialog that appears after the repair reads exactly like this.

Open Drawing - Damaged File
The drawing file was recovered.
Errors were found and fixed in the drawing. Invalid data might have been
changed or deleted, and some previously erased objects might have been restored.
Errors found:   105
Errors fixed:   105
Objects erased: 0

Skim that and it is reassuring: everything fixed, nothing erased. Counting the objects in the repaired drawing tells a different story.

398 objects gone, which is 8.5% of the drawing. Nothing said so, and the dialog still reads Objects erased: 0. That figure counts objects deleted after the drawing finished loading; it does not count what the program could not read and stepped over on the way in.

Autodesk's page on RECOVER says so plainly, in a sentence most readers skim past: "Repairs and then opens a damaged drawing file. The program extracts as much data as it can from the damaged file."

As much data as it can is the operative phrase. The command does not patch the damage; it salvages whatever it can reach.

There is genuinely good news in the measurement too. The whole framework of the drawing survived untouched: 30 layers still 30, 14 text styles still 14, 6 dimension styles still 6, and both layouts present. What went missing was scattered geometry, not settings.

Finding out what was lost: AUDITCTL and the ADT report

When repairing a broken file, this order saves hours of guesswork.

Step two is the one almost nobody takes, and it is what answers the question "what went missing". Autodesk's page on AUDIT states: "If the AUDITCTL system variable is set to 1, a text file with an ADT file extension is created that describes the problem and the action taken."

Setting AUDITCTL to 1 and repeating the repair on the same damaged file produced t7.adt, 1,117 lines long, sitting next to the drawing. It opens like this.

Drawing: C:\t9\t7.dwg   Autodesk, Inc.   AutoCAD  AUDIT REPORT   Page 1
 Release: 26.0s (LMS Tech)   Microsoft Windows NT Version 10.0 (Intel64)

Reading handle 4239D object type AcDb2dVertex
        Error 13 (eUnknownHandle)
Reading handle 423B0 object type AcDb2dVertex
        Error 13 (eUnknownHandle)
...
Total errors found 105 fixed 105
Erased 0 objects

The file names the handle and the type of each object the program could not read. With AUDITCTL at 0, the identical run produces no .adt file at all. Using PURGE and the audit command as housekeeping tools rather than repair tools is covered in our article on lightening a CAD drawing.

One more cause gets mistaken for damage: a drawing saved in a newer release than the one being used. Nothing is broken there, it only needs converting down, and that is covered in our article on saving a drawing to an older DWG version.

A write protected drawing: three real causes

The second group of symptoms has nothing to do with damage. The drawing opens beautifully, edits fine, and simply will not save. That is almost always one of the three causes below.

One, the Windows read-only attribute. Set the read-only flag on a DWG and open it: the title bar gains the words Read Only after the drawing name, and a small padlock appears on the drawing tab. Press save and a message box comes up.

AutoCAD Message
Drawing file is write protected.

That is the exact line anyone facing a write protected drawing sees. The fix lives outside the program: right-click the file in Windows, open Properties, clear the Read-only box. If the file sits on a network drive where you have no write permission, SAVEAS to somewhere else is the only route.

Two, the FILEDIA variable set to 0. Plenty of pages advise setting FILEDIA back to 1, and the advice is right, but the reason is usually told wrong. FILEDIA at 0 does not block saving. It replaces the file dialog with a question on the command line.

Command: _.SAVEAS
Current file format: AutoCAD 2018 Drawing
Enter file format [R14(LT98&LT97)/2000(LT2000)/2004(LT2004)/2007(LT2007)/
2010(LT2010)/2013(LT2013)/2018(LT2018)/Standards/DXF/Template] <2018>:

The user presses Ctrl + S, sees no familiar dialog, and assumes the program has hung. It is in fact waiting for an answer at the bottom of the screen. Type FILEDIA, enter 1, and the dialog comes back.

Three, the file is sitting in a temporary folder. Opening a drawing straight out of an email attachment or a zip archive does this. It saves without complaint, and the next day the file cannot be found. Extract to a real folder before opening.

The DWL file names who holds the drawing, and locks nothing

Open any drawing and two small files appear beside it in the same folder.

Open the .dwl in Notepad and it holds exactly three lines.

pc
DESKTOP-L2465T5
Sunday, September 20, 2026  8:23:15 PM

Account name, machine name, time opened. Close the drawing and both files disappear. That is their real purpose: on a shared network folder, the .dwl tells you who has the drawing, so you ring the right person.

And here is the correction worth making. Many guides teach that a locked drawing is freed by deleting the .dwl. Tested directly: a .dwl was written by hand naming a different user on a different machine, placed beside a drawing, and the drawing was opened. It opened normally, fully editable, with no warning of any kind — and the program overwrote that .dwl with its own machine name.

So a leftover .dwl locks nothing. It is a note taped to the door. The real lock is elsewhere: the operating system holding the file while a program has it open, and the read-only flag from the previous section. Deleting a .dwl does no harm, but do not expect it to cure anything.

Three files that save you when the machine dies

When the power goes mid-session, what rescues the drawing is not a command but a few files the program quietly left behind.

The .bak file. Save a drawing once and there is none. Save a second time and a .bak appears, measured at 15,461 bytes — exactly the size the .dwg had after the first save. In other words, the .bak is the drawing as of the previous save. Rename it to .dwg and it opens, but you go back one save.

The .sv$ file. The program autosaves every 10 minutes, per the SAVETIME variable, into the folder named by SAVEFILEPATH. On the test machine that is C:\Users\pc\AppData\Local\Temp\, holding a file named mau-mbkc_1_1200_ca1ccebe.sv$. Copy it elsewhere, rename it to .dwg, and it opens with all 6,184 objects present, with no object type missing.

There is a small trap here. Open the .sv$ without renaming it and the program reports the file as missing, even though it is sitting there with all 709,527 bytes.

File C:\t9\t6.sv$ is not found

Renaming is mandatory, not a nicety.

The drawing recovery manager. After an abnormal exit, type DRM to open it. It gathers the original, the .bak and the .sv$ for each drawing that was open when the crash happened, with the timestamp of each, so you can pick the newest. RECOVERYMODE on the test machine reads 2, meaning the palette opens by itself after a crash.

For a drawing with external references, use RECOVERALL instead of RECOVER, because it repairs the attached xrefs as well. Managing external references is covered in our article on xrefs in AutoCAD.

Five things people say that are not true

Frequently asked questions

The drawing errors the moment I open it — what first?

Copy the file to a spare first, then run RECOVER on the copy. Never work directly on the original.

How do I find out what recovery lost?

Set AUDITCTL to 1 before repairing. The program leaves an .adt text file beside the drawing, naming the handle and type of every object it could not read.

The title bar says Read Only — how do I fix that?

Close the drawing, right-click the file in Windows, open Properties and clear the Read-only box. On a network drive, ask the administrator or save somewhere you can write.

The machine died before I saved — where is the drawing?

Type DRM to open the drawing recovery manager. If it lists nothing, go to the folder named by SAVEFILEPATH, find the .sv$ matching the drawing name and rename it to .dwg.

Should I save the repaired drawing over the old one?

No. Save it under a new name and keep the damaged file. If something turns out to be missing later, the original is still there to try again on.

What about a drawing with many xrefs?

Use RECOVERALL rather than RECOVER. It checks and repairs the host drawing and every external reference it calls.