[SOLVED!] How to fix Unverified Breakpoints

[enricodegan]

Hello,

I’m having some trouble with debugging in VS Code.
I place a breakpoint normally and the red dot shows up to the left of the line number. When I start the debugging mode, however, the normal red circle turns into a gray circle with a hole in the middle. I’ve looked it up and it’s called an “Unverified Breakpoint.”

I’m not sure what to do about this or how to solve it. I have tried searching on the internet, but have found nothing. Especially nothing that I can understand at my level. In addition, most of the responses I’ve found either haven’t found a solution or are not in C++.
Any help is appreciated!

Thanks,
Enrico

[QueueButton]

You shouldn’t put break points on comment only lines. Does it still do that if you put it on line 58 or 61?

You can always put a break point before the line you need it at and just step through the code.

[DanM]

And what are the contents of your launch and tasks.json?

[enricodegan]

@QueueButton I tried putting breakpoints on lines 58 and 61 and I still got the Unverified Breakpoint error.

Then, just for fun, I tried by putting a breakpoint on every single line and all of them didn’t work:

@DanM I think the problem may be with the launch.json file. Here is mine:

{
   // Use IntelliSense to learn about possible attributes.
   // Hover to view descriptions of existing attributes.
   // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
   "version": "0.2.0",
   "configurations": [
       {
           "name": "(Windows) Debugger",
           "type": "cppvsdbg",
           "request": "launch",
           "program": "${workspaceFolder}/main.exe",
           "args": [],
           "stopAtEntry": false,
           "cwd": "${workspaceFolder}",
           "environment": [],
           "externalConsole": false
       }
   ]
}

The only lines that I changed were the "name": line (which should have no effect) and the "program": line (which should also have no effect).

Thanks for any help!
Enrico

[DanM]

What does your explorer (Ctrl + Shift + E) look like?

[enricodegan]

@DanM Here is my explorer:

[DanM]

You have both FBullCowGame.exe and main.exe. So that’s a bit puzzling.
What you could do is have a build task and then use that as a pre-launch task.

i.e. tasks.json

{
    "version": "2.0.0",
    "tasks": [
        {
            "type": "shell",
            "label": "Build",
            "command": "cl.exe",
            "args": [
                "/Zi",
                "/EHsc",
                "/Fe:",
                "BCGame.exe",
                "${workspaceFolder}\\main.cpp",
                "${workspaceFolder}\\FBullCowGame.cpp"
            ],
            "options": {
                "cwd": "${workspaceFolder}/build"
            },
            "group": {
                "kind": "build",
                "isDefault": true
            },
            "problemMatcher": [
                "$gcc"
            ]
        }
    ]
}

launch.json

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Debug",
            "type": "cppvsdbg",
            "request": "launch",
            "program": "build/BCGame.exe",
            "args": [],
            "stopAtEntry": false,
            "cwd": "${workspaceFolder}",
            "environment": [],
            "externalConsole": false,
            "preLaunchTask": "Build"
        }
    ]
}

Which means this will compile main.cpp and FBullCowGame and create an executable inside a build directory (required to make that first before running this task) before then launching it.

So now F5 will “build and debug” and “Ctrl + Shift + B” will just build.

[enricodegan]

Hi @DanM,

This firs time I tried it, whatever magic you did worked! Then I stopped debugging and tried again and I get this strange error:

I don’t really know how to fix this … especially since "program": has something to the right of it.

Also, I’m wondering why did you say:

You have both FBullCowGame.exe and main.exe. So that’s a bit puzzling.

What makes it puzzling? I’m guessing by your reaction that this isn’t normal, so is it something I did wrong or is my computer just weird?

Thanks,
Enrico

[DanM]

Then I stopped debugging and tried again and I get this strange error:

Could I see the same things, again?

What makes it puzzling? I’m guessing by your reaction that this isn’t normal, so is it something I did wrong or is my computer just weird?

It’s puzzling since compiling this should result in one executable, so either you compiled and linked each file separately e.g.

cl main.cpp
cl FBullCowGame.cpp

Which would mean you needed to have defined int main() in both files.
Or you compiled at least twice under different output names

cl main.cpp FBullCowGame.cpp /Fe:FBullCowGame.exe
cl main.cpp FBullCowGame.cpp /Fe:main.exe

[enricodegan]

Hello @DanM,

I’m guessing your talking about my explorer and the launch.json/tasks.json.
Explorer:

The launch.json and tasks.json are the ones that you typed. All I did was copy and paste them into my files.

Also, it seems there might be another problem. When I press F5 or the green play button (to start debugging), VS Code says “Building” but it never stops building.
Here is a screenshot of what I mean:

---

By the way, the way I compile is always by typing:

cl main.cpp FBullCowGame.cpp

and then I type:

main FBullCowGame

to get the program actually running.
And I definitely did not compile under different output names because I didn’t even know the main.exe. and FBullCowGame.exe files existed.
So I also have absolutely no idea how that happened.

---

Thanks,
Enrico

[DanM]

From your screenshots you didn’t create a build folder. The tasks and launch I wrote used a separate build folder to keep the source directory clean of the build files.

---

By the way, the way I compile is always by typing:

cl main.cpp FBullCowGame.cpp

and then I type:

main FBullCowGame

The first command you wrote - cl main.cpp FBullCowGame.cpp - compiles each file and creates a compiled object file (.obj) and then the linker (invoked automatically) links those two object files together to create an executable, by default cl will name the executable after the first file you list.

So now after I typing that out I suspect you didn’t have the same order each time. i.e.

cl main.cpp FBullCowGame.cpp
//or
cl FBullCowGame.cpp main.cpp

---

I didn’t even know the main.exe. and FBullCowGame.exe files existed.

When you do

main

That’s the same thing as

main.exe

You can run executables without typing their file extension in cmd. And

main FBullCowGame

just executes main, the other is disregarded.

[enricodegan]

Hopefully, this is the last thing @DanM:

I’m getting this error now:

I’m guessing it’s connected to the last line in launch.json file: (keep on reading if you don’t understand where the error came from…)

            "preLaunchTask": "Build"

What do I do from here?
And just to make sure is my explorer correct now (in regards to the .vscode and build folders)? I tried putting the launch.json in the build folder but VS Code didn’t know what to compile so this was my solution (which probably also led to the error above.)

---

By the way, you are correct. I do remember that one time I typed this:

cl main.cpp FBullCowGame.cpp 
//or 
cl FBullCowGame.cpp main.cpp

I didn’t think the order was important, but I’ll make a note for the future. By the way, do I need to fix this problem by deleting the FBullCowGame.exe file or something similar? or is it alright if it stays like this for this project?

Thanks so much for all your help!
Enrico

[DanM]

1. You have the tasks.json inside the build folder. It’s a VS Code file, it should remain in .vscode. Your explorer should look something like this.
   
   The benefit of having the build folder is that if you ever need rebuild - say the output isn’t matching what you’ve coded at atll - all you do is delete the contents of build and compile. No need to go searching for all the intermediate files that are mixed with your code, just delete the contents of the folder.

And yes that prelaunch task is to run the task named “build” before launching

---

I mean you can keep it, but it’s completely unused so no point keeping it.

[enricodegan]

Hi @DanM,

One more question.
I don’t have any files labeled BCGame.exe, .ilk, and .pdb. I think this is a problem since VS Code’s Debug Console said:

Loaded 'C:\Windows\SysWOW64\ntdll.dll'. Cannot find or open the PDB file.
Loaded 'C:\Windows\SysWOW64\kernel32.dll'. Cannot find or open the PDB file.
Loaded 'C:\Windows\SysWOW64\KernelBase.dll'. Cannot find or open the PDB file.

I’m also noticing that you don’t have a main.exe file in your explorer. Why is that? and, more importantly, how do I get all the BCGame files?

Here is an updated picture of my explorer:

Thanks so much!
Enrico

P.S. I can feel it. We’re getting closer to solving the problem!

[QueueButton]

You can compile to any executable name you desire. The main.exe is how you have chosen it to be even if you feel you didn’t decide from non-understanding.

You should be able to delete main.exe and build:
“cl FBullCowGame.cpp main.cpp” to produce FBullCowGame.exe

If you want BCGame then you can rename your project files for FBullCowGame to BCGame.

Alternatively, you can also specify a name when compiling eg “cl /FeBCGame.exe FBullCowGame.cpp main.cpp” should make BCGame.exe instead of FBullCowGame.exe.

https://docs.microsoft.com/en-us/cpp/build/reference/fe-name-exe-file?view=vs-2019

/Fe (Name EXE File) is not working

[enricodegan]

Thanks @QueueButton!
Just to clarify: why does @DanM have a FBullCowGame.cpp file, but also BCGame.exe. My understanding was that BCGame came about from having the project files named BCGame as you said:

If you want BCGame then you can rename your project files for FBullCowGame to BCGame.

But that doesn’t appear to be Dan’s case. Am I overthinking this or is my question valid? It if is, do you know the answer?

---

Moreover, the problem still remains: I don’t have a .ilk or a .pdb file regardless of the name before the period.
Do you know how I can solve that?

Anyways, thanks for the information and the link. I’ll keep in mind for future projects!

Thanks,
Enrico

[DanM]

Look at the build task

"command": "cl.exe",
"args": [
    "/Zi",
    "/EHsc",
    "/Fe:",
    "BCGame.exe",
    "${workspaceFolder}\\main.cpp",
    "${workspaceFolder}\\FBullCowGame.cpp"
]

So run the command cl with these arguments i.e. (from the build folder)

cl /Zi /EHsc /Fe:BCGame.exe ..\main.cpp ..\FBullCowGame.cpp

/Zi - Compile with Debug Info
/EHsc - Specify Exception Handling Model
/Fe - Name the executable

---

The .ilk and .pdb are part of the Zi switch.

[enricodegan]

Thanks again for your prompt replies @DanM and @QueueButton , but there is one more game-breaking problem.

Even if I run the line below:

cl /Zi /EHsc /Fe:BCGame.exe ..\main.cpp ..\FBullCowGame.cpp

(which does generate the necessary files), every time I run it, it keeps on creating duplicate files.
Here is my explorer before running it:

and after:

As you can see, it’s clearly creating duplicate files of FBullCowGame.obj and main.obj file. I believe that the problem is that VS Code doesn’t know the files already exist because they are in a different folder. Right now I am always compiling in this folder:

c:\Users\enric\Documents\gamedevUnreal\BullsCowGame_original>

Should I instead be compiling in this?

c:\Users\enric\Documents\gamedevUnreal\BullsCowGame_original\build>

What do you think I should do about this?
Also, from now on, do I always need to compile with the above statement or can I use the normal one?

cl main.cpp FBullCowGame.cpp

---

And I’m having another problem. I’m not sure if it’s due to the one above but every time I do compile it doesn’t work and this is what the console spits out:

/out:main.exe
main.obj
FBullCowGame.obj

or

/out:BCGame.exe
main.obj
FBullCowGame.obj

based on what line I compile with.
What is happening and why?
I’m pretty sure that my program isn’t even compiling anymore. This has really been disheartening, especially since I was thinking we were soooo close to a solution.

Anyways I deeply thank you for all the help!

Thanks,
Enrico

[DanM]

You don’t need to manually compile yourself, this is what that tasks are for

So now F5 will “build and debug” and “Ctrl + Shift + B” will just build.

Here I was saying that this build task is the same as doing this following command.

So run the command cl with these arguments i.e. (from the build folder)

cl /Zi /EHsc /Fe:BCGame.exe ..\main.cpp ..\FBullCowGame.cpp

[enricodegan]

Hi @DanM,

Just to clarify:
I no longer need to type cl ... in the terminal. Instead, I should use “Ctrl+Shift+B” to build and run my program (basically to play it, right?). And I should use F5 to “build and debug.”

I understand and agree with this, but there are two small problems…

1. When I press “Ctrl+Shift+B” this is what turns up:
   

   
   
   I can’t find any .json file that has “program” in it, so I’m having difficulty finding the source of the problem. What should I do at this point?

2. Also, when I press F5 to “build and debug” the terminal still says that it can’t located .pdb files:
   

   
   
   All three of the .pdb files are under SysWOW64 which is part of the Windows x64 architecture. So, I tried searching the path in File Explorer and all three of the files exist, so I don’t undrstand what the problem is with VS Code.
   I’m not sure if the above reason is causing this, but the only function that loads is void PrintIntro(). void PlayGame() might load but stops before running the FText GetValidGuess() function which should print, directly after “Can … thinking of?”: "Try #x. Enter your guess: ". I don’t know what’s stopping the program. I don’t think its the breakpoint I put becuase it’s located well after the line where FText GetValidGuess() is called.
   How can I fix these problems?
   As always, thank you so much for all your help! I really hope these problems can be solved quickly!

Thanks,
Enrico