Support

This is actually an issue with PHP's thread safety on Windows. If your AMP installation is using PHP as an Apache module -like XAMPP does- you need the thread-safe (TS) version. If your AMP installation is using PHP through CGI or FastCGI then you need the non-thread-safe (NTS) version. XAMPP is indeed running PHP as an Apache module but I'm not sure that they are using the correct, thread-safe version. I had consistent crashes with it so I ultimately had to roll my own local server on Windows.

A possible workaround is to make the backup much, much slower. In the Configuration page of Akeeba Backup set:
Minimum execution time: 7 seconds
Maximum execution time: 5 seconds (yes, maximum is less than minimum)
Execution time bias: 75%

That said, this workaround will NOT work very reliably. I would recommend simply using a better local server. Something like MAMP might work better.

This is NOT helpful information. The backup runs by making requests to your server. While each step is running of course you will see "Waiting for localhost" since your browser is waiting for the server to finish running the step.

What else do you get? If you get an HTTP status 0 it simply means that your server closed the connection on you. Have you tried changing the maximum execution time to something really low, e.g. 5 seconds?

This does mean that the web server (Apache) or the database (MySQL) service dies. I'm afraid there's not much you can do here. In the end of the day, though, it comes down to Windows and resource handlers, i.e. the low level handling of files by Windows itself. Here's the thing. This behavior is both machine-specific and not related to Akeeba Backup itself. It's not even related to Joomla!. It goes deep down into how PHP, Apache and Windows interact under the hood. This is two to four layers before our code has even the chance to load, making it impossible for us to offer any solution to what is, essentially, a server platform issue. All I can offer is some anecdotal information about your issue.

One thing I've found that helps sometimes is disabling your antivirus. This includes Windows Defender. At the very least you should add exceptions for the folders which contain your web server, your site files and MySQL (that is: the entire c:\xampp folder if you're using the default installation). The reason that helps, I suspect, is that antivirus application hook to Windows' file access events. Every time you try to access a file they try to scan it - that's what most antivirus call "realtime protection". The problem is that they end up opening too many files. Sometimes crap happens and the internal Windows file handle is not released at all or fast enough. This can cause some interesting race conditions with Apache and PHP which wait forever for the file lock to be released - something that never happens because code outside them dropped the ball.

I did have that issue when I was using Windows 7 on an AMD Phenom x3 back in 2009 with XAMPP. All I can tell you is that I no longer have that problem on either of my Windows 10 computers anymore. One is an Intel NUC with a 2013-spec i5 and 16GB RAM, the other is a 2016 Surface Book with an i7 and 16GB RAM. I am using my own AMP server, mostly with PHP 7.0. Davide, our other developer, has a rather ancient Thinkpad with Windows 10 and XAMPP which he uses without a problem. If I may offer more information, when I first bought the Surface Book I had MASSIVE issues like yours - they have been recorded as part of my Joomla! Day Austria 2016 presentation when that issue happened when I was trying to demonstrate backing up on stage... I trashed and rebuilt my AMP, killed off my antivirus (NOD32 - I realised antivirus is mostly snake oil), added folder exceptions to Windows Defender and all the issues "magically" went away. Also, everything started running so much faster.