In fact, while I have seen numerous examples of patching code, very very
few of them are properly implemented. It is quite common for people to
think they can merely change the in-memory version of the code but do
not consider the impact that this has in more complex environments.
To properly patch code in current x86 systems, you have to rendezvous
ALL the processors, patch the code, and then serialize the caches on all
the processors (the interesting case here is the Pentium 4, which
translates instructions into “micro-ops” and changes made on one
processor won’t be visible to the trace cache (where the micro-ops are
stored) on other processors. But rest assured we will see MORE of these
cases in the future, not fewer).
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ravisankar Pudipeddi
Sent: Friday, June 03, 2005 8:05 PM
To: ntfsd redirect
Subject: RE: [ntfsd] Bugcheck “ATTEMPTED_WRITE_TO_READONLY_MEMORY” while
patching kernel.
I guess pretty much similar to the way you are ‘hijacking’
IoCreateFile(). There are better ways to filter create than patch it
(this alias is devoted to such filters & supporting them).
You will always run into problems when you try to patch code owned by
somebody else. There’s no guarantee it will ever work.
Ravi
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jason Yueh
Sent: Thursday, June 02, 2005 10:45 PM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] Bugcheck “ATTEMPTED_WRITE_TO_READONLY_MEMORY” while
patching kernel.
Hi Dan,
Thanks for your help!
We did find that it’s caused by a third party driver.
Without that driver loaded, we will not get the BSOD.
But we’re wondering that how does that driver “hijacked” the request and
denyed it.
Can a driver hijack a memory copy operatoin?
And how can I prove it from the dump.
I didn’t see it on the callstack…
Thanks,
Jason
“Dan Partelly” wrote in message
news:xxxxx@ntfsd…
> Hehm , yes,
>
> Im sure on the special machine somebody hooked whatever code you
> created for patching IoCreateFile(), hijacked the request and denyed
it.
>
> Dan
>
>
> ----- Original Message -----
> From: “jason_yueh”
> To: “Windows File Systems Devs Interest List”
> Sent: Friday, June 03, 2005 6:24 AM
> Subject: [ntfsd] Bugcheck “ATTEMPTED_WRITE_TO_READONLY_MEMORY” while
> patching kernel.
>
>
> Hi,
>
> We got a bugcheck code “ATTEMPTED_WRITE_TO_READONLY_MEMORY” while
> patching kernel.
> First we make the page of IoCreateFile writable.
> Then we patch the kernel and make the page read-only.
> On most machines, it works.
> But on one special machine, we always got bugcheck code above.
>
> This is the info from the dump file.
>
> We make sure that the page is writable.
> ----------------------------------------------------------------------
> ----
–
> -----
> 0: kd> x nt!IoCreateFile
> dd4a2054 nt!IoCreateFile =
> 0: kd> !pte dd4a2054
> DD4A2054 - PDE at C0300DD4 PTE at C0375288
> contains 00034163 contains 004A2123
> pfn 34 G-DA–KWV pfn 4a2 G–A–KWV
> ----------------------------------------------------------------------
> ----
–
> -----
>
> But we still got a bugcheck…
> ----------------------------------------------------------------------
> ----
–
> -----
> ATTEMPTED_WRITE_TO_READONLY_MEMORY (be) An attempt was made to write
> to readonly memory. The guilty driver is on the stack trace (and is
> typically the current instruction pointer).
> When possible, the guilty driver’s name (Unicode string) is printed on
> the bugcheck screen and saved in KiBugCheckDriver.
> Arguments:
> Arg1: dd4a2054, Virtual address for the attempted write.
> Arg2: 004a2123, PTE contents.
> Arg3: eb45b9f0, (reserved)
> Arg4: 0000000a, (reserved)
> ----------------------------------------------------------------------
> ----
–
> -----
>
> Anybody has an idea about why?
>
> Thanks,
> Jason
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: unknown lmsubst tag
argument: ‘’
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com