why memory break point does not work

I use ba r1 address to set breakpoint to see who is changing the memory, and it does not stop when the data has been changed. I tried memcpy to that address from my code and windbg stops right way at the memory access. I tried r1, r2, r4, r8 and none of them works.
It is a disk filter driver, and the application Hyper-v. The guest os has some problem to get the right data to boot. Does the virtual machine have any impact on the memory break point? Or under what circumstance memory break point does not work?

Thanks
Jin

Or under what circumstance memory break point does not work?

normally hardware breakpoints viz ba breakpoints do not fail

there is a caveat when you set a data breakpoint in user mode it may
not trigger if context switch happens (you can experience this when
you set ba bps on early process creation traces especially when
(Nt/Zw)Continue calls are made ) and you can try .apply_dbp (dot apply
data breakpoints command for applying the bps to a different register
context)

0:000> ba e1 windbg!wmain
^ Unable to set breakpoint error
The system resets thread contexts after the process
breakpoint so hardware breakpoints cannot be set.
Go to the executable’s entry point and set it then.
‘ba e1 windbg!wmain’
0:000> bp ntdll!NtContinue
0:000> g
ModLoad: 5cb70000 5cb96000 C:\WINDOWS\system32\ShimEng.dll
ModLoad: 76390000 763ad000 C:\WINDOWS\system32\IMM32.DLL
Breakpoint 0 hit
eax=00000000 ebx=7ffdc000 ecx=7c91b02a edx=7c90e514 esi=00f6f746 edi=0007fd30
eip=7c90d05e esp=0007fd24 ebp=00000000 iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246
ntdll!NtContinue:
7c90d05e b820000000 mov eax,20h
0:000> ba e1 windbg!wmain
0:000> bl
0 e 7c90d05e 0001 (0001) 0:**** ntdll!NtContinue
1 e 010550f0 e 1 0001 (0001) 0:**** windbg!wmain
0:000> .bpcmds
bp0 0x7c90d05e ;
ba1 e1 0x010550f0 ;
0:000> bp 010550fa
0:000> .bpcmds
bp0 0x7c90d05e ;
ba1 e1 0x010550f0 ;
bp2 0x010550fa ;
0:000> g

Breakpoint 2 hit ------------------- hardware bp didn’t work here
but software bp set a few instructions later got hit

eax=0000203c ebx=00000000 ecx=0107a584 edx=00000000 esi=00000001 edi=0107a584
eip=010550fa esp=0007ff7c ebp=0007ff7c iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246
windbg!wmain+0xa:
010550fa e8c13b0000 call windbg!_alloca_probe (01058cc0)

other possible reason might be some antidebugged app meddling with
debug register and disabling hw bps

not sure about hyper-v but using vms in general haven’t displayed any
impact afaik

On 7/19/12, ren.j@263.net <ren.j> wrote:
> I use ba r1 address to set breakpoint to see who is changing the memory, and
> it does not stop when the data has been changed. I tried memcpy to that
> address from my code and windbg stops right way at the memory access. I
> tried r1, r2, r4, r8 and none of them works.
> It is a disk filter driver, and the application Hyper-v. The guest os has
> some problem to get the right data to boot. Does the virtual machine have
> any impact on the memory break point? Or under what circumstance memory
> break point does not work?
>
> Thanks
> Jin
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
></ren.j>

I’m confused. You’ve set a read breakpoint on data in the guest OS? Or in
the management OS?

The read breakpoint should work whenever you’re running a virtual processor
that has that value set in its debug registers. (This sort of breakpoint
relies on the debug registers.) So if you set the breakpoint in the
management OS, then you should expect to see it hit if the management OS
does the read. You shouldn’t expect to see it hit if the guest OS does the
read.

Jake Oshins
Windows Kernel Team

The message offers no warranties and confers no rights.

wrote in message news:xxxxx@ntdev…

I use ba r1 address to set breakpoint to see who is changing the memory, and
it does not stop when the data has been changed. I tried memcpy to that
address from my code and windbg stops right way at the memory access. I
tried r1, r2, r4, r8 and none of them works.
It is a disk filter driver, and the application Hyper-v. The guest os has
some problem to get the right data to boot. Does the virtual machine have
any impact on the memory break point? Or under what circumstance memory
break point does not work?

Thanks
Jin

The driver is installed on host machine A. I’m using my laptop B connecting to A using serial port. And the test is to boot a guest os on host A in Hyper-v.
I get the buffer using MmGetSystemAddressForMdlSafe, and copy data from my cache to the buffer. Interesting thing is that if I do memcmp right after memcpy, the two content of the two buffers are different. That is why I want to set a memory break point to find who is changing the memory.

Raj, this should be in kernel and the case you said should not apply, is that correct? The host machine is a clean installed 2008 so should have no antidebugged program.

Memory contents could be changed through a different virtual mapping (for example, the calling user app could write to the buffer’s user address from another thread) or through DMA. In either case data breakpoints set on the MDL’s system mapping would not fire.

Dummy pages are one common scenario in which MDL page contents can appear to change spontaneously:

http://msdn.microsoft.com/en-us/library/windows/hardware/gg463193.aspx

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of ren.j@263.net
Sent: Thursday, July 19, 2012 1:46 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] why memory break point does not work

The driver is installed on host machine A. I’m using my laptop B connecting to A using serial port. And the test is to boot a guest os on host A in Hyper-v.
I get the buffer using MmGetSystemAddressForMdlSafe, and copy data from my cache to the buffer. Interesting thing is that if I do memcmp right after memcpy, the two content of the two buffers are different. That is why I want to set a memory break point to find who is changing the memory.

Raj, this should be in kernel and the case you said should not apply, is that correct? The host machine is a clean installed 2008 so should have no antidebugged program.


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

How do you do call memcmp and memcpy? Show the code.

old_buffer = MmGetSystemAddressForMdlSafe(Irp->MdlAddress,NormalPagePriority);//Skipped some error handling here.

memcpy( os_buffer, buffer, currentIrpStack->Parameters.Read.Length );

if( memcmp( buffer,os_buffer,currentIrpStack->Parameters.Read.Length ) )
DbgPrint( “data error at lba %lld”,lba );

The buffer did not change.

Sorry, it should be
os_buffer = MmGetSystemAddressForMdlSafe…

Similarly, breakpoints set with a user mode debugger won’t fire if a kernel mode component performs the modification, such as a system call or an IOCTL to a driver.

  • S (Msft)

From: xxxxx@lists.osr.com [xxxxx@lists.osr.com] on behalf of Pavel Lebedynskiy [xxxxx@microsoft.com]
Sent: Thursday, July 19, 2012 3:04 PM
To: Windows System Software Devs Interest List
Subject: RE: RE:[ntdev] why memory break point does not work

Memory contents could be changed through a different virtual mapping (for example, the calling user app could write to the buffer’s user address from another thread) or through DMA. In either case data breakpoints set on the MDL’s system mapping would not fire.

Dummy pages are one common scenario in which MDL page contents can appear to change spontaneously:

http://msdn.microsoft.com/en-us/library/windows/hardware/gg463193.aspx

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of ren.j@263.net
Sent: Thursday, July 19, 2012 1:46 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] why memory break point does not work

The driver is installed on host machine A. I’m using my laptop B connecting to A using serial port. And the test is to boot a guest os on host A in Hyper-v.
I get the buffer using MmGetSystemAddressForMdlSafe, and copy data from my cache to the buffer. Interesting thing is that if I do memcmp right after memcpy, the two content of the two buffers are different. That is why I want to set a memory break point to find who is changing the memory.

Raj, this should be in kernel and the case you said should not apply, is that correct? The host machine is a clean installed 2008 so should have no antidebugged program.


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Hi Pavel,
the link you posted seems to be very relevant condering vhd file has a large amount of non-consecutive page. I will give it try tomorrow.

If the MDL is properly locked for READ operation, it should not contain dummy pages. All pages must be writable.

> If the MDL is properly locked for READ operation, it should not contain dummy pages. All pages must be writable.

Win8 can use read-only dummy pages to fill gaps in MDLs used for pagefile writes.

In any case, the situation the OP described seems to be a read IO operation (so the MDL is locked for write access). In that scenario dummy pages have been used since Vista.

Allocating new temporary buffer fixed the problem. Previously, I reuse the original Irp to read data from disk and cache it in my driver. Apparently some of the pages in the mdl are dummy pages and are not supposed to be cached. Thanks to Pavel and all other people. I would never figure it out in a million years without your help!

>In any case, the situation the OP described seems to be a read IO operation (so
the MDL is locked for write access). In that scenario dummy pages have been used
since Vista.

Wait, so when the driver writes to the system-mapped address at DISPATCH_LEVEL, it will cause a page fault and a real page will be substituted transparently? What is a real page is not available at that time?

>Wait, so when …
For a read request, I don’t know what does system do when I copy data into the dummy pages. Maybe it won’t cause a page fault becasue Windows does not care about the data? Anyway, that is why the memory keeps changing after I copied data into it, more precisely, only some of the pages keep changing.

>Wait, so when the driver writes to the system-mapped address at

DISPATCH_LEVEL, it will cause a page fault and a real page will be
substituted >transparently?

The VA range is valid, it’s just that some pages map to the same global
“dummy” PFN. Thus no page fault occurs in this case, the data is just
(essentially) thrown away.

-scott


Scott Noone
Consulting Associate and Chief System Problem Analyst
OSR Open Systems Resources, Inc.
http://www.osronline.com

wrote in message news:xxxxx@ntdev…

In any case, the situation the OP described seems to be a read IO operation
(so
the MDL is locked for write access). In that scenario dummy pages have been
used
since Vista.

Wait, so when the driver writes to the system-mapped address at
DISPATCH_LEVEL, it will cause a page fault and a real page will be
substituted transparently? What is a real page is not available at that
time?

>The VA range is valid, it’s just that some pages map to the same global “dummy” PFN. Thus no page fault occurs in this case, the data is just (essentially) thrown away.

I don’t get it. An application issues a ReadFile. The driver gets an MDL locked for IoWriteAccess, writes data into the system-mapped address, and you’re saying the data will never make it to the application?

It’s a case like: the VMM wants to page in 64k, a 64k hole, and 64k from a contiguous location in the paging file. It does ONE read of 64k+a bunch of dummy pages all mapping to the same page, and the other 64k. ALL the data is read from the disk, but only 64k+64k are used.

Jan

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@broadcom.com
Sent: Friday, July 20, 2012 9:42 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] why memory break point does not work

The VA range is valid, it’s just that some pages map to the same global “dummy” PFN. Thus no page fault occurs in this case, the data is just (essentially) thrown away.

I don’t get it. An application issues a ReadFile. The driver gets an MDL locked for IoWriteAccess, writes data into the system-mapped address, and you’re saying the data will never make it to the application?


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer