Search User Space While Kernel Debugging

[goalan...@yahoo.com]

I am trying search memory in user space while debugging in kernel mode
in WinDbg, and I cannot get the s command to work? If I debug the
process locally in user mode then I can do `s –a 00400000 L4 “MZ”` and
it will find the string. However, if I am debugging remotely in
kernel mode this returns nothing. I tried changing the process
context beforehand using the .process command, but this still did not
work. I can also see that memory at location 00400000 has the values
‘M’ ‘Z’ by doing db command or looking in the memory window. Any
thoughts on how to get this to work or why it won’t work?

[Pavel A.]

<goalan...@yahoo.com> wrote in message
news:61b2bfde-f662-4864...@k4g2000yqb.googlegroups.com...

> I am trying search memory in user space while debugging in kernel mode
> in WinDbg, and I cannot get the s command to work? If I debug the

> process locally in user mode then I can do `s -a 00400000 L4 "MZ"` and

> it will find the string. However, if I am debugging remotely in
> kernel mode this returns nothing. I tried changing the process
> context beforehand using the .process command, but this still did not
> work. I can also see that memory at location 00400000 has the values
> 'M' 'Z' by doing db command or looking in the memory window. Any
> thoughts on how to get this to work or why it won't work?

The memory can be paged out.
--pa

[DuckSeductor]

On Dec 4, 11:07 pm, "Pavel A." <pave...@12fastmail34.fm> wrote:
> <goalanumb...@yahoo.com> wrote in message

What do you mean exactly by this comment? I understand page tables
and paging, but shouldn't the search command still be able to read
it? It doesn't seem to have a problem reading the memory with other
commands such as db.

[Ivan Brugiolo [MSFT]]

First of all, the command works in kernel mode, as shown here as an example.

0: kd> !process -1 0
PROCESS fffffa800226db30
SessionId: 1 Cid: 01c0 Peb: 7fffffd7000 ParentCid: 01b0
DirBase: 701ec000 ObjectTable: fffff8a001bcf940 HandleCount: 71.
Image: csrss.exe

0: kd> lm v m csrss
start end module name
00000000`499f0000 00000000`499f6000 csrss (deferred)
0: kd> s -a 499f0000 L4 "MZ"
00000000`499f0000 4d 5a 90 00 03 00 00 00-04 00 00 00 ff ff 00 00
MZ..............

Pavel's comment was about the general availability of virtual-address-based
memory in a KD session. Only NonPagedPool, by definition, is available.
Everything else is subject to virtual addresses being being paged-in
(KD does not read from the page-file, unless the `.pagein` command is being
used,
that has a lot of other issue with regard of continuing execution).

In a nutshell, doing memory search in KD is better
accomplished with `!search`, that does a physical-memory search always.

--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

"DuckSeductor" <goalan...@yahoo.com> wrote in message
news:46090093-35c2-40f7...@m16g2000yqc.googlegroups.com...

[Pavel A.]

"DuckSeductor" <goalan...@yahoo.com> wrote in message
news:46090093-35c2-40f7...@m16g2000yqc.googlegroups.com...

No, if the memory is paged out, windbg can't search in it.
Try .pagein to bring the pages back to memory.

Regards,
--pa

[DuckSeductor]

Ok, I understand what you are both saying now. I was able to search
the page of memory for the bytes, and they were found. Thank you both
for responding. It was a big help.

I did not know that the KD debugger had restrictions on the memory
upon which it operates. Is there a resource somewhere that describes
this? I went through the Help Contents again, but I could not find
anything on this.

My main question now is how do I know which commands require the
memory to be in physical memory and which do not? For instance, the
dumb bytes, enter bytes, and compare bytes commands all work before
the call to the .pagein command while the search command fails. Then
after .pagein is invoked all of the commands work including search.
This proves to me that the dump bytes, enter bytes, and compare bytes
commands do not operate under the restriction that KD only operates on
addresses in physical memory. I reread the search command help file
and it mentioned nothing about the memory addresses having to be paged
into physical memory while debugging in kernel mode. Is this
documented somewhere?

Thanks again!

[Ivan Brugiolo [MSFT]]

In general, all KD commands that require reading/writing from anything
that is not NonPagedPool are naturally subject to the virtual memory
being present and backed by physical memory.

On average, the simlpe `dt <something>` commands works because
they operate on variables on the stack (that is page-in, if you have
touched that page by the virtue of executing code that pushed
something on the stack).
But, kernel-stack are pageable, and, if you debug any machine that
is severely out-of-memory, you can have only as few as handful
of pages paged-in for the current process.

There is no need to document which commands works and which one
does not. All of them are expected to NOT work, unless the target
address is paged-in (by allocation attributes, by chance, or explicitly).

Searching in KD using `s -<size> <address_rage> <value>` is
most likely going to not work, because the wider the range, the
higher the chances to have something paged out.
That is exactly why `!search` was created, to search in physical memory
only.
--

--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

"DuckSeductor" <goalan...@yahoo.com> wrote in message

news:b469b908-9016-4bc9...@s20g2000yqd.googlegroups.com...