How to: Debug an Executable Not Part of a Visual Studio Solution
This topic applies to:
Pro and Team
Does not apply
Command or commands hidden by default.
Sometimes, you may want to debug an executable that is not part of a Visual Studio project. It may be an executable you created outside of Visual Studio or an executable you received from someone else.
The usual answer to this problem is to start the executable outside of Visual Studio and attach to it using the Visual Studio debugger. For more information, see Attaching to Running Processes.
Attaching to an application requires some manual steps, so it takes a few seconds. This slight delay means that attaching will not help if you are trying to debug a problem that occurs during startup. Also, if you are debugging a program that does not wait for user input and finishes quickly, you may not have time to attach to it. If you have Visual C++ installed, you can create an EXE project for such a program.
To create an EXE project for an existing executable
On the File menu, click Open and select Project.
In the Open Project dialog box, click the Files of type drop-down arrow, and select Executable Files.
Locate the executable, and click OK.
This creates a temporary solution that contains the executable.
As an alternative, you can import an executable into an existing Visual Studio solution.
To import an executable into a Visual Studio solution
On the File menu, click Add Project, and then click Existing Project.
In the Add Existing Project dialog box, locate and select the executable.
Start the executable by choosing an execution command, such as Start, from the Debug menu.
Not all programming languages support EXE projects. Install Visual C++ if you need to use this feature.
When you are debugging an executable without the source code, the available debugging features are limited, whether you attach to a running executable or add the executable to a Visual Studio solution. If the executable was built without debug information in a compatible format, available features are further limited. If you have the source code, the best approach is to import the source code into Visual Studio and create a debug build of the executable in Visual Studio.