关于 MSVSMON.EXE 的 Visual Studio 调试错误似乎没有运行

Question

I have a program which when I hit F5 to run the program it shows this error and doesn't run:

Error while trying to run the project, Unable to start program 'F:....` The Microsoft Visual Studio Remote Debugging Monitor (MSVSMON.EXE) does not apear to be running on the remote computer ...

This is while the project was compiling successfully before. Is there any project setting that should be set in a wrong way sometime!?

I'm using Visual Studio 2012 Update 2.

Answer 1

I've discovered that the reason is not about downgrading! It's about a tunneling software called "Proxifier". While it's running on the system, it causes the Visual Studio this problem.

Answer 2

I've had this happen when I have an entry in my HOSTS file to run the site locally but I've then commented it out to enable me to view live.

For example - the live site runs on http://my.url.com

In VS in the Properties for the web project on the Web tab, I have the project URL set to the above. When I want to debug locally, I put the following in my HOSTS file

127.0.0.1    my.url.com

When I'm done and I want to revert to live I comment this out

#127.0.0.1    my.url.com

If in the future I need to debugt again, VS attempts to debug against the live server rather the request being routed back to localhost via the HOSTS entry.

Answer 3

I you are running Proxifier add a rule to route ::1 (IPV6 Loop-back) Direct and not via the proxy.

Answer 4

IIS >> Application Pool >> choose pool >> advance setting >> Enable 32-bit Applications=true. It's worked for me.

Answer 5

You must have killed the msvmon process by mistake. I know it sounds stupid but try restart VS and if that doesn't work then try a machine reboot. But I noticed that when we run VS, the msvmon process will be running in the background.

Answer 6

Here's a couple things to try:

For me my Project URL( in project properties ) was over ridden with a setting from another team member for some reason. I simply needed to set it back to me:

also you could try setting your server to use IIS Express if you're not already running that.

Answer 7

Try to select 'Local Machine' , when you run the application. It looks like Remote Machine is selected for debugging.

Also check the details of this error on MSDN

When you try to do remote debugging, you might receive this error message. It means that Visual Studio could not find an instance of the Visual Studio Remote Debugging Monitor on the remote computer. The Visual Studio Remote Debugging Monitor is required for remote debugging to work.

Answer 8

I have this regularly on VS 2013 and Windows 8.1 on a 64 bit PC. It disappears if you go to the start project, open the project properties, go to the 'Build' tab and change the 'Platform target' from 'Any CPU' to 'x86'.

Answer 9

I had this issue as well.

The solution was to correct the entry for my computers hostname in my hosts file to the correct IP.

The story behind: I originally put the entry in the hosts file because VS was taking around 1 minute (yes 60 seconds) to enter debug mode. I discovered that putting an entry in my hostes file containing my PC's IP and its host name caused VS to enter debug mode in 1-2 seconds!!

Might also be worth mentioning that I, in property pages -> start options have configures VS to "Don't open a page. Wait..." and "User custom server" and set "Base URL" to the website on my local IIS

Answer 10

Try this:

Step 1-> go to Program Files (x86)\\Microsoft Visual Studio 14.0\\Common7\\IDE\\Remote Debugger\\x64 and run msvsmon.exe as administrator.Then you will get a window stating Msvsmon started a new server named *****.

Step 2-> Click on attach process and Enter the same server name that you get in the Remote debugger window in the Qualifier column of visual studio and click on refresh.

step 3-> Now attach your process from the list.It will work.

Note: The Qualifier Value in VS and Server name in Remote debugger must match

If It doesn't work then stop your Remote debugger process in background and follow these steps freshly

Answer 11

I just had this problem after rebooting my router.

It turns out that the reboot assigned my devices IP addresses again, but in a different order. For example, in my Hosts file, I had my IP down as 192.168.0.3, but when I checked it again with ipconfig in command prompt, the IP address was 192.168.0.4.

So if you run into this issue, check that the IP address in your Hosts file matches your current IP address as it may have changed!

Answer 12

If you came here because of an Azure problem, then check this out:

Try attaching manually the debugger:

I have outlined the steps in the following answer:

https://stackoverflow.com/a/35738995/1057052

Answer 13

If it's a Web Application, Simply just go to your Application Pool which your project is using, Right-Click, Advanced Settings , Enable 32-Bit Application = true .

It should work.

Answer 14

This worked for me:

1) Do not change anything on your machine and try step # 2 before repairing your Visual Studio.

2) Launch Visual Studio as a ADMINISTRATOR. Then open your Solution and try to debug.

Answer 15

You can just go to debug settings, check the box in the debugging tab

"use remote machine"

and type in some name (doesn`t matter if the machine exists)

Save settings, run with configuration and after an error simply uncheck "use remote machine" again.

Visual Studio will set the debugging to local debugging again and that should fix the issue. I think this is better than shutting down programs or altering settings that are not the root cause.

Answer 16

I had this problem when attempting to deploy a JavaScript UWP app to Xbox One, due to the target architecture that I had selected (x64). Changing this to Any CPU allows me to deploy to the console.

Answer 17

I had this happen to me today in a C# project when I added a linkLabel to the form to access a web page.

I found the cause was an entry in my hosts file for a ethernet tap interface (tinc vpn). I had an entry in there for an alias of my own machine on the tap IP address. Commenting it out allowed the debugger to run with no issues.

Many thanks for the hint above about the hosts file; it lead me in the right direction! Hope this may help someone else.

Answer 18

I also had the same problem..I had this problem while I was using Visual Studio 2012 Update 5.

The following link gives more better explaination on different scenarios in which this error might occur. https://msdn.microsoft.com/en-us/library/ms164726.aspx

Link says that Visual Studio is a 32-bit application, so it uses the 64-bit version of the remote debugger to debug 64-bit applications. The two processes communicate using the local network within the local computer. No traffic leaves the computer, but it is possible that third party security software may block the communication.

So what I did is I opened Firewall settings.

Control Panel-->System and Security-->Windows Firewall-->Allowed apps to communicate through windows firewall

And added MSVSMON.exe to the allowed apps list.This worked for me.

Note: You can find MSVSMON.exe file on following location:

C:\\Program Files (x86)\\Microsoft Visual Studio 11.0\\Common7\\IDE\\Remote Debugger\\x64

Answer 19

Do this for your debug configuration. But uncheck in Release configuration.

Answer 20

This occurs when you try to run your project on IIS instead of IIS express and your Visual Studio is unable to connect to the Website on IIS.

If your website is not binded to localhost and you have given a domain name binding, you need to make sure your host file (Run->drivers->etc->hosts) has an entry pointing to that domain name.

Answer 21

当我将devenv.exe添加到防火墙排除项时，我的问题已解决

Answer 22

The root cause of the problem is not always the same so this is a useful check list to perform (I'm assuming that in the project settings Configuration Properties -> Debugging -> Debugger to launch: is set to Remote Windows Debugger ):

1. VS is running as Administrator privileges
   
   In this case Windows defender may prevent the devenv.exe process to initiate communication towards an IP different than 127.0.0.1. If you can't run VS as normal user try this command in a Powershell prompt (Run it as Administrator):
   
   set-mppreference -EnableNetworkProtection 0 .
   
   

2. The VS computer can't resolve the hostname specified in the Remote Debugging settings
   
   In the project settings Configuration Properties -> Debugging -> Remote Server Name replace the hostname with its IP address (and the related port if the msvsmon.exe process is listening on a port different than the default. See here what is the default port for your VS version).

3. The VS computer can't connect to the computer which is running the Remote Debugger
   
   The remote debugger requires at least these ports 4020 , 4021 , 135 and 445 . As if things aren't complicated enough the default port is not always 4020 but change for each VisualStudio version (for example it's 4024 in VS2019). Take a look here . The simplest and most effective way to check if the ports are opened and the communication between the two ends are working correctly is to install nmap on both computers. Note that the nc command in cygwin is not the same implementation of NetCat and is not useful for our tests. Run this command on the computer which needs to run the Remote Debugger (don't run msvsmon.exe during the test) :
   
   ncat -v -l <host_ip> <port>
   
   and then run this command on the computer which is running VisualStudio:
   
   ncat -v <host_ip> <port>
   
   Note that host_ip is the ip of the computer which is running the Remote Debugger. If the connection is received on that host then no firewall is blocking the communication. In that case you should see something like this in the remote host: Ncat: Connection from xxx . You can repeat the test for the port 4020 and 4021 . Note that the port 4020 can be changed in the Remote Debugger interface and as already said the default port is not always 4020 but change for each VisualStudio version.
   
   You probably need also other ports to authenticate (if authentication is enabled on the Remote Debugger) and to deploy files on the remote computer. You can run the same command
   ncat -v <host_ip> <port> on the computer which is running VisualStudio. and check the following ports: 135 and 445 . Note that in this case you don't need to run nmap on the remote host (the services are already listening on that ports).