Memory manager writing pages back to executables...

I was reading an article posted in code project website. The author has
noticed that his XP explorer was taking about 5 seconds to display an
error message when he tried deleted a locked file or directory. He
found that shell32.dll was looping around sleep for 5 times with 1
second expiration. So he decided to patch the shell32.dll using a
driver so that it will loop for 0 times thus avoiding the delay.

He writes "Now that we know which addresses to patch, we need to map
those addresses into the kernel-mode area of the memory. This will
allow us to lock the pages in memory, thus preventing them from being
swapped out to disk. In this case the memory we're modifying is
"backed" by shell32.dll. If it were to be swapped out, the memory
manager would attempt to write the changes back to shell32.dll. ...."

He also writes (in the Some Final Thoughts section) "I'm not sure why
the memory manager doesn't try to write the modified pages back to
shell32.dll. I suspect that it's because the entries in the Page Frame
Number Database representing the physical pages we've modified always
have a "reference count" of at least 1 (because they're locked). If my
understanding is correct, this means they will not be moved to the
"Modified List" and thus will not be written to disk by the Modified
Page Writer. If anyone can expand on this, please leave a comment. "

My question is:
1. Is it true that the memory manager will write pages back to the
executable upon modification? Under what circumstance does the memory
manager does this?
2. Where can I find more information about this topic?

The original article may be found at
http://www.codeproject.com/system/NoDeleteDelay.asp

Tom

Maxim
Wed Feb 01 13:56:42 CST 2006

Wrong approach. The correct approach is to write an FS filter, which will
intercept noncached paging reads from shell32.dll, and patch the buffer
post-read.

Anyway - wait for next Windows Update hotfix (shell32 is usually updated in
them) and look at your killed OS :-) so, such toys are evil, absolutely evil.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

"Tom V S" <TomVeeYes@gmail.com> wrote in message
news:1138817860.477233.66640@g43g2000cwa.googlegroups.com...
> I was reading an article posted in code project website. The author has
> noticed that his XP explorer was taking about 5 seconds to display an
> error message when he tried deleted a locked file or directory. He
> found that shell32.dll was looping around sleep for 5 times with 1
> second expiration. So he decided to patch the shell32.dll using a
> driver so that it will loop for 0 times thus avoiding the delay.
>
> He writes "Now that we know which addresses to patch, we need to map
> those addresses into the kernel-mode area of the memory. This will
> allow us to lock the pages in memory, thus preventing them from being
> swapped out to disk. In this case the memory we're modifying is
> "backed" by shell32.dll. If it were to be swapped out, the memory
> manager would attempt to write the changes back to shell32.dll. ...."
>
> He also writes (in the Some Final Thoughts section) "I'm not sure why
> the memory manager doesn't try to write the modified pages back to
> shell32.dll. I suspect that it's because the entries in the Page Frame
> Number Database representing the physical pages we've modified always
> have a "reference count" of at least 1 (because they're locked). If my
> understanding is correct, this means they will not be moved to the
> "Modified List" and thus will not be written to disk by the Modified
> Page Writer. If anyone can expand on this, please leave a comment. "
>
> My question is:
> 1. Is it true that the memory manager will write pages back to the
> executable upon modification? Under what circumstance does the memory
> manager does this?
> 2. Where can I find more information about this topic?
>
> The original article may be found at
> http://www.codeproject.com/system/NoDeleteDelay.asp
>
> Tom
>

Tom
Wed Feb 01 14:13:22 CST 2006

Maxim,
Thank you for your reply. Can you shed some light on "Memory Manager
writing back to shell32.dll upon paging" concept?
Even with an FS filter if what the author claims is right, the memory
manager should write the pages back to shell32.dll as the content has
changed, isn't? I am not sure how the loader-memory manager-dirty page
writer stuff work together in this case.
Tom

pavel_a
Wed Feb 01 14:15:29 CST 2006

( wild guess of a diletant ...)
Perhaps locked dirty pages are not written back because there is no way
to know whether they are still being modified; the write back can
occur only after the memory is unlocked.
--PA


"Tom V S" wrote:
> I was reading an article posted in code project website. The author has
> noticed that his XP explorer was taking about 5 seconds to display an
> error message when he tried deleted a locked file or directory. He
> found that shell32.dll was looping around sleep for 5 times with 1
> second expiration. So he decided to patch the shell32.dll using a
> driver so that it will loop for 0 times thus avoiding the delay.
>
> He writes "Now that we know which addresses to patch, we need to map
> those addresses into the kernel-mode area of the memory. This will
> allow us to lock the pages in memory, thus preventing them from being
> swapped out to disk. In this case the memory we're modifying is
> "backed" by shell32.dll. If it were to be swapped out, the memory
> manager would attempt to write the changes back to shell32.dll. ...."
>
> He also writes (in the Some Final Thoughts section) "I'm not sure why
> the memory manager doesn't try to write the modified pages back to
> shell32.dll. I suspect that it's because the entries in the Page Frame
> Number Database representing the physical pages we've modified always
> have a "reference count" of at least 1 (because they're locked). If my
> understanding is correct, this means they will not be moved to the
> "Modified List" and thus will not be written to disk by the Modified
> Page Writer. If anyone can expand on this, please leave a comment. "
>
> My question is:
> 1. Is it true that the memory manager will write pages back to the
> executable upon modification? Under what circumstance does the memory
> manager does this?
> 2. Where can I find more information about this topic?
>
> The original article may be found at
> http://www.codeproject.com/system/NoDeleteDelay.asp
>
> Tom
>
>

Maxim
Wed Feb 01 14:20:54 CST 2006

I don't think that this will work with image files at all.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

"Tom V S" <TomVeeYes@gmail.com> wrote in message
news:1138824802.045519.216140@g49g2000cwa.googlegroups.com...
> Maxim,
> Thank you for your reply. Can you shed some light on "Memory Manager
> writing back to shell32.dll upon paging" concept?
> Even with an FS filter if what the author claims is right, the memory
> manager should write the pages back to shell32.dll as the content has
> changed, isn't? I am not sure how the loader-memory manager-dirty page
> writer stuff work together in this case.
> Tom
>

Pavel
Wed Feb 01 22:51:07 CST 2006

Memory manager will not try to write these pages back to the
image. Images are mapped with PAGE_EXECUTE_WRITECOPY
so when a process modifies memory in an image it gets a private
copy of the modified page, backed by pagefile. This is why
you can (for example) set a breakpoint in a system DLL in one
process without affecting the rest of the system.

--
This posting is provided "AS IS" with no warranties, and confers no
rights.

"Tom V S" wrote:

>I was reading an article posted in code project website. The author has
> noticed that his XP explorer was taking about 5 seconds to display an
> error message when he tried deleted a locked file or directory. He
> found that shell32.dll was looping around sleep for 5 times with 1
> second expiration. So he decided to patch the shell32.dll using a
> driver so that it will loop for 0 times thus avoiding the delay.
>
> He writes "Now that we know which addresses to patch, we need to map
> those addresses into the kernel-mode area of the memory. This will
> allow us to lock the pages in memory, thus preventing them from being
> swapped out to disk. In this case the memory we're modifying is
> "backed" by shell32.dll. If it were to be swapped out, the memory
> manager would attempt to write the changes back to shell32.dll. ...."
>
> He also writes (in the Some Final Thoughts section) "I'm not sure why
> the memory manager doesn't try to write the modified pages back to
> shell32.dll. I suspect that it's because the entries in the Page Frame
> Number Database representing the physical pages we've modified always
> have a "reference count" of at least 1 (because they're locked). If my
> understanding is correct, this means they will not be moved to the
> "Modified List" and thus will not be written to disk by the Modified
> Page Writer. If anyone can expand on this, please leave a comment. "
>
> My question is:
> 1. Is it true that the memory manager will write pages back to the
> executable upon modification? Under what circumstance does the memory
> manager does this?
> 2. Where can I find more information about this topic?
>
> The original article may be found at
> http://www.codeproject.com/system/NoDeleteDelay.asp

Pavel
Wed Feb 01 23:13:50 CST 2006

Oh, I see - he's doing all this in a driver... Never mind.

--
This posting is provided "AS IS" with no warranties, and confers no
rights.

"Pavel Lebedinsky [MSFT]" wrote:

> Memory manager will not try to write these pages back to the
> image. Images are mapped with PAGE_EXECUTE_WRITECOPY
> so when a process modifies memory in an image it gets a private
> copy of the modified page, backed by pagefile. This is why
> you can (for example) set a breakpoint in a system DLL in one
> process without affecting the rest of the system.

Pavel
Thu Feb 02 00:48:30 CST 2006

By the way, even if he did not lock the pages Mm still wouldn't
try to write them to disk. The mapped page writer checks to
see if a page is from an image section and if so it basically
throws it away.

Of course, this means that the hack wouldn't be persistent - if
the system was low on memory, it could repurpose modified
pages for something else and then simply re-read them from
the image file.

--
This posting is provided "AS IS" with no warranties, and confers no
rights.

> Oh, I see - he's doing all this in a driver... Never mind.
>

RossettoeCioccolato
Thu Feb 02 01:16:03 CST 2006

Pavel,

> try to write them to disk. The mapped page writer checks to
> see if a page is from an image section and if so it basically
> throws it away. <

Good Microsoft! Good Microsoft!

Regards,

George.

RossettoeCioccolato
Thu Feb 02 14:36:17 CST 2006

Pavel,

Why should the processor mode matter. Won't the modified page have a page
file backed PTE in either case?

Regards,

George.

"Pavel Lebedinsky [MSFT]" <pavel@online.microsoft.com> schrieb im
Newsbeitrag news:%23Nzoxd7JGHA.1760@TK2MSFTNGP10.phx.gbl...
> Oh, I see - he's doing all this in a driver... Never mind.
>
> --

Carl
Fri Feb 03 03:38:04 CST 2006


"Tom V S" <TomVeeYes@gmail.com> wrote in message
news:1138817860.477233.66640@g43g2000cwa.googlegroups.com...
>I was reading an article posted in code project website. The author has
> noticed that his XP explorer was taking about 5 seconds to display an
> error message when he tried deleted a locked file or directory. He
> found that shell32.dll was looping around sleep for 5 times with 1
> second expiration. So he decided to patch the shell32.dll using a
> driver so that it will loop for 0 times thus avoiding the delay.

Wow, someone was bored... ;-)

> He writes "Now that we know which addresses to patch, we need to map
> those addresses into the kernel-mode area of the memory. This will
> allow us to lock the pages in memory, thus preventing them from being
> swapped out to disk. In this case the memory we're modifying is
> "backed" by shell32.dll. If it were to be swapped out, the memory
> manager would attempt to write the changes back to shell32.dll. ...."

No, images are mapped copy on write, the pages would be eligible for paging
and not being written back to the image, this is why every now and again you
see bits of executables in the paging file, .rdata sections that contain
strings and importantly IAT tables can end up in the paging file because
they are modified by the loader as the import addresses are resolved and
stored in the IAT. Images have critical initialisation steps to perform on
loading, snapping the IAT being a good example. If Mm were to flush these
changes back to disk, your image would never load again.

> He also writes (in the Some Final Thoughts section) "I'm not sure why
> the memory manager doesn't try to write the modified pages back to
> shell32.dll. I suspect that it's because the entries in the Page Frame
> Number Database representing the physical pages we've modified always
> have a "reference count" of at least 1 (because they're locked). If my
> understanding is correct, this means they will not be moved to the
> "Modified List" and thus will not be written to disk by the Modified
> Page Writer. If anyone can expand on this, please leave a comment. "

The modified page writer wakes up every second or so and if there is a low
memory condition. Pages that have been selected as eligible for paging are
written via MiGatherPagefilePages via IoAsynchronousPageWrite. The same is
true for the mapped page writter, MiGatherMappedPages.

My understanding is that because the pages that have been locked are still
valid virtual addresses, they still live in the working set and follow all
the same rules as other working set pages. This would include being moved to
the modified list. The difference is that when pages are selected for paging
by the working set trimmer, locked pages are explicitly ignored as are AWE
pages. This is not true for pages locked by VirtualLock, this just updates
the working set list entry for the page and specifies that the page should
be brought back in as the thread comes back on the CPU.

> My question is:
> 1. Is it true that the memory manager will write pages back to the
> executable upon modification? Under what circumstance does the memory
> manager does this?

No, it wont, it could do very wrong...!

> 2. Where can I find more information about this topic?
>
> The original article may be found at
> http://www.codeproject.com/system/NoDeleteDelay.asp
>
> Tom
>

Mark
Thu Mar 09 08:22:44 CST 2006

Tom V S wrote:
d on this, please leave a comment. "
>
> My question is:
> 1. Is it true that the memory manager will write pages back to the
> executable upon modification?

I certainly hope it isn't doing this for code or static data, that would
be like a hideous enormous security hole.

> 2. Where can I find more information about this topic?

The Inside Windows XXXXXX series from microsoft press (russinovich et
al) are a good place to start.