I was using one of my home made debugging tools recently and it kept crashing :( I assumed it was something I was doing but I've eventually tracked it down to where I load the symbols for the loaded modules in the target process. Attempting to load the symbols for x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.2180_x-ww_a84f1ff9\\comctl32.dll leads to dbghelp.dll generating a BEX event (which appears to be either buffer overrun or data execution prevention related).
I don't think I'm doing anything too stupid. I start the target process using the Win32 debug API, stick a breakpoint in the main thread at the thread start location, and when the breakpoint is hit I unset it and suspend the thread (I also do this with any other threads that start before the main thread hits its breakpoint). Once all threads are suspended at a safe point I inject my code and wire things up which includes taking the module snapshot and loading the symbols for the target exe and all its dlls. At this point my app sometimes tanks with the BEX.
I assume it's a race condition somehow as it seems to work OK if run under the VS debugger... It seems a little weird though. For now my hacky fix is to simply skip loading symbols for the dll in question...
More as and when I find it...