Sandeep Mewara">
Click here to Skip to main content
15,395,877 members
Articles / Unmanaged
Technical Blog
Posted 4 Sep 2020



“vshost32.exe has stopped working”

Rate me:
Please Sign up or sign in to vote.
5.00/5 (5 votes)
4 Sep 2020CPOL4 min read
This is another one of the common errors developers get and ask about: vshost32.exe has stopped working.
This is to assess the problem, understand the things behind and the possible reasons and resolutions to solve it.

Problem Statement

When I run my project (or a particular usecase), it displays an error: vshost32.exe has stopped working.


vshost was introduced in Visual Studio 2005 (only for use in VS). These are files that contain vshost in the file name and are placed under the output (default bin) folder of the application. It is the “hosting process” created when we build a project in Visual Studio.

It has the following core responsibilities:

  • to provide support for improved F5 performance: To run a managed application in debug mode using F5 command, Visual Studio would need an AppDomain to provide a place for the runtime environment within which the application can run. It takes quite a bit of time to create an AppDomain and initialize the debugger along with it. The hosting process speeds up this process by doing all of this work in the background before we hit F5, and keeps the state around between multiple runs of the application.
  • for partial trust debugging: To simulate a partial trust environment within Visual Studio under the debugger would require special initialization of the AppDomain. This is handled by the hosting process.
  • for design time expression evaluation: To test code in the application from the immediate window, without actually having to run the application. The hosting process is used to execute code under design time expression evaluation.

More details can be read here.

With the above details, there could be issues while interacting with Operating System through this AppDomain and thus causing an error.

Possible Resolutions

Generally, it would be to figure out if the issue is specifically because of Visual Studio hosting process or there are other issues at play interacting with vshost.

Scenario 1

It’s 64 bit OS, app is configured to build as AnyCPU, yet we get an error.


32 bit/64 bit issues usually play a role in relation to OS features and locations that are different. There is a setting in Build configuration that drives the debugger behavior when it is setup for AnyCPU. You need to turn off (un-tick checkbox) the Prefer 32 bit flag to run in 64 bit mode.

Now, even with the above change, we can face issues that fall into 32/64 bit region. This is where vshost is still playing a role. Irrespective of the above, flag vshost continues to work in 32 bit mode (platform config AnyCPU). Now, calls to certain APIs can be affected when the hosting process is enabled. In these cases, it is necessary to disable the hosting process to return the correct results. Details about how to turn it off in Debug tab: How to: Disable the Hosting Process

With the above changes, AnyCPU configuration would be equivalent to the app as platform target x64 configuration.

Scenario 2

Application is configured to build as x86 (or AnyCPU).


If the workflow is related to a third party, for 32 bit applications, use 32 bit runtime, irrespective of the OS being 32 bit or 64 bit.

Scenario 3

Application is throwing an error for a specific code work flow that involves unmanaged assembly.


If the workflow includes an interop call to an external assembly (unmanaged code that is executed outside the control of CLR), there might be incorrect usage of the function all. I have seen examples where a wrong return type can cause a vshost error. Return type of the external DLL cannot be string, it must be IntPtr.

[DllImport("Some.dll", CallingConvention = CallingConvention.Cdecl)]
private static extern IntPtr SomeMethod();

Scenario 4

Application is throwing an error for a specific code work flow that is in the realms of managed code (by CLR).


It could be that the process is taking time while executing that particular workflow. If the process is busy for a long time, it can throw an error. One of the solutions would be to try the entire long operation on a BackgroundWorker thread and free up UI thread.


We can turn off the vshost as long as we are okay without it. It always helps to have the same debugging environment (32/64 bit) as the app is expected to run in. We should be cognizant of the operations done with third party assemblies or unmanaged ones and have the right set of code/files interacting with application.

Happy troubleshooting!



This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


About the Author

Sandeep Mewara
Software Developer (Senior) Intuit India
India India

Comments and Discussions

GeneralMy vote of 5 Pin
Aijaz M Hassan7-Sep-20 19:42
MemberAijaz M Hassan7-Sep-20 19:42 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.