0

I'm encountering a persistent issue where a TCP port remains stuck in the LISTENING state, but the process that allocated it cannot be found. This happens even though the application that originally used the port is no longer running. Restarting the machine resolves the issue, but I need a solution that doesn't involve restarting Windows.

The problem:

  • Running netstat -ano | findstr :1041 shows the port is in LISTENING state with a PID (e.g., 13536).

  • When I attempt to kill the process using taskkill /PID 13536 /F , I receive the error:

    ERROR: The process "13536" not found. 
  • Repeating the netstat command shows that the port is still LISTENING with the same PID, even though the process supposedly doesn't exist.

image

I have tried the following solutions without success:

  1. Check for active connections:

    netstat -ano | findstr :1041 

    This only confirms the port is open but doesn't show a valid process.

  2. Kill the process by PID:

    taskkill /PID 13536 /F 

    But the process cannot be found.

  3. Restart TCP/IP stack without rebooting:

    netsh int ip reset netsh winsock reset 

    This didn't help.

  4. Restart the NDU service (Network Data Usage Monitoring Driver):

    sc stop ndu sc start ndu 

    The issue persisted.

    Even with SYSTEM privileges, the process is not found.

  5. Check for port forwarding or proxy settings:

    netsh interface portproxy show all netsh interface portproxy reset 

    Nothing was configured.

  6. Attempt to delete the process via WMI:

    wmic process where "ProcessId=13536" delete 

    The process was not listed.

  7. Used TCPView and Process Explorer from Sysinternals:

    • The port appears as LISTENING, but no process is tied to it.

This ghost process issue happens randomly, usually after my application crashes or is forcibly terminated. The only solution that works so far is rebooting the machine, which isn’t ideal.

Question:

  • How can I forcefully release the port without restarting Windows?

  • Is there a way to reset or clear ports that are stuck in LISTENING without an active process?

Any suggestions or alternative approaches would be greatly appreciated!

Edit: Thanks to @Massimo for the tip.

Also, thanks for nothing to the moderators who closed the topic at light speed.

The Answer

1. Identify the port in use and find the associated PID:

netstat -ano | findstr :1041 

Output Example:

 TCP 0.0.0.0:1041 0.0.0.0:0 LISTENING 14392 

The PID in this case is 14392.


2. Trace the parent process of the PID:

wmic process get processid,parentprocessid | findstr/i 14392 

Output Example:

14392 9584 

Here, 9584 is the parent process of 14392.


3. Check for child processes under this parent process:

wmic process where (ParentProcessId=9584) get Caption,ProcessId 

Output Example:

Caption ProcessId conhost.exe 38776 

This revealed a conhost.exe process with PID 38776.


4. Terminate the identified process:

taskkill /f /pid 38776 

Output Example:

SUCCESS: The process with PID 38776 has been terminated. 

After this, the port was released, and I could restart the application without rebooting the system.


Key Insight:

In some cases, the process occupying the port might not appear directly in tasklist or through taskkill with the initial PID. However, by tracing the parent process and terminating its child processes (like conhost.exe), the issue can be resolved without restarting Windows.

I hope this helps someone else facing a similar ghost process issue!

1
  • This can happen to any resource, such as files. If a handle to a resource isn't closed properly, Windows cannot allocate it to another process. It's possible to use SysInternals Handle.exe to terminate, but this inevitably will lead to instability in Windows, including crashing. The only answer is to fix the offending application, and/or restart Windows. Commented Jan 7 at 21:51

1 Answer 1

1

This can be caused by an application failing to properly close a listening socket; see f.e. here:

https://superuser.com/questions/215351/how-do-i-kill-a-process-that-is-dead-but-listening https://stackoverflow.com/questions/9024090/winsock-tcp-listener-stays-in-listening-state-after-successful-closesocket-cal

Since you mention this happens after my application crashes or is forcibly terminated, this seems indeed to be the case.

You should investigate why your application fails to properly release a socket when it terminates.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.