{"id":91411,"date":"2015-10-08T07:00:00","date_gmt":"2015-10-08T21:00:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/oldnewthing\/20151008-00\/?p=91411\/"},"modified":"2019-03-13T12:20:22","modified_gmt":"2019-03-13T19:20:22","slug":"20151008-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20151008-00\/?p=91411","title":{"rendered":"What happens if you call VirtualAlloc to MEM_COMMIT a page you never MEM_RESERVE?"},"content":{"rendered":"

A customer reported that while trying to solve a problem with their program, they noticed that they had been calling Virtual­Alloc<\/code> incorrectly for years. They were able to reduce it into a simple program: <\/p>\n

\n#include <windows.h>\n#include <stdio.h>\n#include <tchar.h>\n\nint _tmain(int argc, _TCHAR* argv[])\n{\n LPVOID base = VirtualAlloc(NULL, 4096, MEM_COMMIT, PAGE_READWRITE);\n _tprintf(TEXT(\"Allocated at %p\\n\"), base);\n return 0;\n}\n<\/pre>\n
First of all, thank you for reducing<\/a> your program. That really focuses the investigation. <\/p>\n
The customer noted that their code was passing the MEM_COMMIT<\/code> flag without the MEM_RESERVE<\/code> flag, a scenario that is specifically called out in the documentation: <\/p>\n
The function fails if you attempt to commit a page that has not been reserved.  The resulting error code is ERROR_INVALID_ADDRESS<\/b>. <\/p><\/blockquote>\n
But their call to Virtual­Alloc<\/code> was succeeding! The customer suspected that this was not actually the source of their problem, but they wanted to double-check that perhaps their incorrect use of Virtual­Alloc<\/code> was somehow indirectly contributing to it. Specifically, they were wondering if what they’re doing is okay, or whether they should always use MEM_RESERVE | MEM_COMMIT<\/code>. <\/p>\n
What the customer found is a compatibility hack. A lot of application forget to set the MEM_RESERVE<\/code> flag when they MEM_COMMIT<\/code>, so the memory manager lets it slide if they also pass lpAddress = NULL<\/code>, indicating that they are requesting a new allocation rather than modifying an existing one. <\/p>\n
The problem is that MSDN fell into the trap of over-documenting. Instead of documenting the contract, MSDN documented the implementation. The contract is “A page being committed must also be reserved.” If you try to commit a page that is not also reserved, then the behavior is unspecified. It is therefore valid for the implementation to treat the violation as “Sorry, you lose,” or “Okay, I’ll let you do it, but just this time.” <\/p>\n
It appears that some time after this issue was identified, the MSDN documentation was revised. But they didn’t revise it by documenting the contract. They revised it by documenting the implementation more precisely<\/i>. <\/p>\n
Attempting to commit a specific address range by specifying MEM_COMMIT<\/b> without MEM_RESERVE<\/b> and a non-NULL<\/b> lpAddress<\/i> fails unless the entire range has already been reserved. The resulting error code is ERROR_INVALID_ADDRESS<\/b>. <\/p><\/blockquote>\n
My recommendation to the customer was to switch to MEM_RESERVE | MEM_COMMIT<\/code>, since that is the preferred behavior and therefore the one least likely to trigger compatibility behavior. But the fact that they were accidentally omitting the MEM_RESERVE<\/code> was not related to their problem, and they should keep looking. <\/p>\n","protected":false},"excerpt":{"rendered":"
It is not guaranteed to succeed.<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[25],"class_list":["post-91411","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
It is not guaranteed to succeed.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/91411","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/users\/1069"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/comments?post=91411"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/91411\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media\/111744"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media?parent=91411"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=91411"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=91411"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}