跟踪数据执行保护 (DEP)
在运行我们的一款软件时，测试人员遇到了Windows的数据执行阻止对话框。
我们尝试在开发人员计算机上重现这种情况以进行调试：但没有成功。
有谁知道如何找到可能导致 DEP 保护杀死应用程序的原因？ 有可用的现有工具吗？
When running one of our software, a tester was faced with the data execution prevention dialog of Windows.
We try to reproduce this situation on a developer computer for debugging purposes : with no success.
Does anyone know how to find what may cause the DEP protection to kill the application?
Is there any existing tools available for this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
DEP 对话框通常仅在您尝试从未标记为可执行的区域执行代码时显示。 这可能是由您正在使用的库（例如 ATL 窗口）中的“thunk”引起的。 此问题在 ATL 8.0 中得到修复。
通过将返回地址设置为不可执行的位置，堆栈垃圾错误（例如缓冲区溢出）也可能导致此问题。 如果 DEP 为进程关闭或在硬件上不可用，这可能不会导致访问冲突，而是会导致奇怪的行为。
如果您引发 C++ 异常或引发 SEH 异常，并且您的结构化异常处理程序因缓冲区溢出而被废弃，也可能会发生这种情况。
The DEP dialog will typically only show when you try to execute code from a region that you're not marking as executable. This might be caused by 'thunks' in a library you're using, e.g. ATL windowing. This problem is fixed in ATL 8.0.
A stack-trashing bug - for example, a buffer overrun - can also cause this problem, by setting the return address to a location that isn't executable. This might not cause an access violation but instead weird behaviour, if DEP is turned off for the process or not available on the hardware.
It might also happen if you throw a C++ exception or raise an SEH exception, and your structured exception handlers have been trashed by a buffer overrun.
我认为任何时候你尝试写入未分配的内存时，这都可能是一个结果。 可以是删除对象然后使用它，或者将字符串写入太小而无法容纳它的缓冲区中的任何内容。
Potentially I would think any time you try to write to memory that isn't allocated this would be a possible result. Could be anything along the lines of deleting an object then using it, or writing a string into a buffer which is too small to hold it.
DEP 受硬件功能的影响。 我们最近遇到了一种情况，我们的应用程序在旧机器上运行良好，但在新机器上会失败。 事实证明，尽管在旧服务器和新服务器上都启用了 DEP，但我们在新服务器上崩溃了，因为硬件检测更好、更积极，或者类似的原因。 因此，如果您的 QA 可以重现，但 DEV 不能，那么请使用相同的硬件进行尝试...尽管 QA 拥有比开发人员更新/更好的 PC 似乎不合理...我完全相信！
以下是我对最近这方面经验的记录：
Indy 9 和 Windows Server 2003 之间不兼容？
DEP is influenced by the presence of hardware capability. We recently had a situation where our app ran fine on old machines, but would fail on new ones. It turned out that although DEP was enabled on both the old servers and the new servers, we crashed on the new ones because the hardware detection was better, more aggressive, or something like that. So if your QA can reproduce but the DEV can't, then try it with identical hardware... Although it seems unreasonable that the QA would have a newer/better PC than the dev... I totally believe it!
Here are my notes on our recent experience with this:
Incompatibilities between Indy 9 and Windows Server 2003?