This project is read-only.

Creating large archives

Jan 25, 2010 at 2:06 PM


     When using the DotNetZip libs and compressing large files ( between 250megs and 500megs) the c# application gives a warning but allows a continue and operation completes fine.

Here is the message I get:

ContextSwitchDeadlock was detected
Message: The CLR has been unable to transition from COM context 0x2408900 to COM context 0x24086b0 for 60 seconds. The thread that owns the destination context/apartment is most likely either doing a non pumping wait or processing a very long running operation without pumping Windows messages. This situation generally has a negative performance impact and may even lead to the application becoming non responsive or memory usage accumulating continually over time. To avoid this problem, all single threaded apartment (STA) threads should use pumping wait primitives (such as CoWaitForMultipleHandles) and routinely pump messages during long running operations.

It seems the Messagepumps have been buried under .Net... What can I do to avoid this error/message?


Steven Schultz

Jan 25, 2010 at 11:22 PM

That message, i gather, can occur if you run a threaded app under the debugger.  It is the result of a "managed debug assistant"  that has been put into place in .NET to provide extra information to developers when they are running their apps under the debugger.

Are you running your app under the debugger?  

You can read about Managed Debug Assistants here:

You can read about the ContextSwitchDeadlock MDA here: 

It's not anything to worry about.  if you describe your application a little, I might be able to help advise how to avoid the message. Do you run the zip operation on the main thread? If so, then the way to avoid it is to put the zip operation on a background thread, as with the BackgroundWorker.

Jan 26, 2010 at 12:30 PM

You are correct. I have disabled the ContextSwitchDeadlock MDA. Thanks for your help.

I am currently looking at the differences in using a BackgroundWorker vs. a new System.Thread.....  I guess this is kind of out of the "scope" of this discussion board but are there any advantages in using a BackgroundWoker over a Thread? Are backgroundworkers preprogrammed/setup to handle thread racing/locking?


Thanks again!

Jan 26, 2010 at 11:01 PM

When in doubt, DO NOT start your own thread.

There's an advantage to using a thread from the threadpool, over starting a thread via Thread.Start().  Here's a Q&A on the topic, may be useful: .   That question asks specifically about ThreadPool.QueueUserWorkItem(), but it also applies to the use of any mechanism that uses threads from the threadpool (including BackgroundWorker), versus starting threads explicitly (by calling Thread.Start()) . 

If you are writing a winforms app,  BackgroundWorker is a good approach because it provides a design-time experience. and it includes events you can register for.   If you don't need those features, then using QUWI is equivalent to using a BackgroundWorker.  I advise against Thread.Start().