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.
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 created a DLL from Haskell code and I am calling this DLL from C++. My application works fine when I run it in Debug mode in Visual Studio 2010, but when I make a Release build and install it, I get the error
The procedure entry point GetDataChunk could not be located in the dynamic link library AdvancedMath.dll.
AdvancedMath.dll is my Haskell-based DLL. The weird thing is that the function GetDataChunk isn’t in that DLL—it’s in another DLL I link against, and nothing about that DLL or my application’s use of it changed when I added the Haskell DLL.
This error message seems to be saying that Windows is confused about which functions live in which DLLs. What could be going wrong here?
This looks to be a bug in Visual Studio 2010 Release mode (Haskell dll functions are not imported by exe built in Release mode hence Haskell dll is not loaded, in Debug imports are present and it works fine).
The same exe project built in Release mode using Visual Studio 2013 Update 4 and Visual Studio 2015 RC works fine.
Have you tried using .def file to define exports? https://msdn.microsoft.com/en-us/library/d91k01sh.aspx
After you create it, you must edit project properties Linker->Input->Module definition file
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'm working on a C++ dynamic library that I want to use in Unity3D, except I'm encountering an error somewhere in it and would like to debug it in visual studio. To do this, I would like to convert the VS2010 project temporarily into an .exe project. What steps would I need to follow to do this? I've already tried changing the target extension, linker output file, and set the entry point but it just won't start.
Found that I can attach the VS debugger to Unity3D process, which does what I need.
I am trying to debug a project developed in visual studio 2010 and it loads VC++6 (VisualStudio 6) DLLs. Unfortunately I am unable to see the VC++6 DLL process under "Attach to process".
When I searched on the net I found the http://msdn.microsoft.com/en-us/library/cta4x5hc(v=vs.80).aspx article and it suggested to add /ASSEMBLYDEBUG when building vc++6 DLL. But then I get "Command line warning D4002 : ignoring unknown option '/ASSEMBLYDEBUG' ".
So can some one tell me whether it is possible to debug a VC++6 DLL from visual studio 2010.
regards
Upu
you do not need to attach. DLL is loaded into host process. So just start debugging you project that loads the dll. if you have pdb and source code of the dll, you will be able to set breakpoint in dll code.
The DLL's wont show up as a "process" in the debugger, they're part of the process that loads and uses the DLL's (i.e. the main application).
So yes, you can debug them with VS2010, you can just launch the app written in VS2010 (or attach to it in the debugger) and you should see the DLL's loaded in that.