64 位 MFC 版本中的访问冲突异常答案

【问题标题】：Access violation exception in 64bit MFC version64 位 MFC 版本中的访问冲突异常
【发布时间】：2011-07-05 12:30:03
【问题描述】：

我正在尝试将 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 位指针，但我无法指出发生这种情况的位置。我从 microsoft 加载了调试符号，它显示了调用堆栈的顶部。

非常感谢任何帮助。里昂

编辑

调用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} 标签点

【问题讨论】：

标签： c++ visual-c++ mfc 64-bit

【解决方案1】：

我刚刚解决了具有相同行为的问题。该错误是在将参数传递给 SetWindowLongPtr( GWLP_WNDPROC ) 时，指向 WndProc 的指针被不正确地转换为 LONG 而不是正确的 LONG_PTR。这样，指向 WndProc 的错误指针被放入内部 OS WND 结构中，因此对 HWND 的 WndProc 的任何后续调用都崩溃了。

【讨论】：

这个。 F***SetWindowLongPtr(... (LONG) pWndPrc。 (LONG_PTR)修复它。您的回答为我节省了大量工作。

【解决方案2】：

看起来问题是在 MFC 中调用 DispatchMessage 时发生的。如果您将参数发布到此调用中会很有帮助。

【讨论】：

感谢您的回复。调用 DispatchMessage 的代码是： if (pState->m_msgCur.message != WM_KICKIDLE && !AfxPreTranslateMessage(&(pState->m_msgCur))) { ::TranslateMessage(&(pState->m_msgCur)); ::DispatchMessage(&(pState->m_msgCur)); }
@Leon：是的，我以前看过有问题的代码。我在此函数中调用 DispatchMessage 时传递的参数。使用调试器查找“State->m_msgCur”的内容。
这是你的意思是什么？ - pState-> m_msgCur {味精= 0x00000022 WP = 0x0000000000000000 LP = 0x0000000000000000} tagMSG + HWND 0x0000000000020416 {未使用= 00000000} HWND__ *消息0x00000022无符号整型的wParam 0x0000000000000000无符号__int64的lParam 0x0000000000000000 __int64 时间 0x000f3967 unsigned long + pt {x=0x0000030f y=0x00000356} tagPOINT
抱歉，我无法将代码整齐地放在 cmets 中。我会把它附加到问题中

【解决方案3】：

好的，0x00000022 是WM_CHILDACTIVATE 消息。它不带参数，因此这些参数不会有问题。唯一想到的其他可能原因是窗口程序无效。例如，包含它的 DLL 可能已被卸载，或者窗口可能已使用无效地址进行子类化。

【讨论】：

您应该考虑编辑以前的答案，而不是开始新的答案。
@YeenFei：好的。下次会做。
@Steve，预期会发生在许多消息类型上。它最初是从 WM_MOVE 开始的。当我剥离一些功能时，它现在发生在 WM_CHILDACTIVE 上。
@Steve，user32.dll 是正确的版本吗？它是从 'C:\Windows\System32\user32.dll' 加载的，我读过它应该是 64 位版本。 32 位版本在 SystemWow 文件夹中？
@Lean：由于 WM_CHILDACTIVE 消息没有参数，看起来问题在于将消息分派到窗口过程。在我的脑海中，我只能想到几个可能的原因（我在这篇文章中列出了它们）。鉴于问题和消息的性质会导致崩溃。