Resolving PCS 7 S7-400 CPU 417 Download Error 0xFFDF_4061 S7DOS

1. Problem Overview

Engineers maintaining a SIMATIC PCS 7 V6.0 SP2 HF1 automation station on a S7-400 CPU 417-4 (Siemens order number 6ES7 417-4XT05-0AB0) report that an SFC type exchange inside a CFC chart is followed by a rejected download to the AS. The SIMATIC Manager download dialog displays "Message 0x0" with no further descriptive text, while the lower status pane of the dialog simultaneously reports:

0xFFDF_4061: [S7DOS] In global memory. [FB662]
DLL "s7jcomfb.dll" - No text in resource available
Load memory RAM: 67% assigned
Work memory code: 33% assigned
Work memory data: 10% assigned

The combination is diagnostic: the project still compiles, the CPU still has substantial free memory in every partition, yet the download cannot be opened over the S7DOS communication layer because the resource string table for s7jcomfb.dll has been released from process address space. This is not a CPU memory shortage. It is a PC-side runtime / S7DOS resource exhaustion that the PC side signals back to the engineering tool as a misleading "global memory" error.

2. Affected Hardware and Software Stack

Reference: Siemens Support Entry 38068213 — "Why is it not possible to download to the CPU?" describes the same symptom family for PCS 7 V6.x / V7.x and is the authoritative entry point for this class of fault.

3. Decoding the Error Message

The download status text is a stack of three independent messages. Treat each separately:

3.1 Message 0x0 — "No text in resource DLL s7jcomfb.dll"

Message identifier 0x0 means the S7DOS layer could not resolve an error code against the resource string table of s7jcomfb.dll. The DLL is present on disk and registered, but the resource block that maps S7 error codes to human-readable text has been unloaded or corrupted in the address space of the engineering or WinCC process. The DLL itself is not necessarily damaged — the operating system simply could not satisfy a LoadString call against it during a download attempt.

3.2 0xFFDF_4061 — [S7DOS] In global memory [FB662]

S7DOS error 0xFFDF_4061 belongs to the S7 communication / download object system. The "in global memory" qualifier means that S7DOS could not allocate a block of the requested size from the process global heap that it shares with the calling component (SIMATIC Manager on the ES, or WinCC on the OS). The bracketed [FB662] is the FB instance that was being loaded at the moment the allocation failed — it is informational, not the cause. PCS 7 plant objects frequently expand to FB660–FB699 instances (motor, valve, PID, dosing blocks); these are the largest single consumers of the S7DOS scratch area during a type exchange.

3.3 Memory line — Load/Work statistics

The CPU-side memory line is a snapshot taken by the download service before it commits any block to the AS. The numbers do not justify rejection:

• Load RAM 67% assigned — ~1.3 MB free of the 4 MB nominal load memory
• Work code 33% assigned — ~2.7 MB free of the 4 MB work memory code partition
• Work data 10% assigned — ~3.6 MB free of the 4 MB work memory data partition

These values confirm the S7-400 CPU 417-4 has more than enough free space; the failure is on the PC side.

4. Root Cause Analysis

Three converging conditions produce the symptom set. The first two are necessary, the third is a frequent accelerator:

1. Long-lived WinCC Runtime process. The PCS 7 OS Runtime (WinCC) holds handles into s7jcomfb.dll for the entire OS lifecycle. On a station that has been up for weeks or months, the process heap fragments, the S7DOS connection table grows, and the loaded resource block of the DLL can be released by Windows memory manager under load. When the engineering station then attempts a download through the same S7DOS instance, the call returns a bare error code because no string resource is available.
2. SFC type exchange inflates block count. Replacing an SFC type in a CFC causes PCS 7 to regenerate the SFC instance and re-instantiate all derived FBs. The compiler typically produces one or two new FB/DB pairs and a small number of updated instances. The download service must hold both the old and new image in its global heap while the delta is computed, doubling its working set transiently. If the heap is already fragmented, the allocation fails with 0xFFDF_4061.
3. SIMATIC Net / S7DOS background load. With WinCC Runtime active, OS server tags, alarms, and trends are continuously pulled from the AS. S7DOS multiplexes these requests with the engineering download request on the same CP. Resource pressure on the channel is highest precisely when the engineer is online, and the failure presents first as a download error rather than as visible OS degradation.

5. S7-400 CPU 417-4 Memory Architecture Reference

The 6ES7 417-4XT05-0AB0 belongs to the first-generation CPU 417-4 family. Its memory is partitioned; understanding the partitions is required to interpret the download dialog and to plan the next download after a fix.

Reference: S7-400 CPU 417-4 Manual (11/2006 edition) documents the memory model, the role of the Flash Memory Card, and the RAM-to-Flash mirroring behavior used by the download service.

6. SFC / CFC Type Exchange Behavior in PCS 7 V6.0

An SFC type exchange in a CFC chart is one of the heaviest engineering operations in PCS 7 because of the way the SFC compiler and the CFC compiler cooperate:

1. The CFC compiler reads the new SFC type and rebuilds the run sequence group ordering.
2. For every instance of the old SFC type, the compiler produces a delta DB that contains the new state-transition table, the new sequencer constants, and any new operator-set parameters.
3. Every referenced FB type (motor block FB662-class, valve block, PID block) is re-instantiated because the SFC reference is part of the FB signature.
4. The total delta is then handed to the download service, which must hold the new image, the old image, and the AS-side handshake buffer simultaneously.

On PCS 7 V6.0 SP2 HF1 specifically, the SFC type exchange path was updated to also clear and re-bind the WinCC tag list, which is what causes s7jcomfb.dll to be touched immediately before the download. That is why the failure mode is "first download after SFC type exchange" rather than "every download".

Reference: SIMATIC PCS 7 V6.0 Service Pack Documentation Collection contains the CFC/SFC compiler notes for SP2.

7. Resolution Path A — WinCC Runtime Restart (Primary Fix)

This is the fix that resolved the case described in the source symptom. The PC-side process that holds the broken resource string table is the WinCC Runtime, not the engineering tool. Recycling it frees the resource block, re-establishes the S7DOS connection, and clears the global heap fragmentation that triggered 0xFFDF_4061.

7.1 Prerequisites

• Operator station must be released by the operator (WinCC in productive mode)
• OS server redundancy (if any) must be configured to take over the alarm/visibility load
• Engineering station must remain online and logged in as a user with the same rights as the project owner

7.2 Procedure

1. On the OS server, open Start > SIMATIC > WinCC > WinCC Explorer.
2. Right-click Computer > Properties > Startup and note the current WinCC project path.
3. Right-click the WinCC Runtime icon in the system tray and choose Stop WinCC Runtime. Confirm the dialog; allow up to 60 s for a controlled shutdown of all picture trees, scripts, and S7DOS connections.
4. Wait until the CCMsgServer and CCAlgServer services are no longer visible in Task Manager. If a redundant partner is present, verify that the standby has taken over (alarm line should remain live).
5. Open Start > Run > services.msc. Restart the SIMATIC S7 Protocol Suite service (this is the service that owns s7jcomfb.dll in a service-mode install).
6. Restart WinCC Runtime from the WinCC Explorer toolbar. Confirm that the OS server reconnects to the AS (green S7DOS icon in the WinCC channel diagnostics).
7. On the ES, repeat the download: PLC > Download on the S7 program. The download should now complete without the 0xFFDF_4061 status line.

7.3 Why this works

Stopping the WinCC Runtime forces s7jcomfb.dll to be unloaded from the process address space. When the Runtime restarts, the DLL is reloaded from disk and Windows re-binds the resource string table. The fragmented global heap is released, and the S7DOS download service can allocate the working buffer it needs for the SFC delta.

8. Resolution Path B — SIMATIC Manager Reorganize (Secondary)

If a WinCC restart is not acceptable (for example, on a station that does not run a PCS 7 OS but only the engineering tool) the alternative is to clean up the STEP 7 project itself.

1. Close the project on every ES that has it open.
2. Open the project with exclusive write access on the project server: SIMATIC Manager > File > Open > User Project (exclusive).
3. Choose File > Reorganize. The SIMATIC Manager walks the entire S7 program, the S7 sources, and the symbol table, and rewrites them sequentially. This eliminates the project-side fragmentation that can amplify the S7DOS allocation problem.
4. When the reorganize finishes, recompile the S7 program: Options > Compile > S7 Program. Verify that the diagnostic buffer is clean (no 0xFFDF_4061 during the recompile).
5. Save the project to the project server and reopen from a workstation to perform the download.

9. SIMATIC Net Configuration Verification

If both fixes above fail, the S7DOS layer itself is misconfigured. Verify the SIMATIC Net side before assuming a hardware fault.

Reference: SIMATIC Net PC Software — S7DOS Programmer's Guide covers the resource ownership of s7jcomfb.dll in service-mode versus application-mode installs.

10. Diagnostic and Verification Procedure

After applying fix A or B, verify in this sequence:

1. Download the S7 program. In SIMATIC Manager, PLC > Download. Expect a clean dialog with no 0xFFDF_4061 line. The lower pane should display the block-by-block progress and end with "Download completed (xx errors, yy warnings)".
2. Read the CPU diagnostic buffer. PLC > Diagnostic/Setting > Diagnostic Buffer. Look for STOP/RUN transitions and any SF (system fault) entries. The buffer must be empty of fresh entries related to the download.
3. Check work memory online. PLC > Accessible Nodes, then read the system data block SZL 0x0132 (memory usage). Confirm code + data partitions are within budget and that load memory shows the freshly loaded blocks.
4. WinCC tag consistency. On the OS, open WinCC Explorer > Tag Management > SIMATIC S7 Protocol Suite > S7DOS and right-click Check Tags. All tags used by the new SFC instance must resolve.
5. Alarm line stability. Leave the OS in productive mode for 10 minutes. The S7DOS channel must remain "connected" continuously; if it drops, the resource problem is structural and requires the full SIMATIC Net verification in Section 9.
6. SF/BF LEDs on the CPU 417-4. With the door open, confirm only the RUN LED is lit (or RUN + DC5V in normal operation). No SF, BF1, or BF2 should be active.

11. Troubleshooting Matrix

12. Prevention and Long-Term Hardening

• Schedule a weekly WinCC Runtime restart on the OS server. The WinCC process is not designed to run for months without a recycle; doing so eliminates the heap fragmentation that drives 0xFFDF_4061.
• Plan SFC type exchanges inside a maintenance window with the OS stopped, or at minimum with the S7 Protocol Suite service recycled, so that the S7DOS heap is fresh at the moment of the largest download.
• Keep the project Flash Memory Card at 30% free minimum. Compress the MC on every major download: PLC > Memory Card > Compress.
• Maintain a current HF on PCS 7 V6.0 SP2. HF1 is the cited level; later HF bundles of the same service pack (HF2/HF3/.../HF7) tighten the SFC type exchange and S7DOS resource path.
• Verify the SIMATIC Net release against the PCS 7 V6.0 compatibility matrix on every ES/Server build to avoid mixed-version S7DOS clients.

13. FAQ