I have a C++ DLL project (x86) that I need to debug.
This DLL is consumed by an exe.
I can easily attach the DLL project in VS2017 to a native exe (x86).
When I set breakpoints in the C++ DLL project in VS2017, these break points are hit.
This is the normal, desired behaviour.
Now I have attached the C++ DLL project to a .NET exe (compiled as x86).
Break points are not hit, and I don't have any idea why that doesn't work like with a native exe.
I have unchecked the option "Use Application Framework", but that didn't change anything.
I have also tried the option "Enable native code debugging" without any success.
Also, I have tried to attach it to a Debug version of the NET exe and to a Release version of the NET exe.
I can see that VS2017 attaches to the correct process as when I close the NET exe, VS2017 goes out of debugging mode.
However, breakpoints are not hit.
Is there anything special that I have to take care of?
Most likely, the managed .exe has not loaded the native DLL. Or it has loaded an incorrect build of the DLL, not the one that you’re debugging.
To troubleshoot, add __debugbreak(); call in your native code. That kind of breakpoint is very unlikely to be ignored, unless you mess with structural exception handling. Windows will show you a message offering to attach a debugger, you can choose existing instance of visual studio. Once attached, “Modules” window will show you exactly which build of the native DLL it loaded.
The best way to solve that permanently is add two projects in a single visual studio solution, setup dependency, and ensure the DLL output location is where the EXE looks for the library. I do it all the time in VS2017, with native code debugging enabled I can set my breakpoints in either managed or native code, which helps a lot debugging the interop.
Related
I have a c++ project using visual studio 2013. It compiles a dll.
The dll is called by a Microsoft Access project.
In the Microsoft Access project, we prepare the inputs for the dll, and declares which dll to call, and calls the dll with prepared inputs.The dll returns output to Access.
My goal is to be able to step through the c++ code because I want to improve the c++ code.
Any suggestions on how may I call the dll from Access and then step through the c++ code?
The Visual Studio Debugger, when debugging a DLL allows you to select the executable which is going to load that DLL. So find the MS Access executable, and specify that path. Then put a breakpoint as you would normally do, to indicate where you want to start debugging.
In addition to MSalters' answer, which is correct, you may start Access in the usual way, and attach to a running process. In Visual Studio, it's under menu, Debug/Attach...
If Access loads a debug build of the DLL, line breakpoints in the DLL sources will break into Visual Studio upon execution, as expected.
I'm using VS2010. I have an unmanaged EXE written in C++ that's using a .NET COM component which is also part of the same solution. I know that the COM object was created successfully because CoCreateInstance returned without an error. Yet, the component symbols aren't loaded (I can also notice that by not being able to create breakpoints in the .NET project source files), so I can't step into the code of the object's methods.
I tried to copy the .NET DLL's PDB into the same output directory of the EXE and it also didn't help. All projects in the solution are x64 and Debugging mode is set to Mixed.
If that matters, the DLL was registered using the command regasm /codebase
Any ideas? Thanks.
Yes, you have to enable managed debugging. One problem with Visual Studio (at least 2008 and 2010 -- don't know about later versions) is that you can only debug Native and Managed code at the same time with 32-bit processes. With 64-bit processes, you have to debug one type or the other, but not both at the same time. I suppose you might be able to spin up another instance of Visual Studio and debug the Native with one instance and Managed with the other.
Under your project settings, go to the "Configuration Properties" - "Debugging" page. On the right go over to Debugger Type and select Mixed.
I have a DLL written in C++. It wraps a static library. I am calling it from python with ctypes. So far, so good. I need to debug some calls in the DLL. I can hit breakpoints in the static library, but, not the DLL. I am doing this by using Attach to Process from the Debug menu. The code looks something like this:
extern "C"
{
__declspec(dllexport)
void foo()
{
int i = 0; // Can't hit breakpoint here
}
}
I am generating debug info. The pdb is sitting right next to the DLL. I am loading the DLLI think I am loading. What am I missing?
Edit
I recreated the project. Problem went away. Perhaps the difference is I went from a managed C project to an MFC DLL?
When you attach to a running process using MS Visual Studio, make sure you have the options set for both "Managed Code" and "Native Code". This will ensure your breakpoints in any type of code, native or managed, will be honored by the MS Visual Studio debugger. Otherwise, MS Visual Studio will use its "automatic" settings, which results in it only honoring break points that it sees in its "type" of project (for instance: a MFC project is native code (unmanged) and therefore won't normally debug managed code sections, while a .Net project is managed code and won't bother to stop for break points in "unmanaged" native code.)
You can set this option at attach time by selecting the "Select..." button, and swapping the radio button from "Automatic" to "Debug these code types". Under "Debug these code types", check the box beside "Managed" and "Native". You can select more options if you work with other types that MS Visual Studio recognizes (like T-SQL for SQL Server code, etc).
i'm developing a C++ simulation (OpenGL) on top of VS2008 enviroment. My current operating system is Windows Vista. The trouble is that when trying to execute the application on a Windows XP machine, my application crashes because incompatibilities beteween DLL's (namely, msvcrt.dll function entry points ) ... Has anyone experienced such problem?
I seriously doubt that's the real reason it crashes. You probably just didn't deploy the CRT libraries to the target machine. Or deployed the debug build. If this is a single EXE with no DLL dependencies then solve your problem by linking the static version of the CRT. Right-click the project in Solution Explorer, Properties, C/C++, Code Generation, Runtime libraries, select /MTd. Repeat for the Release configuration, now choosing /MT.
search for 'C redistributables' on MSDN. YOu will see a list of all the run time libs you need, make sure you get the debug / non debug and the unicode / ansi choices correct
Open the Visual Studio Command Prompt.
Type "depends.exe" and press enter.
Open the deployable EXE/DLL from depends.
Write down the list of DLL's needed to run your application.
Verify that those DLL's are either deployed with your targeted OS version or that you deploy them yourself.
I've got a minimal app I just created, using VS 2008 SP1 on Vista x64. Its a Console app, created with the wizard, no MFC or anything, I'm building it in 64bit.
When I run the debug exe, on my development box, by pressing F5 in Visual Studio 2008, I get this error:
TestApp.exe - Unable To Locate Component
This application has failed to start because MSVCR90.dll was not found.
Re-installing the application may fix this problem.
OK
I don't get this error when I run the release exe, it works as expected.
This problem started when I added some include dependencies on iostream and fstream and started calling some winsock API calls.
Any suggestions?
UPDATE: I copied msvcr90.dll (not msvcrd90.dll) into the correct folder, and now I get a different error:
Microsoft Visual C++ Runtime Library
Runtime Error!
Program: [snip]...
R6034
An application has made an attempt to load the C runtime library incorrectly.
Please contact the application's support team for more information.
OK
Alex
You application is using the DLL CRT runtime. The machine you want to run it on requires the installation of the debug CRT runtime dll's (which is a pain in the ass...). I think the better solution is to change the compile options to use the static linked CRT runtime (that means the runtime is linked into your application instead of using the DLL version).
In visual studio go into the Properites for your project then select the Configuration Properties / C++ / Code Generation and change the "Runtime Library" from "multi-threaded debug dll" to "multi-threaded debug".
You may like to do the same for the release build as well because some versions of the OS will not come with the V9 release CRT libraries pre-installed, or you can include the v9 release crt dll as part of your install.
How are you running the release exe (Ctrl+F5 in the IDE)? You should set the Runtime Library to the same thing you are setting the release exe.
Are you linking your debug mode program to a release mode library? You mention this error in a comment:
Error 13 error LNK2005: memmove already defined in LIBCMTD.lib(memcpy.obj) MSVCRT.lib DataEngineSocketsAPI
What that looks like to me is you have a library named DataEngineSocketsAPI that links to MSVCRT.lib, which defines memmove(). But, your exe links to libcmtd.lib, which also defines a different (debug mode) version of memmove().
Third-party (e.g. your own) libraries must have debug and release versions too, and you must use the one appropriate to the mode you're building your exe for.
The Debug exe is linked to the headers for the debug runtime library, MSVCR90D.dll. You need to make sure that dll is in the path. Static linking is, as Shane says, a viable option, but the typical solution is to deploy the dependant dlls with the exe. Statically linking everything leads to bloated exes and lots of duplicated copies of runtime libraries.
Seeing your edit, the problem is certainly the msvcr90d.dll, but it needs to be deployed correctly in the WinSXS folder. You might be able to re-install the service pack for VS 2008 and get it to redeploy.
Thanks again for all the help with this. It turns out I'd just made a mistake and not noticed that a library I was using was statically linked against a different version of the MSVC runtime. That was causing on end of problems.
See this link
http://www.insidercoding.com/post/2008/07/21/Debugging-issues-with-MSVCR90DLL.aspx
You need (for debug mode only) to ignore on the link input tab MSVCRT; MSVCR90; as you want to be using the debug version of the CRT.
I can confirm this problem: letting Visual Studio 2008
create the project (Visual C++/Win32 Console Application)
and pressing F5 will display that error.
There is a simple solution:
Turn incremental linking off. HOWTO: open properties page
for the project. Set Configuration
Properties/Linker/General/Enable Incremental Linking to "No
(INCREMENTAL:NO)".