Resolving WinCC Database Connection Failures and Corrupted DCF Files After OS Download

In SIMATIC PCS 7, when a target OS Server reports database connection failures or 'Database context does not exist or is not valid' following a download from the Engineering Station (ES), the root cause is an invalid Distribution Configuration File (<ProjectName>.dcf). The .dcf file caches SQL Server instance names, network paths, and station UUIDs. When a project is transferred across stations or cloned in virtualized environments, stale pointers prevent SQL database attachment. To resolve this, close WinCC, terminate background processes via Reset_WinCC.vbs, delete the .dcf file, and reopen the project to trigger automatic file regeneration.

Mechanics of the WinCC Distribution Configuration File (.dcf)

In SIMATIC PCS 7 WinCC, every project maintains a critical configuration file bearing the project name with the extension .dcf (e.g., OS_SVR.dcf):
* The Role of the DCF File:
The .dcf file acts as the bridge between the Windows operating system environment, the SIMATIC Shell network, and the Microsoft SQL Server database engine.
* Internal Cached Parameters:
It stores the unique project identifier (GUID), the designated Computer Name, the local database file paths (.mdf and .ldf), and the active SQL Server instance descriptor (<ComputerName>\WINCC).
* The Failure Scenario:
If the .dcf file contains outdated parameters (e.g., referencing the ES computer name instead of the OS Server, or an old IP/path after migration), WinCC cannot attach the database, triggering the error: 'Database context does not exist or is not valid.'

Why Network Downloads and Cloning Corrupt Database Contexts

Interrupted OS Downloads:
During an OS download from SIMATIC Manager, the ES copies files over the network share and modifies the .dcf file to point to the target server. If the network drops or the transfer times out, the .dcf file is left in an unfinalized state.
Virtual Machine Duplication (VMware / Hyper-V):
When engineers clone an OS Server VM without generalizing the Windows security identifiers (SIDs) and hostname, the .dcf file references the parent VM's database handles.
Unexpected Power Loss:
A sudden power outage while WinCC is active prevents the SQL Server engine from cleanly detaching files, leaving dirty flags in the .dcf transaction cache.

Comparison Table: WinCC Project Configuration Files and Their Roles

The table below outlines essential files in the WinCC project directory and their recovery procedures:

File Name / ExtensionPurpose / ContentSafe to Delete When Closed?Regeneration Mechanism<Project>.mcpMaster Control Project configurationNo (Critical Project File)Must be restored from backup<Project>.dcfDistribution Configuration File (Context)Yes (Safe to Delete)Auto-generated upon opening project<Project>.mdf / .ldfSQL Server Configuration DatabaseNo (Contains Project Data)Attached by SQL Server engine<Project>RT.mdf / .ldfSQL Server Runtime DatabaseNo (Active Runtime Data)Recreated on OS Compilation*.lckProcess file lock indicatorsYes (Safe to Delete)Created dynamically by running processes

Step-by-Step Procedure to Regenerate Corrupted .dcf Files

Ensure WinCC is Completely Closed:
On the target OS Server, exit WinCC Explorer. Open Windows Task Manager and verify no CC*.exe processes remain active.
Execute WinCC Cleanup Script:
Open Windows Command Prompt as Administrator and run:
C:\Program Files (x86)\Siemens\WinCC\bin\Reset_WinCC.vbs
Wait for the command to complete.
Backup the Project Directory:
Create a compressed ZIP copy of the entire project folder as a safety precaution.
Delete the Corrupted .dcf File:
* Open Windows File Explorer.
* Navigate to the root directory of the WinCC project.
* Locate <ProjectName>.dcf and press Shift+Delete.
* Also delete any remaining *.lck files.
Reopen the Project in WinCC Explorer:
Double-click <ProjectName>.mcp. WinCC Explorer launches, interrogates the local Windows environment and SQL Server instance, and generates a fresh, clean <ProjectName>.dcf file.
Verify and Activate Runtime:
Check that project properties display the correct local computer name. Activate Runtime to verify seamless operation.

SQL Server Instance Attachment and User Permissions Recovery

If database attachment still fails after regenerating the .dcf file:
* Verify SQL Server WINCC Service:
Open services.msc. Confirm that SQL Server (WINCC) is running under the local system account or dedicated Siemens service account.
* Verify SIMATIC HMI Security Group:
In Windows Computer Management -> Local Users and Groups -> Groups:
Ensure that the active Windows user account logged into the OS Server is a member of the SIMATIC HMI and SIMATIC NET security groups. Without these group rights, Windows blocks SQL database file attachments.

Verification

To verify that the database context is restored and operational:
1. Confirm that <ProjectName>.dcf is present in the project directory with the current system timestamp.
2. Open WinCC Explorer. Verify that the navigation tree (Tag Management, Alarm Logging, Graphics Designer) expands without errors.
3. Open WinCC Channel Diagnosis. Verify that the communication channels connect to the automation station.
4. Activate WinCC Runtime. Verify that alarm banners populate and process values animate normally.

Limitations and Operational Precautions

Never Delete .MDF or .LDF Files: While deleting .dcf files is safe, never delete .mdf or .ldf files. Deleting database files destroys all plant tags, alarm configurations, and historical logs.
Redundant Server Partnering: On redundant OS systems, perform the .dcf reset on one server at a time. Ensure the partner server remains online to prevent operator console disruption.
Licensing Disclaimer: SIMATIC PCS 7 OS Server runtime licenses (6ES7658-2CX58-0YB5 / 6ES7652-0XX08-1XB0) must be validated against the applicable Siemens catalog and authorized distributor quotation.