4

I'm experiencing a strange "freezing" issue in a C# WinForms application I developed. Here are the symptoms:

The program will at seemingly random times freeze the GUI. This means that no UI element can be selected. The app's windows can't be moved or resized. It feels like there's an invisible modal dialog on top.

Here's what I have found out so far:

  • Code calls to GUI elements will go through normally, but UI elements don't reflect the change at all.
  • The windows task manager does NOT classify my app as "not responding". Everything is normal from that perspective, even CPU usage is just around 1-2%. So I'm not in an infinite loop.
  • The problem can not be provoked by any specific action, or I haven't found the "rule" yet. I did notice that when I use screenshot tools (like "demo builder") the problem seems to appear sooner. But I have no idea if and why this could be connected to my problem.
  • The problem is not caused by an active user interaction. It can occur at any time even when no user interaction is going on.
  • Among other things I have a threaded timer that's run every 5 seconds, and my log tells me that the timer's elapsed-method is called normally even after the UI freezing has started. So it's not the entire application that's blocked, just the UI.
  • When I attach the debugger and pause, nothing special can be observed. It'll break at Application.Run(). There are several threads but all of them are on "external code", so nothing I can really debug.
  • My program never recovers from the frozen state by itself. It stays that way, except in one case:
  • When I attach the debugger after the freeze, then hit "Pause" and leave the program in paused state for maybe 1-2 minutes and then continue execution, the UI freeze will miraculously go away! The program is then back to normal until the next freeze.

Here are a few special things I do in my app:

  • I wait for TAPI calls in a background thread (AddTAPI.NET component) and react to incoming calls. But I synchronize every call to the GUI using Control.BeginInvoke
  • I have a threaded timer running every 5 seconds in which I send a short message to a WCF service.. basically just saying "hi I'm still alive"
  • I use WCF client-/server communication with a client callback interface. Some calls from server to client cause GUI updates, but again, I'm always using Control.BeginInvoke to synchronize. Apart from that, the problem occurs even when there's no special communication from server to client.

Any ideas where or how to look for the cause of this strange problem is greatly appreciated!

Michael Irigoyen
  • 22,513
  • 17
  • 89
  • 131
Marco
  • 700
  • 5
  • 11
  • 5
    It seems like there's something on the main thread that is running long. Are you using log4net or something that can show debug statements by thread? – Doug Dawson Jan 16 '15 at 16:20
  • 1
    If it weren't for the fact that breaking lands you in `Application.Run`, I'd be sure this was just a WinForms timer going off and running a long process on the UI thread. But this sounds trickier than that... – adv12 Jan 16 '15 at 16:21
  • 1
    @marco just because your system is not taxed does not mean the UI thread is not busy. It could be waiting on network IO for example. While I understand your plight, there is little hope you will find any help here. – iamkrillin Jan 16 '15 at 19:06
  • @iamkrillin: All network operations are done on separate threads. And even it that were the issue, wouldn't the debugger then jump to the code line where it's waiting for an IO answer if I hit pause? Instead, it claims to be sitting at Application.Run(). And when I continue the app after 1 minute, the freeze resolves by itself. – Marco Jan 16 '15 at 19:42
  • 3
    To all of you who flagged my question as "off-topic": After intensive research I found out that the following problem was very similar to my initial post: http://stackoverflow.com/questions/4077822/net-4-0-and-the-dreaded-onuserpreferencechanged-hangst So who ever flagged my question owes me an apology if they want to retain their professional credibility. Long live freedom of speech :-) – Marco Jan 17 '15 at 11:50
  • @Macro We've undeleted the question and rolled it back to it's original state. I've put in a flag to have it closed as a duplicate of the question you found that solved your issue. Sorry about the mixup. – Michael Irigoyen Jan 19 '15 at 02:23
  • 8
    @Marco The fact that somebody else was able to slip a bad question under everybody's noses doesn't excuse yours. You really need to read up more on what Stack Overflow is and what kinds of questions we try to answer here. – Chris Hayes Jan 19 '15 at 02:25
  • This question is on hold, but you if you are doing any threading, you might want to look into the possibility of a deadlock. http://msdn.microsoft.com/en-us/magazine/cc163618.aspx – teynon Jan 19 '15 at 17:04
  • 3
    This question inspired a discussion on meta: http://meta.stackoverflow.com/q/283849/1612701 – Cody Piersall Jan 19 '15 at 17:07
  • 2
    It's not about freedom of speech, but rather about following the rules of the community you've agreed with during the registration process. Also, the question you've found is almost 5 years old. Things changed and are more strict nowadays. This question in its current form will produce just answers of type "try this". We can't debug this for you without any code that we could use to reproduce your issue. – walther Jan 19 '15 at 17:15
  • 4
    possible duplicate of [C# application keeps freezing on remote](http://stackoverflow.com/questions/5103250/c-sharp-application-keeps-freezing-on-remote) – Lance Roberts Jan 19 '15 at 17:20
  • 3
    On using freedom of speech as an argument: http://xkcd.com/1357/ . Not saying thats what you are doing, but its a pretty crappy argument. I happen to agree with the close reason. The only thing we can answer with is "Something is locking the UI thread". *Exactly what* (which would be an answer) is impossible to say. – BradleyDotNET Jan 19 '15 at 17:50
  • 3
    @BradleyDotNET (&walther): Sorry, I still have to disagree with you. There are problems that raise questions which can't be answered in one single correct way. In other words: A UI freezing problem may have several causes. If you had creflly read my initial post (instead of skimming over it and jumping to conclusions) you would have seen that there was plenty of information in there to go on FOR SOMEBODY WITH EXPERIENCE IN THE FIELD. And that's exactly my point: Just because YOU don't see an immediate solution doesn't mean someone else hasn't already solved this strange issue. – Marco Jan 19 '15 at 22:28
  • .. and as it turned out, the problem was completely solvable and provenly extremely difficult to diagnose (that too you can verify yourself, even Microsoft says so on their sites). So if stackoverflow is only for questions whose answers are basically implicated in the question itself, then yes, I guess my post was off-topic. But if stackoverflow also allows tricky questions, then it should have been allowed in its initial form. – Marco Jan 19 '15 at 22:31
  • 4
    @Marco I did read the entire post, and we can disagree about its "answerableness" (I actually do have experience in this field). I have no problem with tricky questions, I have a problem with questions with *no real definable answer(s)*. The best you are going to get is "Try these things", the usefulness of which is arguable at best (at least to me). This holds even for the linked duplicate, which had exactly those kinds of answers. Just want to make sure you understand my differentiation between a "tricky" question (which are great!) and an "unanswerable" one. – BradleyDotNET Jan 19 '15 at 23:00
  • @BradleyDotNET: It is my firm belief that by reading a question NO ONE can know ahead of time whether the question will have a real definable answer. Answering to a difficult problem is a process, not a one-liner. There is no benefit for anyone in deleting or flagging a question, but all the more benefit in "let live" or try to answer it yourself. Your personal resources invested in the question are the same in all cases, but the outcome is a different one for all involved parties. I'll post a final statement about my problem in the meta blog and then leave you alone. :-) – Marco Jan 20 '15 at 08:09
  • 1
    @Marco As others said, the thing is that the same problem (app freezing) could have many, MANY different causes - even MULTIPLE causes. THIS is what's wrong about your question. That doesn't make it insignificant; it just doesn't fit well with SO's format. The fact that a similar question was asked (and answered) in the past doesn't change that. – Crono Jan 20 '15 at 16:30
  • 1
    Also, there actually *is* a benefit from flagging such broad questions: you have to think about people who browses through them trying to find solutions to their own problem. The more isolated and precise the problems are, the better they fit in a specific search scope and the more relevant they get. – Crono Jan 20 '15 at 16:35
  • @Crono: Under "Help/how-to-ask" I don't see any rule that states that a problem is only allowed to have one single cause. This is a rule that some of you obviously made up to justify the flagging of my question. But you know what, it's ok, I've learned my lesson. With low reputation it's a living nightmare on here. I'm being taxed as an idiot until I have 3'000 what-evers. I won't post any more questions and also not participate in answering questions. The Spanish inquisition was rather friendly in comparison ;-) – Marco Jan 21 '15 at 08:14
  • Oh and just to be sure, let's go through "/help/dont-ask" as well (_To prevent your question from being flagged_): 1. I did not ask for favorites, 2. The answer was not provided along with my question, 3. There WAS an actual problem to be solved, 4. The question was not hypothetical but concrete with all observed facts listed, 5. The question was not a rant. So really there was absolutely no reason to flag or close, except when I myself found out that the question was a duplicate. – Marco Jan 21 '15 at 08:30

0 Answers0