C++ DX11应用程序仅在Visual Studio IDE中运行
好吧，我在 MSDN 论坛上提出了这个问题，但尚未收到任何回复，所以我想我应该尝试一下 StackOverflow。
我目前正在Win7上使用VS2008开发DirectX应用程序。我最近经历了一个令人讨厌的内存损坏错误，内存分配类抓取了字节对齐的内存。在此错误期间，我仍然可以运行调试和发布可执行文件，但是由于指令损坏或其他原因，它会崩溃，但它仍然会执行一段时间，直到崩溃。
然后我删除了整个内存分配类。该应用程序在 IDE 中完美运行（发布和调试版本），但我根本无法运行任何可执行文件。他们立即因无响应/停止工作错误而崩溃。我不认为这是我的环境的问题，因为我在另一台之前没有问题的计算机上遇到了同样的问题。
Dependency walker 给出“警告：至少未找到一个延迟加载依赖模块。警告：由于延迟加载依赖模块中缺少导出函数，至少有一个模块具有未解析的导入。”错误并表明找不到 GPSVC.dll 和 IESHIMS.DLL。我读到这可能会产生误导，只是表明某个地方存在潜在问题。并且 Dependency walker 前一天没有给我这个错误。
我没有修改任何配置或项目设置或添加新代码。知道什么可能导致这种行为吗？
另请注意，我在同一天安装了 Windows 7.1 sdk。认为这可能是某种与编译器相关的错误？
以防万一 MSDN 帖子上弹出一些有用的信息，这里是链接 http://social.msdn.microsoft.com/Forums/en-IE/vsdebug/thread/f692b394-8af2-4453-991c-aa6a443a9019
谢谢！
编辑 -
这是 Dependency Walker 分析输出的最后几行
GetProcAddress(0x76CD0000 [c:\windows\syswow64\KERNEL32.DLL], "DecodePointer") 从地址 0x6D8BAE4F 处的“c:\windows\syswow64\NVWGF2UM.DLL”调用并返回 0x77B59D65。 GetProcAddress(0x76CD0000 [c:\windows\syswow64\KERNEL32.DLL], "DecodePointer") 从地址 0x6D8BAE4F 处的“c:\windows\syswow64\NVWGF2UM.DLL”调用并返回 0x77B59D65。 GetProcAddress(0x76CD0000 [c:\windows\syswow64\KERNEL32.DLL], "EncodePointer") 从地址 0x6D8BAF60 处的“c:\windows\syswow64\NVWGF2UM.DLL”调用并返回 0x77B60FDB。 GetProcAddress(0x76CD0000 [c:\windows\syswow64\KERNEL32.DLL], "DecodePointer") 从地址 0x6D8BAF70 处的“c:\windows\syswow64\NVWGF2UM.DLL”调用并返回 0x77B59D65。 第二次机会异常 0xC0000005（访问冲突）发生在地址 0x0110152E 的“c:\users\joel\desktop\DXAPP.EXE”中。 退出“c:\users\joel\desktop\DXAPP.EXE”（进程 0x27D8），代码为 255 (0xFF)。
这是指 DLL 获取空指针还是我的实际指令？我将快速阅读有关如何使用 WinDbg 的信息，如果这不能立即解决该问题，我将发布它的输出。
编辑 2 -
只需运行应用程序并点击“调试”即可启动 Visual Studio，我就会一直到编译着色器的位置。我目前假设问题的根源在于此。但是，我仍然不明白使用 IDE 和不使用 IDE 之间执行期间行为的变化。
解决方案！ -
我对之前的内存损坏错误感到非常困惑，以至于我没有意识到我的着色器不在可执行文件的本地目录中。这反过来又生成了一个空指针，该指针在调用 D3DX11CompileFromFile() 后未正确处理。
Alright, I presented this question on the MSDN forums but have yet to receive any kind of response so I figured I'd give StackOverflow a try.
I'm currently developing a DirectX application using VS2008 on Win7. I recently experienced a nasty memory corruption bug with a memory allocation class that grabbed byte aligned memory. During this bug I could still run the debug and release executables however it would crash due the instructions getting corrupted or whatever, but it would still execute for a bit until the crash.
I then stripped out the entire memory allocation class. The application runs perfectly in the IDE (release and debug builds) but I can't run any of the executables at all. They immediately crash with a non-responding/stop working error. And I don't think it is my environment because I get the same issue on another computer that wasn't having problems before either.
Dependency walker gives a "Warning: At least one delay-load dependency module was not found. Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module." error and indicates that GPSVC.dll and IESHIMS.DLL can't be found. I've read that this can be misleading and just indicates a potential problem somewhere. And Dependency walker wasn't giving me this error the day before.
I haven't tinkered with any of the configuration or project settings or added new code. Any idea of what could be causing this behavior?
Also another note, I installed the Windows 7.1 sdk the same day. Think this could be some kind of compiler related bug?
Just in case some useful information pops up on the MSDN post, here is the link
http://social.msdn.microsoft.com/Forums/en-IE/vsdebug/thread/f692b394-8af2-4453-991c-aa6a443a9019
Thanks!
Edit -
Here is the last couple lines of Dependency Walker's profiling output
GetProcAddress(0x76CD0000 [c:\windows\syswow64\KERNEL32.DLL], "DecodePointer") called from "c:\windows\syswow64\NVWGF2UM.DLL" at address 0x6D8BAE4F and returned 0x77B59D65.
GetProcAddress(0x76CD0000 [c:\windows\syswow64\KERNEL32.DLL], "DecodePointer") called from "c:\windows\syswow64\NVWGF2UM.DLL" at address 0x6D8BAE4F and returned 0x77B59D65.
GetProcAddress(0x76CD0000 [c:\windows\syswow64\KERNEL32.DLL], "EncodePointer") called from "c:\windows\syswow64\NVWGF2UM.DLL" at address 0x6D8BAF60 and returned 0x77B60FDB.
GetProcAddress(0x76CD0000 [c:\windows\syswow64\KERNEL32.DLL], "DecodePointer") called from "c:\windows\syswow64\NVWGF2UM.DLL" at address 0x6D8BAF70 and returned 0x77B59D65.
Second chance exception 0xC0000005 (Access Violation) occurred in "c:\users\joel\desktop\DXAPP.EXE" at address 0x0110152E.
Exited "c:\users\joel\desktop\DXAPP.EXE" (process 0x27D8) with code 255 (0xFF).
Is this referring to a DLL grabbing a null pointer or to my actual instructions? Going to read up on how to use WinDbg real quick and I'll post it's output if this doesn't shed any immediate light on the issue.
Edit 2 -
Simply running the application and hitting debug to bring up Visual Studio consistently brought me to where I'm compiling my shaders. I'm assuming at the moment that the root of the problem lies around this. However, I still don't understand the change of behavior during execution between using the IDE and not.
Solution! -
I was so thrown off by the previous memory corruption bug that I didn't realize my shaders weren't in a local directory to the executables. This in turn was generating a null pointer that wasn't handled properly after calling D3DX11CompileFromFile().
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
射击，抱歉，我想将此作为评论发布......
我只能建议更多的诊断尝试。
一种方法是从 Depends 内部分析应用程序，这还将显示动态 DLL 加载，并可能显示新的内容。它还捕获调试输出。它的行为可能与在调试器本身中启动不同并提供线索。您没有提到实际的分析，所以我想我会建议您这样做，以防万一您没有提到。另外，请密切注意 DLL 加载的路径 - 您可能会对 DLL 从非预期位置加载感到惊讶。
另一个建议是尝试在崩溃后附加到已停止的应用程序（在关闭错误对话框之前）。看看是否可以从中获取堆栈跟踪或任何内容。
最后尝试附加（甚至从）WindDbg 而不是 IDE 启动。与 Depends 配置文件一样，调试器行为及其挂钩应用程序方式的差异可能会导致崩溃发生，同时提供您需要的线索。
祝你好运！
Shoot, sorry I meant to post this as a comment...
I can only suggest more diagnostic attempts.
One would be to profile the app from within Depends, this will also show dynamic DLL loads and might show something new. Also it captures the debug output. It may behave differently than launching in the debugger itself and provide a clue. You don't mention actually profiling so I thought I'd suggest it in case you hadn't. Also, pay very close attention to the paths for the DLL's loaded - you might be surprised at a DLL loading from a location other than you intended.
Another suggestion is to try at attach to the stopped app after the crash (before dismissing the error dialog). See if you can get a stack trace or anything out of it.
Finally try attaching (or even launching from) WindDbg rather than the IDE. Like the Depends profile, the difference in debugger behavior and how it hooks the app may allow the crash to happen, while providing the clues you need.
Good Luck!