I am really wondering why FogBugz when installed locally insists that DEP is turned off?
Not knowing the specifics of FogBugz, but...
The most common reason for turning off DEP is incorrectly linked code segments that appear to be data segments.
The second most common reason is machine code in strings. In general, this is really bad style but sometimes on Windows it cannot be helped.
The third most common reason is some algorithm in the code assumed the stack layout. DEP messes with that.
Or perhaps the program really is running code on a heap buffer.
Turn it on and see where it crashes with a debugger :) I ran across some COM components that would execute some code from a data block that triggered a DEP exceptions. I would be willing to guess FogBugz is also accessing some native components somewhere that are doing the same.
Code that attempts to patch or insert hook into other modules within it's address space often won't work unless DEP is disabled, or the appropriate memory protection options are set for the installed hook.
This is a common technique with some frameworks (eg Delphi) where 'patches' are applied dynamically ar run-time to fix bugs that the vendor has not yet address.
I just don't like the idea to have DEP turned OFF in a Server environment because a modern state of the art software just can't handle it. Specially since it is the only software that I have tried over the years that have required it.
Its during the installation that I came across the DEP alert.
As the FogBugz link above says, " Be warned, however, that FogBugz will not function properly with DEP enabled.".
FogBugz 6 (and earlier) requires that Data Execution Prevention (DEP) be disabled on versions of Windows that have DEP, because of a third-party COM component that we use for parsing email. We will fix this in the next major release of FogBugz: FogBugz will no longer use this third-party component (in fact, the next version of FogBugz will not use any COM components).