IIS 7.5 site is stopped, but it still responds to requests with 404 errors

5,288

Sounds like either something is sharing the port or its failing to shut down correctly

Run a netsh http show servicestate to diagnose if anything is running on the HTTP Service.

Additionally do a netstat -ano and see if the IIS service is running on a ID. (I know you said TCPView is reporting ID:0 but this doesn't sound right and I'd put more trust in the netstat command.

If you find its still running then a simple taskkill /pid:IDNUMBERHERE should do the trick.

Share:
5,288

Related videos on Youtube

ewall
Author by

ewall

I'm a picker, a grinner; I'm a lover, and I'm a sinner, playin' my music in the sun. I'm a Renaissance soul with a love for beautiful code, linguistic syntax, passionate music, and efficiency in all of its forms. I am always sure to enjoy a good cup of coffee, a long lazy afternoon read of a good book, a chat with a friend or even a stranger, a date with my Sweetie, and dancing in the grocery store aisles like I was possessed by the spirit of Napoleon Dynamite.

Updated on September 18, 2022

Comments

  • ewall
    ewall over 1 year

    What you'd expect when you select a site in the IIS console and choose the "stop" button is that all bound ports would stop responding, right? That's what it did in earlier versions of IIS, at least.

    What I'm seeing today (on more than one server) is that, when I stop the site, the SSL port 443 stops as expected, but port 80 stays open -- and it keeps responding to requests with 404 Not Found errors!

    TCPView shows that port 80 is being used by "System service" with a PID of 0. Process Explorer does not show PID 0 using port 80.

    This is IIS 7.5 on Windows Server 2008 R2 x64. Is this perhaps some fancy new feature of the Windows Firewall? (The service is running, but the firewall is disabled by Group Policy.)

  • ewall
    ewall about 11 years
    Thanks, that's it! Interestingly, netstat also shows PID 0 as the owner. But the netsh command you gave was able to list more info, including the correct process: turns out it's Microsoft's Web Deploy Remote Service, which happens to be used by the site hosted by the servers I noticed the "problem" on.
  • Simon Hayter
    Simon Hayter about 11 years
    Glad I could help ;)