I have used the Visual Studio 2012 Performance Analysis to profile my C++ code for a long time, but recently when I try to use it seems to be failing to load the symbols as I get this error when I try to view the details
Matching symbols could not be found. Choose the 'Symbol Settings..'
link to add the symbol file location and then reload the report.
I have visited Options -> Debugging -> Symbols but I don't know what I need to add so that the symbols load correctly.
Currently in that menu Symbol file (.pdf) locations: has one option available in it and it called Microsoft Symbol Servers and it is selected. In the Cashe symbols in this directory: I can see it is being set in a temp folder but when I go that folder I see it is empty.
What do I need to add so that the symbols load correctly?
I asked this question on MSDN and I was told that this is a known issue with Visual Studio 2012 and Windows 8.1. Microsoft has either by now fixed it or will fix it in a future update. Here is a link to the MSDN question.
make sure you build your project with .pdb files and add these to the list of symbol locations (possible library pdb's as well). I know this should be a comment, but i don't have the reputation for it yet :(
Related
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.
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.
I walked through this tutorial and tried to recreate the example I get this error:
Error 1 error LNK2019: unresolved external symbol __imp__GetXyz#0 referenced in function _main app.obj app
If I download the source from the website and run the project in visual studio it works, but If I even copy the code from the original project in my own visual studio solution it still doesn't work. I guess it must be some project settings, I don't know. What do do?
You need to add the XyzLibrary.lib to your Linker settings within project settings.
You can also do it directly in code by using #pragma comment(lib,"xyzlibrary.lib") if you are using VisualStudio.
The reason why it works in the given sample without these 2 approaches is that in the solution file, the dependencies are set from XyzExe to XyzLib, and XyzProject has 'Link Library Dependencies' in Linker settings set to true. However, I am not too keen on this approach, as I don't like to store data important for building inside solution files (for larger projects, developer's solution files can differ from build system solution files)
Seems like you are missing some external library that needs to be linked in. Whatever provides the GetXyz function is missing.
Open the Solution that works, right click the project, Properties, Linker, Input, and check what their Additional Dependencies list up. You need to add the same to your own project.
There is a short response from Microsoft regarding this issue:
https://connect.microsoft.com/VisualStudio/feedback/details/470376/odbc-application-linking-with-odbccp32-lib-gets-link-errors-in-vs2010-beta-1?wa=wsignin1.0#tabs
Basically, their response doesn't seem to address the problem.
Our application needs to statically link to the C libraries, but there is a linker error when attempting to do so. Microsoft's answer seems to be "dynamically link instead", but that's not an option. Their alternative is to "Use the version of odbccp32.lib that came with Vista SDK." However, I am unaware as to how to force VisualStudio 2010 to use a different version of the ODBC library?
I just spent the last hour trying every conceivable search through the .vcxproj and .sln files for any references to odbccp32.lib. None. I similarly looked for ODBC. None. Looking at all of the compiler & linker options for the project(s) in question: nothing refers to ODBC whatsoever. The only connection between our application and ODBC I can see is the #include <sql.h> and <sqlext.h>. However, even those files do not refer to odbccp32.lib (or any other .lib or linker option).
The only references to odbccp32.lib I can find at all are in .obj files. So it appears that VS2010 automagically knows which ODBC libraries to link against based on what functions are referenced in our software (SQLConnect(), for example).
So how might I:
1) "obtain Vista SDK version of odbccp32.lib"?
2) cause VS2010 to link against that version?
-OR-
Is there a better way to solve this?! Right now I am unable to proceed with a conversion of our software from VS2008 -> 2010 unless I can find a way to force this goofy software to compile.
NOTE: Apparently I could force the system to compile using 2008's tooling, which may "cure" this. But that means changing all of our projects up & down the chain to do this, which is rather backwards and contrary to the whole point of moving to 2010, no?
For the curious, the exact linker error:
odbccp32.lib(dllload.obj) : error LNK2019: unresolved external symbol __imp___vsnprintf referenced in function _StringVPrintfWorkerA#20
Reading through your link, it seems that Microsoft has verified that there is a problem, and they intend to fix it in the next version of the SDK. Doesn't help much, does it?
It's quite normal for the linker to daisy-chain through the objects, linking one object only to discover that it has dependencies on other objects. If you want to preemptively link to a specific library, add it to the "Additional Dependencies" in the Linker Input tab of the project properties.
If you aren't able to get the linker to prefer a specific version of a library, just seek out and replace the version of the library in the installation.
I think this is a link to the Vista SDK, but I can't verify it: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=ff6467e6-5bba-4bf5-b562-9199be864d29&displaylang=en
I see it. Ouch, my condolences. Their advice is about as best as it is going to get if you don't want to compile with /MD. I think I know the source of the problem, this isn't that easy to fix for them either. It's going to require them getting the VS2010 CRT header file fixed first, then recompile and issue an SDK update. That takes some major doing.
It is getting linked because it is listed in the "Core Windows Libraries" property sheet. View + Property Manager to see it. Not linking it is not an option, you are probably actually using it when you #include <sql.h>
The Vista version indeed doesn't have the same problem, it was probably built with an earlier version of VS. Project + Properties, Linker, Input, Additional Dependencies = "c:\program files\microsoft sdks\windows\v6.0a\lib\odbccp32.lib". This injects the vista version before the 7.0 version. You may have to live with this for a while, be sure to keep VS2008 installed on your build machines.
I just encountered the undefined __imp___vsnprintf symbol while converting an ODBC application to Visual Studio 2015. Figuring that there must be a workaround, I dumped all the symbols exported by the various libraries in the Visual Studio 2015 LIB directories with DUMPBIN and found that this library with a most obvious name, legacy_stdio_definitions.lib, defines these symbols.
Adding this to the LINK command line resolved the missing external referenced by odbccp32.lib.
Once one knows what to search for, some info is available here.
Don't know all the details, so shooting in the dark. When I had a situation when certain functions were available with one compiler and not the other, I created a simple DLL with the functions exported with C interface, using compiler version that supported those functions, and used that DLL with another compiler.
the solution is to link with just odbccp32.lib from v6.0 sdk all else from the default sdk.
1. download v6.0 sdk from: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=ff6467e6-5bba-4bf5-b562-9199be864d29&displaylang=en
(do not install documentation and samples/examples, the result is 75MB downlaod):
2. create a folder, some folder.
for example: lib_odbc_fromsdkv6.0 in your project's folder
3. copy the file odbccp32.lib from:
C:\Program Files\Microsoft SDKs\Windows\v6.0\Lib
to folder created above (only one file).
4. in each project's properties add that (lib_odbc_fromsdkv6.0) directory to Library directories:
VC++ Directories -> Library directories
the depended projects in myodbc are myodbc5S and myodbc-installer.
(from Mordachai)
WinDbg can't find mfc90 version 9.0.30729.4148 symbols on msdl.microsoft.com
Where are those mfc symbols?
Some background info:
I have a crash dump that I want to analyze in WinDbg.
My symbol path contains http://msdl.microsoft.com/download/symbols
The 9.0.30729.4148 version seems to be installed by some Windows update
When a dump contains an earlier version of mfc90, it is located by WinDbg on the Microsoft symbol server with the same settings.
When I use !sym noisy, the output for mfc90.dll contains:
SYMSRV: http://msdl.microsoft.com/download/symbols/mfc90.dll/4A596D4939c000/mfc90.dll not found
The same thing happens on two different computers
The symbols are present on the server, but WinDbg can't get them.
I had a similar behaviour in Visual Studio; the symbols for MFC90.dll wouldnt load. Clicking on "Symbol load information" for mfc90.dll gave "No matching binary found".
I searched for the correct dll on my computer and found it at
C:\WINDOWS\WinSxS\x86_Microsoft.VC90.MFC_1fc8b3b9a1e18e3b_9.0.30729.4148_x-ww_a57c1f53
Note that of course this path only contains the dll, but not the .pdb-file.
Anyways, after adding this path to the symbol search path, Visual Studio is able to download the correct pdb-file from the Microsoft symbol server.
In case the required dll cannot be found locally, I suppose ModuleRescue can help.