Hi Guys I have a winform which acts as an interface for a database. At some point the user will select a directory which contains 30 to 40 files. These files will have to be inserted into the database as raw data. That is as is. Then that raw data will interrupted and fixed up. Once this is done the user can dump the fixed data to one excel file. This works perfectly when I am running it in visual studios in release or debug mode. However when I try to run it form outside of visual studios (that is from the bin / release file) it stalls then becomes non-responsive. I and the user don't mind if it becomes slow (about 60 thousand records are printed). However why does it stop working. I figured the part where it stops responding and it doesn't seem like its deadlocked? Any ideas of how to improve it would be appreciated. I also requested that my application runs with high priority but that still doesn't help.
You need to do all that processing in a separate thread. I would recommend using the BackgroundWorker.
Here is information about the class - http://msdn.microsoft.com/en-us/library/system.componentmodel.backgroundworker.aspx
Here is an example of how to use it - http://fernandof.wordpress.com/2007/04/04/implementing-multi-threading-in-winforms-using-the-backgroundworker-class/
Related
My program uses C# and interop to create complex Excel documents. The generation process runs against an invisible background instance of Excel. One particular interop call sometimes runs incredibly slowly. Most individual interop commands take just a few milliseconds, but assigning to the Font.Bold property can sometimes take 40-60s.
The 'slow' runs of this line of code are intermittent but follow a pattern. After a slow run, all successive runs will be fast for about 7-10 minutes, after which the next call will be slow. It is like there is a 'timer' which is reset on each slow run. While the timer is counting down all interop runs smoothly. Once the timer has expired, the next assignment to Font.Bold will be slow. It will be slow no matter whether the call comes immediately after the timer has expired, or if I leave the computer idle for a couple of hours and run the code again.
Restarting my program has no impact on this invisible timer. In other words I can run my code, wait for a slow run, and then exit the process. Then if I immediately start my code again, I will get fast runs for the next 7-10 minutes. I have ensured there are no instances of Excel or other Office apps running, including hidden ones lingering in the background. The only thing which 'resets' the timer is restarting my machine. It is like the timer exists on a system level outside of Excel or my code.
This applies in Debug and Release solution configurations, running with and without the debugger attached.
There is one other crucial piece of evidence. If I manually open an instance of Excel from the Start menu (i.e. driving it using mouse and keyboard rather than interop), there are repro steps for what looks like the same problem.
Create blank workbook
In the Home ribbon click Cell Styles
Right-click a style and click Modify...
Click the Format... button
Excel completely freezes for 40-60 seconds, then finally the dialog opens and behaves as normal
The freeze in the final step follows the same 7-10 minute cooldown behaviour as when I assign to the Font.Bold property in interop. The invisible 'timer' in the background is apparently shared between the Excel dialog and the interop code. In other words a slow run in interop will be followed by 7-10 minutes of Excel not freezing. And a frozen dialog in Excel is followed by 7-10 minutes of fast interop.
I have phrased this question as one about interop since that is how I first came across the problem. It may in fact just be a general Excel problem or bug, but it was only after many fruitless days of debugging my code, trying desperate garbage collection/Marshal.ReleaseComObject nonsense etc. that I discovered the Excel GUI symptom.
What is causing this slowness and what can I do about it?
Windows version: Windows 10 Home 21H1 (19043.2006)
Excel version: version 2209 Build 16.0.15629.20152 64-bit
I have a partial answer or at least explanation to my own question.
My deduction is, Excel hangs while trying to contact an offline printer. Work around the problem by setting the Windows default printer to one which is available.
The key was finding a post (archive 1, 2) where someone describes the Excel freezing dialog symptom, and suggests changing the system default printer. My Windows default printer was set to a network-attached HP LaserJet which Windows Printers & scanners says is Online even though it's not been connected to the network or powered on in months. Changing the default printer to Microsoft Print to PDF eliminated the hangs both from interop and the live usage of Excel GUI.
This is speculation, but I imagine when the freeze happens Excel is trying to contact the printer, perhaps to determine which device fonts it supports. The Excel GUI thread (!) is ultimately blocked on a network call which times out. The 40-60 seconds is presumably the network timeout on trying to reach the printer, and the 7-10 minute 'timer' is an actual OS-wide timer which says 'if connection to a network printer fails assume it is unreachable and don't try to contact it again in this interval'.
I've tried on another machine with a different offline default printer, but I could not reproduce. Presumably the problem is only with specific printer drivers.
I'm not sure what can be done to prevent this problem in the wild when the code is running on other systems. Hopefully the problematic configuration is rare. I feel the blame could equally lie with Excel, a printer driver, or the Windows OS, so a bug fix seems unlikely.
We have a Winforms application that is located on a server.
In other words, the people start the application by a shortcut that points to the executable on the intranet. There where never any performance issues with this approach up till now.
The problem is that over a VPN the application loads extreme slow.
It takes 1 minute and 40 seconds just to show the main form.
All code in the main form in the Load and Show events are disabled to test the performance, and it still takes this long time just to load the form.
Also the mapped directory is set a trusted by windows.
The question is what could cause this slow loading over VPN ?
It seems to me that just loading the main form without any code is already slow.
The application uses DevExpress so there are lots off DLL's to load. Can that be the cause of this problem ?
I know this is not a good question for SO but I need some ideas in which direction to look for this problem.
I found this question here but the problem there was due to a bug in their code so it does not helps me
Deploy the application as ClickOnce. When the application is first run it will be slow as the application will download, then install in the Users[user]\AppData folder. From then on as long as the application hasn't been redeployed it'll run from the local copy after checking with the network deployed version.
You can choose to have the application install locally so it has a start menu entry and can be removed with add/remove programs or you can have it only available online which means there's no start menu entry and it should be started from the setup.exe (I would assume this is the option you would want to go for so your users still start it from the VPN network location.
I have written a rather large application running in the background, doing dome stuff and processing some data.
Now the problem is, for some time the application runs fine. But when I check a day later for example the Backgroundworker of my application seems to loop or stuck. There is no error message and the UI of the application is still running fine. It just stops processing data.
Specifically for this case I added a simple website for myself where the Backgroundworker reports the current DateTime. So when the DateTime on the website is somewhat current I know it is running fine. But when it's in the past I know my application is stuck.
The issue comes after a undefined time. It can be 10 minutes or 90 Hours.
Now for debugging: Is there a way in Visual Studio that I can see where the application currently is? That would make debugging a whole lot easier. Otherwhise I would have to set breakpoints on trial-and-error base...
Best regards,
Julian
you have two options:
1.- attach the debugger as it is suggested already and check the code, but if the application runs fine for a long time, it is not the best idea.
2.- log files. Create log files to track your application.
What I would do: I would combine both options. Add log files to check results and when the application reached certain points (to decide by you) and then, once I know more or less where the problem is, use the debugger.
Good luck
Edit:
I fully concur with this answer but would add that you may benefit from making the background worker pass key position information back to the UI as it enters and leaves particular sections so that you can simply interrogate this when you attach. Since the problem can take several hours to manifest itself you could end up with a lot of log file to wade through unless you use a rolling log with limited entries, continuously setting a telltale would at least allow you to know approximately where to put the breakpoint at that moment.
I'm now working on some pretty big application with really nasty code. The problem is that from time to time the whole GUI of the app is freezing and stops responding (and after some time Windows wants to take the app down). I have a really big problem to even look where to debug the app, mostly because when this thing happens and I pause it in the VS debugger, it highlight the line:
CardWindow.ShowDialog();
It's not helpfull at all. Also when this thing happens it tends to grow the app size in the memory, ocasionally throwing OutOfMemoryException.
I also checked whether it might be some kind of an infinite loop in one of created threads, but VS shows me that only the main thread is active, and the rest are either ended or not running at all (the thread implememtation is also really poorly written).
The application uses remote objects within local networks, and some threads are used to transfer photos and other data from clients to server, but I don't know how to check if this is what it's causing it. But when the server app hangs, the clients are still fully capable to connect with it.
Short info of how it's made: the app uses Firebird engine to store its data. The DB is on the server machine, and the clients are connected via local LAN to it using standard Firebird C# library, and the app instances communicates with each other using remote object (the server is also a client).
It's the second week of debugging and I'm getting pretty desperate as I'm getting out of ideas of even how to check what's wrong. The fact that the bug appears randomly also doesn't help.
Can anyone give me some ideas of how to find a trace of this bug?
Using C# .NET 4.5 and WPF with Visual Studio Ultimate 2013 and Firebird 2.5
I'd suggest using a profiling tool to assist in finding the problem
What Are Some Good .NET Profilers?
In addition to #DerekTomes. The System.Windows.ShowDialog method, Described in: Window.ShowDialog Method, all other windows are disabled and return only when the window is closed. Check to make sure the window is eventually closed(this.Close() in the CardWindow.xaml.cs or whatever .cs file) or use CardWindow.Show() instead of CardWindow.ShowDialog() so other windows remain running while the CardWindow is running.
I finally figured it out.
When the function that usually hanged the app after 30th run launched, I could see that some of it ran (the window's title changed as it was supposed to). I've found this function and after every single line put:
this.Title = "1";
SomeFunction();
this.Title = "2";
AnotherFunction();
this.Title = "3";
// and so on
I localized what was causing the problem; there was a function that changed the GUI significantly (lots of foo.Visibility and foo.Opacity) and ran in some weird loop. It was fine for the first 20 times to run it, but after 30th it slowed down the app, and after 40th - caused crash.
It now runs only once when it needs to and the problem does not appear. I suppose it caused GUI memory overflow of some kind.
Anyway, thank you for your answers - I ran memory profiling, but it slowed my app down to that point it was impossible to use it.
Is it possible to rise a cmd.exe processes from the silent background mode to the visible foreground so I can LOOK at them?
Problem Background:
I'm using VS2008 working with a very large solution containing C#, C++, and Fortran. Occasionally (a few times a day) when building my project the build hangs and does not allow me to do anything in VS (resulting in the need to kill the process). I have checked the output box, and there appears to be nothing helpful there.
Possible Cause:
I am thinking that maybe one of the cmd.exe windows that are spawned in the background may be waiting for some form of input, but to investigate I need to see those windows.
Search for Other Causes/Solutions:
If not this, is there a way to try to check and see if there is something else going on? Is this a problem anyone else is having. (Note: killing VS and reloading often fixes the problem first try, and the build process takes less than 15 seconds.)
If stopping and restart fixes the problem, I guess it's not an input problem.
For example when my build project halts, it's always the VB6 project or SVN that are upset. (strangely the VS projects always work fine).
Once one of these halt, they halt until they are fixed. Thus for the VB projects run and work-out what the model dialogue is saying and fix it. or on SVN it usually need a clean-up run on the directory.
The intermittent nature suggests some sort of timing issue, like a file been lock open etc.
You could attach another copy of visual studio to the cmd.exe and see where it's at. Not sure if you can get symbols for it, so it might be fun to diagnose.