none
visual studio 2010 remote debugger settings don't persist

    Question

  • How do you get the noauth option to stick?
    Everytime I configure with the wizard (to run as a service) the settings don't get saved.
    ProcMon shows it trying to save things in RPC\SecurityService\DefaultAuthLevel, but it doesn't have access.
    Am I missing something?  or is the QA missing something?

    Thanks.
    Wednesday, May 16, 2012 12:53 PM

All replies

  • procmon shows the service trying to start it like this

    c:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\Remote Debugger\x86\msvsmon.exe /CHILDSERVER c4 bc c0 b0 ac "svc=msvsmon100@HP-9DLS5O6356S9" /silent+

    But the help for the debugger, doesn't say anything about /CHILDSERVER c4 bc c0 b0 ac "svc=msvsmon100@HP-9DLS5O6356S9"

    or silent+, but it does describe silent.

    WHY OH WHY Microsoft?

    Why put the help in an exe?

    Why not doc things the way you use them.

    If it wasn't for Mark Russinovich, I don't think anyone could use this crap.

    Help Topics:


    1. Server Names -- What is a
      server name?
    2. Security -- What is the
      difference between Windows Authentication and No Authentication?
    3. Setup -- How do I setup remote
      debugging?
    4. Remote Debugging Across User
      Accounts
      -- How do I debug to another user's computer?
    5. Service -- Should I run the remote
      debugger as a Service?
    6. Command Line -- What are the
      remote debugger command-line options? What do they do?
    7. User Interface -- What do
      user interface options do?




    Server Names

    Multiple users can run the remote debugger on the same computer. If two
    instances of the remote debugger are running on the same computer, how does
    Visual Studio decide which instance to connect to? Each instance of the remote
    debugger has a unique server name.

    Server names are configurable. You can give an instance of the remote
    debugger any server name. Usually, the default server name is satisfactory. The
    default server name depends upon what user started the remote debugger. If a
    user user_name from domain domain_name is logged into computer
    computer_name, then the default server name would be
    domain_name\user_name@computer_name.

    Connect to an instance of the remote debugger by entering the server name
    into the 'Attach To Process' dialog (Tools->Attach To Process or
    Debug->Attach To Process), or by entering the server name into the debugging
    properties for a project.

    Sometimes, Visual Studio can determine which instance of the remote debugger
    to connect to based only on a computer name. If domain_name\user_name
    runs Visual Studio, then domain_name\user_name can connect to the
    remote debugger by entering just computer_name. However, if a custom
    server name (example: custom_name@computer_name) is used, or if a
    different user wants to connect to domain_name\user_name's instance of
    the remote debugger, the complete server would be necessary.




    Security

    The remote debugger supports two authentication modes:


    1. Windows Authentication mode
    2. No Authentication mode

    Windows Authentication mode

    Windows Authentication mode uses Windows's built-in security to provide a
    high level of security. Kerberos and/or NTLM authenticate all requests. RPC
    packet privacy is used to encrypt data traveling over the network.


    No Authentication mode

    No Authentication mode has no security. Visual Studio sends the current
    username to the remote debugger, but this information is not verified. No
    Authentication mode should never be used on a network that may have hostile
    traffic. No Authentication mode should never be used to remote debug across the
    Internet. No Authentication mode supports native debugging only.




    Setup

    There are several different ways to setup remote debugging.


    Running the remote debugger off a file share

    The easiest way to setup remote debugging is to run the remote debugger
    (msvsmon.exe) from a file share. Visual Studio installs msvsmon.exe into these
    directories:

     Program Files\Microsoft Visual Studio 9.0\Common7\IDE\Remote Debugger\x86
     Program Files\Microsoft Visual Studio 9.0\Common7\IDE\Remote Debugger\x64
     Program Files\Microsoft Visual Studio 9.0\Common7\IDE\Remote Debugger\ia64
        

    By sharing out the 'Remote Debugger' directory on the Visual Studio computer,
    you can run msvsmon.exe on the remote computer.

    Features that will not work if msvsmon.exe is run from a share:


    • Stepping into a web service. However, it is still possible to manually
      attach.
    • Automatically launching an ASP.NET site under the debugger. Manually
      attaching is still possible.

    Running remote debugger setup on the remote computer


    1. Insert Visual Studio DVD into the remote computer.
    2. Navigate to the 'vs\Remote Debugger' folder on the DVD.
    3. Under the 'vs\Remote Debugger' folder, there is a setup program for every
      processor architecture, i.e. rdbgsetup_x86, rdbgsetup_x64, and rdbgsetup_ia64
      (supported SKUs only). Select the setup program that matches the processor of
      your computer.
    4. Start the setup program, and follow the instructions to complete setup.




    Remote Debugging Across User
    Accounts


    Background

    Remote debugging to a different user's computer is not as simple as remote
    debugging between two machines with the same user logged in.

    There are two primary issues:


    1. Permissions -- by default, only an administrator or the user running the
      remote debugger can connect to the remote debugger.
    2. Specifying the server name --
      Visual Studio needs to know which instance of the remote debugger you want to
      connect to. If the same user is running the remote debugger and Visual Studio,
      Visual Studio can find the remote debugger with only the remote computer name.
      However, if a different user is running the remote debugger, then Visual Studio
      must be told to connect to domain_name\user_name@remote_machine, not
      just remote_machine.

    Walkthrough

    Scenario: Alice and Bob are both connected to SomeDomain. Bob is having
    trouble with some software that Alice wrote. Alice wants debug the software on
    Bob's computer.


    1. Bob does not have the remote debugger on his computer. To setup the remote
      debugger, Alices share out the 'Program Files\Microsoft Visual Studio
      9.0\Common7\IDE\Remote Debugger' directory on her computer. She creates a file
      share called 'Remote'.
    2. Bob runs \\AliceComputer\Remote\x86\Msvsmon.exe
    3. After the remote debugger (Msvsmon.exe) starts up, Bob configures the remote
      debugger through the Tools->Permissions dialog. He gives Alice permission to
      debug. Alternatively, Bob could configure the remote debugger by passing the
      '/allow' option at startup.
    4. Alice starts Visual Studio
    5. In the Tools menu, Alice clicks Attach to Process
    6. Alice asks Bob to read her the server name shown in the Remote Debugging
      Monitor as the server name. It is SomeDomain\Bob@BobComputer.
    7. Alice connects to Bob's computer by entering SomeDomain\Bob@BobComputer into
      the name edit box.
    8. Alice selects the application, and starts debugging




    Service

    You can run the remote debugger as either a Windows service or a Windows
    application. Running the remote debugger as a service allows you to easily debug
    server applications such as ASP.NET without logging onto the remote
    computer.

    Running the remote debugger as a service causes it to always run and listen
    on the network. It is not recommended to run the remote debugger as a service
    for debugging client applications.

    With the Visual Studio 2010 Remote Debug Configuration wizard, you can
    control the username and password that the remote debugger service runs under.
    When the remote debugger is running as a service, the following requirements
    must be met to debug remotely:


    1. The user must be a member of the Administrators group to allow debugging of
      any process.
    2. The user must have network permissions so that the remote debugger can
      communicate with Visual Studio.
    3. The user must be granted the 'Log on as a service' privilege. This can be
      done with the 'Local Security Policy' administrative tool.

    The default user for the remote debugger service is 'LocalSystem.' The
    LocalSystem account is recommended when both the remote computer is connected to
    a domain and Visual Studio is run by a domain user. This is because the
    LocalSystem account has administrative, network, and service privileges. In
    workgroup or cross-domain scenarios, use a local user account that exists on
    both the remote computer and the local computer where Visual Studio is
    running.

    The name of the service is 'Visual Studio 2010 Remote Debugger'. It is
    recommended that you only control the service through the Visual Studio 2010
    Remote Debugger Configuration wizard. If necessary, it can be controlled through
    the computer management administration tool, or on the command line -- 'net stop
    msvsmon100' or 'net start msvsmon100'.




    Command Line

    Description of all remote debugger command line options

    Option Description
    /allow user_name Allows specified users to connect to the remote debugger.
    Only fully trusted users should be allowed to debug. If a malicious user was
    given permission to connect, they would be able to take over the user account of
    the user running the remote debugger. User names should be semicolon or comma
    separated (example: SomeDomain\Bob;SomeDomain\Alice)
    /name server_name This option changes the server name. This is useful if the
    same user wants to run multiple instances of the remote debugger on the same
    computer. For more information, see Server Names.
    /timeout number_of_seconds Configures the number of seconds the remote debugger waits
    before exiting if no user is connected. In Windows Authentication mode, the
    default timeout is infinite. In No Authentication mode, the default timeout is
    15 minutes.
    /nostatus Starts the remote debugger with the status window hidden.
    The status window can be shown from the remote debugger's system tray icon.
    /silent Tells the remote debugger not to show the user interface.
    /noauth Switches the remote debugger from Windows Authentication
    mode to No Authentication mode. For more information, see Security.
    /anyuser In No Authentication mode, Visual Studio sends the current
    user's username to the remote debugger. The remote debugger uses this username
    for a safety check to help prevent users from accidentally connecting to a
    different user's remote debugger. This option disables the safety check so that
    any user can connect.
    /port port_number In No Authentication mode, the remote debugger opens a
    TCP/IP port to listen to network requests. This option changes the port number
    that the remote debugger listens on.
    /noclrwarn The remote debugger tries to load the 2.0 Common Language
    Runtime (CLR). This option suppresses the warning that appears if the installed
    CLR is incompatible. This option is useful if you don't want to debug managed
    code.
    /nosecuritywarn When using the '/noauth' or '/allow' command line options,
    the remote debugger normally displays a warning because both of these options
    are dangerous unless used with care. The '/nosecuritywarn' disables these
    warnings. This option should only be used if you understand the security
    implications of the '/noauth' and '/allow' options.
    /noguestonlywarn When debugging between computers running on a workgroup, the
    operating system usually enables a security policy that is not compatible with
    debugging using Windows Authentication. This option turns off checking for this
    condition.
    /nofirewallwarn Do not warn if the Windows Firewall blocks remote debugging.
    /nowowwarn 64-bit versions of Windows are capable of running 32-bit
    applications. This technology is called 'WOW'. When running the remote debugger
    under WOW, it is not able to attach to 64-bit processes. This option turns off
    checking for this condition.




    User Interface


    Status window

    The status window shows remote debugging events. Successful connections and
    successful initializations are shown.


    Options dialog

    Option Description
    Server name Each instance of the remote debugger must have a unique
    name. This edit box shows this unique name. In Windows Authentication mode, this
    name can be changed. This is necessary if you want to run more then one instance
    of the remote debugger. For more information, see Server Names.
    Windows Authentication This option enables Windows Authentication mode. For more
    information, see Security.
    Permissions In Windows Authentication mode, this option opens the
    permissions dialog.
    No Authentication This option enables No Authentication mode. For more
    information, see Security.
    TCP/IP port number In No Authentication mode, the remote debugger will listen
    on a TCP/IP port. This option can be used to configure what TCP/IP port to
    listen on.
    Allow any user to debug In No Authentication mode, Visual Studio sends the current
    user's username to the remote debugger. The remote debugger uses this username
    for a safety check to help prevent users from accidentally connecting to a
    different user's remote debugger. This option disables the safety check so that
    any user can connect.
    Maximum idle time (seconds) Configures the number of seconds the remote debugger waits
    before exiting if no user is connected. In Windows Authentication mode, the
    default timeout is infinite. In No Authentication mode, the default timeout is
    15 minutes.

    Permissions dialog

    In Windows Authentication mode, this dialog can be used to specify which
    users can connect and debug through the remote debugger. Only fully trusted
    users should be allowed to debug. If a malicious user was given permission to
    connect, they would be able to take over the user account of the user running
    the remote debugger.



    Wednesday, May 16, 2012 1:02 PM
  • Also, I've completely disabled the firewall and the config wizard keeps telling me "The windows firewall on this machine is currently blocking..."

    I did reboot.

    WTF?  Does anyone use this POS?

    Wednesday, May 16, 2012 1:07 PM
  • Hi chupper,

    Thank you for posting in the MSDN forum.

    Would you mind letting us know more information? Do you mean that you get the error message The Windows Firewall is currently blocking remote debugging when you try to use the Remote Debugging Monitor (Msvsmon.exe) in Microsoft Visual Studio?

    If so, to resolve this problem, a kb provided some useful information, and if possible, please check them.

    1. Manually set the Windows Firewall settings to unblock the Remote Debugging Monitor. For more information, visit the following Microsoft Developer Network (MSDN) Web site: http://msdn2.microsoft.com/en-us/library/bb385831.aspx.
    2. Click Start, type msvsmon /nofirewallwarn in the Start Search box, and then press ENTER.

    Before we start remote debugging, we also need to check some settings, for detailed information, see How to: Run the Remote Debugging Monitor. Hope it could help.

    If not the correct error message, would you mind sharing us the detailed error message?

    Best Regards,


    Jack Zhai [MSFT]
    MSDN Community Support | Feedback to us

    Thursday, May 17, 2012 7:34 AM
    Moderator
  • Hi chupper,

    I marked this reply as the answer, if you still need the help, please feel free to let us know, we will try our best to help you.

    Best Regards,


    Jack Zhai [MSFT]
    MSDN Community Support | Feedback to us

    Wednesday, May 23, 2012 2:47 AM
    Moderator
  • Or you could just try it for yourself and see.

    No you did not answer the question.  As I said, my firewall is completely off in control panel.

    so why is this thing complaining about it?

    Also, I stated that I need to run it as a service, so what good is that command line option?

    What a joke.

    Wednesday, May 23, 2012 12:55 PM
  • Hi chupper,

    Sorry for my reply no help.

    Would you mind sharing the whole error message? Which systems are you using? Whether you could ping one machine from the other one (do it for your both computers)?

    As you said that the firewall is completely off, like this link if you reopen it and configure the firewall to allow the Remote Debugging Monitor to communicate with the Visual Studio host computer. What result did you get?

    Best Regards,


    Jack Zhai [MSFT]
    MSDN Community Support | Feedback to us

    Thursday, May 24, 2012 2:26 AM
    Moderator