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)".
Related
I have copied a C++ solution folder written with visual studio 2013 to my Pc and tried to run it (I mean VS Debugging) with VS 2022. the solution Contains 5 projects but I just target one of them so unloaded the rest and set the one as Startup project and this error happened.
Error Image
Solution file is working well on first pc and project is not a win32 project its x64 (I don't know much from win32 or x64).
Unable to start program. [VALUE].dll is not a valid Win32 application error in Visual Studio 2017
According to this question I tried selecting project, setting as startup, repairing VS, installing vcredist_x64 but non helped.
After Running, VS make Debug folder in solution Directory not the project "LP_Dll\x64\Debug" (LP_Dll is the solution name) without any .exe file, and the error path is exactly this folder, can it be from that?
Project properties the "Configuration Type" was mistakenly changed to .dll.
I want to execute a C++ program in a second machine without any IDE.
I tried to launch the .exe file which is located in the debug folder of the project and to generate a .exe file following this guide.
Both .exe gave me the same errors (launched manually and from a prompt):
The program can’t start because
- VCRUNTIME140D.dll
- MSVCP140D.dll
- VCRUNTIME140_1D.dll
- ucrtbased.dll
is missing from your computer. [...]
So i try to uninstall and reinstall Microsoft Visual C++ Redistributable per Visual Studio 2015, 2017 e 2019 from there, but still the same errors.
What am I missing? How can I run it without install the whole Visual Studio IDE? Thanks for your time.
You need to compile your program to a Release exe file. Compiling your program using Debug will never work on any device unless it has Visual Studio installed on it.
Why this happens?
If you select debugging, before the program runs it loads some DLL files for debugging in visual studio. Now, on other machines visual studio may not be installed, so it couldn't find the DLL files so it will just not start. But Release, it is like its name, when you want to send your program to a friend or use it on another computer or share it on the internet, use Release. But if you are testing bugs and still working on the program, use Debug.
i have a strange problem.
the dll that i built (lets call it my.dll) in c++ visual studio 2010 uses a third party library (say tp.lib) which in turn calls a third party dll (say tp.dll).
for debugging prupose i have in configurationProperties->debugging->command: Excel.exe
and configurationProperties->debugging->commandArguments: "$(TargetPath)"
in my computer i also set PATH variable to the directory where tp.dll resides
now when i hit the F5 in visual studio excel opens up with my.dll and crashes giving me a "cannot open in dos mode" error. the reason this happens is tp.dll is not deployed when debug version of my.dll is deployed.
when i open an instance of excel seperately and manually drop the debug version of my.dll then everything works fine and i can see all my functions that i wrote in my.dll
the only issue is now i do not know how to debug becuase i do not know how to attach visual studio to the instance of excel i opened up seperately.
my question is:
1> how can i attach visual studio to an already opened instance of Excel
or
2> how can i hit F5 and still make Excel pick up the required tp.dll from the directory specified in the PATH variable before it starts to deploy my.dll.
any of these two will allow my to step through the code for the purpose of debugging.
thanks in advance.
okay i figured out a way to do it by trial and error
1>build the debug dll.
2> open instance of excel and drop my.dll from the debug folder to it.
3> in visual studio 2010 : properties->configurationproperties->debugging->command = excel.exe
4>properties->configurationproperties->debugging->Attach = yes
and now you hit F5 in visual studio. this will attach the visual studio editor to the running copy of my.dll which will allow to to step through the code.
Unless you are using the Express edition you can attach visual studio to a running process.
I would copy tp.dll into the folder containing my.dll.
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.
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.