I have a NDK Project in Visual Studio 2019 which uses several shared libraries.
In the project which contains the android_main function i can set breakpoints and use them without problems. If I set a breakpoint in one of my shared libraries (.so) and start the debugger I get this message:
The breakpoint will not currently be hit. Module containing this breakpoint has not yet loaded or the breakpoint address could not be obtained.
How can I load the missing symbols?
I'm using the platform toolset Clang 5.0
What I tried so far:
With this command I proved that symbols are present:
llvm-nm -D libMySharedLib.so
In the modules window (in debug mode) I can see that symbols are loaded for my .so module.
What I'm guessing is wrong:
With NDK typically such problems show up when the debugging info is being stripped away. There is also an option to disable this behavior which is called "donotstrip" in Android Studio. But I'm on Visual Studio.
Apparently, in Visual Studio, when starting the debugger, the respective shared library (.so) project must be set as "Startup Project". Only the breakpoints of the current Startup Project are reached or those breakpoints that are contained in .cpp files, which in turn are part of the respective Startup Project. This is of course not very comfortable and if someone here knows a better solution, a corresponding comment would be very helpful.
Anyway, if a shared library project is to be launched, the appropriate path and name of the .apk file must be set under "Configuration Properties"->"Debugging"->"Package to Launch".
Related
I have a C++ DLL project in Visual Studio I've downloaded, which is a plugin module for another existing program (a media Player). The DLL created by this project is saved into the addon folder, is loaded by the media player and works great with no issues. However, I would like to be able to step through the code in the library while the player is running to understand how the code works.
The problem is that when I setup the project to launch the media player and step through the DLL project code, it starts fine and I can set breakpoints. But at certain times, the Visual Studio debugger tries to access other loaded DLLs inside the media player, which I don't have source code for, and it crashes the whole thing with an "access violation writing location blah blah blah" error. I have no interest in trying to access any other libraries the program is loading other than the one I have the source code for, so is there any way to prevent the Visual Studio Debugger from trying to hook into these other libraries? I know the error is not due to anything in the DLL project itself because it runs absolutely fine if I just tell it to "Start Without Debugging."
I have the source code for, so is there any way to prevent the Visual
Studio Debugger from trying to hook into these other libraries?
Please try these steps:
Suggestion
1) check Enable Just My Code under Tools-->Options-->Debugging-->General
2) enter Tools-->Options-->Debugging-->Symbols-->choose All modules, unless excluded and then click Specify excluded modules
then input the name of the dlls you want to exclude. Their symbols will not be loaded when you debug your application.
3) do not forget to uncheck option Warn if no user code on launch(managed only) under Tools-->Options-->Debugging-->General
I have two C++ Visual Studio (16.5.0 Preview 2.0) projects: a library and an application that uses it. The library project produces four .lib files (for x86/x64 and release/debug), which the other statically links against. The application was until recently working fine in all configurations. Then recently I modified the library and rebuilt the .libs, and now when I build the application for x64 with "Use Link Time Code Generation" enabled, it crashes at runtime with an (apparently impossible) access violation. Note that the x86 build works with or without LTCG, and the x64 build works without it ("No Whole Program Optimization"). I've tried clean builds of both solutions and double-checked that I'm linking against the correct .lib.
This probably isn't a lot to go on, but does anyone have an inkling what the issue could be? Could VS's LTCG somehow cause the linker to use the old code?
I have a project in visual c++ where I am referring some external DLL.
I have already included the lib directory in linker section and mention it in the input section of the linker and also included the same in c/c++ General Additional Include Directories section.
Thus the project compiles successfully but whenever I try to run it; it fails with an error "Application was unable to start correctly" but if I see the output section it seems everything is loaded correctly but against that particular Dll it says that "Cannot find or open the PDB file".
How to fix this error so that I can run my program. It is an MFC program running in Visual Studio 2010.
when I run the program through the Dependency Walker, most of the API-MS-WIN-CORE-HEAP, FILE, and EXT-MS-WIN-SESSION USERMGR -l1-1-0.dll many similar to this are unavailable. I even tried to repair the visual studio it didn't work. Is there any idea how to go about it
0x0000007b sounds familiar to me.
Most likely that is due to 32/64 bit library mixture you are linking with.
Either you are building for x64 and linking with a win32 external library or vice versa.
In your Visual Studio project settings separately configure platform architectures you are compiling for and then you can choose the profile which you are actually compiling for.
I have a VisualStudio (2015 in case it matters) solution which has a C++ project compiled as a DLL, and that DLL is then used via DllImport in a C# Windows Forms project that is my executable. Let's call this executable ExeA. Because this ExeA needs my DLL in the same directory as the build location for ExeA.exe, and because I build for multiple platforms, in both Debug and Release flavors, configured the C++ project settings to have
<OutDir>$(SolutionDir)ExeA\bin\$(Platform)\$(Configuration)\</OutDir>
This makes sure that whichever way I build my executable project, the DLL is always delivered to the correct folder. However, this hard-codes ExeA name into the C++ project settings.
I am now adding a secondary C# executable project, let's call it ExeB, which must also use this DLL. Ideally, I would modify my C++ project settings to pick up the name of the target executable project from some Visual Studio variable. I looked here, but could not find a variable that represents the name of the project within a solution which is currently set as the "executable" project. Does anyone have any suggestions?
In my Visual Studio 2008 project, the active configuration is Release, and there are no debug symbols enabled in the Compiler and Linker settings. I'm building an exe file from command prompt:
devenv standalone_cpp.sln /build "RELEASE|WIN32"
There is no reason why a debug dll MSVCR90d.dll should get used at runtime, but it does and crashes. I don't have the slightest clue why only the debug dll gets picked up not the release dll MSVCR90.dll. Can someone please help?
I even tried building my .exe in debug mode hoping that it would not crash, but still it crashes with the same assertion failure _BLOCK_TYPE_IS_VALID(pHead->nBlockUse). Please help before I shoot myself.
Re-install the MSVS2008 Service Pack 1. Your install seems to have gotten corrupted.
I've had this happen -- it manifests with mysterious behavior like this, although I've also seen it manifest with strange "internal errors" when linking large DLLs/EXEs, and sometimes compiling very large projects, or very large translation units. For some reason, re-installing the service pack worked.
Here's a quick link: http://www.microsoft.com/downloads/en/details.aspx?FamilyId=FBEE1648-7106-44A7-9649-6D9F6D58056E&displaylang=en
Another thought might be that you did link debug into your release executable. Even though you built the solution for "RELEASE|WIN32", if any prerequisites (linked libs) were the debug version (either the *.lib was referenced directly, or you referenced the debug path instead of the release path), you'd end up with that mix and the "debug" version of that DLL would attempt to load.
Then, the reason it crashed, is probably that you allocated in a "release" module and deleted in a "debug" module (or vice versa). That won't work, because the allocators are different (since the "debug" versions allocate extra state for sentinels and other "debug checks").
Remember that MSVS2008 will "override" any project/solution settings with those found in Tools==>Options, even if you build from the command line. Check that no debug paths are set there for linking in your release targets. (That was a bad decision by Microsoft because it leads to project/solution files that do not describe what's actually happening, they removed that "feature" in MSVS2010.)
You might also have a look at:
Linking against library in release and .exe in debug crashes in Visual studio
C++ Linking release built library with my debug build
I think #Charley is on the money.
Download Dependency Walker and see what is actually causing the debug DLL to be loaded. If what you say in your question is correct, then it'll probably be another library that you exe is depending on.