Breakpoint will not currently be hit. No executabl

Question

I have a class in a .h file:

class Blah
{
public:
    Blah(){}
    virtual ~Blah(){}

    void WriteMessage( bool MessageReceived )
    {
        if(MessageReceived)
        {
            cout << "Message Recieved\n";
        }
    }
};

I was trying to figure out why my code isn't working, so I set a breakpoint on the conditional inside the WriteMessage() funcition, but as soon as I started running the project in debug mode the breakpoint faded out and the tooltip for it said:

Breakpoint will not currently be hit.
No executable code associated with this line.

I have no idea why this is happening, because all of my other member functions for other classes work just fine when implemented in the .h file. What is causing this?

Edit: Okay as requested, here's a stripped down version of the real code I'm working with:

VimbaBridgeAPI.h (header file for .dll)

#pragma once

#ifdef VIMBABRIDGEAPI_EXPORTS
#define VIMBABRIDGEAPI_API __declspec(dllexport)
#else
#define VIMBABRIDGEAPI_API __declspec(dllimport)
#endif

#include "AlCamIncludes.h"
#include "VimbaSystem.h"

////////////////////////////////////////////
//  Global Variables ///////////////////////
////////////////////////////////////////////
extern HBITMAP hbit;
extern CEdit* global_filenamehandle;

////////////////////////////////////////////
//  Global Flags ///////////////////////////
////////////////////////////////////////////
extern bool imageReady;
extern bool take_picture;

using namespace AVT::VmbAPI;

VIMBABRIDGEAPI_API void BridgedGetImage(FramePtr framepoint, VmbUchar_t** imgDat);

VIMBABRIDGEAPI_API HBITMAP ExternalFrameRecieved( const FramePtr pFrame );

//////////////////////////////////////////////////////////////////////////
//////////  MyObserver class   ///////////////////////////////////////////
//////////////////////////////////////////////////////////////////////////
class VIMBABRIDGEAPI_API MyObserver : public IFrameObserver
{
private:
    MyObserver( MyObserver& );

    MyObserver& operator=( const MyObserver& );

    //class member variables
    //BITMAPINFO*             pbmi;
    CEdit*                  m_filenameedit;

public:

    MyObserver(CameraPtr pCamera) : IFrameObserver(pCamera) {}
    virtual ~MyObserver() {}

    void FrameReceived ( const FramePtr pFrame );
};

NOTE: IFrameObserver is not written by me, but the FrameReceived function is a pure virtual declared in the IFrameObserver class. Their documentation says that FrameRecieved gets called by their API whenever a frame comes in, and I had to implement the function. I have tested this functions and it works, but only when defined outside the class (inside I get the error I'm getting now)

VimbaBridgeAPI.cpp (code hidden from user)

void FrameRecieved( const FramePtr pFrame )
{
    DbgMsg(L"Frame Received\n");

    ////////////////////////////////////////////////////////////////////////
    //////////  Setup Bitmap  ////////////////////////////////////////////////
    //////////////////////////////////////////////////////////////////////////

    //// FILEHEADER ////
    BITMAPFILEHEADER* bf = new BITMAPFILEHEADER;
    bf->bfType = 0x4d42;
    bf->bfSize = 6054400 + 54 + sizeof(BITMAPINFO);
    bf->bfOffBits = 54;

    //// INFOHEADER ////
    BITMAPINFOHEADER* bih = new BITMAPINFOHEADER;
    bih->biSize = 40;
    bih->biWidth = 2752;
    bih->biHeight = -2200;
    bih->biPlanes = 1;
    bih->biBitCount = 32;
    bih->biCompression = 0;
    //bi->biSizeImage = 6054400; //not required
    bih->biXPelsPerMeter = 2835;
    bih->biYPelsPerMeter = 2835;
    bih->biClrUsed = 0;
    bih->biClrImportant = 0;

    //// INFO ////
    BITMAPINFO* pbmi = (BITMAPINFO*)alloca( sizeof(BITMAPINFOHEADER) + sizeof(RGBQUAD)*256);
    pbmi->bmiHeader.biSize = sizeof (pbmi->bmiHeader);
    pbmi->bmiHeader.biWidth = 2752;
    pbmi->bmiHeader.biHeight = -2200;
    pbmi->bmiHeader.biPlanes = 1;
    pbmi->bmiHeader.biBitCount = 8;
    pbmi->bmiHeader.biCompression = BI_RGB;
    pbmi->bmiHeader.biSizeImage = 0;
    pbmi->bmiHeader.biXPelsPerMeter = 14173;
    pbmi->bmiHeader.biYPelsPerMeter = 14173;
    pbmi->bmiHeader.biClrUsed = 0;
    pbmi->bmiHeader.biClrImportant = 0;

    //create grayscale color palette
    for(int i=0; i<256; i++)
    {
        pbmi->bmiColors[i].rgbRed = BYTE(i);
        pbmi->bmiColors[i].rgbGreen = BYTE(i);
        pbmi->bmiColors[i].rgbBlue = BYTE(i);
        pbmi->bmiColors[i].rgbReserved = BYTE(0);
    }

    //// IMAGE DATA ////
    VmbUchar_t* imageData = NULL;
    BridgedGetImage(pFrame, &imageData);

    //////////////////////////////////////////////////////////////////////////
    ////// Create image that's printed to dialog box /////////////////////////
    //////////////////////////////////////////////////////////////////////////
    HDC hdc = ::GetDC(NULL);  
    hbit = CreateDIBitmap(hdc, bih, CBM_INIT, imageData, pbmi, DIB_RGB_COLORS);

    //clean up
    DeleteObject(bf);
    DeleteObject(bih);
    DeleteObject(hdc);
}

Answer 1

Wanted to mention that I experienced the "Breakpoint will not be hit..." error when porting some of my older MFC (managed--using clr support) projects into VS2015.

What fixed the issue for me was setting this:

Configuration Properties\Linker\Debugging\Debuggable Assembly

... to this:

Yes (/ASSEMBLYDEBUG)

Answer 2

I wound up having this issue too, the context of my app was a main app in C# which used unmanaged C++ code in a lower layer that I wanted to step into from the debugger. From the C# project properties I went into the Debug tab and under the Enable Debuggers section checked the "Enable unmanaged code debugging".

Answer 3

I had the same issue but the accepted solution of cleaning up files didn't work for me. I have my issue resolved and it had to do with my code. Here are the details of my fix, hope it gives some clues to your fix.

What I was doing is overloading CArchive << operator for my structure but the code never steps into it. I would set the break point and I got the solid red symbol. As soon as I start debugger the symbol becomes outlined and the warning message on it says:

The breakpoint will not currently be hit. no executable code is associated with this line

My relevant code is below where the break point doesn't break.

class Book
{
     friend CArchive& operator << (CArchive& ar, const Book & book )
     {

         ar << book.title;
         ar << "\r\n";
         ar << book.price;
         ar << "\r\n";
     }
}

Now there is an obvious problem with this code is that it doesn't have a return statement return ar but the compiler never complained. The reason compiler didn't complain was I was using the operator incorrectly (and rather never using it)

book *mybook = new Book(...);
ar << mybook;

Because mistakenly I am accessing the operator via pointer, my object's << operator was never really invoked and that's why compiler didn't complain either because it was never being used.

So first I fixed the calling code

book *mybook = new Book(...);
ar << *mybook;

Now the operator overloading method complains about the return statement and I fixed that too.

I can now step into the function. So the bottom line was that the break point was not being set because this code was essentially sidelined by compiler (correctly) because it was never used in the code.

Answer 4

I would suggest you firstly Delete the output files : Physically delete all generated DLLs, PDBs and EXEs. Then compile (rebuild) again to generate the files. Sometimes Visual Studio can "get lost" and "forget" to overwrite the output files when you build your solution.

This can happen for a few other reasons:

• The code the debugger is using is different from the code that the application is running
• The pdb file that the debugger is using is different from the code that the application is running
• The code the application is running has been optimized and debug information has been stripped out.
• The code in which you have breakpoints on hasn't been loaded into the process yet

Answer 5

I also wanted to chime in with my own solution. I had a C++ project loading a dll that consisted of C++/CLR code. Turns out, I had to set the startup project's debugger type to "Mixed". "Auto" wasn't detecting that it needed managed support because the dll was loaded manually after the program started.