How to debug exe in visual studio

Then, run a debug build of the app. If you don't have the source code, and the app doesn't have debug information in a compatible format, available debugging features are very few. In the Open Project dialog box, select All Project Files , if not already selected, in the dropdown next to File name. Start debugging the app by selecting an execution command, like Start Debugging , from the Debug menu.

With the new file selected, start debugging the app by selecting an execution command, like Start Debugging , from the Debug menu. Skip to content. Attaching to an app requires manual steps that take a few seconds. Because of this delay, attaching won't help debug a startup issue, or an app that doesn't wait for user input and finishes quickly. Not all programming languages support EXE projects. Debugging features for an app that wasn't built in Visual Studio are limited, whether you attach to the app or add it to a Visual Studio solution.

If you have the source code, the best approach is to import the code into a Visual Studio project. Then, run a debug build of the app. If you don't have the source code, and the app doesn't have debug information in a compatible format, available debugging features are very few. If you can't connect using the remote computer name, try using the IP and port address for example, For other remote debugger port assignments, see Remote debugger port assignments. Select the Find button next to the Connection target box to open the Remote Connections dialog box.

The Remote Connections dialog box lists all the devices that are on your local subnet or directly attached to your computer. You may need to open UDP port on the server to discover remote devices. Select the computer or device you want, and then click Select. The Connection type setting persists between debugging sessions. The Connection target setting persists between debugging sessions only if a successful debugging connection occurred with that target.

To find processes running under all user accounts, select the Show processes from all users check box. If you try to attach to a process owned by an untrusted user account, a security warning dialog box confirmation will appear. For more information, see Security Warning: Attaching to a process owned by an untrusted user can be dangerous. If the following information looks suspicious or you are unsure, do not attach to this process.

In some cases, when you debug in a Remote Desktop Terminal Services session, the Available processes list won't display all available processes. If you are running Visual Studio as a user who has a limited user account, the Available processes list won't show processes that are running in Session 0.

Session 0 is used for services and other server processes, including w3wp. You can solve the problem by running Visual Studio under an administrator account or by running Visual Studio from the server console instead of a Terminal Services session. If neither of those workarounds is possible, a third option is to attach to the process by running vsjitdebugger.

You can determine the process ID using tlist. To obtain tlist. Visual Studio attempts to attach the remote debugger to the instance of Azure App Service Windows that the profile is publishing to.

For more information, see Remote debug. Starting in Visual Studio , you can attach the Visual Studio debugger to a process running on a Docker container. For a Linux. When you choose this command, the debugger will immediately try to attach to the last processes you attached to by first attempting to match the previous process ID and if that fails, by matching to the previous process name.

If no matches are found, or if several processes have the same name, the Attach to Process dialog box will open so you can select the correct process. To help you determine whether to use Attach to Process and what process to attach to, the following table shows a few common debugging scenarios, with links to more instructions where available.

The list is not exhaustive. For client-side script debugging, script debugging must be enabled in the browser. Visual Studio will follow the same process to try to obtain symbols as it does when debugging a normal project. More information and best practices for symbols can be found in this blog. That behavior can be overridden from the Breakpoint Settings peek window. In the settings peek window click on the Must match source link text and then check the box to allow mismatched source, as illustrated below.

This is a really good reason to use SourceLink with your projects. Even if you have a local enlistment you might not have the same version that was used to build the binary.