The new AspNetCoreModule module just like IIS somehow detects when an application crashes and restarts it. How is it implemented? Just by asking Windows if a process still exists or something more subtle (like a RPC call maybe)? What happens if a process just hangs resulting in HTTP timeouts?
When AspNetCoreModule creates the child process, it immediately check the whether the child process is up by connecting it via socket and exist code. If the child process is up, the module calls RegisterWaitForSingleObject with processInformation.hProcess and some callback, so that if child process exists, the callback will be called. In the case, the child process hangs, the module will return 502 back to the client after timeout and will not kill the child process.
Related
I am trying to figure out who killed my process from taskmanager. Since taskmanager uses TerminateProcess and to Terminate a process remotely, it opens a Process Handle first.
So I am trying to look for UserMode ways to get a notification when a remote process tries to open a handle to my process.
I am aware there are possible solutions for this from Kernel mode using Driver Callbacks etc. But currently I am looking for User Mode possible solutions
I am trying to figure out who killed my process.
There is no official way to do that.
I am trying to look for UserMode ways to get a notification when a remote process tries to open a handle to my process.
There is no such notification in user mode.
The only way I can think of doing this is to use SetWindowsHookEx() to globally inject a custom DLL into every running process, and then you can have that DLL manually hook OpenProcess() directly, such as with a detour.
The hook can then compare the function's dwProcessId parameter value against your app's current process ID, which you can store in a block of globally shared memory while your app is running, such as via CreateFileMapping()+MapViewOfFile() (see Sharing Files and Memory and Creating Named Shared Memory).
i've got problem with tuxedo tmshutdown command. One of processes still runs (with huge cpu usage) though tmshutdown stops it succesfull. There is also one opened IPC shared memory which i can close when I kill existing process. There are other servers but only this one is problematic. Is it possible that the problem is in code (tpsvrdone is exiting without errors)?
Tmshudown normally sends a SIGTERM signal to tuxedo serves unless you use -k KILL (which sends a SIGKILL)
If the source code of the Tuxedo server implements a handler of the signal, you could get the behavior you explained.
http://www.thegeekstuff.com/2012/03/catch-signals-sample-c-code/
Also, if it is not possible to shutdown a server, or remove a service advertisement, a diagnostic is written on the ULOG.
I am trying to attach debugger(windbg,ollydbg) to running process but there's an error saying Debugger is already attached then how can i detach that unknown debugger from that process?
Process includes multi thread, one thread can be attached to debugger and other can't.
The process might be spawning a second process which attaches to the first process for debugging using DebugActiveProcess() in order to prevent people from debugging the first process. Keep in mind that a process cannot debug itself using this method, so a second process must be spawned to do this.
Things you could try:
Use any sort of process monitor or even task manager to figure out what process the first process spawns
Inject code into the second process to call DebugActiveProcessStop() to detach it from the first process
Hook DebugActiveProcess() (kernel32.DebugActiveProcess, ntdll.ZwDebugActiveProcess, or in kernelmode) and redirect it to attach to a different dummy process
Kill the second process
Prevent the second process from getting a handle to the first process with the needed permissions - DebugActiveProcess() will then fail
Use alternative debugging methods (Cheat engine with VEH debugging for example) that don't use the normal debugging API's and therefore bypass this problem
What is the difference between killing an application using the close button and ending the process from the Task Manager?
I am aware of the fact that hitting the close button posts a WM_CLOSE message in the message queue, but I don't know what happens when we kill a process from Task Manager (or any similar application like Killbox or Process Explorer).
When you click the "X" button in the title bar of an application's window, that sends the window a WM_CLOSE message. This is a "graceful" shutdown—the application processes the message, handles any necessary cleanup tasks, and can even refuse to shut down if it so desires (by returning zero in response to the message). WM_CLOSE is simply a request that the window or application terminate; the window is not destroyed until the application itself calls the DestroyWindow function.
When you press the "End Task" button in Task Manager, Windows will first try to send the application (if it is a GUI application) a WM_CLOSE message. In other words, it first asks nicely and gives the app a chance to terminate itself cleanly.*
If you fail to close in response to that initial WM_CLOSE message, the Task Manager will follow up by calling the TerminateProcess function. This function is a little bit different because it forcefully terminates the application's process and all of its threads without asking for permission from the app. This is a very harsh method of closing something, and should be used as a last resort—such as when an application is hung and is no longer responding to messages.
TerminateProcess is a very low-level function that essentially rips the user-mode part of a process from memory, forcing it to terminate unconditionally. Calling TerminateProcess bypasses such niceties as close notifications and DLL_PROCESS_DETACH. Your application does not have the ability to refuse to close, and there is no way to catch/trap/hook calls to TerminateProcess. All user-mode code in the process simply stops running for good. This is a very unclean shut down procedure, somewhat akin to jerking the computer's power plug out of the wall.
* Note that this only true if you use the "Applications" tab of Task Manager to kill the application. If you use the "Processes" tab, this step is skipped and the TerminateProcess function is called immediately. This distinction is reflected in the caption on the respective buttons. For the "Applications" tab, the button is lableled "End Task"; for the "Processes" tab, the button is labeled "End Process".
Killing the process with WM_CLOSE simply signals the process with the message and allows the target to handle the message and exit gracefully. Alternatively, the process could choose not to exit in its WM_CLOSE handler.
Killing the process via task manager will do so with TerminateProcess which is far harsher:
The TerminateProcess function is used to unconditionally cause a
process to exit. The state of global data maintained by dynamic-link
libraries (DLLs) may be compromised if TerminateProcess is used rather
than ExitProcess.
This function stops execution of all threads within
the process and requests cancellation of all pending I/O. The
terminated process cannot exit until all pending I/O has been
completed or canceled. When a process terminates, its kernel object is
not destroyed until all processes that have open handles to the
process have released those handles.
TerminateProcess is asynchronous;
it initiates termination and returns immediately. If you need to be
sure the process has terminated, call the WaitForSingleObject function
with a handle to the process. A process cannot prevent itself from
being terminated.
If you close an application using the close button you let the application to perform necessary closing tasks if any. If you kill a process from task manager there is no chance for application to perform those tasks, you just terminate the application without informing.
I'm working on a C++ Windows application, that runs as a process but not a windowed application (does not have WndProc). It has it's own message loop, which is used to process a quit message, and that's how we safely exit the application from within it's self.
What I want to do is somehow send a message to the process from another process, in order to tell the process to exit safely.
In Linux, we would do this by trapping signals, but I'm not sure how it's done on Windows.
PostThreadMessage can post messages to threads without requiring a window proc.
In the first process, do a GetCurrentThreadId to get a system wide id for the current thread. And somehow get that id to the second app.
In the second app, OpenThread will convert to a thread handle, that you can then use with PostThreadMessage.
Do note that if your 'windowprocless' application ever pops up a message box, the message box enters its own modal message loop, which will silently destroy any thread messages. If any kind of window is ever created on the thread you would be far better off creating an invisible message window that messages can be sent to to control the app.
Do you have the control over both processes i.e., do you have the code of both processes? If yes I suggest to expose a API to exit safely.