Resolving TIA Portal 'Project in Use' Lock After Crash

Problem Definition: TIA Portal Project Stuck in 'Project in Use' State

After an abnormal termination of the Totally Integrated Automation Portal (TIA Portal) — typically a crash during Save As to a new directory, a Windows shutdown mid-write, or a power loss — the engineering workstation may refuse to re-open the affected project. The dialog "The project is in use" appears even though no TIA Portal instance is visibly running, and the project cannot be opened, archived, or migrated until the lock is released.

Unlike ordinary multi-user locks (handled by TIA Portal Multiuser Engineering), this scenario is a stale local file-system lock caused by a leaked file handle inside the TIA Portal ObjectFrame. The lock must be cleared manually because the original owning process was terminated before it could release its resources.

Root Cause: The .info File and FileStorage.Server.exe Handle Leak

TIA Portal protects every open project against concurrent writes by writing a sidecar file with the .info extension alongside the project archive. This file is created when the project is opened and is deleted by the framework when the project is closed cleanly. The lock file is owned by the host process Siemens.Automation.ObjectFrame.FileStorage.Server.exe, which is a background COM server that brokers the project's I/O operations.

When TIA Portal crashes:

1. The Siemens.Automation.Portal.exe process is terminated by the OS or killed by the user.
2. The child process Siemens.Automation.ObjectFrame.FileStorage.Server.exe is not always terminated with the same parent — Windows treats it as an orphaned COM server and keeps it alive in the background.
3. The orphaned server retains the open file handle on the .info file and never executes the deletion logic that releases the lock.
4. On the next launch, TIA Portal detects the .info file, assumes the project is in use by another session, and refuses to open it.

Because the orphaned server is invisible in the main window list (it has no UI), most engineers only see a memory-resident, headless process in Task Manager that they do not associate with TIA Portal. This is why simply restarting the IDE does not clear the lock.

Affected Versions and Project File Extensions

The lock behavior is consistent across TIA Portal V13, V14, V15, V15.1, V16, V17, V18, V19 and V20. The .info lock-file mechanism is version-specific only in the sense that the project file extension changes between major releases. The lock itself always uses .info.

Preconditions for the Recovery Procedure

Before attempting any manual lock release, verify the following:

1. No Siemens.Automation.Portal.exe is currently running (close the TIA Portal main window completely).
2. No PLCSIM V13/V14/V15/V16/V17 instance is running with a virtual CPU loaded from this project.
3. No TIA Portal Multiuser server session is active on the project (check the TIA Multiuser Administration tool).
4. You have administrator rights on the local workstation (required to terminate the system service and to delete files inside ProgramData or %ProgramFiles% paths).
5. You have a full Windows file backup or a project archive (.zap13, .zap14, ...) of the project as a fallback. If recovery fails, restore from this archive.

Solution 1 — Terminate the Orphaned FileStorage.Server.exe Process

This is the most reliable method and the one most often reported in the field. The orphaned COM server retains the open handle on the .info file, and terminating it is enough to release the lock.

Step-by-step

1. Close TIA Portal if it is open.
2. Open Task Manager (Ctrl+Shift+Esc).
3. Click More details to expand the process list.
4. Locate the process Siemens.Automation.ObjectFrame.FileStorage.Server.exe. It is usually listed as a background process and consumes between 30 MB and 200 MB of working set, depending on project size.
5. Right-click the process and select End task. Confirm the elevation prompt if Windows asks.
6. Wait 5 seconds. The COM server releases its file handle on .info as it shuts down.
7. Re-launch TIA Portal V13 and open the project. The "Project is in use" dialog should no longer appear.

If multiple FileStorage.Server.exe instances are listed (one per previously opened project), end them all unless one belongs to an actively open TIA Portal window.

Verification

• Task Manager → Details → confirm no FileStorage.Server.exe remains after TIA Portal is closed.
• Windows Explorer → navigate to the project folder → confirm the .info file is either absent or has a timestamp matching the project close time.

Solution 2 — Delete the Stale .info Lock File

If the orphaned server has been terminated but the .info file remains (for example after a forced power-off), it can be deleted manually. TIA Portal only checks for the presence of this file on open; if it does not exist, the project is considered free.

Step-by-step

1. Close TIA Portal completely.
2. In Windows Explorer, navigate to the project folder (for example C:\Users\<user>\Documents\Automation\MyPlant\).
3. Enable File name extensions in the View ribbon.
4. Look for a file with the same base name as the project and the .info extension, e.g. MyPlant.ap13.info.
5. Confirm that the modification time of the .info file predates the crash (i.e. it was not touched on the last clean close).
6. Select the file and press Delete. If Windows reports "The action can't be completed because the file is open in another program", return to Solution 1 and terminate the orphaned server first.
7. Re-launch TIA Portal and open the project.

Solution 3 — Copy the Project Folder to a New Location

If Solutions 1 and 2 fail (for example because Windows itself has cached the open handle and the file cannot be deleted), copying the project produces a clean, lock-free copy. This works because Windows Copy opens the source for read, which is permitted even on a write-locked file. The destination has no .info file unless TIA Portal has been launched in between.

Step-by-step

1. Close TIA Portal.
2. In Windows Explorer, right-click the project folder (e.g. MyPlant) and select Copy.
3. Paste to a sibling location, e.g. C:\Users\<user>\Documents\Automation\MyPlant_recovered\.
4. Verify the new folder contains the .ap13 project file and the standard subfolders but not the .info file.
5. Open TIA Portal, choose Open > Project, and browse to the new folder.
6. Once verified, archive the recovered copy with Project > Archive to obtain a clean .zap13 for long-term storage.

This method is field-tested as a last resort when both the process termination and the file deletion fail. It is also the safest option because the source folder is left untouched until the copy is verified to open.

Solution 4 — Log Off the Windows User

When the orphaned server runs as the same Windows user that owns the TIA Portal project, logging off the user profile terminates all processes spawned in that session — including the orphaned COM server. This was the historical workaround before the Task Manager approach was widely adopted.

Step-by-step

1. Close TIA Portal and any open instance of the project.
2. Open the Start menu, click the user icon, and select Sign out.
3. Sign back in with the same Windows credentials.
4. Re-launch TIA Portal and open the project.

Why Each Solution Works and When to Choose It

Troubleshooting Matrix

Prevention: Engineering Workstation Hardening

The crash mode that creates this lock condition is most commonly triggered by a write interruption (power loss, BSOD, forced shutdown) during Save As or Archive. The following practices reduce the probability of encountering the issue in the future.

• Use a UPS on every engineering workstation. A 5-minute runtime is sufficient to ride out short outages during save operations.
• Disable Windows fast startup. Fast startup hibernates the kernel session and can leave file handles in an undefined state after the next boot. Disable via powercfg /h off in an elevated command prompt.
• Enable TIA Portal auto-archive on every save. Configure under Options > Settings > General > Auto save / auto archive. Keep the archive interval short (5–10 minutes) and the number of generations to at least 10.
• Use the project on a local SSD, not a network share. Network shares introduce additional lock semantics that complicate recovery.
• Close PLCSIM before closing TIA Portal. PLCSIM V13/V14/V15 keeps an independent handle on the project file even after the TIA Portal window is closed.
• Maintain a regular archive schedule. Even when the lock can be cleared, the recovered project should be archived immediately to a .zapXX file on a separate drive.

Verification After Recovery

1. Open the recovered project in TIA Portal.
2. Compile the project (Project > Compile > Software (rebuild all) or the equivalent in your version).
3. Cross-reference the offline/online comparison for every CPU in the project.
4. Download to a test CPU and verify the program state.
5. Archive the project (Project > Archive) and store the .zapXX file in a versioned location.

Related Lock Conditions to Recognize

Not every "project in use" message is the orphan FileStorage.Server.exe case. The following related symptoms have different root causes and must be diagnosed separately:

• Multiuser lock: Multi-user engineering projects on the TIA Multiuser Server produce a .mul sidecar file in the local project cache. The lock is held by the active session user and is cleared when that user closes the project. Only the multiuser server administrator can force-release it.
• PLCSIM lock: A running PLCSIM V13/V14/V15/V16/V17 instance may retain the project open. Stop PLCSIM and the PLCSIM service (S7-PlcSimService.exe) before opening the project.
• Read-only attribute: A failed save can set the NTFS read-only attribute on the project folder or on the .ap13 file. The lock message may then be misleading. Clear the attribute via Properties > General > Attributes.
• Antivirus scan lock: Some endpoint protection products open project files for scanning. The scan handle is short-lived, but if the scan hangs it can produce a similar symptom. Configure an exclusion for %USERPROFILE%\Documents\Automation\.

Field-Proven Sequence of Operations

For repeatable recovery in a service dispatch situation, follow this sequence in order. Stop at the first step that resolves the issue.

1. Open Task Manager → end Siemens.Automation.ObjectFrame.FileStorage.Server.exe.
2. Re-open the project.
3. If the message persists, close TIA Portal and delete the <projectname>.<ext>.info file.
4. If the file cannot be deleted, restart the workstation.
5. If the project is still locked, copy the folder to a new location and open the copy.
6. Archive the recovered project immediately.

FAQ