Develop Reference

Visual Studio is not stopping even after closing the app in debug mode

I am developing a windows form in c#. It is working fine but when I am running it in debug mode, I can see that visual studio is not stopping even after closing the form.
Below are some screenshots-
and
Probably my app is not releasing any resource. How can I deal with this problem? How to know which resource is still in use?

This can happen if you are using ApplicationContext instead of a form as the default message queue. If so, consider handling the form closing event of your form.

When I have seen this issue in the past it was because my application hasn't actually exited. This would most likely be because you or a dependency still has a thread running that hasn't stopped. You can tell if this is the case by looking at the task manager and checking for yourapplication.exe or yourapplication.vshost.exe. If either of these is open in the task manager you can kill it.
To fix this issue, make sure you call Abort() on all threads!

You might want to try looking at the Processes from Start Task Manager. That could give you some information if a third party process initiated by the application is still running.

Detect whether a Windows reboot was due to Windows updates

A few applications on my PC have been doing a detection wether a restart was done by Windows Update or not. This is observable due to them restarting after the automatic Windows Update reboot.
This is very helpful since those applications reload changes, even unsaved changes or restore tabs (in case of a browser). Examples of applications that do this:
Google Chrome
Microsoft Visual Studio
Microsoft Paint
In all cases the applications save the state they were in before the reboot.
(My PC actually woke up from a standby state automatically, and rebooted itself while instaling updates. Too bad it didnt go back to standby after doing this.)
My question is: How do I programmatically detect this kind of reboot? It seems to be reliably detectable before the reboot.
The question How can I get the Windows last reboot reason might seem like a duplicate, but no answer said anything about updates.
I code in C#, so an answer in C# would be helpful, though I can read C and C++ too, for example.

See Application Restart:
An application can use Application Recovery and Restart (ARR) to save data and state information before the application exits due to an unhandled exception or when the application stops responding
and:
or if the computer needs to restart as the result of an update.
The applications aren't detecting the restart reason after the fact - they've been architected to use this API. There isn't (so far as I'm aware) a managed API for this.
A couple of clicks away is Saving data and application state when application is being closed due to a software update. Again, no managed API.

Normally when Windows Reboots, it performs a restart by using shutdown.exe and the /g flag which saves the state of all registered running programs before restart. What you want to do is to Register your application for restart. There is a good sample with documentation for this by MSDN. It is available in C# and C++.

Debugging Windows Form Thread Freezes

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.

Handling a forced exit

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.

Is there a posix SIGTERM alternative on Windows? - (A gentle kill for console application)

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.