Windows 10 works incorrectly with Large memory pages

For all the improvements to Windows that have come from Microsoft thanks Nadella & co., it is still rather shocking to realize Windows has no public bug tracker, and no real way to report these issues besides screaming loudly and hoping someone in Redmond hears you. It's even worse customer service than Google, which is quite an achievement.

Insightful response in the linked thread: <a href="https:&#x2F;&#x2F;sourceforge.net&#x2F;p&#x2F;sevenzip&#x2F;discussion&#x2F;45797&#x2F;thread&#x2F;e730c709&#x2F;?limit=25&amp;page=1#b240" rel="nofollow">https:&#x2F;&#x2F;sourceforge.net&#x2F;p&#x2F;sevenzip&#x2F;discussion&#x2F;45797&#x2F;thread&#x2F;e...</a>

So, as much as I hate to hate on somebody here, Igor is... somewhat unreliable with regards to these issues.<p>Igor is infamous for disabling virtually every setting. 7-Zip has no ASLR, compiler-stack checks, or anything what-so-ever. Igor refuses to use a modern VC++ (Visual Studio 2015 and later have FREE versions available for open-source code) that would solve a lot of security issues and bugs.<p>I&#x27;m not entirely sure if this is a Win10 problem, or if its a 7-Zip problem. Any complaints from the 7-Zip dev IMO will require a very careful eye: 7-Zip code is not necessarily in the cleanest state or using the best practices.

<p><pre><code> &#x2F;&#x2F; A Windows bug exists where a VirtualAlloc call immediately after VirtualFree &#x2F;&#x2F; yields a page that has not been zeroed. The returned page is asynchronously &#x2F;&#x2F; zeroed a few milliseconds later, resulting in memory corruption. The same bug &#x2F;&#x2F; allows VirtualFree to return before the page has been unmapped.</code></pre> I wonder what MSRC would think of that bug

In reading the article it&#x27;s clear this is not a bug, it&#x27;s API abuse. The documentation for VirtualAlloc is very clear that Large Pages should be a one time allocation thing are not intended for general malloc replacement.

For those interested, this issue was apparently already resolved in RS4 insider builds and only affects some older releases. After updating a system to RS4 (the upcoming release), this issue should no longer be encountered:<p><a href="https:&#x2F;&#x2F;aka.ms&#x2F;Yxum93" rel="nofollow">https:&#x2F;&#x2F;aka.ms&#x2F;Yxum93</a><p>(requires Feedback Hub App on Win 10 to view)

Leery about going to read this - has sourceforge cleaned up its act at all since the download poisoning issues?

It is funnily interesting to me how they prefer to capitalize the word BUG, perhaps as a means of drawing attention to its (apparent) importance.