FogBugz 6（及更早版本）要求在具有 DEP 的 Windows 版本上禁用数据执行保护 (DEP)，因为我们使用第三方 COM 组件来解析电子邮件。 我们将在 FogBugz 的下一个主要版本中修复此问题：FogBugz 将不再使用此第三方组件（事实上，FogBugz 的下一个版本将不会使用任何 COM 组件）。
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).
打开它并使用调试器查看它在哪里崩溃:) 我遇到了一些 COM 组件，这些组件将从触发 DEP 异常的数据块中执行一些代码。 我愿意猜测 FogBugz 也在访问某些执行相同操作的本机组件。
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.
正如上面的 FogBugz 链接所说，“但是请注意，启用 DEP 后 FogBugz 将无法正常工作。”。
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.".
关闭 DEP 的最常见原因是以编程方式在堆栈或堆上生成的 thunk。 Windows 内核模拟最常见的内核，但“最常见”并没有很好的覆盖范围。
关闭 DEP 的第二个最常见原因是错误链接的代码段看起来像是数据段。
第三个最常见的原因是字符串中的机器代码。 一般来说，这是一种非常糟糕的风格，但有时在 Windows 上这是无济于事的。
第四个最常见的原因是代码中的某些算法假定了堆栈布局。 DEP 搞乱了这一点。
或者程序可能确实在堆缓冲区上运行代码。
Not knowing the specifics of FogBugz, but...
The most common reason for turning off DEP is programmatically generated thunks on the stack or the heap. The Windows Kernel emulates the most common ones but "most common" wasn't very good coverage.
The second most common reason for turning off DEP is incorrectly linked code segments that appear to be data segments.
The third most common reason is machine code in strings. In general, this is really bad style but sometimes on Windows it cannot be helped.
The fourth 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.
发布评论
评论（5）
FogBugz 6（及更早版本）要求在具有 DEP 的 Windows 版本上禁用数据执行保护 (DEP)，因为我们使用第三方 COM 组件来解析电子邮件。 我们将在 FogBugz 的下一个主要版本中修复此问题：FogBugz 将不再使用此第三方组件（事实上，FogBugz 的下一个版本将不会使用任何 COM 组件）。
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).
打开它并使用调试器查看它在哪里崩溃:) 我遇到了一些 COM 组件，这些组件将从触发 DEP 异常的数据块中执行一些代码。 我愿意猜测 FogBugz 也在访问某些执行相同操作的本机组件。
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.
尝试修补或插入挂钩到其地址空间内的其他模块的代码通常无法工作，除非禁用 DEP，或者适当的 内存保护选项是为已安装的挂钩设置的。
这是某些框架（例如 Delphi）的常见技术，其中“补丁”在运行时动态应用以修复供应商尚未解决的错误。
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.
我只是不喜欢在服务器环境中关闭 DEP，因为现代最先进的软件无法处理它。 特别是因为它是我多年来尝试过的唯一需要它的软件。
在安装过程中我遇到了 DEP 警报。
正如上面的 FogBugz 链接所说，“但是请注意，启用 DEP 后 FogBugz 将无法正常工作。”。
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 的具体情况，但是...
关闭 DEP 的最常见原因是以编程方式在堆栈或堆上生成的 thunk。 Windows 内核模拟最常见的内核，但“最常见”并没有很好的覆盖范围。
关闭 DEP 的第二个最常见原因是错误链接的代码段看起来像是数据段。
第三个最常见的原因是字符串中的机器代码。 一般来说，这是一种非常糟糕的风格，但有时在 Windows 上这是无济于事的。
第四个最常见的原因是代码中的某些算法假定了堆栈布局。 DEP 搞乱了这一点。
或者程序可能确实在堆缓冲区上运行代码。
Not knowing the specifics of FogBugz, but...
The most common reason for turning off DEP is programmatically generated thunks on the stack or the heap. The Windows Kernel emulates the most common ones but "most common" wasn't very good coverage.
The second most common reason for turning off DEP is incorrectly linked code segments that appear to be data segments.
The third most common reason is machine code in strings. In general, this is really bad style but sometimes on Windows it cannot be helped.
The fourth 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.