Binary not built with debug info - why?

I use Visual C++ 2005 Express and for some of my projects, such as my "WAV file sample rate generator" or my test program, I get, upon closing it, "binary was not built with debug information". This is likely the cause as to why breakpoints are not working at all. I made sure I'm in the "debug" option instead of "release", but every time, I get the note that the binary wasn't built with debug information. How do I get it to be built with debug information so I can use the step-by-step process of how the code executes.

For some reason, however, my 2D game has this debug info built into the binary, but this uses Windows components. The ones I want it for just use a basic command prompt window since nothing special is needed.

Are you sure it's YOUR executable it says that about - it usually splurges out a long list of other binaries (DLL's) that you link with that are built in release only - which is perfectly normal and you should most likely never need to debug those as they are supplied by Microsoft and despite MS's reputation, normally works as advertised.

--
Mats

This is one of my own. If I click on the line number, to add a breakpoint on the first line of the main function, and run it, the breakpoint isn't hit. The program runs as if the breakpoint didn't even exist. When I run my program, then close it, this is the first line on the debug output:

'smalltest.exe': Loaded 'C:\My Documents\My programs\smalltest\debug\smalltest.exe', Binary was not built with debug information.

I flagged the key part in bold. There's a bunch of bunch of Windows-related DLLs after it with "no symbols loaded" appearing. I've included windows.h to use the "bitmapinfoheader" struct. This is actually my test program which often contains small programs I run through a menu. When I need to figure out what is causing a bug, it is more difficult and a lot slower to hunt them down as I have to use test variables and several printf statements to track what is going on.

Perhaps you have somehow messed up the settings for your compiler and linker to disable the debug symbols, then?

Check your "project->properties->compiler/linker->debug symbols" and make sure it's all "on".

--
Mats

They were all off/disabled. I set them and now I'm getting this message. The breakpoint becomes an outline with an exclamation in a triangle. Putting the mouse over it shows this text:

"The breakpoint will not currently be hit. No symbols have been loaded with this document."

First, what are symbols? Second, how can I get them to be loaded.

"Symbols" in this case are the debug information that the compiler and linker produces. It consists of many different types of information (in no particular order):
1. Line-number to address information - so the debugger knows that line 123 in your code is 0x401047, and can set a breakpoint at that address when you click on line 123 and press F9 (or whatever it may be).
2. Variable information - both local and global variables are listed in tables - local variables are obviously per function. This allows the debugger to show you the local variables and their values.
3. Function list - list of all functions and their starting address and length, parameters and space used on the stack.
4. Type list - list of non-standard types, e.g. structs, enums and other such things, which allows the debugger to show you the content of these types in a symbolic way.

To fix your problem, you may want to do a rebuild of your project, and also check that the settings you changed are for the debug build of the project.

--
Mats

I went to solution > rebuild solution, but that didn't work. Here's what I have for the settings, for things involving debug (that I can find). I have the "configuration" set to "Active(debug)" and platform as "Active(Win32)". If it helps, this program doesn't use Windows (such as your browser's window or your image editor's window), rather, it's just a command prompt box.

In configuration properties > debugging:
Debugger to launch: "Local Windows Debugger" // There's one for the web, but I'm not using anything that involves the web or the internet so the other option is irrelevant.
Command: "$(TargetPath)"
Attach: "No"
Debugger type: "Auto" // I don't what these others are
Merge environment: "Yes"

In "Configuration > C/C++ > General":
Debug information format: "Disabled" // this could be a culprit, but I have no idea what the other options are for or what they mean

In "Configuration > preprocessor":
Preprocessor definitions: "_DEBUG" // I originally didn't have anything here, but this was suggested from someone on another forum

In "Configuration > Linker > debugging":
Generate debug info: "Yes (/DEBUG)" // was "no" when I first posted this here
Generate program database file: "$(TargetDir)$(TargetName).pdb"
Generate map file: "No" // I don't know what this is
Map Exports: "No" // don't know what this is
Debuggable assembly: "No Debuggable attribute emitted" // not sure what this is

These are all the known areas that I can see that involve debug in some way or another. Some of it is irrelevant, others may be missing (or have nothing in them).

You definitely need to "generate debug info" in the Compiler setting, so

Code:

---

Debug information format: "Disabled"

---

is definitely wrong - I don't know what the options other than Disabled are, but choose the one that seems best.

I'm not sure what the "Debuggable Assembly" means - I think "assembly" is a .Net "executable" - but I see no harm in enabling that option.

--
Mats

There are four options and I don't know what they even mean:

Disabled
C7 compatible // I have no idea what this is; what's C7?
Program database
Program database for edit & continue

I don't know what the difference is between the last two. I primarily like two aspects of the debugger - step by step (press a key to execute a line, seeing the results, and move onto the next, and putting the mouse over a variable to see its value at that point.

C7 is "Microsoft C version 7", I beleive - which is about old enough to start dating or some such.

You want Program Database (your choice if you want to have "Edit and Continue" - which means that you can change the code a little bit and continue running, rather than starting over from scratch - I don't use that at all, but if you are often making small mistakes [1] in your code, it may be a useful thing).

[1] If you make big mistakes, leading to large enough changes, the compiler will say "can't continue, OK to quit" or some such.

--
Mats

Well, now I got breakpoints to be reached, but it's not working correctly. I chose the "program database" option. The problem right now is that, if I press F11, it skips over content. For example, if I have an if statement, I see that it skips over "X = Y" but stops at the next if statement without evaluating these. Put the mouse over the X or the Y and nothing appears. Any ideas why this is happening? Here's an example:

Code:

---

VariableA = 4; // I can see the value of this
VariableB = 12.2f; // I can see this as well

if (Something > SomethingElse)
{
    VariableC = 8; // it skips over this and I can't see the value
   
    if (VariableD < Something) // it stops here
    {
        VariableE = VariableD/3.0f; // I can't see what this evaluates to
    }
}

---

In my main project, this works just fine, but it's not in my simpler projects. If I put the breakpoint at the line the "VariableC" one is at, then run it, I find that the breakpoint goes immediately to where the if statement is (the dot and arrow). Once I stop the debugging, quitting, I see that the dot returns to where I had it. It's as if that code didn't even exist, which probably explains why I'm not seeing the value upon putting the mouse over it. This isn't my actual program, but just an example to demonstrate the behaviors I'm seeing and getting.

The step next feature will not evaluate all code paths, only those which are true. Highlight your boolean expressions and do a quickwatch (or anything similar), and confirm that these are true. If they are false then step next is working.

What determines if you can watch a specific variable is it's scope: that is, if the debugger skips a code path, definitions in that scope are not watchable, as they have no location value to inspect. This is not a bug.

Have you, by any chance, enabled optimization in your build settings? When code is (heavily) optimized, the compiler may well cause the debugger trouble by re-arranging and removing parts of the code in such a way that it becomes hard to follow - and it sounds like this is the case. Check that your optimization options are "No optimization". [I'm guessing that since your debug options where turned off, anything else would potentially be "broken" in the project configuration as well].

--
Mats

I had optimization present, toward speed. I actually didn't set it that way.... Disabling optimization (using the C/C++ section) resolved the problem. Interestingly, VC encountered an internal error when it got to the "fwrite" functions and I pressed F10 for it to process, giving the usual "send error report to Microsoft" notice. I snagged a screenshot of the error too!

When I rebuild the project, I get this, which seems a bit weird:

Linking...
LINK : C:\My Documents\My programs\smalltest\Debug\smalltest.exe not found or not built by the last incremental link; performing full link

It happens every time. Before I made changes to the configuration menu, this wasn't happening....

Edit: I forgot to mention that the debugger is now working exactly as I expected for this project and is also what I get in my 2D game. Thanks for resolving this.

By design, rebuild "cleans" the project. A full link after compiling is normal here.

Ah, thanks. You can put this thread in the "resolved questions" bin.