<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Aug 15, 2014 at 10:03 AM, Zachary Turner <span dir="ltr"><<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Correct, AFAIK the only way to disable ASLR in Windows is:<div><br></div><div>a) Editing a registry setting which will require a reboot and be system-wide</div>
<div>b) Compiling your executable with a specific flag which has been set to enable ASLR by default since VS 2012.</div>
<div>c) Using the <a href="http://support.microsoft.com/kb/2458544" target="_blank">EMET utility</a>  (untested, but I guess should work).  Regardless, it's a manual step and would require elevation (aka sudo)</div><div>
<br></div><div>
Maybe it's just because I'm used to an environment where ASLR is per-boot, but what are the issues with debugging when ASLR is enabled?  Source/line breakpoints can just be resolved every time you debug.  Same with symbol breakpoints.  Even absolute address breakpoints can be translated to Module+offset and persist across ASLR.  The only things I can think of off the top of my head are hardware data breakpoints, and printing addresses to log files.  Is there other stuff that is complicated by ASLR?</div>
</div></blockquote></div><br>Watchpoints on heap-allocated memory (whether software or hardware).</div></div>