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 :-)
* Reference: Intel 64 and IA-32 Architectures Software Developer’s Manual Volume 3A: System Programming Guide, Part 1 [page 16-4]
** As far as I know, this is how Ollydbg implements its memory access breakpoint support.
I alluded to the existence of a parallel programming course in my previous post about the SDP. This three-day course, Parallel Programming in .NET 4.0 [DNParallel], was born a few weeks ago following intense work by Bnaya Eshet and yours truly.
The syllabus can be broken roughly into the following:
- Introduction to processes, threads, and the thread pool
- Explicit (task) parallelism—creating and managing tasks and continuations
- Implicit (data) parallelism—parallelizing loops and LINQ queries
- Synchronization mechanisms, including lock-free code, memory models, thread-local storage, and kernel synchronization mechanisms
- Task schedulers
- Concurrent (thread-safe, lock-free) collections
- Architecture styles and design patterns, including case studies for parallelizing algorithms and managing dependencies
- Optimization tips and tricks, cache coherence matters, profiling
The course is packed with demos, including a gorgeous parallelism visualizer written by Bnaya:
There are also labs in which students implement parallel algorithms and parallelize existing programs, as well as practice introductory profiling and debugging scenarios.
Finally, I’m happy to announce that if you were at my SDP session on Parallel Programming (SVR201), you are entitled to a 20% discount for the next course! You can register through SELA, or if there’s a problem—write me through the contact form.
It’s been a busy couple of months! The SELA Developer Practice, SELA’s annual conference for .NET developers, has taken place on March 13-16 in SELA’s offices and the Crowne Plaza hotel in Tel-Aviv.
Dear conference attendees: thanks for being there! I personally appreciate your coming to the sessions, mingling with the speakers, telling us your pain points and participating in active discussions. I hope to see you again next year, and if there’s any feedback you have or tips for us to improve the conference, please feel free to use the comments or the contact form.
I delivered four sessions at the SDP:
- One-day .NET Debugging tutorial (fairly similar to last year’s), packed with demos and labs covering various debugging scenarios, including miscellaneous crashes, memory leaks, deadlocks, and their kin. [The materials for this session will be distributed separately, as it is based on the full .NET Debugging course]
- Programming Languages in the 2010s—a session in the decision makers track in which I tried to highlight the significant changes the mainstream programming languages (C#, C++) are undergoing in the last few years. Among the things we discussed were concurrency, declarative constructs in the languages, and DSLs. [Download the slide deck]
- Parallel Programming in .NET 4.0 and C# 5 Async Methods—unlike last year’s session, this time I was armed with more practical experience and a full-blown Parallel Programming course. What we covered was the primary APIs—task parallelism and data parallelism—and the scenarios in which it is appropriate to use each. We also discussed async methods, a likely addition to C# 5, which is the first time concurrency “leaks” into the language. [Download the slide deck and demos]
- MVP Panel—in which there were several primary trends: Silverlight 5, HTML 5, Windows Phone 7 and the in-between; ORMs; and the world of TFS. We took questions from the audience and nearing the end of the second hour had a couple of very interesting discussions around practical, real-world uses of ORMs.
Finally, the conference has been recorded—so all the sessions should become available for online viewing. Follow the conference website for news. [At the time of writing, the “Play” links under some presentations lead to promotion videos of these sessions, recorded at a live sprint before the conference, and not the actual video recording.]
Again, thanks for coming, and see you all next year!