[RESOLVED] "This breakpoint will not currently be hit"... code mysteriously disabled?

[fafalone]

"This breakpoint will not currently be hit. No executable code of the debuggers target code type is associated with this line. ..."

That's what it's saying about a class Initialize routined. But it's not disabled, or anything suspicious. It seems to jump right over that line, then continue into starting the message pump, which promptly crashes because everything is NULL.

int WINAPI wWinMain(
    HINSTANCE hInstance,
    HINSTANCE hPrevInstance,
    LPWSTR pszCmdLine,
    int nCmdShow)
{
    UNREFERENCED_PARAMETER(hPrevInstance);
    UNREFERENCED_PARAMETER(pszCmdLine);
    UNREFERENCED_PARAMETER(nCmdShow);

    HeapSetInformation(NULL, HeapEnableTerminationOnCorruption, NULL, 0);

    HRESULT hr = CoInitializeEx(NULL, COINIT_APARTMENTTHREADED | COINIT_DISABLE_OLE1DDE);
    if (SUCCEEDED(hr))
    {
        {
            DemoApp app;
            hr = app.Initialize(hInstance);
            if (SUCCEEDED(hr))
            {
                // Main message loop:
                MSG msg;
                while (GetMessage(&msg, NULL, 0, 0))
                {
                    TranslateMessage(&msg);
                    DispatchMessage(&msg);
                }
            }
        }

HRESULT DemoApp::Initialize(HINSTANCE hInstance)

The message occurs for that last line and any subsequent breakpoints in Initialize.

Stepping through the code, every line up through hr = app.Initialize(hInstance); executes, but when I continue after breaking on that line, it somehow jumps straight to the WndProc's WM_SIZE message. I'm at a complete loss to explain why it reaches hr=app.init but then can't even enter the procedure, and how the message pump even starts when while (GetMessage(&msg, NULL, 0, 0) seemingly never executes (no more breakpoints are hit, I've got them on every line).

The same 'this breakpoint will not be hit' message is given for any breakpoint in DemoApp::DemoApp() too.

Also have no idea how a read access violation could result from

            UINT uWidth = LOWORD(lParam);
            UINT uHeight = HIWORD(lParam);
            hr = OnResize(uWidth, uHeight);

(on the last line)

This is a Windows SDK example: https://github.com/microsoft/Windows...wicanimatedgif

The only solution I found searching, setting debug info to FULL, did not help. I also explicitly disabled precompiled headers.

[jmcilhinney]

This usually happens because that code has changed since the last build but you're running the old build output.

[2kaud]

As a minor point, function parameters need not be given a name as long as a type is present. So wWinMain() can be:

int WINAPI wWinMain(HINSTANCE hInstance, HINSTANCE, LPWSTR, int)

[wqweto]

As a minor point, function parameters need not be given a name as long as a type is present. So wWinMain() can be:

int WINAPI wWinMain(HINSTANCE hInstance, HINSTANCE, LPWSTR, int)

Btw, this is MS code, it's from Windows-classic-samples repo linked above.

Win32, Debug works as expected here on VS2022 Community.

All GIFs play as expected too.

x64 build fails within s_WndProc as it uses PtrToUlong to stuff this pointer into GWLP_USERDATA but it trims the pointer to 4-bytes -- ouch! How old is this code?

Using SetWindowLongPtr(hWnd, GWLP_USERDATA, (LONG_PTR)(pThis)); fixed x64 builds.

cheers,
</wqw>

[fafalone]

Yup (LONG_PTR)pThis fixes it... but *how*?? Truncating the pointer made it invalid, so how'd it even wind up in WndProc... lRet = pThis->WndProc(hWnd, uMsg, wParam, lParam) would have been invalid,,, and with Initialize not running, how'd it even register s_wndproc. I rebuilt before every run; it either said succeeded or up to date.

Oh well, not that important I guess. Code is a Windows 7 sample, so pretty old, but shouldn't have been so old 64bit compilation wasn't possible. Microsoft is notorious for their SDK samples not working.

[wqweto]

> how'd it even wind up in WndProc...

It entered WndProc function with garbled this pointer just fine and even handled WM_SIZE by calling OnResize member function which tried accessing member variable m_pHwndRT which then bombed with access violation.

Garbled this pointer does not bother it unless member variables are access. Calling member functions just passes the garbled pointer without dereferencing it in any way.

Over the years, as people kept working with the now-obsolete VB6 language, this forum has gradually turned many of its members into experts in low-level C/C++ internals :-))

cheers,
</wqw>