I have a MS Word Automation C# program that is CPU hungry, basically it loops through records in a DB, opens Word, does a mail merge for the individual record, kills WINWORD.exe and then loops to the next record. When I run the program directly from Command Promtt, it will spike to 100% CPU while doing the mail merge, and then the CPU will drop and I am happy enough with this.
But when I schedule the task through Windows Task Scheduler (Win Server 2008 R2) the CPU spikes to 100% and remains constant and the program bombs out without finishing. Anyone have any ideas as to why there would be differences between running the program through Task Scheduler compared to manually through Command Prompt?
Perhaps it runs with another user when you schedule it? This can cause problems permissions? With environment variables? With default running folder differences?
Can you write a very simple word automation and see if it suffers from the same issue? This will let you know if the problem is the way you run it or what you run.
The comments other people wrote are very correct - you should log and see what causes the trouble.
Also - Killing WINWORD.exe can cause trouble you don't want to get into - like file recovery dialogs. I would recommend closing the document and word properly and wait for winword.exe to exit. Only if that fails kill it, but be ready to handle the trouble.
Vadim.
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.
I'm writing a C# program that is supposed to serve as an intermediate step inside a PDFCreator workflow, while a document is being printed.
It's a regular console program and it works fine when everything else is fine. The root problem, as I've discovered, is that there is currently (i.e. in PDFCreator v4.1.3) no way to cancel the print job from inside my program, should the need arise. PDFCreator simply doesn't check the exit code and continues onto the next step regardless of what happened in my program.
Having exhausted the obvious options I've naturally resorted to the only way I could think of: killing the parent process from inside my app. This works, sort of. It cancels the immediate printing process.
But the problem starts again when I try to print another document. As it turns out, PDFCreator remembers the pending printing task as soon as the workflow starts. If it is killed before finishing, it stays in its queue and is retried the next time. This means the the tasks accumulate when I kill them!
I haven't had any success trying to determine where exactly the PDFCreator stores these pending tasks, so I can't delete them. And so I'm stuck.
I've raised the issue on the PDFCreator forum, but the community there seems to be rather slow to respond.
I want to create a watchdog in c# in which the user selects a process by his pid a then the application watch he consumes of ram and CPU, after, if that application pass over the min consume then restart the process so his CPU and ram go again to 0.
my problem is when I want to restart the process, because I can get the process by his pid, but can't restart again because his want the path of application but I don't want restart entire application I only want restart that specific process
How I can achieve this?
Is possible to do this?
UPGRADE:
well, I think this understand better with an example, so here is:
First, imagine I want to watch the process with pid 12780 of the application Microsoft Edge.
Second, when this process exceeds the min consume of RAM or CPU what I set in my watchdog, that process should restart, begin with RAM and CPU in 0.
But here is the problem if I want to restart that process I can kill it, yes, but I can't start it after, Even if I set the full path of my application (in this case Microsoft Edge) it can't start again.
So, how I can restart only that process don't the full application?
Once you use How to get the full path of running process? to get the executable that was used to start the process you might be able to restart it.
However, if the executable was started in a specific way (think of a working folder, start parameters, environment variables, ...) it might not run the same way it was previously started. These special setting can be retrieved by using this answer: https://stackoverflow.com/a/5497319/563088 (commandline result)
The environment variables can be retrieved by using How to get the Process Environment Block (PEB) from extern process?
No, there is no way to do what you want.
If you wanted to restart a full application, that would be possible, but as you would potentially lose some data.
However, you say that you want to restart only a part of your application, say one of the processes, and that is not possible, unless it is specifically supported by the application itself - which is not generally the case.
Let the explain why.
When an application decides to create a new process, that process gets a copy (simplifying, but still) of the memory of the parent process at that moment, and after that both processes start diverging from that state, so it doesn't exist anymore.
Is it possible to create applications that allow you to restart it's processes? Yes. But most applications don't allow you to do that, and it's not even always clear what would mean to restart a process.
I have a C# winforms application, which communicates to various com data sources, and uses a threadpool for most of its backend processing. I have noticed that 2-3 times a day the winforms thread hangs for 20-30 seconds (visible in the ui, and that the com data stops for 20-30 secs). I have since written a simple task on the threadpool that tracks a heartbeat on the winforms thread to detect these instances, but am looking for a way to automatically trigger a full dump (not a mini dump), so that I can see what exactly the winforms thread is doing during these pauses.
Are there any simple command line apps that my background thread can call on it's own process to bind to the app as a debugger, generate the full dump file, and then allow the application to resume?
Is there a better way to debug this?
You can use the SysInternals procdump utility to generate dump files:
ProcDump is a command-line utility
whose primary purpose is monitoring an
application for CPU spikes and
generating crash dumps during a spike
that an administrator or developer can
use to determine the cause of the
spike.
Sounds like Process Dumper should do the trick.
What might cause an executing process from windows service to run slower than running from command line?
When I execute a process(another exe) from teh command line with admin rights, it is four times faster than when a windows service executes the same process. What could be causing this.
Permissions on directories and files are okay for the account. It runs successfully, just 4x slower. Need ideas on what to investigate to figure out the problem.
We have been using sysinternals processexplorer and not seeing anything.
Where is the advances tab with the ability to modify the "priority" to see if that is causing the problem?
In Windows background services may be given less priority, and that is configurable in the advanced tab of computer properties.
Assuming the priority of both applications is the same, you need to profile the app and see which calls are taking the most time. That should at least give you enough detailed information to come back and ask "why is this specific call running slowly" instead of "why is my app running slowly".
Download the sysinternals process monitor tool from www.sysinternals.com and then start tracing the application, that will show you what the process is doing in terms of registry / file access and will potentially show up what to look at when the delays are occuring.
If you have the debug symbols it can also give you the function call name in the dll / app that is being called, but even knowing what is occuring when a delay occurs and what dlls are in use, user mode or kernal gives you a good indication where to start.