Do you know how can I debug STLPort containers in VS2010 ?
I want to debug them, as easy as STL containers.
Related
Visual Studio 17 and Windows 10 64
Let's say I have written c++ code that uses a 3rd party library like opencv. That library is compiled for release, not debug.
When I try to build the project in debug it fails because VS can't find the debug libraries. But surely there must be some way to be able to debug only my code, I don't expect it to debug opencv functions. How?
I am building a Qt App but I am having problems when I move the app to another PC. When I run the .exe the it keeps saying it is missing dependencies and once I transfer the missing one another one pops up. I assume that I need to install something on the target pc that contains all of these DLLs.
Some of the missing dependencies so far:
MSVCP140D.dll
vcruntime140d.dll
api-ms-win-core-rtlsupport-l1-2-0.dll
I think that there may be issues with the install of MSVS or MSVC on my build pc as I constantly have to point to things like UCRT manually.
Thanks in advance
Missing Runtime: Those files are obviously part of a runtime that your application needs (Visual C++ Redistributable for Visual Studio 2015 - maybe?), but more than that you seem to have distributed the debug version of your application which will depend on debug versions of runtime dlls (dll name ends with "d" as in MSVCP140D.dll). These are generally only installed on developer PCs, and are not for distribution to client PCs at all.
Release Build: Maybe try to build your application in release mode and try to run that executable on your client systems. The required runtime might already be present on their boxes, just not in debug version.
Static Linking: I suppose you could also try static linking (for the Microsoft runtime: How do I make a fully statically linked .exe with Visual Studio Express 2005?), if that is available to you (I am not up to speed with Qt's handling of this in terms of availability of static linking with different forms of licensing): MSVCP140.dll missing. Just so it is mentioned: thought conceptually the same, static linking is different for Qt (licensing issues?) and the core Microsoft runtimes (see link above). Use a binary dependency checker to investigate how dependencies have changed with new compilation settings.
Remote Debugging: If you need to make a test PC capable of running your application in debug mode (maybe for remote debugging without installing all of Visual Studio): Preparing a Test Machine To Run a Debug Executable.
"Hacky": It seems here is another, "hackier" approach that I would not really recommend: install VC++ Debug Runtime Distributable. For other Visual Studio versions look for the debug_nonredist folder. Debug versions of an application are not redistributable, and debug versions of the Visual C++ library DLLs are not redistributable. Very important.
I m writing a multimedia application .For Debugging purpose I need gstreamer debug builds for windows. Ossbuild only provides the release dll. Does anyone know where I can get debug dlls for gstreamer?
You'll have to build it yourself, until the Gstreamer SDK comes out for Windows. Even if you managed to obtain debug DLLs, they would have to be from the same version of gstreamer that you're targeting with your release build, or else you'd get non-meaningful results when debugging.
If you used OSSBuild with Visual Studio, you may be able to find the .pdb files for debugging already in $OSSBUILD/Build/Windows/Win32/Release/pdb directory; if you can find these files, you can add them to Visual Studio so it knows to use them by following, e.g. these instructions.
Reference for OSSBuild debug info: here
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.
I use a 3rd party DLL in my VB.NET project (VS2005) that responds to slow and give wrong values in debug mode. In run-time mode everything works as expected.
I do understand that there are something going on in the debug mode which makes the DLL communication slow. This behavior makes it hard to debug the application correctly.
Is there any way to force VS to communicate with the DLL in "run-time" mode during debugging but let the rest of the project be in control of the debugger?
I found a setting that resolved my issue:
Project Properties > Debug > Enable Debuggers > select "Enable unmanaged code debugging".
Now the DLL communication flowed smoothly. The DLL I use is a middleware between my app and a USB device. There is no Debug/Release version of the DLL.
Change the debug DLL for the release one, either by switching files or by telling the linker/build process to only use the release one, but like the comment above I'd suspect there's some funky stuff going on in both.