The Windows OS tries to conserve physical memory usage by allowing DLLs loaded in their base (desired) address in different processes to use the same physical pages with copy-on-write semantics; this article, for example, describes the mechanism.
Now, the Windows Virtual Memory API allows you to change the protection mode of memory pages via the VirtualProtect function. You'll notice that two of the available protection modes include copy-on-write semantics.
Now that we have the prelude out of the way, the question is: if you take a copy-on-write memory page from a just-loaded DLL and change its protection mode to, say, read-write, how does it affect the other processes? Before the change all the processes use the same physical memory page, so does that single page suddenly lose its copy-on-write voodoo and becomes a weird kind of shared memory?
For sanity's sake I have to assume that if you change the protection mode of a copy-on-write page to read-write (or any non-COW protection mode), the kernel will spawn your own private page with the identical content and the other processes will live happily with their original COW page. The trouble is, I couldn't find any reference to support this, so if anyone could point me to anything that says explicitly that this is indeed the case I'd appreciate that.
EDIT: An even more interesting question would be what happens if you change the COW page to read-write and then write in it - does the change affect the other processes (since the page is no longer COW, and mapped in other processes too, it sounds like it should, but that would be clearly unsafe)?