Resolving WinCC Runtime Advanced Error 429: ActiveX Component Can't Create Object on SIMATIC IPC

Runtime error 429 ("ActiveX component can't create object") is the most common COM instantiation failure encountered when porting WinCC Flexible or WinCE panel scripts into WinCC Runtime Advanced on a Windows-based SIMATIC IPC (IPC377, IPC227, IPC427, IPC477, IPC647, IPC847, or similar). The error fires the moment the VBScript engine calls CreateObject("FileCtl.FileSystem") against a runtime that does not host the legacy FileCtl ActiveX server. Because the call site is inside an alarm or scheduled action that runs unattended on the HMI device, the script aborts, the alarm is never raised, and the operator sees a silent process gap. This article walks through the root cause, the correct object model for a PC-based runtime, the exact replacement call, diagnostic logging via HMIRuntime.Trace, and the verification steps that confirm a permanent fix on WinCC Advanced V15.1 and later Update releases.

1. Problem Description

A VBScript scheduled in a WinCC Advanced HMI screen, a tag-triggered action, or an alarm-triggered action raises the following error the first time a file I/O routine is invoked:

Runtime error '429'
ActiveX component can't create object.

Source: Microsoft VBScript runtime error
Line: <line referencing CreateObject>

Typical call site (taken from a working script that was migrated from a WinCC Flexible / WinCE panel to a WinCC Runtime Advanced IPC):

' --- legacy WinCE / WinCC Flexible syntax ---
Dim oFS
Set oFS = CreateObject("FileCtl.FileSystem")   ' <-- raises error 429 on IPC

Dim sPath, sFile
sPath = "\Storage Card\Logs\"
sFile = sPath & "alarm_" & Year(Now) & "_" & Month(Now) & ".log"

Dim iFile
iFile = oFS.OpenTextFile(sFile, 8, True, -1)  ' 8 = ForAppending, True = create, -1 = ASCII
iFile.WriteLine Now & ";" & Err.Number & ";" & Err.Description
iFile.Close
Set oFS = Nothing

The error fires on the CreateObject line because the WinCC Runtime Advanced process (CCEServer / HMIRuntime) does not expose the FileCtl.FileSystem COM class on a Windows desktop runtime. The function returns the standard VBScript error object, which is then passed unmodified into the ShowSystemAlarm call:

ShowSystemAlarm "MTR1 - Error # " & CStr(Err.Number) & " " & Err.Description

Result: the alarm text becomes "MTR1 - Error # 429 ActiveX component can't create object", the log file is never written, and subsequent scheduled actions keep failing until the runtime is restarted.

2. Affected Software and Hardware

Whenever a script was authored against the WinCC Flexible / WinCC Comfort on a CE device object model and then deployed to a WinCC Runtime Advanced on Windows target, the legacy calls must be rewritten. The Siemens support entry FAQ 59604194 lists the VBScript functions and objects that differ between the two runtimes.

3. Root Cause Analysis

FileCtl.FileSystem is an ActiveX control shipped with the WinCE build of WinCC Flexible and WinCC Comfort. It implements a slimmed-down file I/O API (open / read / write / close, no streams, no Unicode) suitable for the constrained CE kernel. WinCC Runtime Advanced for Windows is a 32-bit or 64-bit process running on the full Win32 / Win64 subsystem and is built on top of the standard Microsoft VBScript 5.8 engine. It does not host FileCtl.dll; the COM class is not registered in the Windows registry, so the COM Service Control Manager returns the CLASS_E_CLASSNOTREG (0x80040154) error, which VBScript surfaces as runtime error 429.

The Microsoft VBScript host translates every COM instantiation failure (registry missing, DCOM access denied, 32/64-bit apartment mismatch, sandboxed user) into the same 429 number. A 429 therefore always means "the COM server for the requested ProgID is unavailable", never "the object does not exist". The actual HRESULT returned by the runtime is recorded in Err.LastDllError in some hosts, but in WinCC scripts the only data exposed to the alarm is the decimal 429.

Other ProgIDs that share the same 429 failure on a Windows WinCC runtime include:

• FileCtl.File (a wrapper for file copy / rename on WinCE)
• WinCCRuntimeAdvanced.FileCtl (does not exist; frequent author typo)
• Siemens.Simatic.Hmi.UAClientCOM on TIA V13 SP1 where the OPC UA COM proxy has not been registered

The general troubleshooting approach is identical: check that the COM server DLL is present and registered for the bitness of the HMIRuntime process (always 32-bit on WinCC Runtime Advanced V15.1, 64-bit on V17+ when the project target is x64).

4. Step-by-Step Diagnostic Procedure

Run the following checks on the IPC to isolate where the COM lookup fails. They assume remote desktop or KVM access to the device.

1. Confirm the runtime is x86 or x64. Open Task Manager, locate CCEServer.exe (the WinCC Runtime Advanced process) and check the Platform column. On V15.1 and V16 the process is always 32-bit; on V17+ the platform follows the TIA project target.
2. Search the registry for the requested ProgID. Run regedit and navigate to HKCR\FileCtl.FileSystem. If the key does not exist, the COM class is not registered. The path HKCR\CLSID\{0D43FE01-F093-11CF-8940-00A0C9054228} must exist for Scripting.FileSystemObject.
3. Check the bitness of the registered COM server. Inspect the InprocServer32 subkey; the default value must point to a DLL that matches the bitness of CCEServer.exe. A 64-bit scrrun.dll cannot be loaded by a 32-bit script engine and yields 429.
4. Test instantiation from a standalone VBScript. Create C:\Temp\fso_test.vbs with the single line CreateObject("Scripting.FileSystemObject"), then run cscript.exe //NoLogo C:\Temp\fso_test.vbs under the same Windows user that runs the runtime service. If this succeeds and the WinCC script still fails, the runtime user lacks the launch permission for the COM object.
5. Inspect the runtime user. WinCC Runtime Advanced runs under the local system account by default when started as a service, or under the interactive user when launched from Start > Programs > Siemens Automation. The DCOM launch permission must include the runtime user. See the Microsoft support article "You receive run-time error 429 when you automate Office applications" for a generic methodology, which also applies to other COM servers.
6. Capture the alarm text. Temporarily add a trace line before the CreateObject call to confirm the error fires on the expected line. See Section 6 for the recommended HMIRuntime.Trace pattern.

Siemens publishes a consolidated script-diagnostics FAQ at entry 106501825, and a WinCC V15.1 / V16 / V17 script-FAQ collection at entry 13408815. Both confirm the same remediation: replace the WinCE-specific object with the Windows equivalent.

5. Solution: Replace FileCtl with Scripting.FileSystemObject

The canonical Windows replacement is the Microsoft Scripting Runtime FileSystemObject (FSSO). The class exposes the same operations used by the original script (open, append, write line, close) with a slightly different calling convention.

' --- corrected WinCC Runtime Advanced script ---
Option Explicit

Const ForAppending = 8
Const TristateUseDefault = -2   ' Unicode on NTFS

Dim oFS, oFile, sPath, sFile

Set oFS = CreateObject("Scripting.FileSystemObject")

sPath = "C:\ProgramData\Siemens\Automation\Logs\"
If Not oFS.FolderExists(sPath) Then oFS.CreateFolder sPath

sFile = sPath & "alarm_" & _
        Right("0000" & Year(Now), 4) & "_" & _
        Right("00" & Month(Now), 2) & ".log"

Set oFile = oFS.OpenTextFile(sFile, ForAppending, True, TristateUseDefault)
oFile.WriteLine FormatDateTime(Now, vbGeneralDate) & ";" & _
             CStr(Err.Number) & ";" & _
             Replace(Err.Description, vbCrLf, " ")
oFile.Close

Set oFile = Nothing
Set oFS   = Nothing

Key differences versus the WinCE version:

• Path root. WinCE panels mount removable media under \Storage Card\. WinCC Runtime Advanced on Windows uses ordinary NTFS paths, e.g. C:\ProgramData\Siemens\Automation\Logs\ or any folder under D:\Logs\ if the IPC has a separate data partition. Avoid the system drive root C:\ for write operations; it requires administrator rights when UAC is active and the runtime service is locked down by Windows.
• Folder creation. FSO will not create intermediate directories. Call CreateFolder once per level, or wrap the path in a recursive helper. FileCtl silently created missing folders on WinCE; FSO does not.
• Unicode mode. Pass TristateUseDefault (-2) to OpenTextFile so that the file is written as UTF-16 on NTFS, matching the rest of the WinCC logging. Passing TristateFalse (0) forces ASCII and mangles non-Latin tag names.
• Append flag. The third parameter of OpenTextFile is create-if-missing, not append. Append behaviour is the second parameter (ForAppending = 8). The original WinCE snippet conflated the two arguments.
• Error handling. Wrap the whole routine in On Error Resume Next only if the upstream logic must continue regardless; otherwise rely on VBScript's default behaviour and inspect Err.Number afterwards. Always reset Err with Err.Clear at the end.

6. Adding Diagnostic Tracing with HMIRuntime.Trace

WinCC Runtime Advanced exposes a dedicated trace API for VBScript. It writes the message to the PDLRT ring buffer and, if configured, to a *.log file under C:\ProgramData\Siemens\Automation\Logs\WinCC_RT_<date>.log. HMIRuntime.Trace is supported on every Windows runtime target and is the recommended replacement for the abort-causing ShowSystemAlarm debug pattern.

Sub LogAlarm(sTag As String, sText As String)
    On Error Resume Next
    HMIRuntime.Trace "[" & sTag & "] " & _
                     FormatDateTime(Now, vbGeneralDate) & " " & sText
    If Err.Number <> 0 Then
        ' FSO failed as well; fall back to a system event log entry
        Dim oShell : Set oShell = CreateObject("WScript.Shell")
        oShell.LogEvent 1, "WinCC_RT trace fallback: " & sText
        Set oShell = Nothing
    End If
    On Error Goto 0
End Sub

' --- call from the alarm action ---
LogAlarm "MTR1", "Error # " & CStr(Err.Number) & " " & Err.Description
ShowSystemAlarm "MTR1 - Error # " & CStr(Err.Number) & " " & Err.Description

To enable the persistent trace file, open the WinCC Runtime Advanced project on the IPC, run SIMATIC WinCC Runtime Advanced > Tools > Settings > Trace, set the trace level to Information and tick Write to file. The path is C:\ProgramData\Siemens\Automation\Logs\ by default. The trace is also viewable with the WinCC Channel Diagnostics applet when the IPC is reachable over TCP/UDP port 4900 (Siemens default S7-RT port range).

7. Deployment and Verification

1. Edit the script in TIA Portal. Open the HMI project that contains the broken action (typically HMI Tags > Events > ChangeValue or Planned tasks). Replace the FileCtl block with the FSO block from Section 5.
2. Recompile the runtime file. In the project tree select Compile > Software (rebuild all). The output .fwx file is regenerated.
3. Transfer the project. Use Online > Download to device > WinCC Runtime Advanced with the correct target IP. If the IPC is offline, copy the compiled .fwx to C:\ProgramData\Siemens\Automation\WinCC RT Adv\<project>\ and restart the runtime service.
4. Restart the runtime. From the IPC, run Stop Runtime and Start Runtime, or reboot the IPC. The WinCC Runtime Advanced service is CCEServer.exe; restarting clears any cached COM apartment state.
5. Trigger the alarm manually. Force the tag value to exceed the configured limit and confirm that a new line is appended to alarm_YYYY_MM.log and that the trace entry appears in the WinCC RT log file.
6. Negative test. Temporarily revert one line back to CreateObject("FileCtl.FileSystem") and confirm that 429 still fires — this proves that the new code path is responsible for the fix and that no stale cached object hides the regression.

8. Troubleshooting Matrix

9. Best Practices for VBScript File I/O on WinCC Runtime Advanced

• Target the runtime user, not the project author. Run a smoke-test VBScript under the same Windows user as the runtime service (default: SYSTEM when started from the Start Center, User when started from a console session). Different users have different DCOM and NTFS permissions; a script that works during commissioning can fail after an unattended reboot.
• Avoid the system drive. Write log files to D:\Logs\, C:\ProgramData\Siemens\Automation\Logs\, or a USB-attached SSD. Writing to C:\ on a UAC-locked IPC forces the runtime to elevate, which the WinCC service user cannot do.
• Cap file size. FSO can fill a partition if the log script runs faster than log rotation. Wrap OpenTextFile with a file-size check (oFile.Size after opening in read mode) and roll the file at 50 MB or 30 days, whichever comes first.
• Time-stamp in UTC. Use FormatDateTime(Now, vbGeneralDate) for local time, but pair it with FormatDateTime(ToUtcTime(Now), vbGeneralDate) if the logs are aggregated across time zones. ToUtcTime is a Siemens VBS helper exposed by WinCC Runtime Advanced.
• Use On Error Resume Next sparingly. It silences every error, including the very 429 you are trying to debug. Enable it only around the call site, capture Err.Number into a local, and re-enable strict mode with On Error Goto 0 before returning to the caller.
• Prefer HMIRuntime.Trace for diagnostics. The trace API is host-aware: messages from a script that aborts mid-routine are still flushed to the ring buffer. The 5-message ring buffer survives a script crash; the system alarm does not.

10. Reference: COM ProgIDs and Their Status on WinCC Runtime Advanced V15.1

11. Cross-Reference to Siemens Knowledge Base

• Siemens Support Entry 13408815 — Scripting FAQs in WinCC Runtime Advanced
• Siemens Support Entry 59604194 — VBScript object model differences Comfort vs. Runtime Advanced
• Siemens Support Entry 106501825 — Diagnostic steps for VBScript failures in WinCC Runtime Advanced
• Microsoft Support — Run-time error 429 when automating Office applications (general methodology for COM launch permission issues)

After applying the Scripting.FileSystemObject replacement and confirming the new log file is written, the WinCC Runtime Advanced IPC will no longer raise runtime error 429 on file I/O. Repeat the fix in every scheduled task and alarm action that referenced FileCtl; a project-wide search for FileCtl in the TIA Portal scripts folder (right-click project > Search in project) ensures no migrated code path is left behind.

Frequently Asked Questions