locked
Visual Studio 2010 Remote Debugger: Attach to process window doesn't display values in "title" column when running as service RRS feed

  • Question

  • I have a machine that runs the Visual Studio Remote Debugger as a service, using an account that has administrator privileges. When I attempt to remote debug a process on this machine via the "attach to process" workflow in Visual Studio, the "title" field in the "attach to process" dialog is always blank, which is irritating when I have multiple instances of the same process name and I want to attach to a specific instance.

    Attach to process window - MSVSMON running as a service

    I've noticed that if I the Visual Studio Remote Debugger by hand (MSVSMON.exe) and connect to the machine I get the titles. 

    Attach to process window - MSVSMON launched manually

    Is it possible for me to get the titles to appear without launching MSVSMON manually?

    Please Note:

    • The included pictures show two attach to process windows looking at the exact same process, the only difference is one is connecting to MSVSMON as a service and the other is to an instance launched manually.
    • Notepad was launched as an administrator to show that the instance where MSVSMON is running as a service, it has elevated privileges
    • The instance where I've launched MSVSMON manually I've launched it with elevated privileges also

    Environment Details:

    Windows 7 Enterprise (SP1)

    Microsoft Visual Studio 2010 Professional Version 10.0.40219.1 SP1Rel



    Liam

    Wednesday, April 25, 2012 2:28 PM

Answers

  • I'm afraid that you will need to use the process id to identify which item is you wanted.

    About why the result is like this, I think the reason would be related to the Windows Service behavior things, and after read the document for the remote debugging service, it seems the service is design for debug service kind things, and service type things has no Window Title.


    Mike Zhang[MSFT]
    MSDN Community Support | Feedback to us


    Thursday, April 26, 2012 7:42 AM
  • Hi Liam,

    I don't see a simliar issue reported before after checking MS database; I also tried to consult with some VS experts, no luck to have a response.

    Your question falls into the paid support category which requires a more in-depth level of support.  Please visit the below link to see the various paid support options that are available to better meet your needs.
    http://support.microsoft.com/default.aspx?id=fh;en-us;offerprophone

    Thanks,

    Fred


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    • Marked as answer by Liam Flanagan Wednesday, May 16, 2012 11:28 AM
    Wednesday, May 16, 2012 9:22 AM

All replies

  • I'm afraid that you will need to use the process id to identify which item is you wanted.

    About why the result is like this, I think the reason would be related to the Windows Service behavior things, and after read the document for the remote debugging service, it seems the service is design for debug service kind things, and service type things has no Window Title.


    Mike Zhang[MSFT]
    MSDN Community Support | Feedback to us


    Thursday, April 26, 2012 7:42 AM
  • That's unfortunate.

    I'll try just running msvsmon.exe via a scheduled task and see if that's any better.

    Thanks,


    Liam

    Thursday, April 26, 2012 8:05 AM
  • You're welcome!

    Best wishes,


    Mike Zhang[MSFT]
    MSDN Community Support | Feedback to us

    Thursday, April 26, 2012 9:04 AM
  • Just for people's information I tried to run msvsmon.exe as a scheduled task (you can see the xml for the task below):

    <?xml version="1.0" encoding="UTF-16"?>
    <Task version="1.2" xmlns="http://schemas.microsoft.com/windows/2004/02/mit/task">
      <RegistrationInfo>
        <Date>2012-04-26T15:03:38.8925517</Date>
        <Author>LIAMVM7X86\Liam</Author>
        <Description>Microsoft Visual Studio Remote Debugger 2010</Description>
      </RegistrationInfo>
      <Triggers>
        <BootTrigger>
          <Enabled>true</Enabled>
        </BootTrigger>
      </Triggers>
      <Principals>
        <Principal id="Author">
          <UserId>LIAMVM7X86\Liam</UserId>
          <LogonType>Password</LogonType>
          <RunLevel>HighestAvailable</RunLevel>
        </Principal>
      </Principals>
      <Settings>
        <MultipleInstancesPolicy>IgnoreNew</MultipleInstancesPolicy>
        <DisallowStartIfOnBatteries>false</DisallowStartIfOnBatteries>
        <StopIfGoingOnBatteries>true</StopIfGoingOnBatteries>
        <AllowHardTerminate>true</AllowHardTerminate>
        <StartWhenAvailable>false</StartWhenAvailable>
        <RunOnlyIfNetworkAvailable>false</RunOnlyIfNetworkAvailable>
        <IdleSettings>
          <StopOnIdleEnd>true</StopOnIdleEnd>
          <RestartOnIdle>false</RestartOnIdle>
        </IdleSettings>
        <AllowStartOnDemand>false</AllowStartOnDemand>
        <Enabled>true</Enabled>
        <Hidden>false</Hidden>
        <RunOnlyIfIdle>false</RunOnlyIfIdle>
        <WakeToRun>false</WakeToRun>
        <ExecutionTimeLimit>PT0S</ExecutionTimeLimit>
        <Priority>7</Priority>
      </Settings>
      <Actions Context="Author">
        <Exec>
          <Command>"C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\Remote Debugger\x86\msvsmon.exe"</Command>
          <Arguments>/nowowwarn</Arguments>
        </Exec>
      </Actions>
    </Task>

    Anyway this suffered from exactly the same problem as when it was run as a service. I investigated the running process in both circumstances (running via Task Scheduler automation / running manually) using process explorer and as far as I can tell everything was identical; "User Name", "Image Path", "Command Line"... The only thing that was different was the spawning process. I.e. in the task scheduler instance it was spawned by the task scheduler and the manual instance it has no parent. Perhaps this is the key difference that creates this problem... I don't know I sort of still expected it to work...

    *stumped*


    Liam

    Thursday, April 26, 2012 2:30 PM
  • If you want this way, then I configured a test case, and it work, I think this would be related to the process integrity level, when we start the msvsmon service, the msvsmon.exe process's integrity is System level(even use the current user account config the service, it is running with the High integrity level), but the process for notepad.exe(x64 in my system) is the Medium integrity level.

    But when I test it use mine task scheduler item start the msvsmon.exe, its process's integrity level is the same as the notepad.exe process, Medium. And the Visual Studio Window can display the Title content.

    Though there're some different settings between your and mine, I think the most possible root cause is the high lighted two configurations below.

    <?xml version="1.0" encoding="UTF-16"?>
    <Task version="1.3" xmlns="http://schemas.microsoft.com/windows/2004/02/mit/task">
      <RegistrationInfo>
        <Date>2012-04-27T15:13:16.2385897</Date>
        <Author>test\currenttestuser</Author>
      </RegistrationInfo>
      <Triggers>
        <TimeTrigger>
          <StartBoundary>2012-04-27T15:14:00</StartBoundary>
          <Enabled>true</Enabled>
        </TimeTrigger>
      </Triggers>
      <Principals>
        <Principal id="Author">
          <UserId>test\currenttestuser</UserId>
          <LogonType>InteractiveToken</LogonType>
          <RunLevel>LeastPrivilege</RunLevel>
        </Principal>
      </Principals>
      <Settings>
        <MultipleInstancesPolicy>IgnoreNew</MultipleInstancesPolicy>
        <DisallowStartIfOnBatteries>false</DisallowStartIfOnBatteries>
        <StopIfGoingOnBatteries>true</StopIfGoingOnBatteries>
        <AllowHardTerminate>true</AllowHardTerminate>
        <StartWhenAvailable>false</StartWhenAvailable>
        <RunOnlyIfNetworkAvailable>false</RunOnlyIfNetworkAvailable>
        <IdleSettings>
          <StopOnIdleEnd>true</StopOnIdleEnd>
          <RestartOnIdle>false</RestartOnIdle>
        </IdleSettings>
        <AllowStartOnDemand>true</AllowStartOnDemand>
        <Enabled>true</Enabled>
        <Hidden>false</Hidden>
        <RunOnlyIfIdle>false</RunOnlyIfIdle>
        <DisallowStartOnRemoteAppSession>false</DisallowStartOnRemoteAppSession>
        <UseUnifiedSchedulingEngine>false</UseUnifiedSchedulingEngine>
        <WakeToRun>false</WakeToRun>
        <ExecutionTimeLimit>P3D</ExecutionTimeLimit>
        <Priority>7</Priority>
      </Settings>
      <Actions Context="Author">
        <Exec>
          <Command>"C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\Remote Debugger\x64\msvsmon.exe"</Command>
        </Exec>
      </Actions>
    </Task>

    If you want view some process integrity info, then you will need to use this like tool: Process Explorer, and then config the columns to let the Integrity column display on the main Window. It seems that the System integrity level is not marked, and the others are used the names I said above(the words beginning with the capital char).

    Best wishes,


    Mike Zhang[MSFT]
    MSDN Community Support | Feedback to us



    Friday, April 27, 2012 7:26 AM
  • Mike,

    That's very useful to know, however if you look back to the original post everything was running with elivated privileges. What I posted was a cut down version of real use case where I sometimes need to attach to custom actions being run as a part of a product installation that must be run with elevated privlileges.

    I've attached a two screenshots from my machine as it's running msvsmon via the task scheduler -just like your machine- however I've left it with elivated privileges:

    Processes running on my Virtual Machine

    The first shows that both the msvsmon.exe and notepad.exe have the same integrity level of "high".

    Visual Studio Instance

    The second shows that my instance of Visual Studio is running with elevated privileges.


    Liam

    Friday, April 27, 2012 8:40 AM
  • I'd like to point out that if I run msvsmon.exe by hand (as administrator) this all works fine. See the images below:

    Processes running on my Virtual Machine

    Visual Studio Instance


    Liam

    Friday, April 27, 2012 8:41 AM
  • It seems that you have not read into my last post, please try my settings to let the msvsmon process with the Medium integrity(not the High integrity level), so that it can work with the common application process, at least in my test, it seems that this is necessary, and the root cause is the integrity level problem, though I got no document from MSDN.

    And I think this is not related the if you elevated process privilege.


    Mike Zhang[MSFT]
    MSDN Community Support | Feedback to us

    Friday, April 27, 2012 9:32 AM
  • Mike,

    First of all, as far as I'm aware process integrity is directly related to security and privilege CF:

    As a result I don't see how I can have msvsmon run:

    1. At Startup (which your task did not do)
    2. With elevated privileges

    with an integrity level of medium. At least in my local tests both these requirements push the integrity level of the msvsmon process up to high. If you recall from my last post:

    "That's very useful to know, however if you look back to the original post everything was running with elivated privileges. What I posted was a cut down version of real use case where I sometimes need to attach to custom actions being run as a part of a product installation that must be run with elevated privlileges."

    I have a requirement to debug process with elevated privileges.

    Furthermore evidence seems to suggest that the integrity level isn't the issue here. If you look at my last post, it shows msvsmon and notepad both running at a high integrity level and visual studio was able to pull the window titles. However obviously this was run by hand so in the interests of completeness I removed the elements of my scheduled task that bumped it up to high integrity and performed the experiment again.

    Here is the task xml:

    <?xml version="1.0" encoding="UTF-16"?>
    <Task version="1.2" xmlns="http://schemas.microsoft.com/windows/2004/02/mit/task">
      <RegistrationInfo>
        <Date>2012-04-27T11:24:43.862914</Date>
        <Author>LIAMVM7X86\Liam</Author>
      </RegistrationInfo>
      <Triggers />
      <Principals>
        <Principal id="Author">
          <UserId>LIAMVM7X86\Liam</UserId>
          <LogonType>Password</LogonType>
          <RunLevel>LeastPrivilege</RunLevel>
        </Principal>
      </Principals>
      <Settings>
        <MultipleInstancesPolicy>IgnoreNew</MultipleInstancesPolicy>
        <DisallowStartIfOnBatteries>false</DisallowStartIfOnBatteries>
        <StopIfGoingOnBatteries>true</StopIfGoingOnBatteries>
        <AllowHardTerminate>true</AllowHardTerminate>
        <StartWhenAvailable>false</StartWhenAvailable>
        <RunOnlyIfNetworkAvailable>false</RunOnlyIfNetworkAvailable>
        <IdleSettings>
          <StopOnIdleEnd>true</StopOnIdleEnd>
          <RestartOnIdle>false</RestartOnIdle>
        </IdleSettings>
        <AllowStartOnDemand>true</AllowStartOnDemand>
        <Enabled>true</Enabled>
        <Hidden>false</Hidden>
        <RunOnlyIfIdle>false</RunOnlyIfIdle>
        <WakeToRun>false</WakeToRun>
        <ExecutionTimeLimit>PT0S</ExecutionTimeLimit>
        <Priority>7</Priority>
      </Settings>
      <Actions Context="Author">
        <Exec>
          <Command>"C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\Remote Debugger\x86\msvsmon.exe"</Command>
        </Exec>
      </Actions>
    </Task>
    Processes running on my Virtual Machine

    Visual Studio Attach To Process Dialog

    As you can see, despite the medium integrity level, the problem is still occurring. This somewhat implies the problem is something else.


    Liam


    • Edited by Liam Flanagan Friday, April 27, 2012 11:07 AM Clarified the msvsmon integrity level list. The sentence didn't make sense.
    Friday, April 27, 2012 11:05 AM
  • I have no idea now for this, I have not found any document can show us a way can let the msvsmon work for you on this way, but I will try to involve others to reply to you once they got ideas for it.

    Best wishes,


    Mike Zhang[MSFT]
    MSDN Community Support | Feedback to us


    Monday, April 30, 2012 4:33 AM
  • Hi Liam,

    I don't see a simliar issue reported before after checking MS database; I also tried to consult with some VS experts, no luck to have a response.

    Your question falls into the paid support category which requires a more in-depth level of support.  Please visit the below link to see the various paid support options that are available to better meet your needs.
    http://support.microsoft.com/default.aspx?id=fh;en-us;offerprophone

    Thanks,

    Fred


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    • Marked as answer by Liam Flanagan Wednesday, May 16, 2012 11:28 AM
    Wednesday, May 16, 2012 9:22 AM
  • Hi Fred,

    Thanks for your response.

    Unfortunately as there is a workaround for this (using the process id or running msvsmon manually) I cannot really warrant using paid support on this. Also I suspect this has something to do with security anyway, i.e. perhaps it's been programmed to be disabled when running as a service to prevent secure information displayed in title's from being displayed or something like that. In which case it would probably be a waste of someone's time / my employer's money.

    Nevertheless thanks again for investigating,


    Liam

    Wednesday, May 16, 2012 11:28 AM