Hello,
I have a strange problem im my application. Unfortunatly the app is
rather complex, so I cannot post a simple demo app or source code, but I
will try to explain what happens.
My application is standard Windows.Forms, Visual Studio 2005 (.Net 2.0).
It has several forms and reacts to tcp messages. Everything works fine,
but at some time (usually after a few hours of opening and closing
forms) the ui seems to be frozen. Everything I do programmatically (like
opening a new form as reaction to a tcp message) works, but everything
that is related to user input (like mouse clicks) does not work. The
state lasts for several minutes or up to an hour, then the application
starts reacting to user input again and it seems that all the previous
events were cached and are now processed in rapid succession.

Things I tried:
- When I pause the app in visual studio while it is frozen, the ui
thread is at Application.Run( ... )
- The processor load is ok
- All Control.Invoke calls to change to the ui thread work fine (so
there is obviously nothing that blocks the ui thread for a long time)
- I've overriden DefWndProc and I see that events are processed. I get
for example WM_NCACTIVATE, WM_NCPAINT and WM_WINDOWPOSCHANGED. I do not
get MOUSE events
- Same if I use WinSpector. I see that events are processed, but no
MOUSE events
- The first event after the freeze was a WM_PARENTNOTIFY with lparam
WM_LBUTTONDOWN
- Nothing special happened before the freeze, no exception, no error.

I know this question is rather broad and unspecific, but perhaps you
have any idea what I can do to find the error. Are there any tools that
help with this sort of problem? Can I add any debug output that would help?

Thanks in advance,
Bernd Rausch

Hello Bernd,

This sounds like you're opening the windows from other threads than the thread
that was created for your application. This can yield very strange results
(like the ones that you describe).

Jesse

> Hello,
> I have a strange problem im my application. Unfortunatly the app is
> rather complex, so I cannot post a simple demo app or source code, but
> I
> will try to explain what happens.
> My application is standard Windows.Forms, Visual Studio 2005 (.Net
> 2.0).
> It has several forms and reacts to tcp messages. Everything works
> fine,
> but at some time (usually after a few hours of opening and closing
> forms) the ui seems to be frozen. Everything I do programmatically
> (like
> opening a new form as reaction to a tcp message) works, but everything
> that is related to user input (like mouse clicks) does not work. The
> state lasts for several minutes or up to an hour, then the application
> starts reacting to user input again and it seems that all the previous
> events were cached and are now processed in rapid succession.
> Things I tried:
> - When I pause the app in visual studio while it is frozen, the ui
> thread is at Application.Run( ... )
> - The processor load is ok
> - All Control.Invoke calls to change to the ui thread work fine (so
> there is obviously nothing that blocks the ui thread for a long time)
> - I've overriden DefWndProc and I see that events are processed. I get
> for example WM_NCACTIVATE, WM_NCPAINT and WM_WINDOWPOSCHANGED. I do
> not
> get MOUSE events
> - Same if I use WinSpector. I see that events are processed, but no
> MOUSE events
> - The first event after the freeze was a WM_PARENTNOTIFY with lparam
> WM_LBUTTONDOWN
> - Nothing special happened before the freeze, no exception, no error.
> I know this question is rather broad and unspecific, but perhaps you
> have any idea what I can do to find the error. Are there any tools
> that help with this sort of problem? Can I add any debug output that
> would help?
>
> Thanks in advance,
> Bernd Rausch
--
Jesse Houwing
jesse.houwing at sogeti.nl

Jesse Houwing schrieb:
> This sounds like you're opening the windows from other threads than the
> thread that was created for your application. This can yield very
> strange results (like the ones that you describe).

Hi Jesse,
thanks for your suggestion. There was indeed a short timeframe during
the start of the application, when the ui could be modified outside the
ui thread. Even if that was not the cause of the problem, we will have
one bug less :-)

Bernd Rausch

Hello Bernd,

> Jesse Houwing schrieb:
>
>> This sounds like you're opening the windows from other threads than
>> the thread that was created for your application. This can yield very
>> strange results (like the ones that you describe).
>>
> Hi Jesse,
> thanks for your suggestion. There was indeed a short timeframe during
> the start of the application, when the ui could be modified outside
> the
> ui thread. Even if that was not the cause of the problem, we will have
> one bug less :-)

You're welcome

But it didn't solve your issue I get from your message?
--
Jesse Houwing
jesse.houwing at sogeti.nl

Jesse Houwing schrieb:
> But it didn't solve your issue I get from your message?

I didn't know for sure, because it needs several hours of testing to
reproduce this bug, sometimes more, sometimes less. Right now it looks
like it was in deed the cause for the problem. I didn't see the problem
again after fixing this bug, but I need to test more. I will mail the
final results next week.

Have a nice day,
Bernd

Jesse Houwing schrieb:
> But it didn't solve your issue I get from your message?

I found an additional threading problem, the eventhandlers of some
controls could be called while the controls were disposing...
Testing is still in progress, but it seems that the fixes to the two
threading problems fix the freezing issue.

Have a nice day,
Bernd