2

I have a large-ish Winforms application written in C# which is periodically unresponsive. The issue seems to occur once the application has been use for an hour or so. Exact timings are difficult to gather as users often go off to work on something selse, get back to it and find it has become unresponsive.

I think a memory leak can be ruled out as I'm not seeing excessive memory usage (I've asked users to send a screenshot of the task manager and memory usagage is the same as I would see when the application is runnning normally)

Similarly, CPU usage is normal (single digit %)

As I've so far been unable to recreate the issue on mydevelopment PC I am planning on sitting next to one of the affected users and mirror every action the user performs in order to recreate this. (I'll be setting up a laptop to RDP in to my main PC)

Recreating the issue is one thing, but I'll need to find out what is actually going on in the application.

Could anyone tell me if running in debug mode (through visual studio) will be sufficient or will I need to do something different?

I've searched through a few posts and I've seen mention of profiling software, however I'm not sure if this would only help with general performance issues or memory management issues.

Alternatively, if anyone has come across similar freezing issues then do you have any suggestions of the kind of causes for this?

Some technical details: Aplication is C#, compiled against .NET 3.5, winforms GUI. There are a few external libraries (most significant is ComponentFactory Krypton Suite). Data access is to a Microsoft SQL Server 2005 database. The solution contains 39 projects, I'm not sure if that might have something to do with it?

Any suggestions/pointers would be greatly appreciated.

Daniel Snowden
  • 177
  • 1
  • 11
  • Perhaps some heavy garbage collection is occasionally needed? So, perhaps tune the GC parameters.... – Basile Starynkevitch Sep 17 '12 at 07:58
  • I assume that unresponsive means frozen, not slow, right? Sounds like a deadlock of some kind. Do you have any multithreaded execution inside the app? – Zdeslav Vojkovic Sep 17 '12 at 08:04
  • @zdeslavvojkovic That is correct, frozen instead of slow. Regarding multithreaded execution, The application does make a lot of use of BackgroundWorkers, these are generally used when searches are carried out against the backend database. – Daniel Snowden Sep 17 '12 at 08:10
  • then most likely you have a deadlock. You can attach debugger to process and break into it when it freezes - it will show you which threads are waiting on which synchronization objects. I would also start with checking the background thread code, especially the places where multiple locking objects are used, as these are most common causes of deadlocks. – Zdeslav Vojkovic Sep 17 '12 at 08:13

1 Answers1

0

The application is working much more reliably now, freezing issues still occur on occasion but nowhere near as often as before.

The issue appears to be related to the endpoint security (in this case, Cisco Security Agent) present in the environment I'm working in, application has been whitelisted and has has significantly rediced the instances of application hangs. The development system I work on does not have this endpoint security present, so it didn't show up in early stages of testing.

Thanks for all your feedback, I think there are still threading and garbage collection issues that need cleaning up, hopefully this should sort out the last few issues.

Daniel Snowden
  • 177
  • 1
  • 11
  • It is pretty unlikely that this was the true cause. A much more common reason is a threading problem in the SystemEvents class. Most commonly induced by creating your own splash screen. Deadlock occurs when the work station is locked and unlocked again, caused by SystemEvents firing the notifications on the wrong thread. – Hans Passant Sep 28 '12 at 10:09
  • The application does create a splash screen on startup, I can investigate how it's being created/destroyed. To the best of my knowledge, most of my users don't lock their workstations (given the number of times I've seen unattended workstations without a lock screen). Thanks for the pointer, I'll investigate in that direction. – Daniel Snowden Sep 28 '12 at 13:31
  • Splash screen makes use of Application.DoEvents(), from what I've found so far this does not seem to be a recommended approach. – Daniel Snowden Sep 28 '12 at 13:59
  • Use .NET's built-in support for splash screens. http://stackoverflow.com/a/393870/17034 – Hans Passant Sep 28 '12 at 14:01