• The dark side of the Hosting Process (vshost.exe)

    by  • September 4, 2012 • .Net, Programming • 2 Comments

    By default Visual Studio wraps managed projects around a Hosting Process to improve the performance when debugging and to enable a subset of features that would not be possible via direct debugging. However just like most things, there are trade-offs to be had, and can introduce new bugs into your application.

    The end goal of a debugger is meant to be as non-intrusive as possible, to get in and out quickly and to create as little overhead as possible to the running application that you are trying to debug.

    The major overhead when repeatedly debugging managed applications from Visual Studio (depending of course on the size of the project) is the creation of an application domain and association of the debugger with the application.

    These tasks can introduce a noticeable delay between the time debugging is started and the time the application begins running. The hosting process helps increase performance by creating the application domain and associating the debugger in the background, and saving the application domain and debugger state between runs of the application.

    Where MSDN becomes a bit vague is where API’s and functionality is affected by this hosting and caching mechanism. Currently MSDN only gives a tidbit in the form of AppDomain changes – Which seems obvious as the whole point of vshost is to cache and manage the debuggers Application Domain.

    AppDomain.CurrentDomain.FriendlyName Differences:

    If you callAppDomain.CurrentDomain.FriendlyName with the hosting process enabled, it returns app_name.vhost.exe. If you call it the hosting process disabled, it returns app_name.exe.

    Assembly.GetCallingAssembly().FullName Differences:

    If you callAssembly.GetCallingAssembly().FullName with the hosting process enabled, it returns mscorlib. If you callAssembly.GetCallingAssembly().FullName with the hosting process disabled, it returns the application name.

    As MSDN is vague about what vshost affects, it took some hunting before I have found a few other issues which didn’t seem obviously connected to vshost at the time.

    • TopMost flag and ‘Always on top’ pinvoke calls can be hit and miss when enabled.
    • Taskbar icon is not show for forms created within an ApplicationContext
    • Reflecting on the Calling Assembly
    It is advised to run a build in retail mode, or to try debugging with the hosting process disabled, thus having a more realistic although slower debugging experience.

    To disable the hosting process

    1. Open a project in Visual Studio.
    2. On the Project menu, click Properties.
    3. Click the Debug tab.
    4. Clear the Enable the Visual Studio hosting process check box.

    In general, when the hosting process is disabled:

    • The time needed to begin debugging .NET Framework applications increases.
    • Design-time expression evaluation is unavailable.
    • Partial trust debugging is unavailable.


    Software engineer. Tea drinker


    2 Responses to The dark side of the Hosting Process (vshost.exe)

    1. dave
      May 1, 2017 at 4:56 pm

      thank you! thank you!thank you!thank you!thank you!thank you!thank you!thank you!thank you!

    2. george
      June 19, 2017 at 9:41 am

      what if a program runs WITH hosting enabled, but fails otherwise?

    Leave a Reply

    Your email address will not be published. Required fields are marked *