Windows Application - Addtional tips to debug lock ups?

App stops responding periodically in my production environment, though

Page 1 of 1

9 Replies - 4947 Views - Last Post: 11 January 2008 - 08:54 AM Rate Topic: -----

#1 EarlyMorningRiser  Icon User is offline

  • New D.I.C Head

Reputation: 0
  • View blog
  • Posts: 6
  • Joined: 17-December 07

Windows Application - Addtional tips to debug lock ups?

Post icon  Posted 03 January 2008 - 10:43 AM

Hi All,

This is my first plea for help and boy do I need it :D.

Here are the basics:
  • C# 2.0
  • Windows Application, deployed via Click Once (or click 4 times, depending on how you look at it:P ).
  • Connects to SQL Server 2000 using typed datasets
  • This is a business application that displays data in Infragistics UltraWinGrids 7.3 and allows the user to Insert/Update/Delete within those grids.
_

The application normally works just fine, but from time to time it will simply stop responding Ė requiring the user to use task manager to ďend taskĒ on the application.

Iíve been able to duplicate this ďfreezingĒ of the application on a few machines (usually a server that I have access to via a VM session) by opening the app and then walking away from it for a few hours. Half the time, when I return, the application has stopped responding.

Things Iíve done to trouble shoot:
  • Duplicate the bug on a machine and then check the Application Logs for errors. No errors are listed for my application.
  • Iíve tried to duplicate the lockup within Visual Studio 2005 in Debug mode, but the application does not lockup there.
_

Things Iíve assumed:
  • Iíve used the same Infragistics controls heavily in other windows applications with no issues; so I do not believe they are the issue.
  • The freezing does not occur during a database request; so Iíve ruled that out.
  • Iím using BackgroundWorker to perform a single task asynchronously, but that task finishes before the freezing occurs; therefore Iíve ruled out BackgroundWorker being the culprit. Just to be sure, I call BackgroundWorker.Dispose() within the RunWorkerCompleted event.
_

Does anyone have any additional debugging tips that I could use?

Thanks!

-EMR

Is This A Good Question/Topic? 0
  • +

Replies To: Windows Application - Addtional tips to debug lock ups?

#2 PsychoCoder  Icon User is offline

  • Google.Sucks.Init(true);
  • member icon

Reputation: 1641
  • View blog
  • Posts: 19,853
  • Joined: 26-July 07

Re: Windows Application - Addtional tips to debug lock ups?

Posted 03 January 2008 - 11:28 AM

Well if it happens after long periods of inactivity then more than likely your connection to your SQL Server has timed out. You have 2 options, use a timer than checks the State Property of your SQL connection and reconnects if need be.

Use Application.DoEvents so other processes do not have to wait for your timer, or you could also run it in its own thread. If the State of the connection is closed then reopen the connection. This just may stop some of your hanging after long periods of inactivity
Was This Post Helpful? 0
  • +
  • -

#3 EarlyMorningRiser  Icon User is offline

  • New D.I.C Head

Reputation: 0
  • View blog
  • Posts: 6
  • Joined: 17-December 07

Re: Windows Application - Addtional tips to debug lock ups?

Posted 03 January 2008 - 12:24 PM

View PostPsychoCoder, on 3 Jan, 2008 - 11:28 AM, said:

Well if it happens after long periods of inactivity then more than likely your connection to your SQL Server has timed out. You have 2 options, use a timer than checks the State Property of your SQL connection and reconnects if need be.

Use Application.DoEvents so other processes do not have to wait for your timer, or you could also run it in its own thread. If the State of the connection is closed then reopen the connection. This just may stop some of your hanging after long periods of inactivity


Hmmm, to tell you the truth, except for one or two connections, I'm not managing the connection whatsoever - though even those rare connections are being handled through Microsoft Data Access Application Block's SQLHelper class.

For example, when filling a particular grid, I do the following. I assumed the .Net 2.0 framework handled the connection for me. Would that be a correct assumption?

		private void Grid_LoadStatusSummary()
		{		  
			  _statusSummaryTA1.Fill(_reports1.StatusSummary);
			  gridStatusSummary.DataSource = _reports1; 
		}


Was This Post Helpful? 0
  • +
  • -

#4 PsychoCoder  Icon User is offline

  • Google.Sucks.Init(true);
  • member icon

Reputation: 1641
  • View blog
  • Posts: 19,853
  • Joined: 26-July 07

Re: Windows Application - Addtional tips to debug lock ups?

Posted 03 January 2008 - 12:42 PM

Theres nothing in the Framework that keeps a connection open during inactivity. If theres no database activity the database server will disconnect you, so before doing any DB work check the state of the connection
Was This Post Helpful? 0
  • +
  • -

#5 tody4me  Icon User is offline

  • Banned
  • member icon

Reputation: 12
  • View blog
  • Posts: 1,398
  • Joined: 12-April 06

Re: Windows Application - Addtional tips to debug lock ups?

Posted 03 January 2008 - 02:03 PM

[rant]
I never let the framework handle the connection thru the use of the dataadapter. The whole point of using the connection in that way is to be disconnected from it. If you want to manage the connection yourself, do so, otherwise use it in the disconnected state that Microsoft wants you to use... and don't whine about it being disconnected.
[/rant]
If you control it yourself, it's a lot more steps with the .NET framework. You can use a connection object, and command objects separately from the Dataadpter and Dataset built in features. If you want to leave the connection open, you can do so for the duration of the scope of the variable. Personally I never use the dataadapter and datasets in my applications.
Psycho is right about the server disconnecting you if there is inactivity, but if the connection is active within 30 seconds you are dealing with the data in a live state.

This post has been edited by tody4me: 03 January 2008 - 02:06 PM

Was This Post Helpful? 0
  • +
  • -

#6 EarlyMorningRiser  Icon User is offline

  • New D.I.C Head

Reputation: 0
  • View blog
  • Posts: 6
  • Joined: 17-December 07

Re: Windows Application - Addtional tips to debug lock ups?

Posted 03 January 2008 - 04:00 PM

View Posttody4me, on 3 Jan, 2008 - 02:03 PM, said:

[rant]
I never let the framework handle the connection thru the use of the dataadapter. The whole point of using the connection in that way is to be disconnected from it. If you want to manage the connection yourself, do so, otherwise use it in the disconnected state that Microsoft wants you to use... and don't whine about it being disconnected.
[/rant]
If you control it yourself, it's a lot more steps with the .NET framework. You can use a connection object, and command objects separately from the Dataadpter and Dataset built in features. If you want to leave the connection open, you can do so for the duration of the scope of the variable. Personally I never use the dataadapter and datasets in my applications.
Psycho is right about the server disconnecting you if there is inactivity, but if the connection is active within 30 seconds you are dealing with the data in a live state.


Ah, based upon your rant ( :D ) and since I'm not taking any additional steps to modify the code generated by the tableadapter when its plopped within the ".xsd", I'm handling my datasets in a disconnected state - i.e. grabbing the data and disconnecting for each and every database call. Therefore I shouldn't be having issues with my connection being disconnected due to inactivity. Right?
Was This Post Helpful? 0
  • +
  • -

#7 tody4me  Icon User is offline

  • Banned
  • member icon

Reputation: 12
  • View blog
  • Posts: 1,398
  • Joined: 12-April 06

Re: Windows Application - Addtional tips to debug lock ups?

Posted 04 January 2008 - 08:33 AM

correct.

This post has been edited by tody4me: 04 January 2008 - 08:33 AM

Was This Post Helpful? 0
  • +
  • -

#8 EarlyMorningRiser  Icon User is offline

  • New D.I.C Head

Reputation: 0
  • View blog
  • Posts: 6
  • Joined: 17-December 07

Re: Windows Application - Addtional tips to debug lock ups?

Posted 08 January 2008 - 01:53 PM

View Posttody4me, on 4 Jan, 2008 - 08:33 AM, said:

correct.


So if the connection isn't causing the lock up, I guess it could be the BackgroundWorker that is causing the problem.

Has anyone else experienced issues with BackgroundWorker? I've used it in other applications, but have not had this freezing issue before.

-EMR
Was This Post Helpful? 0
  • +
  • -

#9 killnine  Icon User is offline

  • D.I.C Head

Reputation: 19
  • View blog
  • Posts: 161
  • Joined: 12-February 07

Re: Windows Application - Addtional tips to debug lock ups?

Posted 11 January 2008 - 08:44 AM

View PostEarlyMorningRiser, on 8 Jan, 2008 - 01:53 PM, said:

View Posttody4me, on 4 Jan, 2008 - 08:33 AM, said:

correct.


So if the connection isn't causing the lock up, I guess it could be the BackgroundWorker that is causing the problem.

Has anyone else experienced issues with BackgroundWorker? I've used it in other applications, but have not had this freezing issue before.

-EMR



Why would the background worker cause your whole app to freeze? That's the reason I use background workers, because they separate a work thread from the UI, keeping the UI from locking up. The symptoms you describe make me hesitant to say its a BW issue.
Was This Post Helpful? 0
  • +
  • -

#10 EarlyMorningRiser  Icon User is offline

  • New D.I.C Head

Reputation: 0
  • View blog
  • Posts: 6
  • Joined: 17-December 07

Re: Windows Application - Addtional tips to debug lock ups?

Posted 11 January 2008 - 08:54 AM

View Postkillnine, on 11 Jan, 2008 - 08:44 AM, said:

Why would the background worker cause your whole app to freeze? That's the reason I use background workers, because they separate a work thread from the UI, keeping the UI from locking up. The symptoms you describe make me hesitant to say its a BW issue.


Since my last post, I pulled the function calls out of the BW and now call them within my form's load event. Even though I'm using the exact same code, the freezing issue has not happened again (to my knowledge to date). Since the execution time is only 5 or so seconds, the client is okay with the change.

I do not know why the freezing issue no longer occurs without the BW for this particualr implementation, but I plan to continue making use of BW in other places and applications.
Was This Post Helpful? 0
  • +
  • -

Page 1 of 1