opsb
opsb

Reputation: 30231

Breakpoints for C++ in Visual Studio

Breakpoints set in Visual Studio for a C++ project aren't hit when I run the debugger.

When I launch the debugger I get the warning

Debugging information for 'IEXPLORER.EXE' cannot be found or does not match. No symbols loaded. Do you want to start debugging?

I hit yes to continue, but then the breakpoints I set have a warning saying that:

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

How do I get the symbols loaded when I debug the project? Do I need to change the way it is built?

Upvotes: 0

Views: 2306

Answers (5)

Ken Smith
Ken Smith

Reputation: 20445

I was running into this problem, and the only way I could get around it was to override the "Automatically determine the type of code to debug" option in "Attach to Process". As soon as I cleared the "Silverlight" debug type, then all the right modules showed up under iexplore.exe, my breakpoints lit up, and I was able to debug appropriately. Not sure why that was necessary, or if it is all the time, but it's what worked for me.

Upvotes: 0

Julien Crozon
Julien Crozon

Reputation: 116

You must be sure of three things:

  • generate the .pdb file of the DLL that contains the code where you're trying to break, and make sure this .pdb file contains source information. If you tell me which IDE/language you use, I can help you to ensure that.
  • make sure that your debugger find this .pdb file; an easy way is to copy the .pdb file close to your binary file. If the .pdb file is loaded, the tool window available in menu Debug\Windows\Modules in Visual Studio should say 'Symbol Loaded' in the column 'Symbol Status' at the line of your DLL file.
  • if you use another computer to debug than the one used to build your DLL file, make sure that you have the source file at the same path in both computer.

With this, your breakpoint should be fine.

Upvotes: 1

Gilles
Gilles

Reputation: 5417

The first thing I would check is that you are building in debug mode. There is a combo box where you can choose between Release and Debug mode in the toolbar.

In Release, the debugging information is not included.

The second thing would be making sure you are attaching your debugging to the right process. You can either start attached to the process (F5) or start without attaching (Ctr-F5) and then attach yourself manually (via the Debug menu, attach to process).

IEXPLORER is the process you are currently attaching to. Are you sure this is correct?

Upvotes: 0

kichik
kichik

Reputation: 34744

It looks like you're trying to debug an extension to Internet Explorer (toolbar, bho, etc.)

If Internet Explorer is giving you trouble attaching to the right process, you can make your process crash on purpose and then JIT debug it. Use DbgBreakPoint in DllMain to do it. Visual Studio should pop-up a window asking you if you want to debug it. It's a little backward, but should help you avoid all of the process toying IE might do.

This will also allow you to see the debug output from your other question, as you'll be attached the correct process.

Upvotes: 1

Dialecticus
Dialecticus

Reputation: 16769

Latest Internet Explorer has different process model that inherently disables debugging of ActiveX controls (which I presume you're trying to debug). There is a registry setting however that may help you.

HKLM\Software\Microsoft\Internet Explorer\Main > TabProcGrowth:DWORD

Set this value to 0 and you should be able to debug controls.

Upvotes: 2

Related Questions