Recover a corrupt CODESYS project file after a crash

What the damage looks like

Match what you see against these four patterns first, because the pattern decides the path.

• The .pro is 4 kB, or it saved as a 0-byte file. The file was wiped during the crash or the interrupted save. A machine project with a web visualization holds far more than 4 kB, so treat a 4 kB file as empty. Recovery here means finding another copy: repair works on damaged structure, and a wiped file has none left. The editor has been recorded saving a project as a 0-byte file that then would not open, so this pattern exists on its own, without a visible crash message.
• The .pro is full size but corrupt inside. The project opens partway, reports broken objects, or refuses after an edit such as renaming a network variable list. The structure is damaged and the content is present. This is the pattern vendor support can usually repair.
• The editor will not start, but the .pro size looks normal. The installation is what broke, and the project file is most likely intact. Repair the installation before you touch the project; the same first-look discipline is in HMI editor crash diagnosis before software repair.
• The controller still runs the application and the web visualization loads. That is the compiled build talking, and it says nothing about your source. It does give you the reference you will rewrite against, and how to check the CODESYS runtime is running or stopped tells you the application stayed up through all of this.

Protect the disk in the first 60 minutes

Undelete works only on space nothing has overwritten, so the first 60 minutes decide whether the fifth search has a chance.

1. Copy the damaged .pro to another drive within the first 10 minutes and mark the copy read-only (in Windows: right-click, Properties, Read-only). Every experiment from here on happens on copies.
2. Stop writing to the disk that held the project: no saves, no installs, no downloads onto it.
3. Never re-save the small .pro from the editor over its own path. Saving over the 4 kB file destroys what an undelete tool could still find in the freed space around it.
4. Leave the controller alone. The running application is your only working program and your reference, and nothing gets downloaded to it while you search.

The five searches that find a copy

Run these on every drive the project has ever touched, including USB sticks and network shares. One full pass of all five takes about 60 minutes on a single PC and settles the question.

1. Every .pro on the machine. In File Explorer search from the root of drive C:, enter *.pro, and repeat from the root of every other drive, not from the project folder. Old copies live in odd places. Include *.project in the same pass; projects saved from the older generation of the tool carry that extension.
2. Every file with the project name. Search the project name with any extension, sort by the Date modified column, and open anything stamped on or before the crash day. A copy with a strange extension is still a copy.
3. .exp exports. Search for *.exp. An export is readable text of the project objects, it opens in any editor, and the import under the editor's Project menu puts the objects into a fresh project. If you find one, do the import into a new project with a different name, so nothing overwrites a surviving original.
4. ZIP archives and the machine documentation. List the contents of every *.zip, *.7z and *.rar you find. Commissioning projects are routinely archived with the machine manual, so check the documentation pack and the stick that shipped with the machine.
5. Deleted files. Check the Recycle Bin first; the mechanics are covered in troubleshooting Recycle Bin data loss in Windows. Then run an undelete tool against the drive; start with recovering deleted Windows files after the bin is emptied. Do this step last, because the four searches above copy files onto the disk, and every copy lowers the undelete odds.

If the project was under source control, run the same *.pro and project-name search against the local working-copy folder before the undelete step; that folder is one more place a full copy sits, and reading it writes nothing to the damaged drive.

What the running PLC can give back

Nothing that reconstructs your project. The compiled application in the controller is build output, and the vendor's answer to the decompile question is a flat no. The web visualization behaves the same way: the pages the PLC serves are generated from the build, and the WebVisu file the controller serves is an output of compilation, not a project you can reopen. What the running machine does give you is a live specification. Every screen, every move, every fault reaction you can provoke on the floor is the behavior your rewrite has to reproduce.

When to send the file to support

CODESYS support at 3S examines corrupt project files, and most structurally damaged projects come back repaired. Send a copy the same day you find the damage, because the repair takes days and it runs in parallel with your search. One limit: repair needs structure to work with. A reported case ended exactly there, with a 4 kB wiped file, support examining it, and nothing coming back. A 0-byte save is in the same class.

Example: a 4 kB .pro, no backup, the machine still running

The inputs:

• Damaged file: one .pro at 4 kB (4,096 bytes), on the engineering PC, after an editor crash (the reported case).
• Backups on that PC: none. No .exp export, no ZIP, Recycle Bin empty. That is the state after the five searches below, which took about 60 minutes, and the backups were skipped because the project was still unfinished.
• Controller: runtime running, web visualization reachable from the office network.
• Vendor support: one repair attempt on the wiped file, one failure.
• Search classes run: 5 of 5.

The rule in words: a recovery path exists only when at least one artifact class yields a usable source. Count the hits before you plan days of work.

The arithmetic:

• Usable copies from the 60-minute search pass: 5 classes x 0 hits = 0 sources.
• Restored projects from support: 1 attempt, 0 restored = 0 sources.
• Total usable sources: 0 + 0 = 0, against a damaged original of 4 kB.
• Sources inside the PLC: 1 working compiled program, 0 recoverable projects, because decompiling is impossible.

The result: zero sources anywhere. The rewrite is the only path.

The decision: when a full five-class pass plus one support attempt returns zero usable sources, stop searching that day and start rewriting. Rebuild the program and the visualization in a new project, verify the rewrite against the running machine, and download only when the two agree. The one hard rule: never download an unverified rewrite over the running application. The machine is your specification and your safety reference while you work.

Make the next crash a non-event

Tie backups to the session, not to the milestone:

• End every editing session with an .exp export (Project > Export) plus a dated ZIP of the project folder. Two formats, because the export is readable text and the ZIP holds the whole project.
• Keep 3 generations of each. That is the common rotation depth that survives one bad save and one bad restore.
• Store one generation off the editing PC, for example on the USB stick kept with the machine documentation.
• Back the unfinished project up first. The unfinished one is the file you open every day, it is the one with no backup, and the crash lands while you are still inside it.

The decision for each case

• A usable copy or .exp turns up: open it, check its date against the crash, and export before you edit further.
• No copy, full-size corrupt .pro: preserve it read-only, send it to support the same day, and keep the machine running while you wait.
• No copy, wiped 4 kB or 0-byte .pro, support failed: rewrite against the running machine, and download only when the rewrite matches.

Recommendation: Run the five searches and the support request in parallel on day one, with the damaged .pro preserved read-only and nothing written to its drive. If any search yields a usable source, recover from it and export the same hour. If the full pass plus the support answer returns nothing, commit to the rewrite that same week and treat the running machine as the specification until the new project matches it.

Questions