Resolving WinCC Flexible 2008 SP2 Script Syntax Error Line -1

Resolving WinCC Flexible 2008 SP2 Script Syntax Error Line -1

WinCC Flexible 2008 SP2 is a mature HMI configuration suite from the SIMATIC HMI line, still widely deployed on Panel-based and PC-based visualization systems. Engineers maintaining long-lived projects occasionally encounter a peculiar compile-time fault: every Visual Basic script in the project returns "Syntax error in line -1, Column 1", and the editor refuses to add new scripts. The error points to a non-existent source line, which is the strongest indicator that the problem is not in the script source itself but in the COM/ActiveX infrastructure that WinCC Flexible depends on for VBScript hosting. This reference covers the root cause, the official Siemens recovery path, and the field-proven secondary fixes that restore scripting in both existing and freshly created projects.

Problem Description

Engineers report the following symptoms on a WinCC Flexible 2008 SP2 engineering station:

• Every existing VBScript in the project reports Syntax error in line -1, Column 1 at compile time, regardless of actual script content.
• The Script Editor refuses to insert a new script under Project > Scripts > Add Script.
• Creating a brand-new, empty WinCC Flexible 2008 SP2 project reproduces the same behavior — the fault is not project-specific.
• The error is identical on every script, including factory default scripts shipped with the product, ruling out authoring mistakes.
• Compiling the project with a different logon (different Windows user) sometimes succeeds, indicating a per-user COM profile corruption rather than a project-file defect.

The line number -1 is the diagnostic giveaway. In a healthy WinCC Flexible scripting host, a true VB syntax error is reported with a positive line and column index tied to the source buffer. A -1, 1 return value is emitted by the host layer when the script control cannot even instantiate — that is, the call to MSScriptControl.ScriptControl either fails to bind or fails to evaluate the very first token.

Affected Products and Versions

WinCC Flexible is delivered on a CD or DVD set. SP2 corresponds to internal build 800x (e.g., 8001 for the initial SP2 release, 8004–8014 for the rolling hotfixes). The script engine is not patched by the WinCC Flexible hotfixes themselves; it relies on the operating system msscript.ocx and vbscript.dll. This is why the issue can be triggered by an out-of-band Windows update on a previously stable engineering station.

Root Cause Analysis

WinCC Flexible 2008 SP2 uses the Windows Script Host infrastructure for its VBScript editor and runtime. Specifically, it binds against two COM components:

1. msscript.ocx — the Microsoft Script Control ActiveX control that exposes the MSScriptControl.ScriptControl class (CLSID {0E59F1D5-1FBE-11D0-8FF2-00A0D10038BC}, ProgID MSScriptControl.ScriptControl.1). WinCC Flexible uses this control to parse and execute VBScript in both the design-time editor and the runtime.
2. vbscript.dll — the Visual Basic Scripting runtime library (CLSID {B54F3741-5B07-11CF-A4B0-00AA004A55E8}, ProgID VBScript.RegExp and friends). WinCC Flexible loads it indirectly when the script control initializes the VBScript engine.

When Windows Update, a System Restore operation, a clean-boot profile reset, an aggressive anti-virus quarantine, or a manual uninstall of a third-party scripting tool removes or unregisters one of these components, the CoCreateInstance call from WinCC Flexible either fails outright (script cannot be added) or returns a host that immediately yields -1, 1 on its first parse pass (every script fails to compile). The error is uniform across all scripts because the host itself never reaches script-specific code.

Typical triggering events seen in the field:

• Installation of Windows security updates that reset COM registration (notably KB4012212, KB4019264, and a long series of cumulative updates for Windows 7 and Windows Server 2008 R2).
• Manual deletion of msscript.ocx by antivirus heuristics flagging it as a legacy ActiveX (Trend Micro, McAfee, and Sophos have all shipped such signatures).
• Rollback from Internet Explorer 11 to Internet Explorer 10, which on certain Windows 7 builds deregisters the 64-bit msscript.ocx.
• Side-by-side installation of Visual Studio 2010 or later, which replaces the in-box vbscript.dll with a newer build that is functionally compatible but may require re-registration.
• Disk cleanup utilities that prune %WINDIR%\System32 of files not in the active WinSxS store.
• Running the engineering station on a different Windows user account that has never had a WinCC Flexible COM profile registered.

Prerequisites

Before applying the fix, verify the following on the engineering station:

If the source files themselves are missing (not just unregistered), the regsvr32 command will fail with "The module ... failed to load". In that case, copy the file from another healthy engineering station, from a Windows install media under install.wim\Windows\System32\, or run sfc /scannow to restore protected system files.

Solution 1 — Re-register msscript.ocx (Primary Fix)

The first and most effective action is to re-register the Microsoft Script Control ActiveX. This is the exact procedure Siemens support has recommended for this symptom.

Step-by-step procedure

1. Close WinCC Flexible 2008 SP2 and any HMI runtime that may be using the script control.
2. Open the Windows command prompt as Administrator: Start > All Programs > Accessories > right-click Command Prompt > Run as administrator. On Windows 7, this is reached through Start > cmd > Ctrl+Shift+Enter.
3. Verify the file is present:

   dir "%WINDIR%\System32\msscript.ocx"
   

   If the file is reported as not found, jump to Solution 5 — File-level repair.
4. Register the 32-bit control. On a 32-bit Windows installation:

   regsvr32 "%WINDIR%\System32\msscript.ocx"
   

   On a 64-bit Windows installation running 32-bit WinCC Flexible 2008 SP2, the file lives in SysWOW64:

   %WINDIR%\SysWOW64\regsvr32.exe "%WINDIR%\SysWOW64\msscript.ocx"
   

5. Confirm the success dialog: "DllRegisterServer in C:\Windows\System32\msscript.ocx succeeded."
6. Repeat the same call for the matching DLLs that the host may also need:

   regsvr32 "%WINDIR%\System32\vbscript.dll"
   regsvr32 "%WINDIR%\System32\scrrun.dll"
   

   scrrun.dll provides the Scripting.FileSystemObject commonly used in WinCC Flexible scripts.
7. Restart the engineering station (a logoff is sometimes sufficient, but a full reboot clears any locked handles on the DLL).
8. Reopen WinCC Flexible 2008 SP2, load the affected project, and attempt to compile.

Expected outcome

After a successful registration and reboot, the script editor re-enables Add Script, the VBScript IntelliSense is restored, and compilation completes without "Syntax error in line -1, Column 1". If the registration reports success but the symptom persists, the issue is one of the secondary causes discussed below.

Solution 2 — Reset WinCC Flexible (Siemens FAQ 36645252)

Siemens has published an official recovery procedure for cases where the WinCC Flexible installation itself is the source of the corruption. This is referenced in Siemens Support Entry 36645252 and is the recommended step if Solution 1 alone does not resolve the problem.

Step-by-step procedure

1. Close all SIMATIC applications, including WinCC Flexible, Automation License Manager, and any HMI runtime.
2. Open Control Panel > Programs and Features (Add or Remove Programs on Windows XP).
3. Select SIMATIC WinCC flexible 2008 SP2 and click Uninstall/Change.
4. Choose Repair (or Modify > Repair). The installer will re-register the WinCC Flexible COM components and overwrite corrupted templates.
5. If Repair is not offered, choose Uninstall, restart, and reinstall from the original SP2 media. The .hmi project files are not touched by either operation — they live under %USERPROFILE%\Documents\Siemens\WinCC flexible 2008 SP2\Projects or a custom path.
6. Reapply the latest hotfix (HF14 or later as appropriate) and any device-specific updates.
7. Reboot, reopen the project, recompile.

The Repair operation re-registers the WinCC Flexible-specific COM servers, including the WinCCFlexible.ScriptProject, WinCCFlexible.ScriptEditor, and the integrated VBScript designer view. It does not, however, re-register msscript.ocx on its own — that is why Solution 1 and Solution 2 are complementary rather than alternatives.

Solution 3 — Re-register vbscript.dll and the Script Runtime

If Solution 1 reports that the msscript.ocx registration is healthy but the symptom persists, the VBScript engine itself is the next suspect. Re-register the runtime DLLs:

cd /d %WINDIR%\System32
regsvr32 /u vbscript.dll
regsvr32 vbscript.dll
regsvr32 /u scrrun.dll
regsvr32 scrrun.dll
regsvr32 /u jscript.dll
regsvr32 jscript.dll

The /u flag performs a clean unregistration first to wipe stale registry entries, then a fresh registration is applied. This sequence has resolved cases where a partial Windows Update left a half-registered vbscript engine that the script control could instantiate but not initialize.

Solution 4 — Per-User COM Profile Reset

On multi-user engineering stations, COM activation is partly per-user. A corruption in %LOCALAPPDATA%\Temp\ or in the user's hive under HKCU\Software\Classes can also produce the -1, 1 return value even when the system-wide registration is healthy.

1. Log off the affected Windows user and log on as a different local administrator.
2. Open WinCC Flexible 2008 SP2 and create a fresh, empty project. Add a one-line test script (for example, Sub Test() : MsgBox "OK" : End Sub) and compile.
3. If the test project compiles, the issue is in the original user's COM profile. Reset it by deleting the following keys while logged in as that user, then log off and back on:

   reg delete "HKCU\Software\Classes\MSScriptControl.ScriptControl.1" /f
   reg delete "HKCU\Software\Classes\CLSID\{0E59F1D5-1FBE-11D0-8FF2-00A0D10038BC}" /f
   

4. Reopen the original project. The script editor will re-create the per-user COM entries on first use.

Solution 5 — File-Level Repair of the Script Components

If msscript.ocx or vbscript.dll is missing from the system directory, re-registration will fail with error 0x8007007E ("The specified module could not be found"). Use one of the following file-level recovery paths.

Option A: System File Checker

sfc /scannow

Run from an elevated command prompt. SFC restores protected system files from the WinSxS store. On Windows 7 SP1, this resolves most cases of missing or corrupted vbscript.dll. msscript.ocx is not a protected system file and must be obtained by other means.

Option B: Copy from a known-good station

1. Identify a second engineering station of the same OS architecture and patch level that has WinCC Flexible 2008 SP2 working.
2. Copy msscript.ocx from %WINDIR%\System32\ (or SysWOW64) to the same path on the affected station.
3. Apply Solution 1 to register the freshly copied file.

Option C: Extract from Windows install media

1. Mount the Windows install ISO and locate sources\install.wim.
2. Use dism /mount-wim /wimfile:install.wim /index:<index> /mountdir:C:\mount to expose the image contents.
3. Copy Windows\System32\msscript.ocx from the mounted image to the live System32.
4. Dismount with dism /unmount-wim /mountdir:C:\mount /discard.
5. Apply Solution 1 to register the new file.

Verification

After each fix, run the following verification procedure to confirm the scripting host is fully functional.

1. Launch WinCC Flexible 2008 SP2 and load the original project.
2. Open the Script Editor (Project > Scripts). Verify the right-hand Scripts tree allows Add new script.
3. Insert a one-line diagnostic script:

   Sub VerifyScriptHost()
       Dim fso
       Set fso = CreateObject("Scripting.FileSystemObject")
       MsgBox "Host OK: " & fso.GetTempName
   End Sub
   

4. Compile the project: Project > Compiler > Check Syntax. Confirm the report is clean and no script returns Syntax error in line -1, Column 1.
5. Optionally, transfer the project to a Panel and confirm the runtime can execute the test script from a button event.

Troubleshooting Matrix

Field-Proven Caveats and Edge Cases

The following edge cases have been documented by Siemens support and by long-term WinCC Flexible users. Engineers maintaining critical visualization systems should be aware of them before declaring the issue resolved.

32-bit vs 64-bit registration

WinCC Flexible 2008 SP2 is a 32-bit application and will not run natively on 64-bit Windows without WoW redirection. The msscript.ocx must be registered in the 32-bit registry hive (HKLM\SOFTWARE\Wow6432Node\Classes) using the SysWOW64\regsvr32.exe. Using the 64-bit regsvr32.exe in System32 will appear to succeed but will not register the control where the 32-bit host looks for it. Verify the registration is in the WoW node with:

reg query "HKLM\SOFTWARE\Wow6432Node\Classes\CLSID\{0E59F1D5-1FBE-11D0-8FF2-00A0D10038BC}" /s

Antivirus quarantine

Several endpoint protection suites (notably McAfee VirusScan Enterprise 8.8 and Trend Micro OfficeScan 11) have historically flagged msscript.ocx as "Suspicious ScriptControl" after signature rollouts. The control is removed or renamed to msscript.ocx.quar. The engineering station should be in a maintenance exclusion scope that includes %WINDIR%\System32\msscript.ocx and %WINDIR%\SysWOW64\msscript.ocx. The exact exclusion syntax is documented in the relevant Siemens support entries for AV-coexistence engineering stations.

DEP and ASLR conflicts

On 64-bit Windows 7 with strict Data Execution Prevention, the script control can throw -1, 1 not because of a real syntax error but because the host process was terminated at the DEP boundary. Verify with System > Advanced System Settings > Performance > Data Execution Prevention. Add the WinCC Flexible executable (flex.exe) to the DEP exception list as a last resort only — the safer fix is to keep the OS and WinCC Flexible SP2 hotfix current.

Multi-version coexistence

Stations that have both WinCC Flexible 2008 SP2 and a TIA Portal installation (V13 or later) can experience the symptom if the TIA Portal installation overwrites the in-box VBScript engine with a newer build that WinCC Flexible 2008 SP2's host does not understand. The two products are not designed to coexist; Siemens recommends using a dedicated engineering station per generation. Where that is not possible, the TIA Portal installation should be applied last and the registration should be re-applied (Solutions 1 and 3) immediately after.

Prevention and Best Practices

Once the scripting host is restored, apply the following best practices to minimize the chance of recurrence.

• Snapshot the engineering station. After every successful WinCC Flexible SP2 hotfix install, image the system drive. Tools such as Acronis True Image, Veeam Agent, or the built-in wbadmin allow a 15-minute rollback to a known-good state.
• Isolate Windows Update cycles. Configure a maintenance window for the engineering station; defer cumulative updates until they have been validated in a test environment. Many sites stage updates on a non-production engineering clone first.
• Maintain AV exclusions. Coordinate with the security team to whitelist msscript.ocx, vbscript.dll, scrrun.dll, and the WinCC Flexible installation path.
• Document the project as part of the install baseline. After any successful compile of a release-version project, archive the .hmi, the .log, the WinCC Flexible version, the installed Windows hotfix list, and the script component file versions. This accelerates future recovery.
• Avoid manual deletion of system files. When cleaning up disk space, never delete msscript.ocx or vbscript.dll; these are required by both WinCC Flexible and many other COM-based tools.
• Use a separate administrator account for repairs. Do not perform regsvr32 operations from the same Windows account that runs the HMI runtime, as the running process can hold file handles that prevent the re-registration from taking effect until the next reboot.

Standards and Reference Documentation

The behavior of the Windows Script Control and the regsvr32 tool is documented in the Microsoft platform reference. The COM CLSID and registration model are defined in MS-DCOM and [MS-COM]. Engineers verifying the underlying behavior can consult the official Microsoft documentation for regsvr32 and the Component Object Model (COM) platform portal. Siemens product installation and repair procedures are documented in the WinCC Flexible 2008 SP2 readme, the SP2 release notes (PDF on the install DVD under Manuals\Readme_SP2.pdf), and in Siemens Support Entry 36645252.

FAQ