0

I am trying to debug a program written in C++ in Visual Studio (using Debug x64 configuration) and have encountered the issue I mentioned in the title. Now I've seen this question: How do I remedy "The breakpoint will not currently be hit. No symbols have been loaded for this document." warning? and tried the answers there, however they do not seem to work for me. This is the function I'm trying to debug:

enter image description here

which, as you can see, is part of _tools_string.cpp. This file belongs to a project called common-files-lib-vs:

enter image description here

And as I start debugging and select Debug->Windows->Modules, I can see that the symbols for this project have in fact been loaded:

enter image description here

Breakpoints do not work in any other file belonging to this project, however they do work properly in files found elsewhere.

As I've mentioned before, I haven't found a solution that would work for me, besides the question I've linked was asked in regard to C# (I'm not sure it makes that big of a difference in this case, but still). Has anyone perhaps had this problem before and managed to come up with a solution?

Jakub Cieślak
  • 65
  • 7
  • 1
    So much information is shown, but the most important part is not shown, namely what build configuration and optimizations are used. – 273K Sep 13 '22 at 07:38
  • @273K could you please elaborate as to what I should add to the post? I'm not sure I understand what you mean by 'build optimization'. – Jakub Cieślak Sep 13 '22 at 07:42
  • @JakubCieślak -- Look at your project configuration settings. Is this a "Debug" build or a "Release" build? If it's a release build, more than likely those lines of code you're trying to put a breakpoint on have been optimized away. Also, make sure that you are not (by accident) building the release version. You will know this in the main menu as to what the configuration is that you are building -- don't rely on the project settings dialog -- what counts is the actual setting you see in the Visual Studio main menu when you are building the program. – PaulMcKenzie Sep 13 '22 at 07:44
  • @PaulMcKenzie I've already edited the question, now it specifies that the configuration is Debug x64, which I am sure of. Thank you for pointing it out, though. – Jakub Cieślak Sep 13 '22 at 07:45
  • Ensure common-files-lib-vs is built with the actual _tools_string.cpp – 273K Sep 13 '22 at 07:48
  • @JakubCieślak -- Also, it is the "Output Window" you should be looking at to verify if the symbols have been loaded. It is the window that shows *all* the DLL's and their statuses. – PaulMcKenzie Sep 13 '22 at 07:50
  • @273K what do you mean by that? Is it possible to exclude a project file from the actual build? – Jakub Cieślak Sep 13 '22 at 07:50
  • @PaulMcKenzie They are loaded according to the Output Window: ```'ConsolePacketSender.exe' (Win32): Loaded '(...)\ConsolePacketSender\x64\Debug\common-files-lib-vs.dll'. Symbols loaded.``` – Jakub Cieślak Sep 13 '22 at 07:52
  • @JakubCieślak -- *Has anyone perhaps had this problem before and managed to come up with a solution?* -- You are obviously doing something wrong, but the issue is that if you don't know what it is that you're doing wrong, then there is little anyone can help you with unless they have access to your computer. My thought is that the DLL was not compiled with the "Debug" and "No optimizations" settings. Other than that, it is a guessing game if you are looking for a third-party to try and diagnose this. – PaulMcKenzie Sep 13 '22 at 07:52
  • @PaulMcKenzie you are probably right, however it is intriguing how Visual Studio is actually contradicting itself, since it clearly states that the symbols for this project are loaded but then says they are not in the breakpoint error description, which led me to believe this is a problem with Visual Studio itself - it is just as possible that I'm doing something in the wrong way, though. And yes, each project used in the solution is compiled under 'No optimizations' and 'Debug (x64)'. – Jakub Cieślak Sep 13 '22 at 07:54
  • 1
    @JakubCieślak -- The symbols can be loaded, but either the source code is not the same that you built the DLL with, or that optimizations have moved the code around so that it doesn't match up with the source code. Have you tried setting a breakpoint anywhere in that file? If you can, then that means one of the two scenarios I mentioned. Also, are you setting these breakpoints before the DLL has been loaded? If so, then they will not appear as valid until the DLL has been loaded successfully. – PaulMcKenzie Sep 13 '22 at 07:57
  • @PaulMcKenzie I have tried moving the breakpoint to a different place in this file, it still does not work, unfortunately. Thank you for trying to help. – Jakub Cieślak Sep 13 '22 at 07:59
  • Do the breakpoints work elsewhere than in common-files-lib-vs.dll? Did you try a rebuilding the whole solution from scratch? – Jabberwocky Sep 13 '22 at 08:20
  • @Jabberwocky no, they don't work anywhere in the project and yes, tried rebuilding the solution to no avail, unfortunately. – Jakub Cieślak Sep 13 '22 at 08:50
  • @JakubCieślak do breakpoints work if you but them in a hello world project made from scratch? – Jabberwocky Sep 13 '22 at 08:52
  • @Jabberwocky I haven't tried a hello world project, but they do work in the main project of the solution. – Jakub Cieślak Sep 13 '22 at 08:53
  • From one of your comments: _"no, they don't work anywhere in the project"_ . From another comment: _"they do work in the main project of the solution."_. Please make up your mind. [Edit] the question and put all relevant information into the question. And if you haven't tried a brand new hello world project, well then do it, it takes 5 minutes... – Jabberwocky Sep 13 '22 at 08:56
  • @Jabberwocky I believe I misread your first question, I thought you were asking whether breakpoints worked in a different file belonging to 'common-files-lib-vs', hence my answer. To reiterate: they *do* work in a different project than 'common-files-lib-vs' and *do not* work in the entirety of 'common-files-lib-vs' itself. And I quickly created a new solution, and they do work as intended as well. – Jakub Cieślak Sep 13 '22 at 09:02
  • I suggest you to clean the project first, then rebuild, and the method mentioned in this [issue](https://stackoverflow.com/questions/27483273/the-breakpoint-will-not-currently-be-hit-and-i-cannot-add-the-pdb-file) can also be tried. – Yujian Yao - MSFT Sep 14 '22 at 05:29

0 Answers0