Visual Studio debug error about MSVSMON.EXE not appear to be running

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.

score 38 · Accepted Answer · answered Oct 27 '13 at 07:02

38

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.

answered Oct 27 '13 at 07:02

mehrandvd

8,806
12
64
111

5

Thanks Dude. It worked flawlessly. Although it must be noted that, you need to restart the Visual Studio after closing the Proxifier else it would keep giving the same error! – Pranav Jituri Aug 11 '14 at 04:44
5

Could you be a little more specific about it(`Proxifier`)? And what does it has to do with my `VS 2015 Community`? Last I checked there was no problem like this. Now when I start my system, I keep getting this error. I am trying to use `Local IIS`. – phougatv Oct 22 '16 at 13:57
@barnes: did you find the solution? – Jitendra Pancholi Aug 19 '18 at 12:10
I likewise turned off my Cisco VPN connection and could successfully run. – alperc May 08 '19 at 09:41

score 27 · Answer 2 · answered Dec 18 '13 at 10:42

27

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.

answered Dec 18 '13 at 10:42

Wayne Feltham

541
4
14

Also if you are using a local VM and have hosts entries and for some reason your IP address has changed as DNS updates, this may be your answer. – Damen TheSifter Mar 25 '14 at 02:29
Thanks. Since I always forget to switch my hosts entry, I've started doing this a little differently. I'll add a hosts entry for local.mydomainname.com to 127.0.0.1 and point VS and my local IIS to that. Then I can still browse to www.mydomainname.com and get the live site for comparison. – solublefish Oct 03 '16 at 22:50
My host was set to static ip before, but I recently took home my workstation and now using vpn. Once I updated my host to new ip, issue was resolved. I'm probably going to have to update it everyday because of dhcp? – Gregory Bologna Nov 05 '20 at 21:08

score 10 · Answer 3 · answered May 07 '15 at 13:57

10

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

IPV6 Visual-Studio Debug Fix

answered May 07 '15 at 13:57

Johan

177
2
6

1

thanks, worked for me. note: Visual Studio needs to be restarted after setting this rule. – Saleh Jan 06 '16 at 05:11

score 6 · Answer 4 · answered Sep 03 '14 at 05:10

6

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

answered Sep 03 '14 at 05:10

Ae Ratchapol

61
1
1

Been up and down googlesphere for days and a 4 year old tip comes to the rescue. Missed the time when a real man remembers all his answers ... ^_^ – Whoever Mar 22 '18 at 16:04

score 5 · Answer 5 · answered Oct 13 '13 at 18:13

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.

answered Oct 13 '13 at 18:13

Aster Veigas

866
3
13
34

2

Tee kind of things that may sound stupid in are often the best solutions. Restarting VS solved my problem. Thanks! – Jean-François Oct 20 '15 at 22:00

score 4 · Answer 6 · answered May 28 '14 at 15:28

4

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:

enter image description here

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

answered May 28 '14 at 15:28

RayLoveless

19,880
21
76
94

@SenjutiMahapatra, Glad I could help :) – RayLoveless Jul 14 '17 at 19:29

Rahul Tripathi · Answer 7 · 2013-10-13T18:06:55.943

3

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

enter image description here

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.

edited Oct 13 '13 at 18:06

answered Oct 13 '13 at 17:52

Rahul Tripathi

168,305
31
280
331

4

I cant find such menu on the toolbar!? Where is it exactly? – mehrandvd Oct 13 '13 at 18:34
@mehrandvd:- ***If you can't see the Standard toolbar, click the View menu, point to Toolbars, and then click Standard.*** Does this help:- http://msdn.microsoft.com/en-us/library/windows/apps/hh441483(v=vs.120).aspx ? – Rahul Tripathi Oct 13 '13 at 18:35
I mean my menu has just one option named 'Start' there's no other options listed above. – mehrandvd Oct 13 '13 at 18:45
What are the options available on the start menu? You must have administrator privileges! – Rahul Tripathi Oct 13 '13 at 18:52
1

There's no options available there. Maybe these options are for Wpf applications or applications other than WinForm... – mehrandvd Oct 13 '13 at 21:19
There is nothing like `Local Machine` in VS 2015 Community, even after following your comment. Could you please be more specific. – phougatv Oct 22 '16 at 13:49

score 3 · Answer 8 · answered Aug 22 '15 at 07:46

3

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'.

answered Aug 22 '15 at 07:46

AndresRohrAtlasInformatik

508
4
7

Found helpful on my windows 7 64 bit, VS2013 – Nitin Daware May 15 '16 at 05:13

score 3 · Answer 9 · answered Aug 28 '15 at 09:29

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

score 2 · Answer 10 · edited Mar 16 '18 at 15:15

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 *****. enter image description here

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.

enter image description here

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

score 1 · Answer 11 · answered Jan 17 '16 at 20:53

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!

score 1 · Answer 12 · edited May 23 '17 at 11:55

1

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

edited May 23 '17 at 11:55

Community

1
1

answered Mar 02 '16 at 05:14

Jose A

10,053
11
75
108

score 1 · Answer 13 · edited Mar 07 '16 at 07:26

1

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.

edited Mar 07 '16 at 07:26

answered Mar 07 '16 at 06:22

Saatvik Aggarwal

11
1

score 1 · Answer 14 · answered Mar 14 '17 at 17:35

1

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.

answered Mar 14 '17 at 17:35

Sagar

579
5
7

score 1 · Answer 15 · answered Apr 24 '17 at 19:09

1

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

answered Apr 24 '17 at 19:09

Subhash Makkena

1,909
2
13
15

score 1 · Answer 16 · answered May 26 '17 at 08:40

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.

Marc Wittmann · Answer 17 · 2015-05-04T13:51:26.347

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.

score 0 · Answer 18 · answered May 15 '16 at 10:13

0

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.

answered May 15 '16 at 10:13

James Wright

3,000
1
18
27

score 0 · Answer 19 · answered Aug 05 '16 at 19:04

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.

score 0 · Answer 20 · answered Apr 11 '17 at 13:19

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

score 0 · Answer 21 · answered Oct 30 '17 at 09:30

0

My issue solved when i add devenv.exe to firewall exclusions

answered Oct 30 '17 at 09:30

Anto Varghese

3,131
6
31
38

Bemipefe · Answer 22 · 2021-10-15T08:50:21.940

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):

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.
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).
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).

Visual Studio debug error about MSVSMON.EXE not appear to be running

22 Answers22

Linked