ContextSwitchDeadlock was detected

I was recently getting the following error in my code:

ContextSwitchDeadlock was detected

Message: The CLR has been unable to transition from COM context 0x143728 to COM context 0x1435b8 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.

which is also described here

This issue seemed to happen when I was trying to close a SQLCeConnection. I have a shared dataaccess layer that handles all of my SQL connectivity, where I open a connection, and close it immediately after the transaction has been completed (more on whether or not this is the best way of handling things with SQL CE later).

Looking into this issue gives basically 2 responses:
1) Turn off the MDA response in visual studio that gives this error
2) use STA pumping

Response 1) was worthless for me, because this issue was translating to the non-debugging clients as the application just freezing, so it wasn't just a debugging issue.

Response 2) sounded good, but i got a lot of conflicting and unhelpful information on how to do this. There's some vague information about using CoInitializeEx , but that didn't really help my situation, unfortunately.

So i started looking at the actual database call. Apparently, i had a WPF gridview with a datacontext set to a collection of a custom business object (let's call it 'customer'). This Customer business object had a readonly string property in it where it got it's value by checking the database. Apparently, it was this call that was causing the issue, and if I set this property instead at the objects instantiation (instead of calling it every time the property was looked at), the issue went away.

This was especially weird, because i recently upgraded this project from .Net 2.0 forms to WPF, without changing the business objects/data layers at all. The old 2.0 project worked fine with no issues at all with this configuration. Apparently WPF doesn't like it at all.