It almost sounds as if things are working as expected.
The way the anti forgery helper @Html.AntiForgeryToken() works is by injecting a hidden form field named __RequestVerificationToken into the page AND it also sets a cookie into the browser.
When the form is posted back the two are compared and if they don’t match or the cookie is missing then the error is thrown.
So it does not matter that Elmah logs that the form is sending __RequestVerificationToken. It always will, even in the event of CSRF attack, because this is simply the hidden form field.
<input name="__RequestVerificationToken" type="hidden" value="DNbDMrzHmy37GPS6IFH-EmcIh4fJ2laezIrIEev5f4vOhsY9T7SkH9-1b7GPjm92CTFtb4dGqSe2SSYrlWSNEQG1MUlNyiLP1wtYli8bIh41" />
The error message on the other hand says the corresponding COOKIE is not being sent:
500 HttpAntiForgery The required anti-forgery cookie
__RequestVerificationToken” is not present.
So basically someone/something is replaying the form post without making the original request to get the cookie. As such they have the hidden form field
__RequestVerificationToken but NOT the cookie to verify it.
So it seems like things are working as they should. Check your logs re: IP numbers, and referrers, etc. You might be under attack or perhaps be doing something weird or buggy when redirecting your form content. As above, referrers are a good place to start for this kind of error, assuming this is not being spoofed.
Also note that as per MDN
location.reload();
The Location.reload() method reloads the resource from the current
URL. Its optional unique parameter is a Boolean, which, when it is
true, causes the page to always be reloaded from the server. If it is
false or not specified, the browser may reload the page from its
cache.
If it is, on occasion loading from cache, then you might end up with a POST that has the old page token but not the cookie.
So try :
location.reload(true);