none
Visual Studio 2015 Remote Debugger (MSVSMON.EXE) not running RRS feed

  • Question

  • I have recently started getting this error on my Windows 7 Home Premium 64-bit machine:

    Error while trying to run project: Unable to start program <path>.The Visual Studio 2015 Remote Debugger (MSVSMON.EXE) does not appear to be running on the remote computer. This may be because a firewall is preventing communication to the remote computer. Please see Help for assistance on configuring remote debugging.

    I am not using remote debugging, everything is on a single Windows 7 machine.

    The error occurs as soon as I try to run the program in debug mode, immediately when the output window shows Build Successful. It occurs on a large Winforms/Entity Framework/SQL Server solution that I have been developing for several years and have migrated to VS2015; and also on a much smaller Winforms application which I have not changed recently and is still on VS2013.

    I have tried the following:

    There are no error messages in Event Viewer at the time of the failure.

    I can find no log messages in appdata\local\temp,  appdata\local\microsoft or appdata\roaming\microsoft at the time of the failure.

    Clean solution, including manually emptying the bin\debug folder makes no difference.

    Fiddling with the build configuration makes no difference. I usually use Any CPU.

    I tried following the advice at https://msdn.microsoft.com/query/dev14.query?appId=Dev14IDEF1&l=EN-US&k=k%28vs.debug.error.remote_debug%29;k%28TargetFrameworkMoniker-.NETFramework and

    https://msdn.microsoft.com/en-us/library/y7f5zaaa.aspx with no progress. MSVSMON.EXE was started manually from C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Remote Debugger\x64 and reported “Waiting for new connections”, but that made no difference to VS. There were no messages in the firewall log, or elsewhere.

    The computer was disconnected from the internet and rebooted without ZoneAlarm firewall, but that made no difference (I suspected the firewall because a ZoneAlarm update has recently been applied).

    I also get the "A 64 bit debugging process is taking longer than expected" at startup and regularly throughout work, but I can’t do any work now.


    Peter

    Tuesday, December 8, 2015 5:19 PM

Answers

  • Well, that did not last long! As soon as I'd posted that it was working, it failed again. I had all sorts of errors, including

    Cannot find wrapper assembly for type library "VBIDE".

    There was a mismatch between the processor architecture of the project being built "MSIL" and the processor architecture of the reference "<NAME>.dll", "x86".

    (When everything was x86)

    as well as the two 64-bit errors that started the problem (Yes, 64-bit errors on an x86 build!).

    I've finally solved the problem. Known issues in VS if Internet Explorer is not installed says that IE 10 or 11 is required.The symptoms described are different to mine.

    I had removed IE because I don't use it. Visual Studio is now behaving after installed Internet Explorer.


    Peter

    • Marked as answer by PeterBill Monday, December 21, 2015 9:25 AM
    Monday, December 21, 2015 9:24 AM

All replies

  • Hi Peter,

    Which kind of app did you really debugging?

    Like the following screen shot, please make sure that you use local debugger target, for example, it has these options for VC++ Debugging.

    For C# apps, in your project property, please also check that whether it has the "Enable Visual Studio Hosting process" option, please disable it, and then debug it again.

    In addition, you'd better to close all third party tools in your window, and then run your VS in safe mode, debug it again, at least, we could know that whether it is related to other third party tools or add-ins.

    https://msdn.microsoft.com/en-us/library/ms241278.aspx?f=255&MSPPError=-2147217396

    Best Regards,

    Jack


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.


    Friday, December 11, 2015 3:10 AM
    Moderator
  • Jack-Zhai

    Thank you for your reply.

    I am using C#. There are no third-party tools installed, only those that were installed with VS.

    I have tried selecting and unselecting the hosting process several times and nothing made any difference.

    I even tried this:

    1. Developer Command Prompt for VS2015 -> devenv /SafeMode

    2. Unselect  Save the solution and exit VS.

    3. Repeat step 1

    4. F5 to debug. The error still occurred.

    5. Select Enable the VS hosting process in Properties -> Debug of the startup project only.

    6. F5 to debug. The error still occurred.

    I have also tried changing Enable the VS hosting process for all 5 projects in the solution, but even that did not stop the error.


    Peter


    • Edited by PeterBill Friday, December 11, 2015 7:25 PM
    Friday, December 11, 2015 12:04 PM
  • Hi Peter,

    If jus the specific apps have this issue, could you share me a simple sample using one drive? So I could really debug it in my side.

    Please also debug the same app in other VS machine, check the result.

    Please reset your VS settings:

    Devenv.exe /ResetSettings: Restores the IDE's default settings, optionally resets to the specified VSSettings file.

    And then debug it again.

    Please connect to your network, and then run the windows update, please also install the update package under tools->Extensions and updates, maybe there are some updates.

    For example, please install the VS2015 update 1.

    >>A 64 bit debugging process is taking longer than expected.

    I met this issue which was related to the network here:

    http://blogs.msdn.com/b/dsvc/archive/2013/12/31/visual-studio-debugging-issue.aspx

    Best Regards,

    Jack


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Monday, December 14, 2015 11:19 AM
    Moderator
  • Jack

    Thanks for your ideas, but nothing works.

    Here are 2 simple examples. The first works if compiled as Release, or as Debug x32 or Any CPU, but fails consistently when set to Debug x64. I have tried in both VS 2013 and VS 2015, even after the rest of your suggestions.

    using System;
    using System.Collections.Generic;
    using System.Diagnostics;
    using System.Linq;
    using System.Text;
    using System.Threading.Tasks;

    namespace FactorLargeNumber
    {
        class Program
        {
            static void Main(string[] args)
            {
                Stopwatch watch = new Stopwatch();
                TimeSpan ts = new TimeSpan();

                watch.Start();
                Factorer f = new Factorer(32193383016914291);
                f.FindFactors();
                watch.Stop();

                ts = watch.Elapsed;
                Console.WriteLine(
                "{0:00}:{1:00}:{2:00}.{3:000} ticks {4}",
                        ts.Hours, ts.Minutes, ts.Seconds,
                        ts.Milliseconds, ts.Ticks);
                Console.ReadLine();
            }
        }
    }


    // Try to find factors of a large number
    {
        public class Factorer
        {
            long largeNumber;
            public Factorer(long number)
            {
                largeNumber = number;
            }

            public void FindFactors()
            {
                long limit = (long)Math.Sqrt((double)largeNumber);
                long factor;
                for (long i = 2; i <= limit; i++)
                {
                    factor = largeNumber / i;
                    if (i * factor == largeNumber)
                    {
                        Console.WriteLine("Found factors {0} & {1}", i, factor);
                        break;
                    }
                }
            }
        }
    }

    The second example, which uses SQL Server, fails even when compiled as Debug x32, but works in Release mode.

    using System;
    using System.Data.SqlClient;

    namespace TestSqlServer
    {
        class Program
        {
            static void Main(string[] args)
            {
                string connectionString = @"Data Source=<DB Server>;Initial Catalog=master;Integrated Security=SSPI;"; // Add valid connection string
                ReadData(connectionString);
                Console.ReadLine();
            }

            private static void ReadData(string connectionString)
            {
                string queryString = "SELECT name, object_id FROM sys.all_objects;"; // Ensure SQL is valid for your database
                using (SqlConnection connection = new SqlConnection(connectionString))
                {
                    SqlCommand command = new SqlCommand(queryString, connection);
                    connection.Open();
                    SqlDataReader reader = command.ExecuteReader();
                    try
                    {
                        while (reader.Read())
                        {
                            Console.WriteLine(String.Format("{0},\t{1}",
                                reader[0], reader[1]));
                        }
                    }
                    finally
                    {
                        reader.Close();
                    }
                }
            }
        }
    }

    devenv /ResetSettings did not help. I have Update 1 and Windows is fully patched.

    Looking at your network link, I disconnected my router from the internet, rebooted without firewall and antivirus, killed every process that looked network-related and tried again. It still failed.

    My second example leads me to suspect something in SQL Server. I am using 2014 Express Local DB. I changed the configuration options - it make no difference if I use shared memory, TCP/IP v6, TCP/IP v4 or named pipes for connection - everything fails.


    Peter

    Wednesday, December 16, 2015 9:49 PM
  • I have had this same problem for months now. Tried many suggested fixes but nothing resolves it.

    My workaround for this problem is to set the Project Properties Debug Platform Target to x86. That avoids invoking the x64 VS Remote Debugger which is where this problem resides (IMO).

    When it is time to build to release, I have the Project Properties Release Build Platform Target to CPUANY.

    Good luck.

    PS I installed VS2015 community Update 1, but it does not fix it.

    Edit:
    I should also mention that MSVSMON.EXE does indeed start when I open my solution in VS2015. But as soon as I click the Debug button to start debugging, MSVSMON mysteriously stops and unloads itself. You can confirm this by watching the Processes tab in Task Manager.

    • Edited by Telexer Thursday, December 17, 2015 12:44 PM
    • Marked as answer by PeterBill Saturday, December 19, 2015 3:43 PM
    • Unmarked as answer by PeterBill Monday, December 21, 2015 9:25 AM
    Thursday, December 17, 2015 12:34 PM
  • Thanks to Jack and Telexer for the suggestions.

    At last I've got debug working. I'm not sure exactly what fixed it, I've played around with so many bits, including a Repair installation. I've marked the x86 debug as answer, because that was the final step in my trials.


    Peter

    Saturday, December 19, 2015 3:43 PM
  • Well, that did not last long! As soon as I'd posted that it was working, it failed again. I had all sorts of errors, including

    Cannot find wrapper assembly for type library "VBIDE".

    There was a mismatch between the processor architecture of the project being built "MSIL" and the processor architecture of the reference "<NAME>.dll", "x86".

    (When everything was x86)

    as well as the two 64-bit errors that started the problem (Yes, 64-bit errors on an x86 build!).

    I've finally solved the problem. Known issues in VS if Internet Explorer is not installed says that IE 10 or 11 is required.The symptoms described are different to mine.

    I had removed IE because I don't use it. Visual Studio is now behaving after installed Internet Explorer.


    Peter

    • Marked as answer by PeterBill Monday, December 21, 2015 9:25 AM
    Monday, December 21, 2015 9:24 AM
  • @Peter,
    Glad you found a fix that works.

    BTW, re:
    "mismatch of architecture of the reference "<NAME>.dll", "x86"."

    That can be fixed by setting the Build Target Platform of the DLL project to CPUANY.

    Happy Holidays!
    Monday, December 21, 2015 10:33 AM