locked
breakpoint will not hit no symbols being loaded RRS feed

  • Question

  • Hi Everyone,

    I am working on a standalone windows application and am not able to debug the code as it is hitting the breakpoint.

    I am getting this error "breakpoint will not hit no symbols being loaded".

    I have cleaned the solution rebuilt it,enabled the debug trace but still it is not working.

    I request you to please help me on this issue.

    Thanks,

    Vishal

    Monday, July 11, 2016 9:38 AM

Answers

  • This indicates that one of several possible situations are occurring.

    SCENARIO: Your code isn't compiling. This seems odd but it is a very common problem for new developers. Most devs tend to use F5/Start Debugging to build and run their code. That is great but what few fail to realize is that if the build fails then you get the option of either stopping the debug session or continuing on with the last build version. There is a dialog that pops up that most people tend to blindly click on without reading and often check the "do not ask again" box. Hence they never get the error.

    SOLUTION: Do a build first and confirm the code is building correctly.

    SCENARIO: You are not generating the PDB. Rare since it is generated by default but can be confirmed in the project settings.

    SOLUTION: Once the build is complete verify the PDB is in the same directory as the binary and that the date/times are the same.

    SCENARIO: The PDB cannot be found. This generally indicates that you are using a custom output path or build script such that the PDB and DLL/EXE are not in the same location.

    SOLUTION: Same as the previous scenario.

    SCENARIO: You are doing a Release build and the code you have the breakpoint on is optimized.

    SOLUTION: Ensure that your project build configuration is Debug. Note that the solution configuration is what VS shows but projects generally match the solution. You can verify using Configuration Manager on the solution.

    SCENARIO: The breakpoint is residing in an assembly that hasn't been loaded yet.

    SOLUTION: .NET delay loads assemblies. If you put a breakpoint in code that resides in an assembly that isn't loaded yet then the BP will display the warning you gave until the assembly loads. If this is your primary assembly then this wouldn't be an issue.

    SCENARIO: The breakpoint is in a library assembly that actually isn't used by the program.

    SOLUTION: Verify the code you are trying to step into is actually the assembly that the program loads.

    Michael Taylor
    http://www.michaeltaylorp3.net

    • Proposed as answer by Hart Wang Thursday, July 14, 2016 9:34 AM
    • Marked as answer by DotNet Wang Monday, July 25, 2016 7:20 AM
    Monday, July 11, 2016 1:58 PM

All replies

  • Here is the answer to a similar question:

    http://stackoverflow.com/questions/2155930/fixing-the-breakpoint-will-not-currently-be-hit-no-symbols-have-been-loaded-fo

    In the modules window, go to the assembly you are debugging, check its symbol status, check if it is user code. In the symbol file column, check if the file path is expected.



    Monday, July 11, 2016 12:51 PM
  • This indicates that one of several possible situations are occurring.

    SCENARIO: Your code isn't compiling. This seems odd but it is a very common problem for new developers. Most devs tend to use F5/Start Debugging to build and run their code. That is great but what few fail to realize is that if the build fails then you get the option of either stopping the debug session or continuing on with the last build version. There is a dialog that pops up that most people tend to blindly click on without reading and often check the "do not ask again" box. Hence they never get the error.

    SOLUTION: Do a build first and confirm the code is building correctly.

    SCENARIO: You are not generating the PDB. Rare since it is generated by default but can be confirmed in the project settings.

    SOLUTION: Once the build is complete verify the PDB is in the same directory as the binary and that the date/times are the same.

    SCENARIO: The PDB cannot be found. This generally indicates that you are using a custom output path or build script such that the PDB and DLL/EXE are not in the same location.

    SOLUTION: Same as the previous scenario.

    SCENARIO: You are doing a Release build and the code you have the breakpoint on is optimized.

    SOLUTION: Ensure that your project build configuration is Debug. Note that the solution configuration is what VS shows but projects generally match the solution. You can verify using Configuration Manager on the solution.

    SCENARIO: The breakpoint is residing in an assembly that hasn't been loaded yet.

    SOLUTION: .NET delay loads assemblies. If you put a breakpoint in code that resides in an assembly that isn't loaded yet then the BP will display the warning you gave until the assembly loads. If this is your primary assembly then this wouldn't be an issue.

    SCENARIO: The breakpoint is in a library assembly that actually isn't used by the program.

    SOLUTION: Verify the code you are trying to step into is actually the assembly that the program loads.

    Michael Taylor
    http://www.michaeltaylorp3.net

    • Proposed as answer by Hart Wang Thursday, July 14, 2016 9:34 AM
    • Marked as answer by DotNet Wang Monday, July 25, 2016 7:20 AM
    Monday, July 11, 2016 1:58 PM