{"id":226395,"date":"2019-09-18T08:00:39","date_gmt":"2019-09-18T15:00:39","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/visualstudio\/?p=226395"},"modified":"2019-09-25T13:48:56","modified_gmt":"2019-09-25T20:48:56","slug":"how-to-debug-and-profile-any-exe-with-visual-studio","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/visualstudio\/how-to-debug-and-profile-any-exe-with-visual-studio\/","title":{"rendered":"How to debug and profile any EXE with Visual Studio"},"content":{"rendered":"

Have you ever needed to debug or profile an executable (.exe file) that you can\u2019t build locally? Then the least known Visual Studio project type, the EXE project, is for you!<\/p>\n

In Visual Studio you can open any EXE as a \u2018project\u2019. Just go to File->Open->Project\/Solution<\/em> and browse to the .exe<\/em> file. Like you would if it was a .sln <\/em>file. Visual Studio will then open that EXE as a project. This feature has been around for a long time. It works on all currently supported Visual Studio versions and the docs for it are at\u00a0 ‘Debug an app that isn’t part of a Visual Studio solution<\/a>‘.<\/p>\n

.\"Opening<\/p>\n

Debugging<\/h3>\n

Just as with a normal project you can start debugging with F5, which will launch the EXE and attach the debugger. 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. Both of these options are available on the context menu for the EXE project in Solution Explorer <\/em>window as illustrated below:<\/p>\n

\"Starting<\/p>\n

For debugging will need to have symbols (PDB files) for the EXE and any DLLs you need to debug. Visual Studio will follow the same process to try to obtain symbols as it does when debugging a normal project. Since it\u2019s 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. More information and best practices for symbols can be found in this blog<\/a>.<\/p>\n

To effectively debug you\u2019ll also need the source code that was used to build the EXE, even for just a few files that you care about. You\u2019ll need to locate those files and open them in Visual Studio. If the source code isn\u2019t 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\u2019t bind. That behavior can be overridden from the Breakpoint Settings<\/em> peek window. In the settings peek window click on the Must match source <\/em>link text and then check the box to allow mismatched source, as illustrated below. Of course, with mismatched source you never really know what\u2019s going to happen, so use at your peril.<\/p>\n

\"Setting<\/p>\n

If the EXE was built with SourceLink<\/a> enabled then information about the source will be included in the PDBs and Visual Studio will try to download the source automatically. 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. SourceLink is your sure-fire way to make sure that the right source is linked with the right binary.<\/p>\n

If you can\u2019t obtain any source code you still have a couple of options:<\/p>\n

    \n
  1. Use a tool to decompile the assemblies back into C#, which you can then recompile into a new assemble to patch the old one.\n
      \n
    1. ILSpy<\/a> is a great choice for this, but there\u2019s plenty of other good paid and free tools out there.<\/li>\n
    2. [Note: Several comments have also pointed out dnSpy https:\/\/github.com\/0xd4d\/dnSpy<\/a> as a great solution for this – thanks!]<\/li>\n<\/ol>\n<\/li>\n
    3. Use the Disassembly tool window in Visual Studio.\n
        \n
      1. The Source Not Found<\/em> document has a link to view disassembly<\/em>. Be warned, if you\u2019re used to debugging C# code the disassembly view is a tool of last resort.<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n

        Lastly, if you need to pass in any arguments to the EXE that\u2019s being debugged you can configure them along with other options in the Project Properties<\/em> page (Right Click->Properties<\/em> on the project node in solution explorer).<\/p>\n

        \"Project<\/p>\n

        Profiling<\/h3>\n

        You can also use the profiling tools with the EXE by launching them from the Debug -> Performance Profiling<\/em>. From the launch page of the profiling tools you can select what tools to use against the EXE. More information on profiling can be found in the docs over at :https:\/\/docs.microsoft.com\/en-us\/visualstudio\/profiling\/profiling-feature-tour?view=vs-2019<\/a>.<\/p>\n

        \"Launching<\/p>\n

        Conclusion<\/h3>\n

        That\u2019s it. A brief overview of how you can use Visual Studio to debug and profile applications that you aren\u2019t building and might not even have source for. So, next time you need to debug or profile an EXE don\u2019t forget you can open it as a Solution in Visual Studio!<\/p>\n

         <\/p>\n

         <\/p>\n","protected":false},"excerpt":{"rendered":"

        Have you ever needed to debug or profile an executable (.exe file) that you don\u2019t have source for or can\u2019t build? Then the least known Visual Studio project type, the EXE project, is for you!<\/p>\n","protected":false},"author":7412,"featured_media":255385,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[155],"tags":[9,4562,12],"class_list":["post-226395","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-visual-studio","tag-debug","tag-profile","tag-visual-studio"],"acf":[],"blog_post_summary":"

        Have you ever needed to debug or profile an executable (.exe file) that you don\u2019t have source for or can\u2019t build? Then the least known Visual Studio project type, the EXE project, is for you!<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/visualstudio\/wp-json\/wp\/v2\/posts\/226395","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/visualstudio\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/visualstudio\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/visualstudio\/wp-json\/wp\/v2\/users\/7412"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/visualstudio\/wp-json\/wp\/v2\/comments?post=226395"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/visualstudio\/wp-json\/wp\/v2\/posts\/226395\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/visualstudio\/wp-json\/wp\/v2\/media\/255385"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/visualstudio\/wp-json\/wp\/v2\/media?parent=226395"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/visualstudio\/wp-json\/wp\/v2\/categories?post=226395"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/visualstudio\/wp-json\/wp\/v2\/tags?post=226395"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}