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.
Related
I'm running a C# .net program under mono on Unix and I'm looking to control or change the behavior of the program after it has started.
I'll write the new functions into the program so I just need to trigger them without restarting the program.
I'm thinking I could allow the program to accept messages such as SOAP but feel this might be insure. It might be better if I could control the program locally from a separate program but i'm unsure of where to start.
Is there a way to give instructions into the program after it has started without a separate program or if the separate program is the solution does anyone know where to start with this?
Thanks!
I think you can create some UI form into your app and you will be able to controll your app by using this UI. If it isn't using you can hide that form to tray.
Or you can use second app and send some messages to your first application by using sockets, for example.
The way this is usually done in Unix programs (reference) is by sending the SIGHUP signal, and letting the program interpret this as a command to reload its configuration file.
Sending a signal can be done from a terminal or script with the Unix kill command (which is named this way because the default signal is SIGTERM to request the process to shut down itself).
This is how you send SIGHUP to a process with a certain PID:
kill -HUP [pid]
You can use the mono UnixSignal class to handle these Unix signals in a .NET program. One way is to use .WaitOne to wait for the signal on a dedicated thread. Another way is by regularly polling .IsSet or .Count.
I'm using Wince 6.0 and application is developed in C#. Application consists of a small GUI and some COM, TCP interfaces. Everything was working fine, I created new thread and everything went wrong. Now I cannot see GUI and cannot close application communication is continuously happening. I tried to format Nand Flash but it shows message cannot be formatted! what to do? How I can stop/delete this application?
Your application created a background thread that is not terminating. Use the Remote Process Viewer (under the Start Menu for Visual Studio 2008) to stop the current running instance. To prevent it from happening again, make sure you set IsBackground on the Thread to true. Generally I also have the Thread watch an instance boolean variable for a shutdown request as well. I set that variable on Dispose of the Thread's creator.
You can do clean booting to clears all memory, including persistent storage. you can find more on this in msdn
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.
Is there any good way to handle a forced exit in C#?
I have a formless C# application that talks to an LCD over serial. Once the application is running, the only way to kill it is with task manager. The trouble with this is that the program needs to turn the LCD off when it is done, and it doesn't look as if my Application.ApplicationExit event is ever fired in this condition.
Any ideas?
Once the application is running, the only way to kill it is with task manager.
My big idea would be to change this.
Stick an icon in the notification area that the user can use to shut your app down properly, or set it up so that running the app again will instead shut down an already-running instance if one exists, or any other way that sounds like a good idea.
Requiring a user to use Task Manager to shut down your application screams poor design.
Write a code in your program loop (with a timer perhaps) to read a file or a registry key. For example if a file at C:\YOURPROGRAM\CLOSEME contains text "closeme", close your program gracefully. Write another program that write that C:\YOURPROGRAM\CLOSEME file. So, whenever you want to shutdown your program, don't use taskmanager, instead, open second program.
Some options:
Write a separate process with a GUI that can start and stop the main process. For example, when you install the Apache web server on Windows the server itself is installed as a service. It can be started and stopped from the system services management panel, but it also comes with a "monitor" process that sits in the notification area, tells you whether Apache is running and lets you start or stop it manually.
If it's acceptable for your use-case, make the application a console application. You can register a handler for when the user presses CTRL+C (see Console.CancelKeyPress) that performs your cleanup before your process exits. This still won't let you handle someone killing the process from Task Manager, but it's very easy to do and might be good enough depending on your situation.
I have a console daemon that is run by a GUI application. When the GUI application is terminated I'd like to stop the daemon as well.
How can I do it in a gentle way on windows?
On Linux, I would just use SIGTERM is there a similar mechanism on windows for console applications?
To provide a bit more detail, the daemon app is written in python and the gui is written in C# & windows forms.
Define "gentle" :)
I'm assuming there is already a communication mechanism in place between the daemon and the GUI. Just introduce a "quit" command and send it.
If you want to kill the daemon even if it's busy doing something (or is frozen), use TerminateProcess().
To have the best of both, you can send "quit", then wait on the process handle for some time (WaitForSingleObject()). If the daemon process does not die in, say, 5 sec, then terminate it.
If the main thread of the daemon is prone to long periods of busy activity, have the daemon start a background thread that does nothing but waits for a named event. To signal that thread, open the event by name from GUI, then raise it. It's up to the daemon what to do upon event detection, but at least it will be a controlled shutdown.
Windows doesn't have signals in the way you're thinking.
There's some infrastructure for changing how the (faked) SIGTERM and SIGBREAK are handled by console apps, mostly SetConsoleCtrlHandler and GenerateConsoleCtrlEvent but both are only of use in the console application itself; not from outside.
It's worth noting that all a windows console app does when it receives a SIGTERM is call ExitProcess, nothing special. I'm not 100% on what the python equivalent is called, but whatever standard "exit" call should be equivalent.
I'd suggest writing some code to signal the console app, causing it to call ExitProcess itself. If that's not an option, use TerminateProcess (equivalent Process.Kill) to close the console process from the outside; attempting to "fake" an ExitProcess is dangerous for reasons noted in the MSDN article.