64位MFC版本中的访问冲突异常
我正在尝试将 32 位应用程序移植到 64 位。计算似乎运行正确，但我无法正确配置视图。我在 W7 x64 机器上的 VS2005 中使用 MFC、C++ 和 OpenGL、Intel 10.0.027 编译器。
崩溃发生时，我收到以下消息：“3DApp.exe 中 0xffffffff8043b1b6 处的第一次机会异常：0xC0000005：位置 0xffffffff8043b1b6 处的访问冲突”，这是堆栈跟踪：
ffffffff8043b1b6()
user32.dll!UserCallWinProcCheckWow() + 0x11d bytes
user32.dll!DispatchMessageWorker() + 0x12a bytes
3DApp.exe!AfxInternalPumpMessage() Line 183 C++
3DApp.exe!CWinThread::PumpMessage() Line 896 C++
3DApp.exe!CWinThread::Run() Line 625 + 0x13 bytes C++
请注意为什么是 UserCallWinProcCheckWow被称为，我认为 Wow 后缀仅用于在 64 位计算机上模拟 32 位应用程序
显然，在某个地方 64 位指针被视为 32 位指针，但我无法确定发生这种情况的位置。我从微软加载了调试符号，它显示了调用堆栈的顶部。
非常感谢任何帮助。 Leon
编辑
调用 DispatchMessage 的代码是：
if (pState->m_msgCur.message != WM_KICKIDLE && !AfxPreTranslateMessage(&(pState->m_msgCur)))
{
::TranslateMessage(&(pState->m_msgCur));
::DispatchMessage(&(pState->m_msgCur));
}
pState 的指针在此阶段似乎是 64 位。
pState->m_msgCu 的状态：
- pState->m_msgCur {msg=0x00000022 wp=0x0000000000000000 lp=0x0000000000000000} tagMSG
- hwnd 0x0000000000020416 {未使用=0x00000000 } HWND__ * 消息 0x00000022 无符号整数 wParam 0x0000000000000000 无符号 __int64 lParam 0x0000000000000000 __int64 时间 0x000f3967 无符号长
- pt {x=0x0000030f y=0x00000356} tagPOINT
I am trying to port a 32bit application to 64 bit. The calculations appear to run correctly, but I cannot configure the views properly. I am using MFC, C++ and OpenGL, Intel 10.0.027 compiler inside VS2005 on a W7 x64 machine.
When the crash happens, I get the following message: "First-chance exception at 0xffffffff8043b1b6 in 3DApp.exe: 0xC0000005: Access violation at location 0xffffffff8043b1b6" and this is the stack trace:
ffffffff8043b1b6()
user32.dll!UserCallWinProcCheckWow() + 0x11d bytes
user32.dll!DispatchMessageWorker() + 0x12a bytes
3DApp.exe!AfxInternalPumpMessage() Line 183 C++
3DApp.exe!CWinThread::PumpMessage() Line 896 C++
3DApp.exe!CWinThread::Run() Line 625 + 0x13 bytes C++
NOTE PLEASE why is UserCallWinProcCheckWow called, I thought Wow suffix was only for emulating 32 bit applications on 64 bit computer
Obviously, somewhere a 64 bit pointer gets treated as a 32 bit pointer, but I cannot pin point where that happens. I loaded debug symbols from microsoft, which show the top of the call stack.
Any help greatly appreciated.
Leon
EDIT
The code calling DispatchMessage is:
if (pState->m_msgCur.message != WM_KICKIDLE && !AfxPreTranslateMessage(&(pState->m_msgCur)))
{
::TranslateMessage(&(pState->m_msgCur));
::DispatchMessage(&(pState->m_msgCur));
}
The pointers of pState appear to be 64 bit at this stage.
State of pState->m_msgCu:
- pState->m_msgCur {msg=0x00000022 wp=0x0000000000000000 lp=0x0000000000000000} tagMSG
- hwnd 0x0000000000020416 {unused=0x00000000 } HWND__ *
message 0x00000022 unsigned int
wParam 0x0000000000000000 unsigned __int64
lParam 0x0000000000000000 __int64
time 0x000f3967 unsigned long - pt {x=0x0000030f y=0x00000356} tagPOINT
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我刚刚解决了具有相同行为的问题。该错误在于将参数传递给 SetWindowLongPtr( GWLP_WNDPROC ) 时，指向 WndProc 的指针被错误地转换为 LONG 而不是正确的 LONG_PTR。这样，指向 WndProc 的错误指针被放入内部操作系统 WND 结构中，因此对 HWND 的 WndProc 的任何后续调用都会崩溃。
I have just fixed an issue with the same behavior. The bug was in passing parameters to SetWindowLongPtr( GWLP_WNDPROC ), pointer to WndProc was improperly casted to LONG instead of correct LONG_PTR. This way, bad pointer to WndProc was put into internal OS WND struct, so any following call to the HWND's WndProc crashed.
问题似乎发生在对 DispatchMessage。如果您将参数发布到此调用中，将会很有帮助。
It looks like the the problem is happening in a call to DispatchMessage inside MFC. It would be helpful if you'd post the parameters to this call.
好的，0x00000022 是 WM_CHILDACTIVATE 消息。它不需要参数，所以这些不会有问题。我想到的唯一可能的原因是窗口程序无效。例如，包含它的 DLL 可能已被卸载，或者该窗口可能已使用无效地址进行子类化。
OK, 0x00000022 is the WM_CHILDACTIVATE mesasage. It takes no parameters, so it can't be a problem with those. The only other possible cause that springs to mind is that the window prodedure isn't valid. For example, the DLL that contains it could have been unloaded or the window could have been subclassed with an invalid address.