Memory Access Breakpoint for Large Ranges using VirtualProtect

Visual Studio has had hardware-assisted memory access breakpoints for quite some time now—they are called data breakpoints and, unfortunately, can be used only for unmanaged code. WinDbg has a similar feature with the ba command, which is more flexible because it can be configured to fire when a memory location is read, not just written. (Of course, WinDbg does not have the managed/unmanaged limitation either, but you still have to exercise caution because managed objects may move in memory every time a garbage collection occurs, which would require you to reconfigure the hardware breakpoints.)

This type of breakpoint is implemented using hardware support from the CPU. On Intel platforms, the DR0-DR7 debug registers are used to enable hardware breakpoints on reading/writing memory locations. For example, to set a hardware breakpoint on reads and writes to four bytes at the address 0x01000100 you set DR0 to this address, and set bits 0, 16, 17, 18, 19 of DR7 to 1.

This is a great feature, and its only limitation is that the area watched by the breakpoint is at most 4 bytes (on 32-bit processors) or 8 bytes (on 64-bit processors)*. In other words, if you have a large array that is being corrupted in a random location once in a while, you can’t figure out the source of the corruption using hardware breakpoints.

What you could do, however, is the following trick**. Suppose for a moment that you large array resides precisely on page boundaries, e.g. an array of 4,096 integers that starts on a page boundary and ends after four pages (x86 pages are 4KB). Then what you could do is:

• Temporarily change the virtual memory protection of that page to PAGE_GUARD.
• Subsequent accesses (reads or writes) to that page will raise a special exception, a guard page violation.
• Your debugger could catch this exception, verify that it occurred on access to that special address, and notify you that a breakpoint occurred.
• When you want to continue execution, the debugger could allow the memory access to go through, set the PAGE_GUARD flag again, and proceed.

Although this is fairly tedious (or impossible) to accomplish in Visual Studio, it sounds like a great task for a WinDbg extension which I might write one day. In the meantime, we can use the SDbgExt extension which exports the !vprotect command, wrapping the VirtualProtectEx Win32 API.

Here’s a sample debugging scenario with that idea in mind. The program being debugged is the following:

int* g_arr;
 
int _tmain(int argc, _TCHAR* argv[])
{
	g_arr = new int[10000];
	for (int i = 0; i < 10000; ++i) g_arr[i] = 0;
	getchar();
	int n = rand() % 10000;
	g_arr[n] = n;
	printf("%d\n", g_arr[n]);
	return 0;
}

…and we are interested in stopping on the red line, which modifies a random location inside the array. Unfortunately, nothing guarantees that the array resides on page boundaries, so we might get PAGE_GUARD exceptions when something within the process attempts to access a memory location close to our array. This is something a real debugger extension would have to handle, too.

0:000> x *!g_arr
00d0715c myapp!g_arr = 0x00590068
0:000> .load c:\temp\sdbgext
0:000> !vprotect 0x00590068 0n10000 104
Protection changed (old protection 4).
0:000> g
(1f54.1c0c): Guard page violation - code 80000001 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
…snipped for brevity…
myapp!wmain+0x9e:
00d0337e 891481          mov     dword ptr [ecx+eax*4],edx ds:002b:0059010c=00000000
0:000> .exr -1
ExceptionAddress: 00d0337e (myapp!wmain+0x0000009e)
   ExceptionCode: 80000001 (Guard page violation)
  ExceptionFlags: 00000000
NumberParameters: 2
   Parameter[0]: 00000001
   Parameter[1]: 0059010c
0:000> ? (0059010c-0x00590068)/4
Evaluate expression: 41 = 00000029
0:000> dv n
              n = 41
0:000> gh

…and the program terminates peacefully with the output “41”.

If you would like to see something like that implemented as a debugger extension, feel free to do so and let me know, or write enough encouraging comments and I might just do it myself :-)