Local Kernel Debuging

OSR_Community_User · November 30, 2005, 1:38pm

Whcihc commands should I expect to work when doing local kernel
debugging? I am trying to read a physical; memory location on my device.
I know I can access the device because I have an app talking to it
through the driver. However, I’m getting the following error when I try
to read a memory location:

lkd> !dd [uc] fe400000
Physical memory read at fe400000 failed

Should I expect this to work?

Beverly

OSR_Community_User · November 30, 2005, 2:03pm

In general you should expect things which deal with stable data to work.
This includes long-lived global memory and such. Anything with
transient data, such as thread stacks, global memory under modification
and so on, may or may not work.

My understanding is that physical memory reads will fail unless the
memory has an OS mapping for the physical memory, as the OS validates
all physical memory reads against known memory regions before allowing
them.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Wednesday, November 30, 2005 10:37 AM
To: Kernel Debugging Interest List
Subject: [windbg] Local Kernel Debuging

Whcihc commands should I expect to work when doing local kernel
debugging? I am trying to read a physical; memory location on my device.
I know I can access the device because I have an app talking to it
through the driver. However, I’m getting the following error when I try
to read a memory location:

lkd> !dd [uc] fe400000
Physical memory read at fe400000 failed

Should I expect this to work?

Beverly

You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

jimd · November 30, 2005, 2:35pm

How do you know that that virtual address is mapped to your device’s memory
region ?

Also, remember that when you break in local kernel mode you are in the
context of an arbitrary thread of an arbitrary process.
Try forcing the system process as the current process…

kd> !process 4 0 - get the eprocess of system on xp
kd>.process /P (eprocess of system)
(the /P forces PTE’s to be automatically translated)

.cache forcedecodeptes (does the same thing as /P)

Also, are you using livekd to fire off the local kernel session ?
Things work much better when you do that …

“Drew Bliss” wrote in message
news:xxxxx@windbg…
In general you should expect things which deal with stable data to work.
This includes long-lived global memory and such. Anything with
transient data, such as thread stacks, global memory under modification
and so on, may or may not work.

My understanding is that physical memory reads will fail unless the
memory has an OS mapping for the physical memory, as the OS validates
all physical memory reads against known memory regions before allowing
them.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Wednesday, November 30, 2005 10:37 AM
To: Kernel Debugging Interest List
Subject: [windbg] Local Kernel Debuging

Whcihc commands should I expect to work when doing local kernel
debugging? I am trying to read a physical; memory location on my device.
I know I can access the device because I have an app talking to it
through the driver. However, I’m getting the following error when I try
to read a memory location:

lkd> !dd [uc] fe400000
Physical memory read at fe400000 failed

Should I expect this to work?

Beverly

—
You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

OSR_Community_User · November 30, 2005, 2:37pm

What do you mean by “OS mapping”? Do you mean system memory as uded by
the OS? And therefore accessing device memory will not work? Well that
rots!

Beverly

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Drew Bliss
Sent: Wednesday, November 30, 2005 2:02 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Local Kernel Debuging

In general you should expect things which deal with stable data to work.
This includes long-lived global memory and such. Anything with
transient data, such as thread stacks, global memory under modification
and so on, may or may not work.

My understanding is that physical memory reads will fail unless the
memory has an OS mapping for the physical memory, as the OS validates
all physical memory reads against known memory regions before allowing
them.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Wednesday, November 30, 2005 10:37 AM
To: Kernel Debugging Interest List
Subject: [windbg] Local Kernel Debuging

Whcihc commands should I expect to work when doing local kernel
debugging? I am trying to read a physical; memory location on my device.
I know I can access the device because I have an app talking to it
through the driver. However, I’m getting the following error when I try
to read a memory location:

lkd> !dd [uc] fe400000
Physical memory read at fe400000 failed

Should I expect this to work?

Beverly

You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

OSR_Community_User · November 30, 2005, 2:42pm

I’m not that familiar with the particulars, but from what I’ve heard
it’s any physical memory that the OS knows about by any mechanism. It
doesn’t have to be used by the OS, so it can be device memory, but it
has to be some memory that a device driver or miniport reported/mapped
so that the OS is aware of it.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Wednesday, November 30, 2005 11:36 AM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Local Kernel Debuging

What do you mean by “OS mapping”? Do you mean system memory as uded by
the OS? And therefore accessing device memory will not work? Well that
rots!

Beverly

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Drew Bliss
Sent: Wednesday, November 30, 2005 2:02 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Local Kernel Debuging

In general you should expect things which deal with stable data to work.
This includes long-lived global memory and such. Anything with
transient data, such as thread stacks, global memory under modification
and so on, may or may not work.

My understanding is that physical memory reads will fail unless the
memory has an OS mapping for the physical memory, as the OS validates
all physical memory reads against known memory regions before allowing
them.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Wednesday, November 30, 2005 10:37 AM
To: Kernel Debugging Interest List
Subject: [windbg] Local Kernel Debuging

Whcihc commands should I expect to work when doing local kernel
debugging? I am trying to read a physical; memory location on my device.
I know I can access the device because I have an app talking to it
through the driver. However, I’m getting the following error when I try
to read a memory location:

lkd> !dd [uc] fe400000
Physical memory read at fe400000 failed

Should I expect this to work?

Beverly

You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

OSR_Community_User · November 30, 2005, 3:21pm

Well, my driver did map in this device memory. I know that because my
app would not have gotten as far as it did. There’s lots it can talk to
on the board, just one thing that seems to not be set right and I want
to verify that the logic in my code set the right value in my device
memory by reading it through the debugger. It’s not working. I can
access system memory just fine.

I think I remember runnning itnto a similar issue once before (with
driver code, not windbg). I could only map memory that the OS “knew
about” using a particular API. In this case “knew about” meant part of
system memory. It would fail to map device memory. I’m guessing that
windbg is using that API to do the mapping.

Can this problem be fixed? I can’t be the only one who wants to read
device memory from a local kernel debugger.

Beverly

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Drew Bliss
Sent: Wednesday, November 30, 2005 2:42 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Local Kernel Debuging

I’m not that familiar with the particulars, but from what I’ve heard
it’s any physical memory that the OS knows about by any mechanism. It
doesn’t have to be used by the OS, so it can be device memory, but it
has to be some memory that a device driver or miniport reported/mapped
so that the OS is aware of it.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Wednesday, November 30, 2005 11:36 AM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Local Kernel Debuging

What do you mean by “OS mapping”? Do you mean system memory as uded by
the OS? And therefore accessing device memory will not work? Well that
rots!

Beverly

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Drew Bliss
Sent: Wednesday, November 30, 2005 2:02 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Local Kernel Debuging

In general you should expect things which deal with stable data to work.
This includes long-lived global memory and such. Anything with
transient data, such as thread stacks, global memory under modification
and so on, may or may not work.

My understanding is that physical memory reads will fail unless the
memory has an OS mapping for the physical memory, as the OS validates
all physical memory reads against known memory regions before allowing
them.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Wednesday, November 30, 2005 10:37 AM
To: Kernel Debugging Interest List
Subject: [windbg] Local Kernel Debuging

Whcihc commands should I expect to work when doing local kernel
debugging? I am trying to read a physical; memory location on my device.
I know I can access the device because I have an app talking to it
through the driver. However, I’m getting the following error when I try
to read a memory location:

lkd> !dd [uc] fe400000
Physical memory read at fe400000 failed

Should I expect this to work?

Beverly

You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

OSR_Community_User · November 30, 2005, 3:23pm

I’m not using a virtual address. I’m using a physical address !dd is
supposed to access physical addresses, not virtual ones. You use dd
(without the !) to access a virtual address.

Beverly

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of jim
Sent: Wednesday, November 30, 2005 2:35 PM
To: Kernel Debugging Interest List
Subject: Re:[windbg] Local Kernel Debuging

How do you know that that virtual address is mapped to your device’s
memory region ?

Also, remember that when you break in local kernel mode you are in the
context of an arbitrary thread of an arbitrary process.
Try forcing the system process as the current process…

kd> !process 4 0 - get the eprocess of system on xp .process /P
kd>(eprocess of system)
(the /P forces PTE’s to be automatically translated)

.cache forcedecodeptes (does the same thing as /P)

Also, are you using livekd to fire off the local kernel session ?
Things work much better when you do that …

“Drew Bliss” wrote in message
news:xxxxx@windbg…
In general you should expect things which deal with stable data to work.
This includes long-lived global memory and such. Anything with
transient data, such as thread stacks, global memory under modification
and so on, may or may not work.

My understanding is that physical memory reads will fail unless the
memory has an OS mapping for the physical memory, as the OS validates
all physical memory reads against known memory regions before allowing
them.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Wednesday, November 30, 2005 10:37 AM
To: Kernel Debugging Interest List
Subject: [windbg] Local Kernel Debuging

Whcihc commands should I expect to work when doing local kernel
debugging? I am trying to read a physical; memory location on my device.
I know I can access the device because I have an app talking to it
through the driver. However, I’m getting the following error when I try
to read a memory location:

lkd> !dd [uc] fe400000
Physical memory read at fe400000 failed

Should I expect this to work?

Beverly

—
You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

—
You are currently subscribed to windbg as: bbrown@mc.com To unsubscribe
send a blank email to xxxxx@lists.osr.com

OSR_Community_User · November 30, 2005, 4:06pm

I’ve passed this on to the expert.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Wednesday, November 30, 2005 12:21 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Local Kernel Debuging

Well, my driver did map in this device memory. I know that because my
app would not have gotten as far as it did. There’s lots it can talk to
on the board, just one thing that seems to not be set right and I want
to verify that the logic in my code set the right value in my device
memory by reading it through the debugger. It’s not working. I can
access system memory just fine.

I think I remember runnning itnto a similar issue once before (with
driver code, not windbg). I could only map memory that the OS “knew
about” using a particular API. In this case “knew about” meant part of
system memory. It would fail to map device memory. I’m guessing that
windbg is using that API to do the mapping.

Can this problem be fixed? I can’t be the only one who wants to read
device memory from a local kernel debugger.

Beverly

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Drew Bliss
Sent: Wednesday, November 30, 2005 2:42 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Local Kernel Debuging

I’m not that familiar with the particulars, but from what I’ve heard
it’s any physical memory that the OS knows about by any mechanism. It
doesn’t have to be used by the OS, so it can be device memory, but it
has to be some memory that a device driver or miniport reported/mapped
so that the OS is aware of it.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Wednesday, November 30, 2005 11:36 AM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Local Kernel Debuging

What do you mean by “OS mapping”? Do you mean system memory as uded by
the OS? And therefore accessing device memory will not work? Well that
rots!

Beverly

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Drew Bliss
Sent: Wednesday, November 30, 2005 2:02 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Local Kernel Debuging

In general you should expect things which deal with stable data to work.
This includes long-lived global memory and such. Anything with
transient data, such as thread stacks, global memory under modification
and so on, may or may not work.

My understanding is that physical memory reads will fail unless the
memory has an OS mapping for the physical memory, as the OS validates
all physical memory reads against known memory regions before allowing
them.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Wednesday, November 30, 2005 10:37 AM
To: Kernel Debugging Interest List
Subject: [windbg] Local Kernel Debuging

Whcihc commands should I expect to work when doing local kernel
debugging? I am trying to read a physical; memory location on my device.
I know I can access the device because I have an app talking to it
through the driver. However, I’m getting the following error when I try
to read a memory location:

lkd> !dd [uc] fe400000
Physical memory read at fe400000 failed

Should I expect this to work?

Beverly

You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

jimd · November 30, 2005, 4:24pm

Ok, I see well unless you have 4,265,607,168 bytes of memory in your box
it’s a given that fe400000 is a bad physical memory address. Usually when
folks say Physical, the really mean a mapping from Physical to some virtual
space, since that’s the only way code can use it. What more most device
can’t be mapped that high anyway, since they don’t usually support 32 bits.

If the driver has mapped fe400000 into kernel address space,
dd fe400000 (no !) should work.

did you try that ?

“Drew Bliss” wrote in message
news:xxxxx@windbg…
I’ve passed this on to the expert.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Wednesday, November 30, 2005 12:21 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Local Kernel Debuging

Well, my driver did map in this device memory. I know that because my
app would not have gotten as far as it did. There’s lots it can talk to
on the board, just one thing that seems to not be set right and I want
to verify that the logic in my code set the right value in my device
memory by reading it through the debugger. It’s not working. I can
access system memory just fine.

I think I remember runnning itnto a similar issue once before (with
driver code, not windbg). I could only map memory that the OS “knew
about” using a particular API. In this case “knew about” meant part of
system memory. It would fail to map device memory. I’m guessing that
windbg is using that API to do the mapping.

Can this problem be fixed? I can’t be the only one who wants to read
device memory from a local kernel debugger.

Beverly

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Drew Bliss
Sent: Wednesday, November 30, 2005 2:42 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Local Kernel Debuging

I’m not that familiar with the particulars, but from what I’ve heard
it’s any physical memory that the OS knows about by any mechanism. It
doesn’t have to be used by the OS, so it can be device memory, but it
has to be some memory that a device driver or miniport reported/mapped
so that the OS is aware of it.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Wednesday, November 30, 2005 11:36 AM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Local Kernel Debuging

What do you mean by “OS mapping”? Do you mean system memory as uded by
the OS? And therefore accessing device memory will not work? Well that
rots!

Beverly

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Drew Bliss
Sent: Wednesday, November 30, 2005 2:02 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Local Kernel Debuging

In general you should expect things which deal with stable data to work.
This includes long-lived global memory and such. Anything with
transient data, such as thread stacks, global memory under modification
and so on, may or may not work.

My understanding is that physical memory reads will fail unless the
memory has an OS mapping for the physical memory, as the OS validates
all physical memory reads against known memory regions before allowing
them.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Wednesday, November 30, 2005 10:37 AM
To: Kernel Debugging Interest List
Subject: [windbg] Local Kernel Debuging

Whcihc commands should I expect to work when doing local kernel
debugging? I am trying to read a physical; memory location on my device.
I know I can access the device because I have an app talking to it
through the driver. However, I’m getting the following error when I try
to read a memory location:

lkd> !dd [uc] fe400000
Physical memory read at fe400000 failed

Should I expect this to work?

Beverly

—
You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

—
You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

—
You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

—
You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

—
You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

OSR_Community_User · November 30, 2005, 4:36pm

Fe400000 is a PCI physical address. I got this value by looking at my
device in device manager and viewing what resources were assigned to it.
Even though my device mapped it into virtual space, fe400000 is still
the phsyical address as it appears on the PCI bus (and no, my system
does not have mapping registers so the PCI physical address looks the
same to the CPU as it does on the bus. The virtual address that it is
mapped to is different. So dd fe400000 will not access the address I
want it to access (assuming that it’s actually mapped to anyhing in
kernel space)

Beverly

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of jim
Sent: Wednesday, November 30, 2005 4:24 PM
To: Kernel Debugging Interest List
Subject: Re:[windbg] Local Kernel Debuging

Ok, I see well unless you have 4,265,607,168 bytes of memory in your box
it’s a given that fe400000 is a bad physical memory address. Usually
when folks say Physical, the really mean a mapping from Physical to some
virtual space, since that’s the only way code can use it. What more most
device can’t be mapped that high anyway, since they don’t usually
support 32 bits.

If the driver has mapped fe400000 into kernel address space, dd fe400000
(no !) should work.

did you try that ?

“Drew Bliss” wrote in message
news:xxxxx@windbg…
I’ve passed this on to the expert.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Wednesday, November 30, 2005 12:21 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Local Kernel Debuging

Well, my driver did map in this device memory. I know that because my
app would not have gotten as far as it did. There’s lots it can talk to
on the board, just one thing that seems to not be set right and I want
to verify that the logic in my code set the right value in my device
memory by reading it through the debugger. It’s not working. I can
access system memory just fine.

I think I remember runnning itnto a similar issue once before (with
driver code, not windbg). I could only map memory that the OS “knew
about” using a particular API. In this case “knew about” meant part of
system memory. It would fail to map device memory. I’m guessing that
windbg is using that API to do the mapping.

Can this problem be fixed? I can’t be the only one who wants to read
device memory from a local kernel debugger.

Beverly

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Drew Bliss
Sent: Wednesday, November 30, 2005 2:42 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Local Kernel Debuging

I’m not that familiar with the particulars, but from what I’ve heard
it’s any physical memory that the OS knows about by any mechanism. It
doesn’t have to be used by the OS, so it can be device memory, but it
has to be some memory that a device driver or miniport reported/mapped
so that the OS is aware of it.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Wednesday, November 30, 2005 11:36 AM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Local Kernel Debuging

What do you mean by “OS mapping”? Do you mean system memory as uded by
the OS? And therefore accessing device memory will not work? Well that
rots!

Beverly

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Drew Bliss
Sent: Wednesday, November 30, 2005 2:02 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Local Kernel Debuging

In general you should expect things which deal with stable data to work.
This includes long-lived global memory and such. Anything with
transient data, such as thread stacks, global memory under modification
and so on, may or may not work.

My understanding is that physical memory reads will fail unless the
memory has an OS mapping for the physical memory, as the OS validates
all physical memory reads against known memory regions before allowing
them.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Wednesday, November 30, 2005 10:37 AM
To: Kernel Debugging Interest List
Subject: [windbg] Local Kernel Debuging

Whcihc commands should I expect to work when doing local kernel
debugging? I am trying to read a physical; memory location on my device.
I know I can access the device because I have an app talking to it
through the driver. However, I’m getting the following error when I try
to read a memory location:

lkd> !dd [uc] fe400000
Physical memory read at fe400000 failed

Should I expect this to work?

Beverly

—
You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

—
You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

—
You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

—
You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

—
You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

—
You are currently subscribed to windbg as: bbrown@mc.com To unsubscribe
send a blank email to xxxxx@lists.osr.com

OSR_Community_User · November 30, 2005, 4:37pm

Thanks Drew!

Beverly

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Drew Bliss
Sent: Wednesday, November 30, 2005 4:06 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Local Kernel Debuging

I’ve passed this on to the expert.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Wednesday, November 30, 2005 12:21 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Local Kernel Debuging

Well, my driver did map in this device memory. I know that because my
app would not have gotten as far as it did. There’s lots it can talk to
on the board, just one thing that seems to not be set right and I want
to verify that the logic in my code set the right value in my device
memory by reading it through the debugger. It’s not working. I can
access system memory just fine.

I think I remember runnning itnto a similar issue once before (with
driver code, not windbg). I could only map memory that the OS “knew
about” using a particular API. In this case “knew about” meant part of
system memory. It would fail to map device memory. I’m guessing that
windbg is using that API to do the mapping.

Can this problem be fixed? I can’t be the only one who wants to read
device memory from a local kernel debugger.

Beverly

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Drew Bliss
Sent: Wednesday, November 30, 2005 2:42 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Local Kernel Debuging

I’m not that familiar with the particulars, but from what I’ve heard
it’s any physical memory that the OS knows about by any mechanism. It
doesn’t have to be used by the OS, so it can be device memory, but it
has to be some memory that a device driver or miniport reported/mapped
so that the OS is aware of it.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Wednesday, November 30, 2005 11:36 AM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Local Kernel Debuging

What do you mean by “OS mapping”? Do you mean system memory as uded by
the OS? And therefore accessing device memory will not work? Well that
rots!

Beverly

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Drew Bliss
Sent: Wednesday, November 30, 2005 2:02 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Local Kernel Debuging

In general you should expect things which deal with stable data to work.
This includes long-lived global memory and such. Anything with
transient data, such as thread stacks, global memory under modification
and so on, may or may not work.

My understanding is that physical memory reads will fail unless the
memory has an OS mapping for the physical memory, as the OS validates
all physical memory reads against known memory regions before allowing
them.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Wednesday, November 30, 2005 10:37 AM
To: Kernel Debugging Interest List
Subject: [windbg] Local Kernel Debuging

Whcihc commands should I expect to work when doing local kernel
debugging? I am trying to read a physical; memory location on my device.
I know I can access the device because I have an app talking to it
through the driver. However, I’m getting the following error when I try
to read a memory location:

lkd> !dd [uc] fe400000
Physical memory read at fe400000 failed

Should I expect this to work?

Beverly

You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

OSR_Community_User · November 30, 2005, 4:50pm

BEVERLY:

The skinny is that, as a best case scenario, no
command/meta-command/extension command that would cause the machine to
halt may be used. This, in my opnion, makes LKD remarkably useless.
For example, you can not break in to the debugger, resume, set
breakpoints, examine registers, et. c. In your particular case, while I
can’t be certain, I seriously doubt that reading physical memory would
work reliably under this conditions. The basic issue is that, from the
host CPU/Debugger perspective, in order to address a physical address,
it must first be equated with a virtual address that happens to map to
it. This is process specific, and I can’t see how WinDbg, which has no
Kernel component (it just uses a few Native API functions), could do
this reliably without (at least) taking control of the machine and,
possibly, creating a virtual address mapping for the physical address in
whatever context you happen to be in. This might itself fail because
(using the NT API since somewhere along the lines of 2000 SP4), attempts
to map a physical address to more than one range with differing cache
attributes fails (to prevent TLB corruption).

I gave up because I was in the fortunate position of having SoftICE as
a possibilty (it is what I used for years before WinDbg). If this is
remotely a possibily for you, this is what I would strongly recommend.
If this is not, your two options, as I see them, assuming that you can
not find someone who can give you a better idea of the likelihood of
getting LKD working, are (1) to use some sort of IOCTL to query the
memory from user mode with the help of your driver; (2) map the
physical address range you are interested in directly in to the virtual
address space of the context of a user mode program (ala MapMem from an
older DDK). As neither is attractive, I would go with option two (on a
readonly basis) as it is much more convenient, albeit remarkably
unsafe.

I hope this helps.

MM

>> bbrown@mc.com 2005-11-30 13:36 >>>
Whcihc commands should I expect to work when doing local kernel
debugging? I am trying to read a physical; memory location on my
device.
I know I can access the device because I have an app talking to it
through the driver. However, I’m getting the following error when I
try
to read a memory location:

lkd> !dd [uc] fe400000
Physical memory read at fe400000 failed

Should I expect this to work?

Beverly

You are currently subscribed to windbg as: unknown lmsubst tag
argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

OSR_Community_User · November 30, 2005, 5:22pm

I understand the reasons behind not allowing breakpoints, etc. I’m OK
with that. I have tried using SoftICE in the past and quite frankly I’m
not very impressed with it. I wouldn’t be able to use it via remote
desktop, for example.

As far as accessing memory locations, I understand all the issues with
accessing virtual addresses as they are process-specific. But a physical
device address (will never be used for a paging operation) should be
accessible. I have in the past successfully accessed global kernel
variables and can access system memory if I give it a physical address.
Of course the contents of those locations can change at any time unless
it is locked in memory. However I have succesffuly accessed common
buffers in this way. I should be able to do the same with device memory,
but for some reason that doesn’t work.

Beverly

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Martin O’Brien
Sent: Wednesday, November 30, 2005 4:50 PM
To: Kernel Debugging Interest List
Subject: Re: [windbg] Local Kernel Debuging

BEVERLY:

The skinny is that, as a best case scenario, no
command/meta-command/extension command that would cause the machine to
halt may be used. This, in my opnion, makes LKD remarkably useless.
For example, you can not break in to the debugger, resume, set
breakpoints, examine registers, et. c. In your particular case, while I
can’t be certain, I seriously doubt that reading physical memory would
work reliably under this conditions. The basic issue is that, from the
host CPU/Debugger perspective, in order to address a physical address,
it must first be equated with a virtual address that happens to map to
it. This is process specific, and I can’t see how WinDbg, which has no
Kernel component (it just uses a few Native API functions), could do
this reliably without (at least) taking control of the machine and,
possibly, creating a virtual address mapping for the physical address in
whatever context you happen to be in. This might itself fail because
(using the NT API since somewhere along the lines of 2000 SP4), attempts
to map a physical address to more than one range with differing cache
attributes fails (to prevent TLB corruption).

I gave up because I was in the fortunate position of having SoftICE as a
possibilty (it is what I used for years before WinDbg). If this is
remotely a possibily for you, this is what I would strongly recommend.
If this is not, your two options, as I see them, assuming that you can
not find someone who can give you a better idea of the likelihood of
getting LKD working, are (1) to use some sort of IOCTL to query the
memory from user mode with the help of your driver; (2) map the
physical address range you are interested in directly in to the virtual
address space of the context of a user mode program (ala MapMem from an
older DDK). As neither is attractive, I would go with option two (on a
readonly basis) as it is much more convenient, albeit remarkably unsafe.

I hope this helps.

MM

>> bbrown@mc.com 2005-11-30 13:36 >>>
Whcihc commands should I expect to work when doing local kernel
debugging? I am trying to read a physical; memory location on my device.
I know I can access the device because I have an app talking to it
through the driver. However, I’m getting the following error when I try
to read a memory location:

lkd> !dd [uc] fe400000
Physical memory read at fe400000 failed

Should I expect this to work?

Beverly

You are currently subscribed to windbg as: unknown lmsubst tag
argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

You are currently subscribed to windbg as: bbrown@mc.com To unsubscribe
send a blank email to xxxxx@lists.osr.com

jimd · November 30, 2005, 5:35pm

Well, it’s cause your using local debug.

If I connect to a box via the com port, I can go into device manager and use
!dd to read their memory from the resource tab just fine, if I try it
locally, no dice.

Before you get too upset understand the HUGH difference between local and
remote debugging - in remote debugging you freeze the entire system - its
some what un-reasonable to ask to poke around in a device while the device
is (possibly) in use, perhaps by windbg itself. It is NOT a failing or
missing feature in windbg.
Truth is local kernel debugging is not at all useful for device drivers.

There is NO debugger that can do that beyond a certain point. Softice
freezes the entire box, therefore all you get is a dos-ish text mode
interface.

If you really want to debug the problem, at least set up VMware, or connect
to your box from a laptop…

“Brown, Beverly” wrote in message news:xxxxx@windbg…
I’m not using a virtual address. I’m using a physical address !dd is
supposed to access physical addresses, not virtual ones. You use dd
(without the !) to access a virtual address.

Beverly

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of jim
Sent: Wednesday, November 30, 2005 2:35 PM
To: Kernel Debugging Interest List
Subject: Re:[windbg] Local Kernel Debuging

How do you know that that virtual address is mapped to your device’s
memory region ?

Also, remember that when you break in local kernel mode you are in the
context of an arbitrary thread of an arbitrary process.
Try forcing the system process as the current process…

kd> !process 4 0 - get the eprocess of system on xp .process /P
kd>(eprocess of system)
(the /P forces PTE’s to be automatically translated)

.cache forcedecodeptes (does the same thing as /P)

Also, are you using livekd to fire off the local kernel session ?
Things work much better when you do that …

“Drew Bliss” wrote in message
news:xxxxx@windbg…
In general you should expect things which deal with stable data to work.
This includes long-lived global memory and such. Anything with
transient data, such as thread stacks, global memory under modification
and so on, may or may not work.

My understanding is that physical memory reads will fail unless the
memory has an OS mapping for the physical memory, as the OS validates
all physical memory reads against known memory regions before allowing
them.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Wednesday, November 30, 2005 10:37 AM
To: Kernel Debugging Interest List
Subject: [windbg] Local Kernel Debuging

Whcihc commands should I expect to work when doing local kernel
debugging? I am trying to read a physical; memory location on my device.
I know I can access the device because I have an app talking to it
through the driver. However, I’m getting the following error when I try
to read a memory location:

lkd> !dd [uc] fe400000
Physical memory read at fe400000 failed

Should I expect this to work?

Beverly

—
You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

—
You are currently subscribed to windbg as: bbrown@mc.com To unsubscribe
send a blank email to xxxxx@lists.osr.com

OSR_Community_User · November 30, 2005, 5:51pm

Yes, I know. I have no problem when I connect with a different machine.
The problem is that the system I am trying to debug has limited physical
acccess so it is difficult to connect to it with a second system. The
local kernel debugger works fine for accessing global system variabls
and even reading PCI config space. I see kno reason why it should have a
problem with reading device memory.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of jim
Sent: Wednesday, November 30, 2005 5:35 PM
To: Kernel Debugging Interest List
Subject: Re:[windbg] Local Kernel Debuging

Well, it’s cause your using local debug.

If I connect to a box via the com port, I can go into device manager and
use !dd to read their memory from the resource tab just fine, if I try
it locally, no dice.

Before you get too upset understand the HUGH difference between local
and remote debugging - in remote debugging you freeze the entire system

its some what un-reasonable to ask to poke around in a device while
the device is (possibly) in use, perhaps by windbg itself. It is NOT a
failing or missing feature in windbg.
Truth is local kernel debugging is not at all useful for device drivers.

There is NO debugger that can do that beyond a certain point. Softice
freezes the entire box, therefore all you get is a dos-ish text mode
interface.

If you really want to debug the problem, at least set up VMware, or
connect to your box from a laptop…

“Brown, Beverly” wrote in message news:xxxxx@windbg…
I’m not using a virtual address. I’m using a physical address !dd is
supposed to access physical addresses, not virtual ones. You use dd
(without the !) to access a virtual address.

Beverly

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of jim
Sent: Wednesday, November 30, 2005 2:35 PM
To: Kernel Debugging Interest List
Subject: Re:[windbg] Local Kernel Debuging

How do you know that that virtual address is mapped to your device’s
memory region ?

Also, remember that when you break in local kernel mode you are in the
context of an arbitrary thread of an arbitrary process.
Try forcing the system process as the current process…

kd> !process 4 0 - get the eprocess of system on xp .process /P
kd>(eprocess of system)
(the /P forces PTE’s to be automatically translated)

.cache forcedecodeptes (does the same thing as /P)

Also, are you using livekd to fire off the local kernel session ?
Things work much better when you do that …

“Drew Bliss” wrote in message
news:xxxxx@windbg…
In general you should expect things which deal with stable data to work.
This includes long-lived global memory and such. Anything with
transient data, such as thread stacks, global memory under modification
and so on, may or may not work.

My understanding is that physical memory reads will fail unless the
memory has an OS mapping for the physical memory, as the OS validates
all physical memory reads against known memory regions before allowing
them.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Wednesday, November 30, 2005 10:37 AM
To: Kernel Debugging Interest List
Subject: [windbg] Local Kernel Debuging

Whcihc commands should I expect to work when doing local kernel
debugging? I am trying to read a physical; memory location on my device.
I know I can access the device because I have an app talking to it
through the driver. However, I’m getting the following error when I try
to read a memory location:

lkd> !dd [uc] fe400000
Physical memory read at fe400000 failed

Should I expect this to work?

Beverly

—
You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

—
You are currently subscribed to windbg as: bbrown@mc.com To unsubscribe
send a blank email to xxxxx@lists.osr.com

—
You are currently subscribed to windbg as: bbrown@mc.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

OSR_Community_User · November 30, 2005, 6:03pm

Here’s the response I got:

In local kernel debugging they should be able to access anything as long
as any one of the following applies :

the physical address is regular memory (so we know what cache
attribute to use to retrieve the data)
the physical address is already mapped by some driver (so we know
what cache attribute to use to retrieve the data)
if neither #1 or #2 apply, then they must explicitly tell us the
type [c,uc,wc] as part of the command.

What happens if you don’t specify [uc]?

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Wednesday, November 30, 2005 12:21 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Local Kernel Debuging

Well, my driver did map in this device memory. I know that because my
app would not have gotten as far as it did. There’s lots it can talk to
on the board, just one thing that seems to not be set right and I want
to verify that the logic in my code set the right value in my device
memory by reading it through the debugger. It’s not working. I can
access system memory just fine.

I think I remember runnning itnto a similar issue once before (with
driver code, not windbg). I could only map memory that the OS “knew
about” using a particular API. In this case “knew about” meant part of
system memory. It would fail to map device memory. I’m guessing that
windbg is using that API to do the mapping.

Can this problem be fixed? I can’t be the only one who wants to read
device memory from a local kernel debugger.

Beverly

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Drew Bliss
Sent: Wednesday, November 30, 2005 2:42 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Local Kernel Debuging

I’m not that familiar with the particulars, but from what I’ve heard
it’s any physical memory that the OS knows about by any mechanism. It
doesn’t have to be used by the OS, so it can be device memory, but it
has to be some memory that a device driver or miniport reported/mapped
so that the OS is aware of it.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Wednesday, November 30, 2005 11:36 AM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Local Kernel Debuging

What do you mean by “OS mapping”? Do you mean system memory as uded by
the OS? And therefore accessing device memory will not work? Well that
rots!

Beverly

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Drew Bliss
Sent: Wednesday, November 30, 2005 2:02 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Local Kernel Debuging

In general you should expect things which deal with stable data to work.
This includes long-lived global memory and such. Anything with
transient data, such as thread stacks, global memory under modification
and so on, may or may not work.

My understanding is that physical memory reads will fail unless the
memory has an OS mapping for the physical memory, as the OS validates
all physical memory reads against known memory regions before allowing
them.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Wednesday, November 30, 2005 10:37 AM
To: Kernel Debugging Interest List
Subject: [windbg] Local Kernel Debuging

Whcihc commands should I expect to work when doing local kernel
debugging? I am trying to read a physical; memory location on my device.
I know I can access the device because I have an app talking to it
through the driver. However, I’m getting the following error when I try
to read a memory location:

lkd> !dd [uc] fe400000
Physical memory read at fe400000 failed

Should I expect this to work?

Beverly

You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

OSR_Community_User · December 1, 2005, 9:42am

If I don’t specify [uc] I get a message telling me to specify a cache
type. I know I mapped the memory into the driver as MmNonCached (I
double-checked the code just to be extra sure).

Beverly

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Drew Bliss
Sent: Wednesday, November 30, 2005 6:03 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Local Kernel Debuging

Here’s the response I got:

In local kernel debugging they should be able to access anything as long
as any one of the following applies :

the physical address is regular memory (so we know what cache
attribute to use to retrieve the data)
the physical address is already mapped by some driver (so we know
what cache attribute to use to retrieve the data)
if neither #1 or #2 apply, then they must explicitly tell us the
type [c,uc,wc] as part of the command.

What happens if you don’t specify [uc]?

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Wednesday, November 30, 2005 12:21 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Local Kernel Debuging

Well, my driver did map in this device memory. I know that because my
app would not have gotten as far as it did. There’s lots it can talk to
on the board, just one thing that seems to not be set right and I want
to verify that the logic in my code set the right value in my device
memory by reading it through the debugger. It’s not working. I can
access system memory just fine.

I think I remember runnning itnto a similar issue once before (with
driver code, not windbg). I could only map memory that the OS “knew
about” using a particular API. In this case “knew about” meant part of
system memory. It would fail to map device memory. I’m guessing that
windbg is using that API to do the mapping.

Can this problem be fixed? I can’t be the only one who wants to read
device memory from a local kernel debugger.

Beverly

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Drew Bliss
Sent: Wednesday, November 30, 2005 2:42 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Local Kernel Debuging

I’m not that familiar with the particulars, but from what I’ve heard
it’s any physical memory that the OS knows about by any mechanism. It
doesn’t have to be used by the OS, so it can be device memory, but it
has to be some memory that a device driver or miniport reported/mapped
so that the OS is aware of it.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Wednesday, November 30, 2005 11:36 AM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Local Kernel Debuging

What do you mean by “OS mapping”? Do you mean system memory as uded by
the OS? And therefore accessing device memory will not work? Well that
rots!

Beverly

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Drew Bliss
Sent: Wednesday, November 30, 2005 2:02 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Local Kernel Debuging

In general you should expect things which deal with stable data to work.
This includes long-lived global memory and such. Anything with
transient data, such as thread stacks, global memory under modification
and so on, may or may not work.

My understanding is that physical memory reads will fail unless the
memory has an OS mapping for the physical memory, as the OS validates
all physical memory reads against known memory regions before allowing
them.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Wednesday, November 30, 2005 10:37 AM
To: Kernel Debugging Interest List
Subject: [windbg] Local Kernel Debuging

Whcihc commands should I expect to work when doing local kernel
debugging? I am trying to read a physical; memory location on my device.
I know I can access the device because I have an app talking to it
through the driver. However, I’m getting the following error when I try
to read a memory location:

lkd> !dd [uc] fe400000
Physical memory read at fe400000 failed

Should I expect this to work?

Beverly

You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

jimd · December 2, 2005, 11:12am

May now, you are very impressed with softice.

The job you wanted to do is childs play in softice.

“Brown, Beverly” wrote in message news:xxxxx@windbg…
I understand the reasons behind not allowing breakpoints, etc. I’m OK
with that. I have tried using SoftICE in the past and quite frankly I’m
not very impressed with it. I wouldn’t be able to use it via remote
desktop, for example.

As far as accessing memory locations, I understand all the issues with
accessing virtual addresses as they are process-specific. But a physical
device address (will never be used for a paging operation) should be
accessible. I have in the past successfully accessed global kernel
variables and can access system memory if I give it a physical address.
Of course the contents of those locations can change at any time unless
it is locked in memory. However I have succesffuly accessed common
buffers in this way. I should be able to do the same with device memory,
but for some reason that doesn’t work.

Beverly

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Martin O’Brien
Sent: Wednesday, November 30, 2005 4:50 PM
To: Kernel Debugging Interest List
Subject: Re: [windbg] Local Kernel Debuging

BEVERLY:

The skinny is that, as a best case scenario, no
command/meta-command/extension command that would cause the machine to
halt may be used. This, in my opnion, makes LKD remarkably useless.
For example, you can not break in to the debugger, resume, set
breakpoints, examine registers, et. c. In your particular case, while I
can’t be certain, I seriously doubt that reading physical memory would
work reliably under this conditions. The basic issue is that, from the
host CPU/Debugger perspective, in order to address a physical address,
it must first be equated with a virtual address that happens to map to
it. This is process specific, and I can’t see how WinDbg, which has no
Kernel component (it just uses a few Native API functions), could do
this reliably without (at least) taking control of the machine and,
possibly, creating a virtual address mapping for the physical address in
whatever context you happen to be in. This might itself fail because
(using the NT API since somewhere along the lines of 2000 SP4), attempts
to map a physical address to more than one range with differing cache
attributes fails (to prevent TLB corruption).

I gave up because I was in the fortunate position of having SoftICE as a
possibilty (it is what I used for years before WinDbg). If this is
remotely a possibily for you, this is what I would strongly recommend.
If this is not, your two options, as I see them, assuming that you can
not find someone who can give you a better idea of the likelihood of
getting LKD working, are (1) to use some sort of IOCTL to query the
memory from user mode with the help of your driver; (2) map the
physical address range you are interested in directly in to the virtual
address space of the context of a user mode program (ala MapMem from an
older DDK). As neither is attractive, I would go with option two (on a
readonly basis) as it is much more convenient, albeit remarkably unsafe.

I hope this helps.

MM

>>> bbrown@mc.com 2005-11-30 13:36 >>>
Whcihc commands should I expect to work when doing local kernel
debugging? I am trying to read a physical; memory location on my device.
I know I can access the device because I have an app talking to it
through the driver. However, I’m getting the following error when I try
to read a memory location:

lkd> !dd [uc] fe400000
Physical memory read at fe400000 failed

Should I expect this to work?

Beverly

—
You are currently subscribed to windbg as: unknown lmsubst tag
argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

—
You are currently subscribed to windbg as: bbrown@mc.com To unsubscribe
send a blank email to xxxxx@lists.osr.com

OSR_Community_User · December 2, 2005, 11:29am

Maybe so, but I can’t use softICE with remote desktop.

Beverly

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of jim
Sent: Friday, December 02, 2005 10:59 AM
To: Kernel Debugging Interest List
Subject: Re:[windbg] Local Kernel Debuging

May now, you are very impressed with softice.

The job you wanted to do is childs play in softice.

“Brown, Beverly” wrote in message news:xxxxx@windbg…
I understand the reasons behind not allowing breakpoints, etc. I’m OK
with that. I have tried using SoftICE in the past and quite frankly I’m
not very impressed with it. I wouldn’t be able to use it via remote
desktop, for example.

As far as accessing memory locations, I understand all the issues with
accessing virtual addresses as they are process-specific. But a physical
device address (will never be used for a paging operation) should be
accessible. I have in the past successfully accessed global kernel
variables and can access system memory if I give it a physical address.
Of course the contents of those locations can change at any time unless
it is locked in memory. However I have succesffuly accessed common
buffers in this way. I should be able to do the same with device memory,
but for some reason that doesn’t work.

Beverly

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Martin O’Brien
Sent: Wednesday, November 30, 2005 4:50 PM
To: Kernel Debugging Interest List
Subject: Re: [windbg] Local Kernel Debuging

BEVERLY:

The skinny is that, as a best case scenario, no
command/meta-command/extension command that would cause the machine to
halt may be used. This, in my opnion, makes LKD remarkably useless.
For example, you can not break in to the debugger, resume, set
breakpoints, examine registers, et. c. In your particular case, while I
can’t be certain, I seriously doubt that reading physical memory would
work reliably under this conditions. The basic issue is that, from the
host CPU/Debugger perspective, in order to address a physical address,
it must first be equated with a virtual address that happens to map to
it. This is process specific, and I can’t see how WinDbg, which has no
Kernel component (it just uses a few Native API functions), could do
this reliably without (at least) taking control of the machine and,
possibly, creating a virtual address mapping for the physical address in
whatever context you happen to be in. This might itself fail because
(using the NT API since somewhere along the lines of 2000 SP4), attempts
to map a physical address to more than one range with differing cache
attributes fails (to prevent TLB corruption).

I gave up because I was in the fortunate position of having SoftICE as a
possibilty (it is what I used for years before WinDbg). If this is
remotely a possibily for you, this is what I would strongly recommend.
If this is not, your two options, as I see them, assuming that you can
not find someone who can give you a better idea of the likelihood of
getting LKD working, are (1) to use some sort of IOCTL to query the
memory from user mode with the help of your driver; (2) map the
physical address range you are interested in directly in to the virtual
address space of the context of a user mode program (ala MapMem from an
older DDK). As neither is attractive, I would go with option two (on a
readonly basis) as it is much more convenient, albeit remarkably unsafe.

I hope this helps.

MM

>>> bbrown@mc.com 2005-11-30 13:36 >>>
Whcihc commands should I expect to work when doing local kernel
debugging? I am trying to read a physical; memory location on my device.
I know I can access the device because I have an app talking to it
through the driver. However, I’m getting the following error when I try
to read a memory location:

lkd> !dd [uc] fe400000
Physical memory read at fe400000 failed

Should I expect this to work?

Beverly

—
You are currently subscribed to windbg as: unknown lmsubst tag
argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

—
You are currently subscribed to windbg as: bbrown@mc.com To unsubscribe
send a blank email to xxxxx@lists.osr.com

—
You are currently subscribed to windbg as: bbrown@mc.com To unsubscribe
send a blank email to xxxxx@lists.osr.com

OSR_Community_User · December 2, 2005, 11:36am

No, but you can use SoftICE remotely over an ordinary network.

Phil

Philip D. Barila
Seagate Technology LLC
(720) 684-1842

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Friday, December 02, 2005 9:28 AM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Local Kernel Debuging

Maybe so, but I can’t use softICE with remote desktop.

Beverly

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of jim
Sent: Friday, December 02, 2005 10:59 AM
To: Kernel Debugging Interest List
Subject: Re:[windbg] Local Kernel Debuging

May now, you are very impressed with softice.

The job you wanted to do is childs play in softice.