0

I'm working on a console app developed by a guy who doesn't work here any longer. While debugging, the ContextSwitchDeadlock exception was thrown (I found this question on the exception). If I ignore it, the app will eventually work through the loop it occurs in. The app runs as a scheduled task every day, but this particular process is not called every single time.

I'm wondering if it is OK to allow this exception to go to production. The author of this app put it in production with this exception, and its been running ever since. Should I just make my (unrelated to this exception) updates and leave the app as is? Or should I try to address the issue? Addressing it seems daunting to me :/

Community
  • 1
  • 1
Ben
  • 704
  • 4
  • 10
  • 25
  • Hmm, this isn't exactly a common warning for console mode apps. You'll need to explain what kind of COM objects you are using to make the call. It is otherwise just a debugger warning, not an error. If the program eventually does complete then it is not actually a deadlock. – Hans Passant Sep 27 '12 at 15:41

1 Answers1

1

Ben. I would say 'NO'. Unless your exception is a ThreadAbortException (i.e. the user closed a window and so the process is dead) or some such thing, an exception like this could open your code up to cascading failures. Based on what we do where I work:

  1. I think, as a band aid, you should encapsulate the offending code with a Try-Catch, and wire it up to send you an email every time it Catches so you have documentation on what's going on AND so that you prevent cascading failures from propagating throughout your code (quarantine the problem).

  2. Towards a fix (when you have time), debug it and step through to figure out why your main thread is taking so long, and if you can, create a worker thread to handle that (DISCLAIMER: this would be my opening attack angle at this problem, based on the answer from the link you provided. I have NOT tested this, nor do I have experience enough to definitively say this will work).

EDIT: After running into this error for a particularly long running process myself, I came across this slew of answers on msdn:

http://social.msdn.microsoft.com/Forums/en/vsto/thread/bf71a6a8-2a6a-4c0a-ab7b-effb09451a89

While I resolved my error (I was reading a System.IO.FileStream into a String Builder instead of using a String and the StreamReader ReadToEnd method), I think it might be helpful to you.

sacredfaith
  • 850
  • 1
  • 8
  • 22
  • Don't worry, I haven't forgotten about your answer. This project is put on hold for the moment, I will further investigate once I am working on it again. – Ben Oct 02 '12 at 19:26
  • Thanks Ben, as a developer, I completely understand. I sincerely appreciate your comment though!! – sacredfaith Oct 05 '12 at 15:59
  • I think I may have found a fix. The code was declaring a StreamReader like 'Dim input As New StreamReader(FileName)'. I changed that to a Using block like 'Using input As New StreamReader(FileName)...End Using'. – Ben Oct 10 '12 at 14:47