Home/ Questions/Q 5965141
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-22T19:33:35+00:00

I am trying to port a 32bit application to 64 bit. The calculations appear

  • 0

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
Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0