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.
Related
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.
I’m developing a screen saver in C# .NET4.0 on VS2010 which needs to do a fair bit of processing before it actually shows screens (fairly complex database access). This is fine because the user is unaware that this processing is going on and then the full screen forms kick in when everything is ready. That is, unless we are running on Windows 8.
Searching on the Microsoft Community (http://answers.microsoft.com/en-us/windows/forum/windows_8-desktop/bubbles-screensaver-has-black-background/e0807324-5ca6-4abe-b6ba-716848b41ff5?page=4) reveals that a design change was made in Windows 8 that prevents screensavers from drawing over an image of the desktop. Any screensaver that previously drew over the desktop will instead draw over a plain background using your chosen “metro” background colour. Experimenting reveals that this background kicks in immediately the .scr file launches i.e. before any forms can be displayed. Hence tricks like displaying forms minimised or with 0% opacity don’t work because this simply reveals the plain background underneath.
The best I’ve been able to come up with is to display full screen plain black forms as first action when my code starts i.e. before any database processing or other screen construction takes place. Why try to replace a plain screen with another plain screen? Well, because the default Windows background colour seems to be blue. That’s blue as in BSOD blue which looks kind of alarming when it kicks in. So the best I can do for a Windows 8 user experience is a quick flicker of blue followed by 3-4 seconds of plain black before screens are populated with something meaningful.
This new behaviour from Microsoft is apparently “by design”. The fact that it doesn’t manifest itself in Preview mode is apparently an error which one supposes MS will tidy up later.
So my question is does anyone know any way around this so that I can continue to have the desktop showing until screensaver forms are ready to kick in?
I struggled quite a lot with a similar problem regarding this awkward design decision in win8.
I the end had to compromise but my search continues for a a bullet proof solution, when I have time.
Now what I ended up with is running a batch file after the monitoring system starts and have thread detect idle time and run that batch again.
#start /wait Bubbles.scr /s & rundll32 user32.dll,LockWorkStation
What this does is:
starts screensaver preview in fullscreen (this works in win8) and waits
on user action lock screen is show and user prompted for password
As I said it's a compromise until a find something better. Hope it helps
Updated to win10; try to use that cool scr and found same issue;
Try to trick ms restriction and found only one very long solution:
enable logging of screensaver invoked events;
here instruction via gpedit: https://superuser.com/questions/538146/run-a-batch-cmd-upon-screensaver
now you will able to start other comand or app when screensaver starting;
goto C:\Windows\System32
copy Bubbles.scr and rename to Bubbles.exe
then config task to run C:\Windows\System32\Bubbles.exe with argument /s (administration->taskcheduler)
use some windows screensaver and config to use 1 min or more; (or use 'runsarver' with empty options from upper link or create your own empty.exe and rename to .scr and install with right menu, etc)
Found cool app to customize hidden screensaver features: http://winaero.com/download.php?view.8
(work with small bugs but work as needed under win10)
All work fine one cons checkbox to lock PC must be unchecked;
If needed create own app to run Bubbles and on exit lock PC or bat file as above, etc;
hope people will have fun with my solution :)
I wrote a command line application in C#.NET that programmatically edits an existing powerpoint, and then starts the slideshow. The powerpoint is automatically configured to advance slides. The problem I am running into is that powerpoint will quit after 4 hours. Any ideas?
I think the computer is going to sleep or my other guess is that the program is causing a memory leak causing the program to crash out and close.
If the computer's gone to sleep or the screensaver has kicked in, waking it back up should put you back inside a running slide show.
If the slide show has actually stopped, I think you can rule out a sleeping computer/screensaver problem. In that case, it might be a problem with your program or it might be that PPT just craps out after some amount of time running a slide show. In some versions on some computers (nobody's ever been able to pin down the magic combo that triggers this).
To rule that out, start the presentation independent of your app and see if it runs w/o problems.
Like everybody already mentioned. Maybe the screensaver or when the Presentation is over, it closes. Maybe you could write your program in such way, that when it is on the last slide, to start again from the 1st one, which will actually create an infinite loop. If your goal is to only show the slide show.
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/
I am working with a COM component. There is a method that does this call to the component, and this method is used many times in my application, for each document to be processed, this method is called.
One weird thing happens sometimes suddenly, doesn't matter the amount of documents processed, it can happen after processing 60, 100 or 300 documents, or just don't happen. The weird thing: the call to the component doesn't return. The method stays stuck into the call line. Do you know any COM particularity that could be causing this problem?
From your question I get that your are doing COM automation with documents. If your COM object is a document processing application (Would MS Office be the right guess?) then it might be that the application is simply blocked by a popup.
This phenomenon happens quite frequently when you automate e.g. Word or Excel. You should do several things to work around this problem (I'm talking about MS Word here):
disable alerts by setting Application.DisplayAlerts accordingly
install the complete products to avoid Windows Installer popups asking for missing features
implement a time-out mechanism that will kill the application if any modal dialog is requesting user input. The reason for that is that there are certain types of popups which cannot be suppressed (If you need further information please ask).