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).
Related
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.
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 short JScript which creates an active X object and calls a function. That active X object is written in C++. When I run the command cscript scriptName.js //X I start VS2012 in debug mode. Than I try to attach a debugger but as you know one is already attached.
Is there a way to reattach the debugger or connect to it some how?
My current solution is not to use JScript and call the code from C++.
Which debugger do you want to use?Visual Studio or WinDBG?
Do you really need to debug both the JavaScript code AND the C++ code simultanously?
If the latter isn't an issue for you, and you want to focus on the C++ code, in Visual Studio (or WinDBG) just debug cscript.exe, without the /x flag. No need even to attach, you can start debugging with F5 from Visual Studio.
In Visual Studio (2008, 2010, or 2012 - they all work), right click on the ActiveX project (That's the C++ project).
Go to: Configuration Properties -> Debugging
In the Command put the cscript full path: C:\Windows\System32\cscript.exe
In the Command Arguments put the full path of you JS file
Put a break point on your ActiveX code (on dllmain, or the constructor of your COM object)
Hit F5
Visual Studio will complain about lack of symbols of cscript. That's OK. keep going.
You'll hit your breakpoint
Some point to consider:
Setup the symbol path to include the Microsoft Symbols. This way, you'll see the names of the functions that calls your code (oleaut32.dll and friends).
Also, this is the default, but make sure that:
The debugger type in the same property box would be either Native or Auto.
Does any one know how we can do this?
I have python code in eclipse and whenever it calls c++ functions, i want the break point to go to the visual studio c++ project.
You can use a __debugbreak in visual studio so that every time the code is invoked it triggers the debugger (you may want to search the function in MSDN).
Insert the instruction in the C++ function (or class method) you want to debug, e.g.
void foo()
{
__debugbreak();
[...]
}
at this point compile the library and run the python script, when library loads and the code is executed a messagebox appears telling if you want to attach the visual studio debugger.
It is the replacement of the old __asm { int 3 }.
If the C++ app runs as a separate process then its pretty easy. You can run the process yourself or attach visual studio to existing running process and put break points.
If C++ code is an embedded DLL/LIB then you can use python as debug/launch process. As soon as python will load the DLL/LIB into your python code visual studio will activate your break points.
Alternatively you can also add windows debugger launcher calls to your code. As soon as your code gets executed, you will see a dialog box asking if you want to attach a debugger.