I have a console job for generting pdfs(to generate 10000 pdfs)
When executing through task scheduler I am facing error "window handle exception" after generating 1100 pdfs
When executing manually or from command prompt, job running successfully and generating 10000 pdfs.
Can any one suggest what may be the issue while running through task scheduler.
Suggest me any software to find any memory leaks, GC Collect, Windows Handles utilized.
What about attaching to the actual process when the task scheduler launches the app? In Visual Studio, Debug > Attach to Process. If the exception is happening right away, you can add a delay to your program so you have time to attach.
System.Threading.Thread.Sleep(120000); //Sleep for two minutes
That way when the exception is hit, your IDE will break on the line and might give you more detail in the inner exception.
If you app runs on a remote server you can install the remote debugging tools and still attach to the process.
Related
I am running a C# windows console application and passing in a couple of arguments via Task Scheduler. It runs all day loading flat file data created by other applications into SQL server. The program fails intermittently and I have Try/Catch logic that writes information regarding the exception using Console.WriteLine().
So basically I need to track down the location of the console output so I can take steps to eliminate the intermittent failures. I've had a good look around online thinking this must be a fairly common requirement to diagnose errors from Task Scheduler scheduled apps. My online search has revealed a couple of work around solutions but no direct answer as to where the console output goes when running a c# console application directly via Task Scheduler.
The two workarounds I have seen are:
(1) Get Task Scheduler to run a windows batch script (.bat file) instead of running the console app (.exe file) directly. Within the batch script use ">" or ">>" to redirect the console output to a flat file (e.g C:\app\myapp.exe arg1 arg2 > "C:\log\myapp_console_output.txt")
(2) A very similar solution is to get Task Scheduler to run the windows command line cmd.exe with /C option and passing arguments into cmd.exe to run my console app and also redirect the console output. e.g. something like:
cmd.exe /C "C:\app\myapp.exe" arg1 arg2 > "C:\log\myapp_console_output.txt"
While I acknowledge that the above workarounds may well help me to capture future failures it doesnt really help me to track down output from the intermittent failures that have already occurred. They also seem quite messy workarounds to achieve what I would have thought was a pretty common standard requirement.
Can anyone please confirm that the console output is definitely not retained somewhere when running a c# console app directly via Task Scheduler?
So I am trying to debug a process in MVC4. I send the POST request, watch it manipulate the database, etc etc. However, after I have seen the information I want to see, I click "Stop Debugging". In any typical GUI .NET application, I would think that the process would terminate, but it instead continues to execute. If I make any changes in the file and try to debug again, the breakpoints will not be hit because the files are not out of date from the previously ran process which is still running. I have 2 choices at this point - let it run or kill the w3wp.exe task with the Task Manager in order to continue debugging.
I have tried to click Debug -> Terminate All, but the process still continues to execute. I know this because I attach to the process (Debug -> Attach to Process) and it pauses at one of my many breakpoints throughout its execution.
Let it be mentioned that I am using Google Chrome to send the POST requests to the Controller, so it may not be terminating because I am not using IE - however, I do think that there is a better solution then using the IE browser.
In order to work around this, I have to go into the Windows Task Manager and kill the IIS process (w3wp.exe), which seems downright messy. Any ideas?
If I make any changes in the file and try to debug again, the breakpoints will not be hit because the files are not out of date from the previously ran process which is still running.
Once you modify any code file you require to re build the solution and then again Debug -> Attach to Process.
Please also note that Stop Debugging does not mean that it will kill process always. It will kill only Visual Studio Web Development Server or sometime IIS Express process with Visual Studio. Here you mentioned w3wp.exe. While this process is managed by IIS.
Couple more graceful ways to restart your w3wp worker process:
in command line, run "iisreset"
in IIS Manager console, select the corresponding application pool and click "recycle"
For a graceful shutdown of a long-running business logic, try Application_Shutdown event in global.asax.
For not-so-graceful approach, ThreadPool may help you - threads on it are marked as Background and thus Windows won't wait for them to complete when main thread of w3wp exits. However this approach doesn't always work, because 3-rd party libraries (especially networking) may create non-background threads that, again, will delay shutdown.
For even faster and dirtiest, use Environment.Exit, triggered by some debugging-only event. http://msdn.microsoft.com/en-us/library/system.environment.exit(v=vs.110).aspx
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.
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.