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.
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 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 have a class library(C++) project in visual studio 2005, and want to debug this project using an application installed on the same PC. I have checked it was under debug and win32 platform.
But when I use the application to call one function in the class library, the breakpoint in the function can't be hit. The error is "The breakpoint will not currently be hit. No symbols have been loaded for this document."
Any ideas ?
It is likely that the library you are currently running does not match the code you have. I guess you did not compile and deploy the latest version of the code.
I am observing a strange behaviour with Visual Studio 2008 when I try to debug an exe remotely.
I have a solution that includes multiple projects. Thereby, each project is compiled into a lib and linked into my main project (the project that starts when hitting the run button). Visual Studio is configured to generate a pdb file that is named exactly like my exe file. Additionally, VS generates a vc90.pdb file for each project.
Now, I can debug my exe locally when I start it from Visual Studio or when I attach Visual Studio to a locally running process of my exe. But when I run my exe on a different machine, VS shows a strange behaviour. In this case, Visual Studio correctly stops at the breakpoints in all projects except for the main project. For each breakpoint in the main project, VS says that it could not load the symbols for the document. However, the modules view shows that VS loaded the correct pdb file.
Does anyone have an idea what is different between a remotely debugged application and a locally attached debugger. Especially because the main project is the only one that causes a problem...
My environment:
Visual Studio 2008 SP1
Host machine: Windows 7 64-bit
Remote machine: Windows XP 32-bit
I figured out that I missed a setting for the main project that was done for all other projects. I had to set "Project -> Properties -> C/C++ -> General -> Debug Information Format" to "Program Database (/Zi)".
I am using Microsoft Visual Studio 2010. When I am building my application in Debug mode, it is producing an EXE file (like it is supposed to be doing). But then (which is very surprising for me), when I change the mode from Debug to the Release mode, the compiler builds the application as a .DLL file?
I have only very recently started to use Visual Studio 2010, so don't know my way around it yet. How do I fix this so that when it is compiling in Release mode, to build the application as an .exe file ?
Set your project type to Windows Application.
In the IDE, right click on your project, and select Properties.
Configuration Properties->General->Configuration Type set to 'Application (.exe)'
In project options you should be able to choose whether you're building a .DLL or .EXE. I thought these were the same for all configurations, but you can check to see for yourself.