{"id":95215,"date":"2017-01-19T07:00:00","date_gmt":"2017-01-19T22:00:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/oldnewthing\/?p=95215"},"modified":"2019-03-13T01:04:56","modified_gmt":"2019-03-13T08:04:56","slug":"20170119-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20170119-00\/?p=95215","title":{"rendered":"A fine detail on how DLLs are relocated as the result of a base address collision, and consequences"},"content":{"rendered":"

If a DLL must be relocated due to a base address conflict, then the image will be relocated<\/a>, and the entire relocated DLL is now backed by the page file. <\/p>\n

If you read the description more carefully, you’ll see that it’s not exactly the entire relocated DLL that gets backed by the page file. More precisely, all the pages that contained fixups are put into the page file. If you’re lucky and have a page without any fixups, then that page will still be demand-paged from the image because the kernel didn’t apply any fixups to it, and therefore did not incur a copy-on-write for that page, so it continues to be backed by the file system image. <\/p>\n

One of the arguments I’ve seen for intentionally causing a base address collision<\/a> is so that the relocated DLL gets copied into the page file, which is a win if the page file is on a faster medium than the DLL. For example, the page file may be on an SSD or (gasp) a RAM drive. <\/p>\n

That logic fails to take into account the case of pages with no fixups. Those pages will still page in directly from the original file, which be a problem if the original file is on a very slow medium, or a medium which could be lost, such as a CD-ROM drive or network drive. <\/p>\n

Fortunately, you don’t need to play funny games with base address conflicts to get your entire DLL loaded into the page file. Instead, use the \/SWAPRUN<\/code> linker flag<\/a> which lets you specify in the module header that the loader should copy the image into the swap file. <\/p>\n","protected":false},"excerpt":{"rendered":"

Fixed up as necessary, but only as necessary.<\/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-95215","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"

Fixed up as necessary, but only as necessary.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/95215","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=95215"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/95215\/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=95215"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=95215"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=95215"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}