Resolving WinCC V6.2 Access Violation Errors on Windows XP SP2

1. Problem Description

A WinCC V6.2 SP2 Hotfix 3 (HF3) runtime station that operated without fault on Windows 2000 Professional SP4 begins to crash unpredictably after the host operating system is replaced with Windows XP Professional SP2. The reported symptom is an access violation recorded in the WinCC diagnostic window followed by a complete runtime freeze, leaving the operator with no recourse other than a hard power-cycle of the industrial PC. The fault is non-deterministic — it may occur during picture change, alarm acknowledgment, archive rotation, project activation, or after several hours of idle runtime. The same project files, the same license dongle, and the same authorization assignments are carried across the migration, isolating the cause to the new operating-system environment rather than the application data.

This document consolidates the remediation steps that resolve the access violation, starting with the Windows components that WinCC V6.2 requires explicitly on XP SP2, and finishing with verification and preventive hardening. It applies to the SIMATIC WinCC V6.2 product line, including the SP2 and SP3 service packs, with Hotfix 3 and earlier.

2. Affected Configurations

3. Symptom Matrix

4. Root Cause Analysis

The access violation class reported by WinCC V6.2 on Windows XP SP2 is, in nearly every documented field case, one of four underlying defects. Each defect has a distinct signature in the diagnostic viewer and the Windows event log.

4.1 Missing Microsoft Message Queuing (MSMQ)

WinCC V6.2 uses MSMQ for internal message dispatch between the Graphics Runtime, the Alarm Logging service, the Tag Logging service, and the User Administrator. Windows 2000 Pro SP4 ships with MSMQ as an optional component; many installations enabled it during the initial setup of WinCC. Windows XP SP2 does not install MSMQ by default, and the WinCC V6.2 installation routine does not silently add it. Without MSMQ, the runtime starts in a degraded mode and the first high-volume alarm or archive event triggers an access violation inside mqmgr.ocx or mqqm.dll.

4.2 Incomplete Local Security Policy

Windows XP SP2 tightened the default DCOM and authentication policies compared with Windows 2000. Several DCOM launch and access permissions that were implicitly granted to the interactive user on Windows 2000 must be re-granted explicitly on XP SP2. When they are absent, the WinCC COM servers fail to register their class factory and the runtime throws an access violation the first time it requests a cross-process handle.

4.3 Missing Windows XP Hotfixes

Microsoft released a sequence of Windows XP hotfixes between SP2 and SP3 that address GDI user-object limits, COM marshalling bugs, and kernel-mode issues that interact with industrial software. WinCC V6.2 SP2 HF3 includes a folder of XP-specific hotfixes on the installation DVD that must be installed manually after the OS install. Skipping this folder is the most common cause of the access violation on a freshly built XP SP2 workstation.

4.4 User Account Hardening

Windows XP SP2 introduces the Limited User Account model and the "Deny logon locally" right for the Guest account. Running WinCC under an account that lacks the SeBatchLogonRight, SeInteractiveLogonRight, and DCOM launch privileges reproduces the same access violation as the missing MSMQ case. The Windows 2000-style Administrator-only model is not enough; explicit Act as part of the operating system and Log on as a service rights must be assigned.

5. Prerequisites

Before any remediation step, confirm the host PC meets the WinCC V6.2 prerequisites for Windows XP SP2:

• Windows XP Professional SP2, English or German MUI, 32-bit (x64 is not supported by V6.2).
• Internet Explorer 6.0 SP1 or higher installed before WinCC setup.
• MSDE 2000 SP3a or SQL Server 2000 SP3a — installed by the WinCC setup.
• Local Administrators group membership for the installing user.
• A clean, slipstreamed XP SP2 image (no OEM toolbars, no pre-installed antivirus that hooks Win32 APIs).
• The WinCC V6.2 SP2 or SP3 installation DVD with the Hotfixes\WindowsXP folder accessible.

6. Step-by-Step Remediation

Execute the steps in the order shown. Each step is independently testable — do not skip ahead.

Step 1 — Install Microsoft Message Queuing

1. Open Control Panel → Add or Remove Programs → Add/Remove Windows Components.
2. Select Message Queuing and click Details.
3. Enable Common (subcomponent) and Active Directory integration if the PC is domain-joined; otherwise Common alone is sufficient.
4. Click OK, then Next. Insert the Windows XP SP2 CD when prompted.
5. Reboot the PC.
6. Verify by opening Computer Management → Services and Applications → Message Queuing. The Message Queuing and Message Queuing Triggers services should be present and set to Automatic.

Step 2 — Apply Local Security Policy

1. Open Control Panel → Administrative Tools → Local Security Policy.
2. Expand Local Policies → User Rights Assignment.
3. Add the WinCC operator user (or the SIMATIC HMI group) to the following rights:
   • Act as part of the operating system
   • Log on as a service
   • Log on locally
   • Increase quotas (for GDI handle limits)
4. Confirm that the Guest account is disabled in Local Policies → Security Options → Accounts: Guest account status.
5. Run gpupdate /force from a command prompt.

Step 3 — Install the XP Hotfix Bundle from the WinCC DVD

1. Insert the WinCC V6.2 SP2 (or SP3) installation DVD.
2. Browse to D:\Hotfixes\WindowsXP (drive letter may vary).
3. Run each .exe hotfix in the folder, in numerical order, accepting the EULA. Typical contents:

   Filename (example)	Purpose
   WindowsXP-KB885523-x86-ENU.exe	GDI subsystem update
   WindowsXP-KB886677-x86-ENU.exe	COM marshalling fix
   WindowsXP-KB904412-x86-ENU.exe	Kernel-mode exception handler
   WindowsXP-KB908531-x86-ENU.exe	MSMQ reliability fix

4. Reboot after every hotfix to ensure the kernel patches are applied.

Step 4 — Configure DCOM

1. Open Component Services (dcomcnfg.exe).
2. Expand Component Services → Computers → My Computer.
3. Right-click My Computer, select Properties, then the Default Properties tab.
4. Set:
   • Enable Distributed COM on this computer = checked
   • Default Authentication Level = Connect
   • Default Impersonation Level = Identify
5. Switch to the COM Security tab and verify that the WinCC user account appears in both the Access Permissions and Launch and Activation Permissions lists with Allow for all four checkboxes.

Step 5 — Disable Data Execution Prevention (DEP) for WinCC

1. Right-click My Computer → Properties → Advanced → Performance Settings → Data Execution Prevention.
2. Select Turn on DEP for essential Windows programs and services only.
3. Add the following executables to the exception list (click Add):
   • C:\Program Files\Siemens\WinCC\bin\CCExplorer.exe
   • C:\Program Files\Siemens\WinCC\bin\WinCC.exe
   • C:\Program Files\Siemens\WinCC\bin\DDECli.exe
   • C:\Program Files\Siemens\WinCC\bin\PDLRT.exe
4. Reboot.

Step 6 — Reinstall WinCC V6.2 Cleanly

If the access violation persists after Steps 1–5, perform a clean reinstall. An interrupted or partial first install is the second most common cause of the symptom. Recommended order:

1. Repartition and re-image the PC with a slipstreamed Windows XP SP2 source.
2. Run sysprep to clear the SID if the image is cloned from another PC.
3. Install the XP hotfix bundle (Step 3) before installing any other software.
4. Install Internet Explorer 6 SP1, then MSMQ (Step 1), then reboot.
5. Run the WinCC V6.2 SP2 setup with the project disabled.
6. Apply Hotfix 3 (or move directly to SP3) — the field reports confirm the behavior is identical between SP2 HF3 and SP3, so the choice is operational rather than corrective.
7. Activate the project and run the runtime for 24 hours without operator input to validate stability.

7. Verification Procedure

Validate the remediation in the following order. Do not declare the fault closed until every step passes.

1. Service check. In services.msc, confirm CCAlgLogging, CCTlgServer, CCRDAServer, Message Queuing, and SQLSERVERAGENT are Started with Automatic startup.
2. MSMQ check. Open Computer Management → Message Queuing → Private Queues. The Siemens_HMI queue must be present after WinCC activation.
3. Stress test. Trigger 500 picture changes in 60 minutes using a WinCC script with SetPicture calls. Pre-fix systems fail within 90 minutes on this test.
4. Event log review. After 24 hours, eventvwr.msc must show zero Application Error entries and zero WinCC-issued access violation messages in the diagnostic window.
5. Archive rotation. Force a tag-logging archive rotation at runtime and confirm the .ldf and .mdf files roll over without fault.
6. Cold reboot cycle. Reboot the PC 3 times consecutively. WinCC must start in fully graphical mode (no degraded mode banner).

8. Diagnostic Logging and Event Tracing

If the access violation reappears after the remediation, enable the WinCC internal trace before the next fault:

1. Edit C:\Program Files\Siemens\WinCC\bin\WinCC.ini.
2. Set

   [GfxRts]
   
   Trace=1

   and TraceLevel=3.
3. Restart the runtime. The trace is written to C:\Program Files\Siemens\WinCC\diagnose\WinCC_Sys_timestamp.log.

Pair this with a kernel-level dump:

1. Open Control Panel → System → Advanced → Startup and Recovery → Settings.
2. Set Write debugging information = Small memory dump (64 KB).
3. Configure System Properties → Advanced → Error Reporting to Do not send for the WinCC binaries to keep the dump on disk.

Send the resulting CCExplorer_AccessViolation_date.mdmp and the WinCC syslog to Siemens Industry Online Support with the project hash for the support team to correlate against the WinCC V6.2 defect list.

9. Related Defects and Workarounds

10. Migration Best Practices (Windows 2000 → XP SP2)

Plants that still need to operate WinCC V6.2 should follow this sequence to avoid the access violation entirely:

1. Image the source Windows 2000 PC with Symantec Ghost or Clonezilla as a recovery baseline.
2. Build the new XP SP2 PC on a verified slipstreamed image. Do not upgrade in place — perform a clean install.
3. Apply the XP hotfix bundle from the WinCC DVD before any other software is installed.
4. Install MSMQ, then Internet Explorer 6 SP1, then reboot.
5. Install MSDE 2000 SP3a from the WinCC DVD, then reboot.
6. Install WinCC V6.2 SP2 / HF3 (or SP3). Do not restore the project from the Windows 2000 PC — re-transfer the project via the WinCC Project Duplicator to refresh the registry keys.
7. Configure DCOM (Step 4) and DEP (Step 5) explicitly.
8. Run the verification procedure (Section 7) before connecting the new PC to plant equipment.

11. Preventive Hardening

Once the runtime is stable, lock the configuration to prevent regressions:

• Disable Windows Automatic Updates on the runtime PC. Patches must be qualified against WinCC V6.2 before deployment.
• Disable the Windows XP Themes service, or set it to Manual, to prevent GDI handle churn on picture change.
• Set the screen saver to None. The Windows XP screen saver has been observed to consume WinCC GDI handles and re-trigger the access violation.
• Set the page file to a fixed size of 2 × RAM + 100 MB, with the file located on the system drive, not the data drive.
• Disable System Restore on the runtime drive to keep the disk I/O profile deterministic for tag logging.

12. Long-Term Recommendation

WinCC V6.2 was qualified for Windows XP SP2 only and reached end of standard support. Plants that need to remain on Windows should plan a migration to a current SIMATIC WinCC version on a supported Windows IoT or Windows Server platform. The access-violation class documented here is one symptom of an aging software base; replacing it eliminates the dependency on MSMQ, on the XP hotfix bundle, and on the DCOM permission model that is itself deprecated in current Windows releases. Reach out to the Siemens regional sales office or check the SIMATIC HMI product page for the current generation of supported runtime hosts.