1

We have got an unexplained issue in a C# windows forms application that we have been using for years and that we do changes on regular cycles for features and bug fixes. The issue is we have an application freeze that happens soon after application is used for a while. (I don't want to say start-up as there is a number of things it does and never freezes on the startup routine).

After much trouble shooting we have narrowed it down to the very first time a datagridview object is used with or without database involvement. i.e even if we display a datagridview from a datable that we build in static code (as a test) it will hang for a number of seconds very noticbles GUI stops, it does differ.(ages in application time). After that initial hang it does not happen again for that application session. You go into the exact same module again same code no state has changed and it performs quickly.

The application is used in a kiosk environment deployed to windows 7 embedded with write filters on, there are very few processes running as explorer.exe is not running and neither any of the other processes its starts. We only have a few flavours of different hardware, this is a "all must be that same type of system". We never ever see the issue manifest on any developer machines only deployed. The application is targeting .Net 4.5.2.

Most of the Designer(Automated) code looks like this for the datagridview should be stock standard as VS writes it.

private System.Windows.Forms.DataGridView datagridView;
this.datagridView = new System.Windows.Forms.DataGridView();
((System.ComponentModel.ISupportInitialize)(this.datagridView)).BeginInit();
this.datagridView.AllowUserToAddRows = false;
this.datagridView.AllowUserToDeleteRows = false;
this.datagridView.ColumnHeadersHeightSizeMode = 

System.Windows.Forms.DataGridViewColumnHeadersHeightSizeMode.AutoSize;
this.datagridView.Location = new System.Drawing.Point(31, 128);
this.datagridView.Name = "datagridView";
this.datagridView.ReadOnly = true;

this.datagridView.RowTemplate.DefaultCellStyle.Font = new System.Drawing.Font("Microsoft Sans Serif", 9.75F, System.Drawing.FontStyle.Regular, System.Drawing.GraphicsUnit.Point, ((byte)(0)));
this.datagridView.Size = new System.Drawing.Size(732, 220);
this.datagridView.TabIndex = 144;

We mainly use the datgridview by creating a datatable and adding it as the source. The custom classes are often only data structures, so they don't access DBs or anything simple primitive types grouped together.

DataTable table = new DataTable("tableName");

DataColumn c0 = new DataColumn("col1");
DataColumn c1 = new DataColumn("Col2");

table.Columns.Add(c0);
table.Columns.Add(c1);
foreach (CustomClass item in items)
{
    DataRow row;
    row = transTable.NewRow();
    row["col1"] = item.something;
    row["col2"] = item.something;
    transTable.Rows.Add(row);
}

datagridView.DataSource = table;

The only other point to add is that, besides us thinking we are going mad, to mention is that this might have (I say might because we have not been able to prove it.) we might have done a roll up package on the visio environment to rollup 5 on the actual coding machines. Visio Studio 2013 is being used, but I think this is grasping.

Any ideas?

Thank you in advance.

user3725237
  • 131
  • 2
  • 10
  • How many items do you have?? Also, I would suggest to bind the "items" directly to the datagrid, see if it's faster – User2012384 Mar 17 '16 at 07:08
  • It should be simple to track what specific functionality is causing free and then fix it accordingly. Use tracing or logging to record time. On Form load. Debug.Writeline(System.DateTime.Now.ToString("yyyy-MM-dd hhmmss"); This should be used before and after any method call or expensive methods only. See which one is taking longer time. Most likely it should be either loading data from database or iterating this data. I just given suggestion so, use logging or tracing as per convenience. – Munawar Mar 17 '16 at 07:19
  • When tracking time in code use the [Stopwatch](https://msdn.microsoft.com/en-us/library/system.diagnostics.stopwatch(v=vs.110).aspx), not a datetime. see [this](http://stackoverflow.com/questions/28637/is-datetime-now-the-best-way-to-measure-a-functions-performance) question for more details as to why – Nick Otten Mar 17 '16 at 07:25
  • Taking the above into consideration why would the second time we call the same code and data be quicker?The number of items is not relevant as we can have even had it with 0 rows. we are stumped on this one. – user3725237 Mar 17 '16 at 10:24
  • @user3725237 We had a similar issue on some of our homegrown controls. First init was extremely slow, I beleive it was JITcompiler and loading libraries into cache. Our solution was to load these objects in a background thread at startup. Then when we created the real objects the 2nd time they would work fine. Its a hack. – GER Mar 17 '16 at 15:35

0 Answers0