Fixing WinCC DataMonitor OutOfMemoryException on Excel Export

1. Problem Description

When exporting a Process Value Table from the SIMATIC WinCC DataMonitor web front end (Trends & Alarms → Process Value Table) to Microsoft Excel, operators encounter the following .NET runtime exception on the WinCC WebNavigator / WebCenter server:

Exception of type 'System.OutOfMemoryException' was thrown.
   at System.String.GetStringForStringBuilder(...)
   at System.Text.StringBuilder.ToString()
   at WinCC.DataMonitor.Export.CsvExport.WriteRow(...)
   at WinCC.DataMonitor.Export.CsvExport.ExportProcessValues(...)

The export target is a CSV file containing paired timestamp + process value columns, in this case 734,400 rows (≈ 28 days @ 1 sample/min × 2 tags, or 1 day @ ~8 s sample interval × 60 tags). The export aborts before the file is written to disk; the browser session terminates and the DataMonitor start page reloads.

The WinCC server in the field case is equipped with 2 GB physical RAM and Windows is configured with System managed size for the paging file. Increasing the physical RAM alone does not always resolve the issue, because the failure is rooted in the managed .NET heap size of the WebNavigator process (WNMSvr.exe) and in the 32-bit / 64-bit architecture of the DataMonitor web service.

2. Architecture and Root Cause

SIMATIC WinCC DataMonitor runs as an ASP.NET application inside Microsoft Internet Information Services (IIS) on the WinCC server. The web service uses a managed .NET runtime whose default memory ceiling is constrained by the following stack:

The CSV exporter concatenates every row of the Process Value Table into a single in-memory StringBuilder before flushing it to the HTTP response. For 734,400 rows with an average row length of 32 bytes (ISO-8601 timestamp + tab + 8-byte value + CRLF), the working set grows to roughly 24 MB in raw string data, but the intermediate StringBuilder capacity requests, string interning, and CLR object header overhead typically inflate this to 120-180 MB per active export request. When the process has been running for weeks under load, fragmentation in the large object heap (LOH) prevents allocation of the contiguous block and OutOfMemoryException is raised.

2.1 Three contributing factors

1. Process architecture: 32-bit IIS worker process (w3wp.exe) caps managed allocations at ≈ 1.4 GB usable.
2. Paging file fragmentation / undersizing: "System managed size" on Windows Server 2012 R2 defaults to physical RAM × 1.5, capped at 4 GB on system drive. Under sustained load the working set is committed, but the reserve is not contiguous.
3. Export buffer strategy: The DataMonitor CsvExport helper holds the entire result set in memory rather than streaming via HttpResponse.OutputStream in chunks.

3. Prerequisites

Before applying the fixes, verify the following on the WinCC server:

• Operating System: Windows Server 2012 R2 / 2016 / 2019 / 2022 (x64) with current cumulative updates.
• WinCC version: V7.4 SP1, V7.5, V7.5 SP1, or V7.5 SP2 with the DataMonitor option installed (license key on the license server).
• WebNavigator / WebCenter server role active; the WinCC WebNavigator and WinCC DataMonitor Windows services are running.
• Administrative RDP or console session to the server with the local Administrators group membership.
• Sufficient license points for the DataMonitor "Process Value Export" feature.

4. Solution: Increase Physical RAM and Re-architect the Process

The recommended remediation follows a tiered approach. Apply tier 1 first, then re-test; only escalate if the failure persists.

4.1 Tier 1 - Hardware and OS baseline

1. Upgrade server RAM to a minimum of 8 GB (16 GB recommended for installations with more than 5,000 archived tags). DIMM population must follow the server manufacturer's memory mirroring or rank-spare guidance.
2. Set a fixed paging file size of initial = 16384 MB, maximum = 32768 MB on the system drive and on the DataMonitor archive drive. Open Control Panel → System → Advanced system settings → Performance → Settings → Advanced → Virtual memory, clear Automatically manage paging file size, select Custom size, and enter the values. Restart the server.
3. Move the SQL archive (WinCC archive database, default path \\WinCCProj\<project>\ArchiveManager\) to a dedicated NTFS volume formatted with 64 KB allocation unit size. This reduces fragmentation that can cause LOH allocation failures.

4.2 Tier 2 - IIS and .NET configuration

1. Open IIS Manager → Application Pools → WinCC_DataMonitor and verify Enable 32-Bit Applications = False (set to False). The DataMonitor application pool must run in 64-bit mode to access more than 4 GB of virtual address space. Confirm by running ! w3wp.exe in WinDbg on the running worker process; the dump header must show Effective machine type: x64.
2. Set Private Memory Limit (KB) on the application pool to 0 (unlimited) to prevent premature recycling under load. Recycling is acceptable but must not be driven by memory pressure alone. Set Regular Time Interval recycling to 0 minutes (disable scheduled recycle) and instead rely on the application_End hook for warm-up.
3. Add the gcServer and gcAllowVeryLargeObjects settings to the web.config of the DataMonitor site (default path C:\inetpub\wwwroot\DataMonitor\web.config):

   <configuration>
     <runtime>
       <gcServer enabled="true"/>
       <gcAllowVeryLargeObjects enabled="true"/>
     </runtime>
   </configuration>

4. Increase the ASP.NET request timeout for long-running exports by editing the same web.config:

   <httpRuntime executionTimeout="3600" maxRequestLength="2147483647" />

   maxRequestLength is in kilobytes; 2,147,483,647 KB ≈ 2 TB, the 32-bit signed integer ceiling.

4.3 Tier 3 - WinCC configuration

1. Open WinCC Explorer → Computer → Properties → Runtime → Tag Logging and reduce the tag logging cycle / archiving cycle for the high-frequency tags to a value matching the actual reporting need. For trend reports exported daily, a 1-minute cycle is rarely required; switch to 10 s or 60 s where the visualization allows.
2. In the Process Value Table configuration, set the display range to the minimal interval that satisfies the report and uncheck the Show all archived values option. The export size shrinks proportionally.
3. Configure the WinCC Archive Manager to compress archived segments older than 24 h. Right-click the archive → Properties → Compression → enabled with algorithm "WinCC standard". Compression reduces the I/O cost of the export query, which in turn shortens the lifetime of the large object heap allocation.

5. Solution: Reduce Export Size (Client-Side Workaround)

If the server cannot be modified (for example, in a regulated production environment pending a maintenance window), operators can apply the following client-side workaround immediately.

5.1 Split the export into time slices

1. Open DataMonitor → Trends & Alarms → Process Value Table.
2. Define a tag selection and set the Time range to 24 h or 1 h rather than the full report interval.
3. Click Export → CSV; the file is generated and downloaded.
4. Repeat for subsequent intervals until the full interval is covered.
5. Concatenate the CSV files with the PowerShell one-liner:

   Get-Content part1.csv, part2.csv, part3.csv | Set-Content merged.csv

5.2 Use the OPC-DA / OPC UA bridge instead of DataMonitor

For recurring bulk exports, install the SIMATIC WinCC Connectivity Station or WinCC IndustrialDataBridge and schedule a job that streams the archive data into a SQL Server or CSV target. The IndustrialDataBridge writes in 10,000-row chunks and never holds the full result set in memory. This is the recommended architecture for any export that exceeds 200,000 rows.

5.3 Use the WinCC OLE-DB provider directly

Power users can query the archive database directly with a VBScript or PowerShell script using the WinCC OLE-DB Provider:

Set conn = CreateObject("ADODB.Connection")
conn.Provider = "WinCCOLEDBProvider.1"
conn.Properties("Data Source") = ".\WinCC"
conn.Properties("Catalog") = "CC_OpenArch_<timestamp>_<project>"
conn.Open

Set rs = conn.Execute("TAG:R,'ProcessValueArchive','0000-00-00 00:00:00.000','2024-12-31 23:59:59.999'")
Do While Not rs.EOF
    WScript.StdOut.WriteLine rs.Fields(0).Value & ";" & rs.Fields(1).Value & ";" & rs.Fields(2).Value
    rs.MoveNext
Loop

This bypasses the DataMonitor web service entirely and is the most reliable method for ad-hoc exports that exceed 500,000 rows.

6. Browser-Side Considerations

When operators use the Open directly with Excel option, the browser also participates in the failure path. Chromium-based browsers (Chrome, Edge) allocate a per-tab renderer process whose heap is bounded by the operating system and the browser's own limits. Microsoft and Google publish the relevant guidance:

• Google Chrome Help: Error code out of memory every time I open a website describes the "AW Snap / Out of memory" symptom in the renderer process.
• Microsoft Learn: Microsoft Edge Error Code Out of Memory fixes recommends disabling Enhance your security on the Internet in Edge Settings → Privacy, search, and services → Security.
• Mozilla Support: Out of memory at line:1 documents the equivalent Firefox symptoms and the safe-mode diagnostic path.

For DataMonitor specifically, instruct operators to select "Save file" rather than "Open with Excel" when the export exceeds 100,000 rows. Once the file is saved to the local drive, opening it in Excel does not engage the browser renderer and the standard 1,048,576 row worksheet limit (Excel 2007 and later) applies.

7. Verification

1. Reproduce the original failure case: open the Process Value Table, set the time range to encompass 734,400 rows, click Export → CSV. The download must complete without the OutOfMemoryException.
2. Open Task Manager → Details → w3wp.exe (DataMonitor pool) and observe Working Set (Memory) during the export. The peak must remain below 70% of physical RAM.
3. Run Performance Monitor with the counter \.NET CLR Memory\# Bytes in all Heaps scoped to the WinCC WebNavigator application pool. Peak should stay below 2 GB on a 32-bit process and below 6 GB on a 64-bit process.
4. Check the Windows event log: Applications and Services Logs → WinCC → Runtime must show no entry with Event ID 1101 (archive disconnect) or 1102 (archive buffer overflow) during the export window.
5. Validate the resulting CSV opens correctly in Excel and the row count matches the requested interval (use the Ctrl+End shortcut to jump to the last cell).

8. Diagnostic Matrix

9. Excel Worksheet Limits - Reference

Microsoft Excel worksheet row and column limits have evolved across versions and are not enforced by the CSV download itself:

The 734,400-row dataset in the field case fits within the Excel 2007+ limit, confirming that the failure is not Excel-side but is server-side in the WinCC WebNavigator / DataMonitor .NET process.

10. Long-Term Recommendations

• Right-size the server. A WinCC V7.5 DataMonitor server with up to 30,000 archived tags and 10 concurrent web clients requires a minimum of 16 GB ECC RAM, an x64 quad-core CPU at 2.4 GHz or higher, and a dedicated SSD for the archive database.
• Use the WinCC IndustrialDataBridge for any scheduled export exceeding 100,000 rows. The IDB streams in blocks, supports filter and transformation logic, and writes to SQL, CSV, or SAP directly.
• Disable the in-browser preview of large CSV files. Configure the Content-Disposition header in the DataMonitor site to attachment only; this forces a download rather than a renderer parse.
• Schedule IIS application pool recycling during low-traffic windows (e.g., 03:00 local time) using the Recycling → Specific Times feature. Combined with the gcServer runtime setting, this prevents LOH fragmentation from accumulating over weeks of uptime.
• Monitor continuously with the WinCC PerformanceConfigurator tool and alert on the \.NET CLR Memory\% Time in GC counter exceeding 30% sustained.

FAQ