In order to hoop the stdout of a console application, my process manager start the console application using CreateProcess with bInheritHandles to be true, everything works except that when my process manager was closed but the console application was still alive, if try to restart my process manager, Windows will report error that the port was in used (my process manager open a port to play the service role), and if i use TCPView to check the port status, i found my process manager seems to be still “alive”, the PID was still there but it could not be found in Task Manager, the port was listed in the TCPView but could not be found via NETSTAT command — Windows failed to terminate my process manager due to the inherited handles of the console application, if i need to restart my process manager, i have to kill the console application first.
Is there any way to terminate my process manager gracefully even when the inherited console application still alive?
Related
I have an unknown AppDetectService using my port 8000 and I am not able to figure out how to close it down or kill any process that seems to be running it. Its being run by System process on PID 4(found that by netstat and searching through task manager). Trying to search for the file running it on task manager leads to ntoskrnl.exe. Also task manager shows it may slightly be using GPU. So my guess is either a system process is holding the port or more probably something is using some kind of system available servers to host a service. Hitting it on the browser shows up this page:
Netstat results:
task manager screenshot showing GPU may also be firing:
Please help me kill this abomination once and for all.
I have used Process Explorer to find out what service was using this port. Since it was impossible to find it even like this, I started to shut down service by service until port 8000 wasn't occupied any more.
In my case, port 8000 was taken over by drivers for Sound BlasterX AE-5 sound card. Process Creative.AudPosService located in C:\Program Files (x86)\Creative\Connection Service has been using this port.
Luckily, it is possible to change this port. Open Creative.AudPosService.exe.config and change line where port number is located <add baseAddress="http://localhost:8000/"/> to <add baseAddress="http://localhost:9999/"/> or anything else that don't interfere with your work. Restart windows and it should be fine.
I made a UDP server class and my program creates a process (running in the background). It is a command line utility, and so running 'udpserver.exe start' would bind the socket and begin a blocking recvfrom() call inside a for(;;) loop.
What is the best way to safely and 'gracefully' stop the server?
I was thinking about 'udpserver.exe stop' would send a udp msg such as 'stop' and the ongoing process from 'udpserver.exe start' would recognize this msg, break from the loop, and clean up (closesocket/wsacleanup).
Also, is just killing the process not a good idea?
Why are you running the UDP server as an external process instead of as a worker thread inside of your main program? That would make it a lot easier to manage the server. Simple close the socket, which will abort a blocked recvfrom(), thus allowing the thread to terminate itself.
But if you must run the UDP server in an external process, personally I would just kill that process, quick and simple. But if you really want to be graceful about it, you could make the server program handle CTRL-BREAK via SetConsoleCtrlHandler() so it knows when it needs to close its socket, stopping recvfrom(). Then you can have the main program spawn the server program via CreateProcess() with the CREATE_NEW_PROCESS_GROUP flag to get a group ID that can then be used to send CTRL-BREAK to the server process via GenerateConsoleCtrlEvent() when needed.
I am facing issue with c++ service which uses port 30015.It runs fine,but sometime it fails to start as the port 30015 is occupied and bind fails with error WSAEADDRINUSE.
I ran netstat command to know the port status
netstat -aon | findstr 30015
Output:
TCP 0.0.0.0:30015 0.0.0.0 LISTENING 6740
I checked the PID 6740 in task manager,this PID is not be taken by an process.
After searching in the net, I used TCPVIEW to see the status of the port. TCPView is showing port in listening mode and process name is "non-existance".
Application basically compress,decompress the file using 7za. Application listen on 30015 port for request and than create a child process and pass the commandline to run 7za command to compress and decompress file.
Here child process doesn't uses socket. Server runs on the main thread and listen on port 30015. This problem comes after restart of the server.
Here child process does not use socket as such. Do I need to make bInheritHandle = FALSE ?
Are you sure? This all sounds very confused. It's not possible for netstat to show a socket in the LISTEN state but for there to be no process -- especially if it shows the pid! You're confused because the process simply exited by the time you looked in Task Manager. All TCP connections in netstat are associated with a running process (except for unusual cases like TIME-WAIT sockets). So, find out which process has the socket open.
Secondly, I think you're trying to say that using bInheritHandles=TRUE as an argument to CreateProcess can lead to handle leaks. Only you have your code -- why not just look at the handles in your child and see if you do have a leak? It is only possible to use bInheritHandles=TRUE with great discipline, in the hands of novice programmers it will only lead to bugs. Create a named pipe with a suitable security descriptor, pass the name on the commandline to the child, and connect back, rather than using handle inheritance which is much too coarse-grained.
Finally, just to make sure, you do know to bind listening sockets with SO_REUSEADDR to prevent conflicting with active sockets using the same port? (SO_REUSEADDR still won't let two passive sockets be created on the same address/port combination, although it is a bit broken on Windows.)
Yes this can happen on Windows. If you've created a child process that inherits handles from the parent process then that includes TCP server sockets in the LISTEN state that will always be listed as owned by the parent PID even after that PID has died.
These sockets will disappear when all child processes that you spawned have exited, causing the reference count on their handles to reach zero.
From a security standpoint you should not use inter-process handle-inheritance, particularly when launching a 3rd part application, unless you have a good reason to need the feature.
If I exit my application normally, aboutToQuit is called and I can do some cleanup, however, if the user logs off of windows, my application closes immediately and aboutToQuit is never called.
The program functions as an application launcher that logs to a server. Each time an application launches, it sends a message to a server with the name (you launch the application from within my app).
Normally, a user shuts down the application when they are done and I log the event. If they shutdown the computer though, I want to send a application's shutdown log event in aboutToQuit, but that function is never called.
I've searched for options and short of making my application into a Windows service (haven't tried this yet), nothing is working.
Any ideas?
This appears to be fixed in Qt5.2.0 as I now receive a QApplication::commitDataRequest() signal at windows logoff.
I have a test driver program that launches a separate test server process. The test server process listens on a local port, and after it's ready, the test driver runs a test that accesses the test server.
Currently the test driver repeatedly tries to connect to the local port (loop some, sleep some, try again). It's not an optimal solution, and is clearly unreliable.
Is it possible to wait for some event that says "somebody listens on a local port"? Trying to connect to early results in a "port closed" error.
I'd like to implement the solution on Windows, Linux, and Mac OS X. If you have some tips for any of these systems, it's welcome (it's probably going to be system-specific in each case).
On Windows I use a named event for this kind of thing.
The test harness can create the event and communicate the name of the event to the server that it launches; it then waits on the event to be signalled before continuing the test. The server then connects to the event, initialises itself and once it's ready to accept connections it signals the event.
Well, if you launch the server process, you can intercept the stdout of the server right?
So have the server output "server started" when the socket ready. The driver should wait until the server sends this string to stdout, then try to connect to the server port.