I injected a C++ DLL into a target process like described here. In Visual Studio I want to debug the injected DLL like a "normal" application. I followed this tutorial which seems reasonable but Visual Studio does not break and only says:
The breakpoint will not currently be hit. No symbols have been loaded for this document.
Why? I'm using the default Debug configuration (with debugging symbols I believe). The DLL is injected successfully and executed the DllMain but Visual Studio does not "notice" that even though it is attached to the target process. Is there anything "special" I need to consider configuring in Visual Studio?
As far as I know even if the Dll was built with Debug configuration it won't contain all symbols necessary for debugging. You will still need its symbol file which is generated when building.
I assume you didn't build the DLL yourself because otherwise Visual Studio should be able to find the symbol file on your disk by itself. The symbol file has .pdb as extension and usually resides inside the build folder. You need to locate it and tell Visual Studio where to search for it during your debug session. When you have found the symbol file select "Debugging" from Visual Studio's menu bar and follow this path: "Options" => "Debugging" => "Symbols". Hit the button with the green plus sign to add the location where the symbol file resides. Take note that you only need to add the file's location, specifying its name is not required.
Related
I am trying to debug a .exe file with a .pdb. The project is using SCons, and here is the part where it compiles in sconstruct:
env.Append( CCFLAGS=["/EHsc"])
env.Append( CCFLAGS=["/DEBUG", "/Zi", "/Fdgame.pdb"])
env.Program('game', ['game.cpp', Glob('feather/*.cpp')], LIBS=['SDL2', 'SDL2_image', 'SDL2_ttf', 'SDL2_mixer', 'SDL2main'], LIBPATH='lib/Windows/lib')
So I'm adding the flags that are correct (I think) to generate the .pdb. The pdb shows up in my project directory, in the same location where the .exe is. After looking at its contents, I'm pretty sure that it has the correct information to work (at least, it is not empty). I am setting game.exe as the startup item, then running it from VS 2022. However, after running the .exe, Visual Studio claims that the "Binary was not built with debug information."
Modules tab showing this message under "Symbol Status."
According this page on the Microsoft VS documentation, it says:
The debugger searches for symbol files in the following locations:
The project folder.
The location that is specified inside the DLL or the executable (.exe) file. By default, if you have built a DLL or an .exe file on
your computer, the linker places the full path and filename of the
associated .pdb file in the DLL or .exe file. The debugger checks to
see if the symbol file exists in that location.
The same folder as the DLL or .exe file.
My .pdb should fulfill conditions 1 and 3, so I'm confused as to why it can't be found (if that's the issue). The docs do mention that this applies when you build a project, but I've seen other video tutorials online where they just attach .pdbs to running processes and it still works. Is there anything I'm missing?
Try changing to
env.Append( CCFLAGS=["/EHsc"])
env.Append( CCFLAGS=["/DEBUG", "/Zi"])
env.Program('game',
['game.cpp', Glob('feather/*.cpp')],
LIBS=['SDL2', 'SDL2_image', 'SDL2_ttf', 'SDL2_mixer', 'SDL2main'],
LIBPATH='lib/Windows/lib', PDB="game.pdb")
If that's still not in the correct location then change to
PDB="${TARGET.dir}/game.pdb"
See the manpage for info on the PDB environment variable:
https://scons.org/doc/production/HTML/scons-man.html#cv-PDB
I have a new SDI project in VS2010 but I can't step into MFC source. I followed the steps here and it seems like the resource symbols are not loaded for some reasons but it wouldn't load on right click either as described in the most voted answer there.
When I go into debug >> Windows > Modules, that window shows the symbol status column as Cannot find or open the PDB file. I guess that's the problem but when I right click on any one module (for example mfc100enu.dll) I get another dialog with similar message than can't find symbol file.
What could have gone wrong that it can't find symbol files and how to fix this?
The function I want to step into is LoadFrame in below in my basic SDI application.
BOOL CMainFrame::LoadFrame(UINT nIDResource, DWORD dwDefaultStyle, CWnd* pParentWnd, CCreateContext* pContext)
{
// base class does the real work
if (!CFrameWndEx::LoadFrame(nIDResource, dwDefaultStyle, pParentWnd, pContext))
{
return FALSE;
}
...
}
Any hints how can I not load them and what might be wrong? Thanks
Update
I was able to get VS2010 to load the symbol files by going to Tools->Options->Debugging->Symbols and select checkbox "Microsoft Symbol Servers" and now Visual Studio loads PDBs automatically. However I still can't step into the function.
Change your mfc library linking mode to static library.
In project properties >> Configuration Properties >> General >> Use of MFC
After debugging, you can change back to what you like.
Hope this help.
I found that adding the symbol servers didn't solve the problem for me.
What did solve the problem was adding this directory to the list of locations to look for symbols. Not sure why Visual Studio doesn't add this itself.
C:\Windows\Symbols\dll
You need a Visual Studio Professional or above. Then you get the sources and debug symbols for MFC. If that is given, you only need to ensure that the PDBs are located in the symbol path, which should be the case with a proper Visual Studio installation.
With Visual Studio 2019, I had same issue.
I can't step-into MFC base classes with VC debugger.
I have solved it with adding Symbol dir. to "Symbol file locations".
Tools > Options > Debugging > Symbols
C:\Program Files (x86)\Microsoft Visual Studio\2019\ (Edition)\VC\Tools\MSVC\14.27.29110\atlmfc\lib\x86
C:\Program Files (x86)\Microsoft Visual Studio\2019\ (Edition)\VC\Tools\MSVC\14.27.29110\atlmfc\lib\x64
Additionally, this setting can't solve MBCS - Multi-byte character set project.
For multibyte project, you have to use "Microsoft Symbol Server".
VS installer does not install required symbol files for you.
It means you cannot debug MBCS project without public network to MS.
Check "Microsoft Symbol Servers" option at "Symbol file locations"
Check next links for more information.
https://learn.microsoft.com/ko-kr/cpp/mfc/mfc-mbcs-dll-add-on
https://support.smartbear.com/testcomplete/docs/app-testing/desktop/visual-c/preparing/mfc-debug-info.html#WindowsSymbolCache
I think VS2019 installer and installation are too complex. And MS changes it rapidly. They must not continue it before all developer leaves VS platform.
I created a cache dir for symbols and loaded them all. The Modules windows told me that the proper PDB loaded OK. But I still couldn not step into MFC.
After playing with other solutions, like adding symbols cache and mfc lib directories to symbol locations, linking statically (which worked), it appeared that simply checking
Tools > Options > Debugging -> General -> Enable Just My Code
OFF
did the trick. I tried stepping into CWinAppEx::InitInstance and now I can.
Configuration: MSVS2022 Pro, Windows10, use MFC as a dynamic library.
The project runs okay in the debug mode of Visual Studio, but when I tried to double-click the exe generated, it says some dll is missing. When I copied the missing dll beside the exe and double-click again, no error message dialog appeared but also nothing happened(the project has Qt-based GUI and reference some external png files).
How does Visual Studio run the exe ? How can I run the exe on my own ? Should I create a installer for the project to make it run on other computers?
you would need to either build statically or provide the required dll files.
the page at http://www.tapkaa.com/2013/05/what-dll-files-are-required-to-run-an-application-developed-with-visual-c/ tells how you can find the missing dll files.
When a process needs to load a DLL by name (without a full path to it), it will check several different places. One of those places may be the current working directory. (The details of the search path are complicated by history and security issues. You can learn the details by looking up LoadLibrary and SetDllDirectory on MSDN.)
In Visual Studio, if you look at the Properties page for the project, and click the Debugging tab, you'll see what directory is set as the working directory when you launch the program from Visual Studio. When you double click on an icon, I believe the working directory will be the directory of the executable file. If these are different, that could explain why you're able to find the DLL in one case but not in the other.
If you're calling LoadLibrary directly, the best thing to do is to always give the full path to the library. Typically, you GetModuleFileName to find out the full path for the executable, then replace the filename portion with the name of the DLL or a relative path from the executable to the DLL.
If you're failing to load an implicitly-linked DLL, then you probably need to make sure your DLL is in the same directory as the executable file.
I have a separate Visual Studio solution with the DLL written in C. I use it in another solution; in a console C++ project. While debugging the console project I step into a DLL function.
However, the page is opened reporting that There is no source code available for the current location with call stack location MyConsole.exe!_tailMerge_MyLibrary_dll(). I use delay loading of the DLL file in the console project. As the no source code page is displayed, I inspect the output window and find symbols loaded of the DLL line. Why does Visual Studio 2012 fail to step into this DLL code?
I had the same problem and the following solved mine. I set "Debugger Type" to "Mixed" on the properties page of the main project. My main project is managed code while the .dll is native.
It happens, when dealing with external projects that Visual Studio asks you if you have the code. If you cancel the process, the requested file gets added to a list in the solution and it remembers NOT to ask for the file again.
Check your Solution Property Pages > Debug Source Files. First, make sure your file is NOT in Do not look for these source files: and then make sure you add the location of the sources in the Directories containing source code. This should help fix the problem.
I have an *.exe project that was written in one solution under vs2005 and i have a DLL file
that the *.exe project is using.
the problem is that the dll was written in adiffrent solution and when i try to make attach
to the *.exe file (after i run it) from the dll solution in order to debug the dll , i get no symbols are loaded error (and i cant debug the dll) altough symbols were loaded (i can see the *.pdb files that created after i compiled the dll solution) .
What can I do?
First check the Output window, it will show whether or not it could find debugging symbols for the DLL when it got loaded. Next, switch to Debug + Windows + Modules, right-click your DLL and choose "Symbol load information". That shows where the debugger looked for .pdb files for the DLL. Ensure the .pdb is located in one of these paths.
If the problem is not getting source code for the DLL instead of missing .pdb files, first delete the hidden .suo file in the solution directory. The next time you debug into the DLL, Visual Studio will again prompt you to provide the path to the source code file. Don't press Escape, enter the path. Another thing you can do is right-click the solution in the Solution Explorer window, Properties, Common Properties, Debug Source Files. Add the path to the DLL source code directory.
If you have the visual studio project that generates the dll, compile it in debug configuration and launch debug. You'll be asked for an executable ; select the one you have (from your other solution) and you'll be able to debug the dll.
Now if you want to debug both at once, i believe your way is correct, as long as the dll that the exe uses is the exact one that you've just compiled in your other solution. That might be the problem you're encountering.