Develop Reference

Terminating w3wp.exe after finishing debugging in Visual Studio 2012, MVC4

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

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.

.Net SerialPort still locked after application is killed

I have an application which calls SerialPort.Open() ...
This works fine and data is read/written through the port.
However if a user decides to kill the Application through the TaskManager the application will close without calling my destructor calling SerialPort.Close().
This in turn (only sometimes) causes the following error:
Access to the port 'COM2' is denied.
This occurs on re-startup of the application.
I've read enough posts to know that this wouldn't happen if .Close() was properly called.
So far I have handled this by having a timer which reattempts the .Open().. which eventually succeeds (that is I think it does most of the time).
My question is this:
Is there a DLLImport method which will allow me to free the Comm port resource?

I rubbed my crystal ball and it revealed that you are using a USB driver that emulates a serial port, that the user decided it was a good idea to kill the process because she jerked the USB connector out of the socket and that she is running a pre-Vista version of Windows.
Roughly any two combinations out of that list. Yes, doesn't work, you cannot kill a process when it has a kernel thread going that is completing an I/O request that cannot finish. You can tell from TaskMgr.exe when you use View + Select Columns and tick Handles. The process will zombie with one handle opened. Won't close until the driver actually lets go. Won't happen, USB drivers suck like that.
Starting the program again will bomb, the first instance of the process still has the port opened. Access denied.
Tell the user to keep her hands off the connector. Or buy another one from a different manufacturer. You can help by adding a "Safely Remove Hardware" menu option to your program. That calls the SerialPort.Close() method. Call Sleep(2500) and display a message box that it is okay to unplug it.

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.

What might cause an executing process from windows service to run slower than running from command line(admin)?

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.