11

We have two Windows Server, one in 2012 R2 and the other in 2008 R2 which uses Apache HTTP Server (httpd) 2.4 in proxy/reverse-proxy mode (usage of ProxyPass, ProxyPassReverse and Virtual Hosts configuration). Both servers uses Apache 2.4.27 x64 binary build from Apache Haus.

We have some backup scripts running on both servers. They stop all the services (including Apache) then do the backup and restart all services again.

These scripts are working fine since several years (almost 4 years). But starting from July 12, 2018, the behaviour is now strange. The backup scripts are doing their jobs, stopping all services, making the backup but now, all services are restarted except Apache.

After investigating, I found that Apache 2.4.27 service can't be stopped. When using the Services console and trying to manually stop the service, the console shows "Stopping" and nothing happens.

So I checked the running processes and seen that a httpd.exe process is running. I tried to kill that process but with no luck.

So, I tried:

taskkill /im "httpd.exe" /f /t

And the output is:

ERROR: The process with PID 560 (child process of PID 480) could not be terminated.
Reason: There is no running instance of the task.

So I tested to kill the process with pskill from Sysinternals:

pskill -t 560

And the output is:

Copyright (C) 1999-2016  Mark Russinovich
Sysinternals - www.sysinternals.com

Process 5956 killed.

But this is false, as the httpd process is always running!

So I've updated Apache from 2.4.27 to 2.4.34, but the problem remains. The only thing to do to unblock the situation is to reboot the whole server.

I checked the installed updates, and some of them were installed the July 11, 2018 so one day before:

  • KB4338420
  • KB4338818
  • KB4339093
  • KB4338423

So I presume the problem is from one of these updates. So before uninstalling all of them, is there someone which have the same problem as I, I mean Apache 2.4 becomes unkillable and can't be stopped on Windows Server?

The big issue is, if that httpd process can't be killed, Apache can't be restarted as the port 80 is already bound.

SiZiOUS
  • 311
  • 2
  • 8

5 Answers5

10

OK, so I think I was on the right track.

After searching on the Web about the recently installed updates, the KB4338818 is the one causing problems.

This is happening for other softwares, like FileZilla Server, as detailed here.

I've just uninstalled this Security Update and now Apache can be started/stopped as normal!

So I hope Microsoft will fix this in a later update!

SiZiOUS
  • 311
  • 2
  • 8
  • I see you've found your answer but I was wondering if a server restart would have also fixed the problem? Additionally, if the update was applied while Apache was not running then it's possible that it might not have caused the issues. – MonkeyZeus Jul 16 '18 at 12:12
  • Yes, as I already explained in the original question, the only solution to unblock the situation is to restart the whole server... which is a dirty workaround! – SiZiOUS Jul 16 '18 at 12:45
  • Sorry, I missed that detail, it was a bit buried. After reboot, did the process remain un-killable? I am just asking because I am running Windows 7 x64 with Apache on my local machine but have not received KB4338818 yet so I want to know what to expect. – MonkeyZeus Jul 16 '18 at 13:12
  • 1
    No problem, you don't have to justify your comment. :) After reboot, if you setted up Apache to automatically start, it will work. But when you try to stop the service (manually or by using scripts) the `httpd` process will freeze and will become un-killable. – SiZiOUS Jul 16 '18 at 16:04
3

Microsoft is releasing KB4345459 to fix the issues in Windows 7 and Windows 2008 Server.

https://support.microsoft.com/en-us/help/4345459/stop-error-0xd1-after-a-race-condition-occurs-in-windows-7-service-pac

Fabricio Pocci
  • 31
  • 1
1

Seems like Microsoft is starting to fix the issue, until now only for Server 2016 and Windows 10: https://support.microsoft.com/de-de/help/4345421/windows-10-update-kb4345421

Hypersonic
  • 11
  • 1
1

KB4338831 seems to fix the issue for Windows Server 2012 R2.

This non-security update includes improvements and fixes that were a part KB4338815 (released July 10, 2018) and also includes these new quality improvements as a preview of the next Monthly Rollup update. Source: July 18, 2018—KB4338831 (Preview of Monthly Rollup)

It's available as a recommended update on Windows Update.

Alessandro Brandão
  • 11
  • 1
0

I think you are definitely on the right track. I was having a similar problem with Tomcat on a Windows Server. I had another server with Tomcat that was not experiencing the problem however, and the only major difference I could find was that the working server also had IIS installed and running on other ports. As a work-around I tried loading IIS on the problem server setting up the default web site so that it used non-standard ports and the problem appears to have gone away without having to uninstall the update.

Don Prezioso
  • 1
  • 1
    OK... I take it back... the IIS trick only seems to work some of the time. Port 80 seems to be fixed with loading IIS, but 443 only works some of the time. Also, for me the offending update seems to be KB4338815. At least for my production server this is the only thing running on it, so I can reboot almost as easily as restarting Tomcat. – Don Prezioso Jul 17 '18 at 02:57