Resolving Orphaned WinCC MsgService When Stopping Runtime

Problem Overview: Orphaned MsgService After WinCC Explorer Stop

When a WinCC 7.x project opens an alarm-logging message service (MsgService) through the Open Development Kit (ODK) on Graphics Runtime start, the service is intended to live for the full lifetime of the Runtime process. A button on a screen can call MSRTStopMsgService() and then Exit WinCC Runtime to terminate cleanly. The same sequence, however, is not invoked when an operator clicks the square Stop button in the WinCC Explorer toolbar.

The Explorer stop button tears down the Runtime container, discards the message-service handle stored in the project, and exits the RT process — but the MsgService worker process started by MSRTStartMsgService() / MSRTStartMsgServiceNotifyCallback() remains alive in the Windows session. Because the RT-side handle is gone, the next Runtime activation cannot re-attach to the surviving service. Attempts to start a fresh MsgService return an error, the alarm subsystem fails to initialize, and the only documented recovery is a full station reboot.

This is a lifecycle ownership problem, not a corruption problem. The orphan does not damage the SQL-backed alarm archive; it just refuses to release the named pipe / mutex used by Alarm Logging Runtime to talk to its message dispatcher.

Root Cause Analysis: Why the Explorer Stop Button Leaves MsgService Alive

WinCC Runtime is a multi-process application. The components involved in this fault are:

• WinCC Explorer (container process) — hosts the project database connection, the Graphics Runtime, the alarm logging editor session, and the project lifecycle events.
• Graphics Runtime (PDL engine) — starts in response to the Explorer and executes C / VBS / ODK actions declared in the project.
• Alarm Logging Runtime (MsgService) — separate Windows process instantiated by ODK; it owns the in-memory message queue that backs MSrvMsg_* API calls.

The Explorer stop button signals the Graphics Runtime and the project services to shut down. It does not send WM_DESTROY-equivalent cleanup to ODK-allocated resources that were started in user code. Specifically:

1. MSRTStartMsgService() returned a 32-bit ServiceID that the developer stored only in a local C variable or a non-persistent tag.
2. When the RT process exits, the variable evaporates. The ODK library cannot match it back to the spawned dispatcher.
3. The dispatcher process has no parent-monitoring contract — it will not self-terminate just because the spawning thread has gone.
4. On the next Runtime start, MSRTStartMsgServiceNotifyCallback() is called again. The ODK tries to create a new dispatcher but the named resource is locked by the previous orphan; the call returns a failure code (typically 0x8004...-class COM error or an empty ServiceID).

The reason screen-button shutdown works is that the developer controls the action chain: stop the service, then exit Runtime. The Explorer stop button bypasses any user-authored Exit Runtime actions, so the chain is broken.

Affected Versions and Components

Solution 1: Store the MsgServiceID in a Runtime-Persistent Tag

The cleanest fix is to give the dispatcher handle a lifetime that spans Runtime stop / start cycles. WinCC 7.x internal tags can be flagged Runtime persistence: their last written value is retained when Runtime stops and is restored on the next start.

Procedure

1. In the WinCC Explorer, open Tag Management and create a 32-bit unsigned internal tag, e.g. MsgServiceID.
2. Open the tag's Properties dialog and switch to the Limits/Reports tab. Tick the option "Runtime persistence" (also labelled Persistenter Wert im Runtime in German locales).
3. Confirm with OK. The tag database in the project now records the value across RT cycles.
4. In your C action that calls the ODK start function, assign the returned ServiceID to the tag with SetTagDWord() / SetTagRaw().
5. At Graphics Runtime start, read the tag back with GetTagDWord(). A non-zero value means a previous session left a dispatcher alive; pass it to MSRTStopMsgService() first, then call MSRTStartMsgServiceNotifyCallback() for a fresh one.

C Action Skeleton

#include "WCCOAAlarmLogging.h"

static DWORD g_ServiceID = 0;

BOOL OnStart(void)
{
    DWORD prior = GetTagDWord("MsgServiceID");
    if (prior != 0)
    {
        // Recover from a previous Explorer-stop orphan
        MSRTStopMsgService(prior);
    }

    g_ServiceID = MSRTStartMsgServiceNotifyCallback(
        /* user data */ 0,
        /* callback  */ &AlarmCallback,
        /* flags     */ 0);

    if (g_ServiceID != 0)
    {
        SetTagDWord("MsgServiceID", g_ServiceID);
        return TRUE;
    }
    return FALSE;
}

BOOL OnStop(void)
{
    if (g_ServiceID != 0)
    {
        MSRTStopMsgService(g_ServiceID);
        SetTagDWord("MsgServiceID", 0);
    }
    return TRUE;
}

Solution 2: External Watchdog via WMI

If you cannot modify the project (third-party delivery, validated system) you can still rescue the station with a host-side process. WMI event subscriptions can watch for the termination of the WinCC Explorer process and run a VBScript that kills the leftover dispatcher.

Install the WMI subscription (elevated PowerShell)

$query = @"
SELECT * FROM __InstanceDeletionEvent
  WITHIN 5
  WHERE TargetInstance ISA 'Win32_Process'
    AND TargetInstance.Name = 'PDLRT.exe'
"@

$action = New-Object System.Management.ManagementEventHandler({
    param($sender, $e)
    Get-WmiObject Win32_Process -Filter "Name='MsgService.exe'" |
        ForEach-Object { $_.Terminate() }
})

Register-WmiEvent -Query $query -Action $action -Namespace "root\cimv2"

This subscription runs in the user session and fires within five seconds of the RT process disappearing. It enumerates any process whose image name matches the alarm dispatcher and calls Terminate(). The WMI subscription itself is persistent across logons; remove it with Unregister-Event after the cleanup completes if you only need a one-time fix.

Edge cases

• The actual process name varies by WinCC service pack (e.g. CCMsgDisp.exe, MsgDisp.exe). Use a broader filter on the command line (LIKE '%WinCC%Alarm%') if the literal name is unknown.
• Run the subscription in the same Windows account that owns the Runtime. A SYSTEM-context subscription cannot see the user-mode dispatcher.
• On a Server Core installation, install the WMI Compatibility feature first; otherwise Get-WmiObject fails with 0x80041010.

Solution 3: ODK Lifecycle via Project Exit Actions

WinCC executes actions in a fixed set of triggers. The Explorer stop button does not fire a project-level "on stop" trigger, but it does fire the standard RT exit event @ExitRT for the Global Script runtime. Configure a C action bound to that trigger to stop any service the project opened.

1. In the WinCC Explorer, open Global Script > C Editor.
2. Create a new action and select the trigger Runtime > Exit.
3. Place the cleanup call in the action body:

#include "apdefap.h"
void OnExit(char* lpszPictureName, char* lpszObjectName, char* lpszPropertyName)
{
    DWORD id = GetTagDWord("MsgServiceID");
    if (id != 0)
    {
        MSRTStopMsgService(id);
        SetTagDWord("MsgServiceID", 0);
    }
}

4. Compile and assign the action to the @ExitRT trigger in the project's Global Script Runtime settings.

This works in projects that allow the Explorer to drive the standard RT shutdown sequence (i.e. you stop Runtime from the project menu or by closing the Explorer window). The square toolbar Stop button on the project still bypasses @ExitRT on some WinCC 7.0 SP3 builds — verify the trigger fires by enabling a debug printf to the WinCC diagnostic file WinCC_Sys_.log.

Solution 4: Reset_WinCC.vbs Utility

Siemens ships a reset script in every WinCC installation:

C:\Program Files (x86)\Siemens\Automation\WinCC\bin\Reset_WinCC.vbs

It tears down the WinCC service stack, the project database connections, and the alarm subsystem, then restarts the WinCC services. It is the safest "last resort" tool for the orphan problem and is the recommended path for hot-fix support tickets.

Solution 5: Connectivity Pack Polling Alternative

If the only reason for opening a MsgService was to publish alarm state changes to an external HTTP endpoint, you can avoid the dispatcher entirely. The WinCC Connectivity Pack exposes a SOAP / .NET API that queries the archived alarm data directly from SQL:

var connector = new WinCC.Runtime.Connectivity.AlarmProvider();
var filter = new WinCC.Runtime.Connectivity.AlarmFilter
{
    TimeStampFrom = DateTime.UtcNow.AddSeconds(-2),
    StateFilter   = AlarmStateFilter.Active | AlarmStateFilter.CameIn
};

foreach (var alarm in connector.Query(filter))
{
    PostToHttp("https://scada-gw/alarm", alarm);
}

Polling every 1–2 s removes the lifecycle problem: there is no MsgService to orphan, and the application scales across WinCC server / client pairs because the connector talks to the central archive. The trade-off is a small latency penalty and a steady network load proportional to the alarm rate.

Verification Procedures

After applying any of the solutions above, validate the fix on a test station with the following sequence:

1. Start the WinCC project and confirm MsgServiceID is written to the persistent tag (inspect with WinCC Tag Simulator or the Tags online view).
2. Trigger a test alarm and confirm the C / VBS callback fires.
3. Click the square Stop button in the WinCC Explorer. The RT process should exit within 5 s.
4. Open Task Manager > Details and sort by image name. The dispatcher image (e.g. CCMsgDisp.exe) must not be present.
5. Start the Runtime again. The dispatcher must start, the alarm subscription must succeed, and the OnStart() C action must return TRUE.
6. Generate a second alarm to confirm the new dispatcher is functional.
7. Repeat steps 3–6 at least three times to ensure the recovery is deterministic.

Troubleshooting Matrix

Best Practices for MsgService Lifecycle Management

• Open the MsgService exactly once in the project's Global Script > C > Runtime Start trigger. Closing and reopening it for every alarm costs 30–80 ms per cycle and exposes you to the orphan condition on any abnormal termination.
• Always pair MSRTStartMsgService with a MSRTStopMsgService in the Runtime Exit trigger. Code defensively: check the return code, log to the WinCC diagnostic file, and zero the persistent tag.
• Keep the ServiceID in a runtime-persistent internal tag, not in a global C variable. C variables evaporate at process exit; the tag is the only durable contract between sessions.
• Document the dispatcher image name in the project functional specification so that WMI / PowerShell scripts authored by IT do not guess the wrong name.
• For alarm forwarding to external systems, prefer the Connectivity Pack polling approach over custom ODK + HTTP post. The polling pattern survives Runtime crashes, server failover, and redundant server pairs without any cleanup logic.
• Schedule a quarterly restart of the WinCC server even with a perfect cleanup, as a defence-in-depth measure against accumulated handle leaks in the WinCC service stack.

Frequently Asked Questions