If the source code isn’t the exact same as the source code that was built the EXE Visual Studio will warn you when you try to insert a breakpoint and the breakpoint won’t bind. You’ll need to locate those files and open them in Visual Studio. To effectively debug you’ll also need the source code that was used to build the EXE, even for just a few files that you care about. More information and best practices for symbols can be found in this blog. Since it’s not likely that the PDB files were distributed alongside the EXE you might want to locate them from a build drop or, better yet, from a symbol server. Visual Studio will follow the same process to try to obtain symbols as it does when debugging a normal project. Both of these options are available on the context menu for the EXE project in Solution Explorer window as illustrated below:įor debugging will need to have symbols (PDB files) for the EXE and any DLLs you need to debug. If you want to debug startup you can launch with F11, which will launch the EXE and stop on the first line of user code. Just as with a normal project you can start debugging with F5, which will launch the EXE and attach the debugger. It works on all currently supported Visual Studio versions and the docs for it are at ‘ Debug an app that isn’t part of a Visual Studio solution‘. This feature has been around for a long time. Visual Studio will then open that EXE as a project. Just go to File->Open->Project/Solution and browse to the. In Visual Studio you can open any EXE as a ‘project’.

Have you ever needed to debug or profile an executable (.exe file) that you can’t build locally? Then the least known Visual Studio project type, the EXE project, is for you!

Pestudio exe