Resolving PCS 7 APL_OperationLog MSG-API Create Failure on OS

Problem Overview

When an operator changes a SetPoint on a PCS 7 Operator Station (OS) running a project that uses the Advanced Process Library (APL), the diagnostic window logs the following error string issued by the APL_OperationLog function block:

APL_OperationLog: MSRTCreateMsgInstanceWithComment szErrorText = Exception in MSG-API (pIAlarmData->Create(...) failed) / File [CRequestContext.cpp] / Line [2878]

The operator's setpoint change is still applied to the automation system (AS), but no operator-action message is written to the WinCC Alarm Logging runtime database. Because PCS 7 requires audit-quality traceability of every operator intervention, the missing log entry creates a compliance gap. In multi-client, single-server, or redundant OS Server topologies the symptom is usually confined to the OS Client; the OS Server itself continues to archive messages correctly, which is why the issue is often misdiagnosed as a network or WinCC Service problem.

The failure is not a user-script defect: the same error appears when the stock Siemens APL faceplates and unmodified APL_OperationLog function block from the master data library are used. The root cause is almost always in the OS Server package that was downloaded to the client. Reassigning the OS Server with the Standard Server preset restores message generation without modifying any application code.

Technical Background: APL_OperationLog in PCS 7

APL_OperationLog is a standard CFC function block shipped in the PCS 7 Advanced Process Library (APL). It is referenced by every APL faceplate (motor, valve, PID controller, analog monitor, digital monitor, dosing, etc.) so that any operator command issued from the OS is captured in the Alarm Logging subsystem with the comment field, the user name, the timestamp and the original/target value pair.

The block writes a message through the WinCC ODK (Open Development Kit) function MSRTCreateMsgInstanceWithComment. This function is part of the WinCC Message System Runtime API and is also used by the OS Project Editor's "Message Configuration" function to register operator-action messages. MSRTCreateMsgInstanceWithComment is considered an internal API call: it is not visible in the WinCC C-Editor and is not part of the documented scripting interface. It is invoked indirectly by the C-Standard function that PCS 7 generates from APL_OperationLog.

Internally the call chain is:

1. Operator clicks on the SetPoint field of an APL faceplate.
2. Faceplate writes the new value to the AS and the APL_OperationLog instance is triggered.
3. The C-Standard function calls MSRTCreateMsgInstanceWithComment() in the WinCC ODK.
4. The ODK routes the call into CRequestContext.cpp at the Alarm Server DLL boundary.
5. The Alarm Server attempts to instantiate a message object via pIAlarmData->Create(...) and either succeeds (message is written) or returns an exception.

When the exception is thrown, the ODK packages the text and line number into szErrorText and returns it to the calling C-Standard function, which then displays the diagnostic string on the OS. The line number (e.g. 2878) is a build-time constant and can vary between PCS 7 versions and WinCC service packs; it should not be used as a unique fault identifier.

Symptoms and Diagnostic Checklist

Before applying the server-reassignment fix, confirm the following symptoms. The combination of (a) and (b) is a strong indicator of the corrupted server-package issue.

Root Cause

The PCS 7 OS Client downloads a partial copy of the OS Server package during project assignment. If the server package becomes inconsistent — typically because the project was edited on the server, a hotfix was applied, or a different OS Server was assigned previously — the downloaded package no longer matches the server's published database schema for Alarm Logging. When the client subsequently calls MSRTCreateMsgInstanceWithComment, the runtime context cannot resolve the message class configuration and pIAlarmData->Create(...) fails. The server side is unaffected because the server always uses its local, canonical package.

Two specific misconfigurations on the server side produce this state:

1. No Standard Server assigned — the OS Project Editor > Server Data > Alarms section does not list any server as the Standard Server. Without a Standard Server, the Alarm Logging runtime does not register the message classes that MSRTCreateMsgInstanceWithComment requires.
2. SSM (System State Manager) without a Standard Server — even when the Alarm Logging standard server is correctly assigned, leaving the SSM without a standard server leaves a subset of system-state messages uninitialised, and the first call from the client triggers the exception.

The fix is to remove the corrupted client package, reassign the OS Server with the Standard Server preset for both Alarms and SSM, and download the freshly generated server package to the client. This rebuilds the Alarm Logging schema on the client to match the server.

Solution Procedure

Prerequisites

• Engineering station with the same PCS 7 version as the OS Server (e.g. PCS 7 V9.0 SP2, V9.1, V8.2 SP1).
• Local administrator rights on the OS Server and on the OS Client.
• User Administrator export of the area-specific operator rights (they will be deleted by the reassignment).
• Latest WinCC Service Pack applied to all OS nodes (see Siemens Support Entry 109769218 for current PCS 7 / WinCC compatibility).

Step-by-Step Reassignment

1. Close all WinCC Explorer instances on every OS node (server, standby server, clients).
2. On the OS Client, open WinCC Explorer and choose OS Project Editor > Server Data. Make a note of the currently assigned OS Server package path; you will need it to restore the client back if anything goes wrong.
3. On the OS Server, open WinCC Explorer and select OS Project Editor.
4. In the Server Data section, verify the Alarms tab. Click Standard Server and select the local server name (e.g. OSSRV01). Confirm with OK.
5. Switch to the SSM tab. Click Standard Server and select the same local server name. Confirm with OK.
6. If a redundant OS Server (Standby) is configured, repeat steps 4 and 5 on the standby server. Both Alarms and SSM must point to a single Standard Server each.
7. Open the WinCC Explorer on the OS Server and choose File > Exit WinCC Explorer to release all locks on the package database.
8. Stop the WinCC services on the OS Client:

net stop "CCArchiveMgr"
net stop "CCAlgMgr"
net stop "CCMsgMgr"
net stop "CCProjectMgr"
net stop "CCRuntimeService"
net stop "WinCC_Pictures"

9. On the OS Client, delete the local OS Server package folder. The default path is C:\Program Files\Siemens\Automation\WinCC\WinCCProjects\<OS_ProjectName>\<ServerName>. Do not delete the client project folder above it.
10. Restart the OS Client and re-establish the connection to the OS Server through the OS Project Editor. The client will download the freshly generated server package.
11. Verify that the <ServerName> folder is recreated under the client project with a current timestamp and that the file Project.pck matches the size of the server's Project.pck.
12. Re-import the area-specific operator rights that were exported before the reassignment. Note: the reassignment deletes all area-specific rights. Default group rights remain.
13. Start the OS runtime on the client and trigger a setpoint change on any APL faceplate.

Re-importing User Rights

User rights on the OS are not bundled with the WinCC project; they are stored in the UserArchive database of each WinCC node. The reassignment of the server does not migrate the UserArchive, but it does invalidate the path mapping for area-specific rights.

1. Open the WinCC User Administrator on the OS Client.
2. Choose Export from the menu and save the user list to a .txt file. Repeat for each authorization level that is in use.
3. After the server reassignment, open the User Administrator and choose Import. Re-create the area-specific authorizations manually; the import does not restore area bindings because the area definitions live in the OS Project.
4. Confirm that operator names appear correctly in the operator-action log: trigger a setpoint change, then check the Alarm Logging archive for an entry of the form User:<name>; Value change SP from 50.0 to 75.0.

Verification

Use the following procedure to confirm that the error is resolved and the operator log is fully functional.

1. Open the OS diagnose window on the client. Confirm that no MSRTCreateMsgInstanceWithComment exceptions are reported.
2. Trigger a setpoint change on a PID controller faceplate. The corresponding message must appear in the Alarm Logging runtime window within one second.
3. Right-click the message in Alarm Logging and choose Comment. The original SetPoint, the new SetPoint, the user name and the timestamp must all be present.
4. Open the Alarm Logging archive and confirm that the message is persisted with the OperatorAction message class and the correct system state.
5. Repeat the test on a different OS Client (if present) to ensure that the server-side configuration is consistent across the plant.

Alternative Approach: @pcs7elements Library

If the server reassignment is not possible — for example in a live plant that cannot tolerate the user-rights reset — a documented alternative is to use the operation log function blocks from the @pcs7elements library. This is a Siemens-supplied add-on library that wraps APL_OperationLog with additional pre-configured faceplates.

1. In the CFC editor on the ES, open the library @pcs7elements and locate the OperationLog function block.
2. Drag the block into the master data library of the project, and assign its inputs to the SetPoint tag of the relevant APL block.
3. Compile the OS and download to the client. The @pcs7elements block is pre-bound to the correct message class and bypasses the ODK call that is failing.

Understanding the ODK Path

The MSRTCreateMsgInstanceWithComment function is exposed by the WinCC ODK DLL CCMsgApi.dll on the OS Server and the OS Client. The ODK documentation in Siemens Support lists the function as part of the legacy ODK interface (PCS 7 V8.x and earlier) and as part of the WinCC ODK in PCS 7 V9.x. The function is used by:

• The C-Standard function generated by the OS Project Editor > Message Configuration.
• The APL_OperationLog function block indirectly, via the same C-Standard function.
• User-defined C scripts that call the ODK directly. Such scripts are discouraged because the ODK function signature and exception text can change between WinCC service packs.

If the function call fails with the Exception in MSG-API text, the ODK is correctly loaded; the failure is in the Alarm Data layer behind it. This rules out ODK installation or licensing as a possible cause.

Troubleshooting Matrix

Configuration Reference

Preventive Measures

1. Always run the OS Project Editor > Message Configuration after every CFC compile that introduces new APL blocks. The configuration regenerates the C-Standard functions used by APL_OperationLog.
2. Avoid editing the C-Standard functions. Custom scripts that call ODK functions directly can mask the symptom but will fail again on the next WinCC Service Pack.
3. Apply WinCC Service Packs to the OS Server first, then to the clients, in that order. Mixing versions is a common cause of the corrupted server package.
4. Schedule a quarterly audit of the user rights. Stale authorizations and orphaned operator accounts contribute to the symptom set.
5. Export the user archive before every planned downtime window that includes an OS reassignment.

Edge Cases and Field-Proven Caveats

• Redundant OS Server (Standby): the Standard Server must be set on both the master and the standby. If only the master is set, the failover will produce the same exception for the duration of the failure.
• WinCC V7.x to PCS 7 V9.x migration: the legacy ODK function is still used, but the szErrorText format changed in V9.0. Old diagnostic parser scripts will no longer match the new format.
• Time sync: operator-action messages are timestamped from the OS node, not the AS. Misaligned time between OS Server and OS Client produces out-of-order log entries that some historians reject. Use a single NTP source for all OS nodes.
• Long user names or domain groups: WinCC truncates the user name to 32 characters. Operators using UPN-style names (e.g. [email protected]) may be logged as [email protected]. This does not produce the MSRTCreateMsgInstanceWithComment error but is a common adjacent issue.
• Antivirus on the OS Server: aggressive real-time scanners can lock the Alarm Logging database mid-write, producing the same exception on the server itself. Whitelist the WinCC project folder and the C:\Program Files\Siemens\Automation directory.

FAQ