views:

395

answers:

1

I have a GUI app which connects to a sensor, gathers data and processes it in the background using BackgroundWorker threads.

As it stands I'm posting data to the GUI using the ProgressChanged which seemed to be working well to begin with. I've since upped the data rates and have discovered a problem; if the software is left to run for a few minutes, the amount of processor usage appears to ramp up until it reaches near 100% on both cores on my machine and at that point, I get an error which reads:

Managed Debugging Assistant 'DisconnectedContext' has detected a problem in 'myapp.exe'. Additional Information: Context 0xe2ba0 is disconnected. Releasing the interfaces from the current context (context 0xe2d10). This may cause corruption or data loss.

I've read some stuff around the web which suggests that this can happen if a GUI app is unable to pump messages fast enough. I've noticed I can provoke the same crash to happen faster if I resize the window rapidly (i.e. pump a load more messages) which supports the theory I think?

So the questions here are:

  1. Whether anyone agrees with my hypothesis about message pumping?
  2. Whether there's another explanation?
  3. Is there some way I can prove it (peek the number of messages in the queue maybe)?
  4. Are these all bad code smells that suggest I'm going about this the wrong way?

Any advice would be very gratefully received.

+1  A: 

This kind of sounds like a very specific problem and I think that's why no one has answered yet but I think I can help on question #3.

Spy++ should be able to see the messages going to your window. I think you could use it to watch the messages pump to your GUI and do your resizing test. If you saw a large increase of messages trying to be processed it might confirm your hypothesis.

As an aside, I've read that you might be able to change the main thread apartment from STAThread to MTAThread to make this MDA go away.

Perphaps you could modify your app to spit the sensor readings out to a file or queue them up in a different mechanism instead of updating the GUI constantly. HTH.

cmw
I tried the MTATHread setting which only seemed to add an occasional crash. I've instead adopted a queuenig mechanism and fonud a bug in part of the display code which was over-fillnig a `RichTextBoxControl`. Between those two, it looks like I've solved the problem. Thanks for the suggestions.
Jon Cage
I've seen this happen a few more times and it's definitely triggered by trying to send too many `ProgressChanged` requests from the data producer thread to it's listeners.
Jon Cage