none
Remote Debugging - VS2010 on Windows 7 64-bit to Windows XP 32-bit

    Question

  • I have developed a WPF application on my workstation using Visual Studio 2010 Professional, which is a Windows 7 64-bit machine.

    I have been getting crash reports about the application on 2 other machines. One of them is a Windows XP 32-bit machine and another one is a Windows 7 32-bit machine.

    I would like to remote debug the application on both those machines.

    Currently, trying to remote debug the application for Windows XP 32-bit machine. I have installed my application (debug build) on the remote machine. I ran the Visual Studio Remote Debugging Monitor on that machine. I went to Tools -> Options and set it to No Authentication with Allow any user to debug set to checked. On my local machine (Which is Windows 7 64-bit machine), went to my Visual Studio and attached process after selecting "Remote(Native only with no authentication)" Qualifier as - remote machine name. When I refresh, I can see my application running on the remote machine and I can start debugging it.

    HOWEVER, I simply cannot get the breakpoints to hit, "The breakpoint will not currently be hit, No Symbols have been loaded for this document".

    The next thing I tried is, I copied over all the .pdb files from my localmachine/bin/debug folder of the application (since its the debug version installed remotely) and put them in the same folder as the .exe of the application. But still no difference.

    How do I get to hit the breakpoints and debug remotely without any problems ? Is the process going to be same when I try to remote debug with a remote Windows 7 32-bit machine ?


    The following sentence is true : The previous sentence is false. Welcome to my corner of the Universe.
    Thursday, January 26, 2012 7:20 PM

All replies

  • >...after selecting "Remote(Native only with no authentication)"

    You have to use the "secure" (aka a right big problem to have
    configured) transport to debug managed code.

    Dave

    Thursday, January 26, 2012 7:53 PM
  • I am sorry, I do not see/understand that setting. Where can I find it ?!
    The following sentence is true : The previous sentence is false. Welcome to my corner of the Universe.
    Thursday, January 26, 2012 9:28 PM
  • >I am sorry, I do not see/understand that setting. Where can I find it ?!

    It's the other option (the default one) along with the "Native only"
    transport that you said you chose.

    Dave

    Thursday, January 26, 2012 11:24 PM
  • How about just open a blank Visual Studio, and then try to attach to the remote target, can this also cannot load the symbols?
    And try to create a same account with the same password on these two computers, and then try the remote debug task under this account.
    How about try to open the Module Window(Ctrl+D,M) in debugging time, then try to right click on your module and use the "Load Symbols" option?

    Mike Zhang[MSFT]
    MSDN Community Support | Feedback to us
    Friday, January 27, 2012 7:02 AM
  • Question about that, I have a feeling that the accounts are the problem.

    Does the remote machine and the local machine (with Visual Studio and Source Code), have to been on the same domain and the same user account ?

    Does that mean that I cannot debug via the internet ? (A situation has come up, where my application crashes on the client's machine and I am unable to reproduce it locally)


    The following sentence is true : The previous sentence is false. Welcome to my corner of the Universe.
    Monday, January 30, 2012 5:42 PM
  • Based on my experience, I can use the ip to access the remote computer, so I think the remote debug can be used through internet.

    And yes, I mean create the same name and password account on both of the computers, then run your Visual Studio on this account, and let your end user run the remote debugger tool under this account.

    This is not necessary condition for remote debugging, but it seems remote debug have much of problems, but there will not if we have a same Windows account with same password.


    Mike Zhang[MSFT]
    MSDN Community Support | Feedback to us
    Tuesday, January 31, 2012 8:18 AM
  • Let me summarize the steps :

    1) Make an Windows account on Host Machine. Log In.

    2) Make an Windows account, with same user name and password as Host Machine, on the Remote Machine. Log In.

    3) Copy all .pdb files to same directory as .exe on the Remote Machine.

    4) Run Remote Debugger on the Remote Machine.

    5) Tools -> Options

    6) Radio Button to "No Authentication (native only)" and Check "Allow any user to debug", OK.

    7) Run the .exe (debug build) on the Remote Machine.

    8) On the Host Machine, open your solution.

    9) Debug -> Attach To Process

    10) Transport : Remote ( Native only with no authentication )

    11) Qualifier : Server name set in Remote Debugger under Tools - > Options

    12) Refresh

    13) Choose the application to debug.

    14) Attach

     

    From now on, I am assuming/hoping that every breakpoint is hit. Also, If I have to add/remove breakpoints during remote debugging, it will not work, since the application running will have access only to the old .pdb files. If I have to add/remove any breakpoint, I have to move the new .pdb files again to remote machine and then restart application and attach again ?

    Please let me know if I have missed out on any step. The only thing I haven't tried so far is, creating same accounts (local not domain) on both machines.

    Also whats with the whole "Native only" thing ? I thought "Native" means unmanaged code. But I believe I am dealing with Managed code here since the whole solution is in C#/.NET. 


    The following sentence is true : The previous sentence is false. Welcome to my corner of the Universe.
    Thursday, February 02, 2012 3:44 PM
  • --> 6) Radio Button to "No Authentication (native only)" and Check "Allow any user to debug", OK.
    Please use the Windows Authentication.(keep it as default)
    And ensure the Permission "Debug" is allowed.
    --> 10) Transport : Remote ( Native only with no authentication )
    I think it is better to keep it use Auto, and it will change according to the process you selected.
    --> 3) Copy all .pdb files to same directory as .exe on the Remote Machine.
    --> since the application running will have access only to the old .pdb files.
    Do you mean that you copied the old .pdb files to the remote computer? Or you copied the news, but Visual Studio always load your old .pdb files. You can find the .pdb file information form the "Module Window" as I mentioned. Then you can ensure if your Symbol configuration is right, if there's something wrong, then please check both of the system variable environment side and your Visual Studio Debugger Symbol windows side.
    One build output only have one version pdb file matched, so I don't think so there's need a replacement as you said in your post to use new pdb for add/remove breakpoint.
    And I found 2 tutorials are good, maybe can give you some help after read is carefully:

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

    Friday, February 03, 2012 5:55 AM
  • Thanks Mike,

    I'll take a carefull look at that tutorial and get back to you.


    The following sentence is true : The previous sentence is false. Welcome to my corner of the Universe.
    Friday, February 03, 2012 6:47 PM
  • I am writing to check the status of the issue on your side. 
    What about this problem now? 
    Would you mind letting us know the result of the suggestions?


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

    Monday, February 13, 2012 8:54 AM
  • Hey Mike,

    Please allow me to get back to you in a while regarding this issue. I am SWAMPED with work.


    The following sentence is true : The previous sentence is false. Welcome to my corner of the Universe.

    Monday, February 13, 2012 2:35 PM
  • It's OK.

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

    Thursday, February 16, 2012 9:49 AM