Collection Was Modified During Enumeration in C#: Why It Happens and How to Fix It

By the end of this page, you will understand why C# throws Collection was modified; enumeration operation may not execute, why it commonly appears with foreach and Dictionary<TKey, TValue>, and how to fix it safely. You will also learn the difference between modifying a collection in the same loop and modifying it from another thread, which is especially important in server code such as WCF services.

In C#, a foreach loop uses an enumerator behind the scenes. That enumerator expects the collection to stay structurally unchanged while it is being read.

A structural change means operations like:

• Add
• Remove
• Clear

When a collection changes during enumeration, the enumerator becomes invalid. To protect you from unpredictable behavior, .NET throws this exception:

Collection was modified; enumeration operation may not execute

In your code, this can happen in two different ways:

1. You remove an item during the foreach loop

   • Inside NotifySubscribers(), if SignalData(sr) throws, you call UnsubscribeEvent(s.ClientId).
   • That removes an entry from subscribers while foreach (Subscriber s in subscribers.Values) is still iterating.

2. Another thread modifies the dictionary at the same time

   • A client may subscribe or unsubscribe while is looping.

Think of foreach like reading names from a printed attendance sheet.

While you are moving down the list, someone else should not:

• erase a name,
• add a new name,
• reorder the list.

If that happens, your place on the sheet may no longer make sense.

A Dictionary enumerator works the same way. It expects the collection to remain stable until the loop finishes.

If you need to remove people while processing them, use one of these approaches:

• make a copy of the list first, then iterate the copy,
• collect items to remove in a separate list, then remove them after the loop,
• use a thread-safe collection when multiple threads are involved.

A useful mental shortcut:

• Read while looping: safe
• Change while looping: dangerous unless you control how it happens

The core rule is simple: do not structurally modify a collection while iterating it with foreach.

Problematic pattern

var numbers = new List<int> { 1, 2, 3, 4 };

foreach (var n in numbers)
{
    if (n % 2 == 0)
    {
        numbers.Remove(n); // Throws at runtime
    }
}

The loop is reading numbers, but Remove changes the collection.

Safer pattern: remove after enumeration

var numbers = new List<int> { 1, 2, 3, 4 };
var toRemove = new List<int>();

foreach (var n in numbers)
{
    if (n % 2 == 0)
    {
        toRemove.Add(n);
    }
}

 ( n  toRemove)
{
    numbers.Remove(n);
}

Consider this smaller example:

var words = new List<string> { "A", "B", "C" };

foreach (var word in words)
{
    Console.WriteLine(word);

    if (word == "B")
    {
        words.Remove("B");
    }
}

What happens step by step

1. foreach creates an enumerator for words.
2. The enumerator starts with the collection in a valid state.
3. First iteration:
   • word is "A"
   • Console.WriteLine("A")
4. Second iteration:
   • word is "B"
   • Console.WriteLine("B")
5. Inside the if, words.Remove("B") changes the list structure.
6. The enumerator is now invalid because the collection it was tracking has changed.

This issue appears often in real applications whenever code keeps a shared in-memory collection.

Subscriber or client registries

Like your WCF example:

• connected clients
• active WebSocket sessions
• SignalR connections
• event listeners

Job and task processing

A server may loop through active jobs while another thread adds or removes jobs.

Caches and lookup tables

A dictionary may store:

• user sessions
• configuration values
• object instances
• API tokens

If one part of the app reads while another writes, enumeration errors can occur.

UI applications

A WinForms or WPF app may loop through controls or models while an event handler removes one.

Data pipelines

A script may process a collection of files, records, or messages while filtering or deleting them at the wrong time.

The general lesson: if a collection is shared, think carefully about when it is read and when it is changed.

In production code, developers usually solve this with a small set of common patterns.

1. Snapshot before iterating

Very common when broadcasting to clients:

Subscriber[] snapshot;
lock (_sync)
{
    snapshot = subscribers.Values.ToArray();
}

This reduces the time spent holding a lock and makes the iteration stable.

2. Remove failed items after processing

Instead of removing during enumeration, collect IDs first:

var failedIds = new List<Guid>();

foreach (var s in snapshot)
{
    try
    {
        s.Callback.SignalData(sr);
    }
    catch
    {
        failedIds.Add(s.ClientId);
    }
}

lock (_sync)
{
    foreach (var id in failedIds)
    {
        subscribers.Remove(id);
    }
}

This pattern is clean and easy to reason about.

3. Guard shared state with lock

For ordinary dictionaries, a private lock object is standard:

private static readonly object _sync = new object();

1. Removing from the same collection inside foreach

Broken example:

foreach (var item in items)
{
    if (ShouldRemove(item))
    {
        items.Remove(item);
    }
}

Why it fails:

• foreach expects the collection to stay unchanged.

How to avoid it:

• use a snapshot
• collect items to remove later
• use a loop structure that supports safe indexed removal when appropriate

2. Assuming the debugger proves the code is safe

Beginners often think:

• “It works in debug mode, so the logic must be fine.”

But concurrency bugs depend on timing. The debugger changes timing, so the bug may hide.

How to avoid it:

• trust the exception and review shared-state access
• test without breakpoints
• look for race conditions in server code

3. Using Dictionary from multiple threads without synchronization

Broken example:

private static Dictionary<Guid, Subscriber> subscribers = new();

  ()
{
    subscribers.Add(s.ClientId, s);
}


{
     ( sub  subscribers.Values)
    {
        sub.Callback.SignalData(sr);
    }
}

// Unsafe: modifying a collection during foreach
foreach (var item in collection)
{
    collection.Remove(item); // don't do this
}

// Safe pattern: snapshot + lock
private static readonly Dictionary<Guid, Subscriber> subscribers = new();
private static readonly object _sync = new object();

Subscriber[] snapshot;
lock (_sync)
{
    snapshot = subscribers.Values.ToArray();
}

foreach (var s in snapshot)
{
    // work with s
}

// Safe pattern: collect removals, then remove after loop
var failedIds = new List<Guid>();

foreach (var s in snapshot)
{
    try
    {
        s.Callback.SignalData(sr);
    }
    catch
    {
        failedIds.Add(s.ClientId);
    }
}

lock (_sync)
{
    foreach (var id in failedIds)
    {
        subscribers.Remove(id);
    }
}

Rules to remember

Why does foreach throw when a collection changes?

Because foreach uses an enumerator that expects the collection structure to remain unchanged while iterating.

Is removing the current item inside foreach ever safe in C#?

Not for normal collections like List<T> or Dictionary<TKey, TValue>. Use a snapshot, a separate removal list, or a different loop strategy.

Does this mean Dictionary is broken?

No. Dictionary<TKey, TValue> works correctly, but it is not designed for concurrent modification during enumeration.

Why does the error disappear when debugging?

Because the debugger changes execution timing. Race conditions often become less frequent or move to different places when code runs more slowly.

Should I use ConcurrentDictionary here?

Maybe, but not automatically. For a subscriber list, a lock plus snapshot iteration is often simpler and easier to reason about.

Should I lock the whole NotifySubscribers() method?

Usually no. Avoid holding a lock while calling client callbacks, because callbacks may be slow or re-entrant. Copy first, then notify outside the lock.

Why is initializing a static dictionary in the constructor a problem?

• foreach loop in C# — Important because the exception happens during enumeration.
• Dictionary<TKey, TValue> — The collection type involved in the error.
• Enumerators in C# — Explains why collection changes invalidate iteration.
• Thread safety — Critical when multiple threads access shared state.
• lock statement in C# — A common way to protect shared collections.
• ConcurrentDictionary<TKey, TValue> — A thread-safe alternative for concurrent access.
• Race conditions — Helps explain why the bug appears randomly and hides during debugging.
• Exception handling in C# — Relevant because callback failures trigger unsubscribe logic.