Jump to content


Photo

Debugging applications remotely with Visual Studio

Started by Andrew Borzycki , 16 January 2012 - 02:57 AM
6 replies to this topic

Andrew Borzycki Citrix Employees

Andrew Borzycki
  • 7 posts

Posted 16 January 2012 - 02:57 AM

This thread covers how to debug applications running inside XenApp sessions remotely from your Windows 7 development machine. It will contain a few messages indicating how to make it all work.



Andrew Borzycki Citrix Employees

Andrew Borzycki
  • 7 posts

Posted 16 January 2012 - 03:02 AM

Introduction
This article outlines how to set up Visual Studio 2010 so you can debug applications remotely. The main situation to do this is if you develop your software using Visual Studio 2010 on Windows 7 x64; yet want to run the software on a XenApp Server inside an ICA session.

Setting up remote debugging with Visual Studio is documented on MSDN at http://msdn.microsof...y/bt727f1t.aspx

Following the MSDN instructions will get you started, but there are steps missing / implied that can cause issues, so hopefully the following steps will give you a clear path to get into the compile / debug / test cycle remotely.

A previous post discussed installing Visual Studio onto the XenApp server itself as a method for debugging. This can hide various deployment issues you can encounter as Visual Studio will install many runtimes and dependencies that may not be present on eventual customer deployment machines.

It is better to find out exactly what dependencies your application has early, so you don't get stung close to deployment time trying to deal with issues like needing redistributables you don't have / cannot redistribute, or end up trying to give customers debug binaries.

By doing remote debugging, there is a much lighter development footprint on your test machine, and is closer to eventual deployment environment.

Scenarios covered
This document aims to let the following scenario work:

* 1. Write a managed (.NET) or native (C/C++) application inside Visual Studio 2010 on Windows 7 x64 using the Citrix Mobile Application SDK.
* 2. Copy the built application to a XenApp server with the Citrix Mobile Application SDK installed.
* 3. Run the application inside an ICA session on a mobile device using the features of the XenApp 6.5 Mobility Pack while running the debugging session from your Windows 7 workstation, which has all of your source code and large screen real estate. You get all the power of Visual Studio and its debugging features.
Setting everything up
The MSDN article "How to Set Up Remote Debugging" http://msdn.microsof...y/bt727f1t.aspx covers the general steps on how to set up remote debugging. In particular, it covers the firewall settings required. The following steps are largely based upon the article.

Setting up the Visual Studio Host Computer (Debugger)
* 1. Make sure Visual Studio 2010 is installed on the machine and the firewall opened up as outlined in the MSDN article.
Setting up the XenApp Server (Debuggee)+ +Software Installation and configuration
* 1. Install the remote debugging components. You can get these from the Visual Studio 2010 DVD image, or download from Microsoft at http://www.microsoft...ylang=en&id=475
* 2. For XenApp 6.5, which is on top of Windows Server 2008 R2, install the rdbgsetup_x64.exe version of the remote debugging tools.
* 3. Execute rdbgsetup_x64.exe to install the remote debugging tools.
* 4. When going through the wizard after installation:
* 5. Do not select "Run the "Visual Studio 2010 Remote Debugger" service, as this is not required / wanted when you are debugging interactive apps running inside a user session.
* 6. Take note of the firewall messages the wizard tells you about the open ports required. These are covered in the MSDN article referenced above as well.
* 7. Depending on your network configuration, either restrict to computers on your local network, or allow any computer to connect to the remote debugger.
* 8. The Remote Debugger Configuration Wizard is on the start menu, so you can run it again later if you wish.



Andrew Borzycki Citrix Employees

Andrew Borzycki
  • 7 posts

Posted 16 January 2012 - 03:05 AM

User and Authentication configuration
This is the area that is most likely to cause remote debugging to fail, and the area of most problems. You need to get this right before you can debug managed code. Native code debugging can bypass these authentication issues by selecting the "Remote" transport mechanism.

The overriding source of problems that arise is that there is either a mismatch of usernames / passwords.

In all cases, make sure you have administrative privileges on the XenApp server for the credentials under which you want to debug the applications. This lets the Visual Studio Remote Debugger run with the privileges it needs.

Debuggee and Debugger part of same domain

If the debugger and debuggee machines are part of the same domain, then this is the simplest situation. Configure your Citrix Receiver to logon as the same domain user as your Windows 7 development machine credentials under which you run Visual Studio.

Debuggee in a workgroup and Debugger in a domain

This is the most complex setup, and possibly the most common. This covers the situation where your main development machine is a Windows 7 machine in a domain, while your XenApp test server is not in a domain. There are 3 user identities which are involved which all need to have matching usernames and passwords:

* 1. The XenApp local user the remote debugger runs as.
* 2. The Windows 7 domain user that Visual Studio runs as.
* 3. The Windows 7 local user that is used by the debugger.

All 3 of these accounts need to have matching usernames and passwords to work. Otherwise you will run into debug authentication problems. Even if you logon to your Windows 7 machine with a domain user, the Windows 7 machine needs to have a local account of the same name, with the same password. Forgetting about the local Windows 7 user is the part that can cause problems.

For example, if I logon to my Windows 7 machine, win7dev as domain\user1, with a password of "password", and debug on a XenApp server called xenappdev, then the following accounts need to be in place:

* 1. xenappdev\user1, with a password of "password" at the XenApp server xenappdev.
* 2. domain\user1, with a password of "password" in the domain "domain", and this must be the user logged onto the Windows 7 machine you intend to debug with.
* 3. win7dev\user1, with a password of "password" at the Windows 7 machine win7dev.

Neither Debuggee nor Debugger in a domain

Make sure that the usernames and passwords match for your Windows 7 development machine and the Citrix Receiver credentials / XenApp server credentials.

Firewall Configuration
The MSDN article "How to: Configure the Windows 7 Firewall for Remote Debugging" http://msdn.microsof...y/ee126350.aspx covers how to set the firewall. The Remote Debugger lets you know when it starts if it needs to configure the firewall to let extra traffic through.

Checking it all works
The quickest way to check everything works is to try and attach to a process from Visual Studio. This ensures that you can get through the firewall to the destination, and that the authentication works correctly.

* 1. Publish a desktop so you launch a server desktop from the Receiver.
* 2. Configure the Receiver to use the username that matches your Windows 7 user running Visual Studio, which also exists on your XenApp server.
* 3. Launch the published desktop.
* 4. Launch All Programs -> Microsoft Visual Studio 2010 -> Visual Studio 2010 Remote Debugger - either the x86 or x64 version will do.
* 5. Accept any UAC prompts that appear, and let it configure the firewall if it says it needs to.
* 6. You should see the Visual Studio Remote Debugging Monitor window saying something like "Msvsmon started a new server named ‘domain\user@server'..."
* 7. Now, at the Windows 7 machine, launch Visual Studio 2010.
* 8. Go to Debug -> Attach to Process...
* 9. Leave Transport as "Default"
* 10. Put into "Qualifier", the text from the Visual Studio Remote Debugging Monitor. For example "domain\user@server". If you just put the machine name in, then you will run into problems when doing a mixed domain / non domain debugging session.
* 11. Then click "Refresh".
* 12. If all goes well, you will see a process list from your session, and a message on the Debugging Monitor indicating that you have connected.
* 13. If there are any problems, then make sure your authentication and firewall are setup correctly.



Andrew Borzycki Citrix Employees

Andrew Borzycki
  • 7 posts

Posted 16 January 2012 - 03:08 AM

Launching a Debug session
At this point, all of the fundamental plumbing should be in place, and remote debugging is possible. The next stage involves getting your application to your XenApp server and actually debugging your application.

When remote debugging, consider a way to get your binaries needed to your XenApp server automatically after each build. This will ensure that you have correct binaries on your target machine that match your current build on your development machine. You can do this by either adding a post build event to copy the binaries, or a script run outside of the IDE.

You can start debugging your application either by attaching to a running instance, or by configuring Visual Studio to launch the debugger remotely for your application. If you configure Visual Studio to launch the debugger remotely automatically for your application, that will give you the easiest debugging experience and the ability to debug / step into your application right from the start.

Configuring Visual Studio
The following instructions describe how to configure Visual Studio for debugging a C# application remotely. For a C++ application, the options are slightly different, but the concepts are the same.

* 1. Bring up the project properties page.
* 2. Select the Debug tab.
* 3. Make the Start Action "Start external program", and specify where your application will be located +on the XenApp server+. Not where it is on your development machine. If this is not done, and the install location on your server is different to that of your development machine build output, then the debugger cannot launch your application.
* 4. For Start Options, tick "Use remote machine", and put the text from the Visual Studio Remote Debugging Monitor session here. For example, user1@xenappdev. If you just put the machine name in, then you will run into problems when doing a mixed domain / non domain debugging session.
* 5. Now Visual Studio should be configured to launch the debugger on the remote machine whenever you decide to debug.
Starting Debugging
* 1. Publish a desktop so you launch a server desktop from the Receiver.
* 2. Configure the Receiver to use the username that matches your Windows 7 user running Visual Studio, which also exists on your XenApp server.
* 3. Launch the published desktop.
* 4. Launch All Programs -> Microsoft Visual Studio 2010 -> Visual Studio 2010 Remote Debugger - either the x86 or x64 version will do.
* 5. Accept any UAC prompts that appear, and let it configure the firewall if it says it needs to.
* 6. You should see the Visual Studio Remote Debugging Monitor window saying something like "Msvsmon started a new server named ‘domain\user@server'..."
* 7. Now, at the Windows 7 machine, launch Visual Studio 2010.
* 8. Load the workspace containing your application.
* 9. Build your application.
* 10. Copy your application to the XenApp server in the location you specified earlier when setting up the debugging configuration.
* 11. Select Debug -> Start Debugging, or Debug -> Step Into, to get the debugger going.
* 12. You should see a message on the Visual Studio Remote Debugging Monitor window saying "domain\user connected".
* 13. Your application should appear on your published desktop, and if any breakpoints are hit, or code execution stops, Visual Studio should appear in its regular debugger mode.
* 14. Code / build / debug, and repeat as needed. You should be able to debug like a local application at this point.

Common problems
* 1. Make sure that the user you run the XenApp session as is a local administrator on your XenApp server.
* 2. You get username / password related errors. Make sure you have gone through the steps related to authentication and that all of your usernames AND passwords match. Make sure to check the local Windows 7 account if you are doing mixed domain / non domain testing.
* 3. There is no communications, or messages about firewalls. Make sure that the firewall on the Windows 7 and XenApp servers are configured according to http://msdn.microsof...y/ee126350.aspx
* 4. Also check that the debug monitor session name matches the connection session name you are trying to use at the debugger machine.
* 5. You can look at process lists, but cannot debug your application. This is a sign that you have not configured your Visual Studio's project's properties to debug remotely correctly. Look at the section outlining how to launch a debug session to resolve this issue.
* 6. Visual Studio indicates there are symbol problems and mismatches between the running application and the symbols it has. Make sure the binaries you build and the binaries on your test machine are in sync.
* 7. You discover that your application is missing DLLs or will not start. This is often due to missing dependencies, such as .NET runtimes, Visual C++ redistributables, or you are using debug binaries. In these situations, install the dependencies as required, and consider the implications when it comes to customer deployment.
Alternative approaches
While this approach is quite powerful, it is not the only way to debug applications written with the Citrix Mobile Application SDK. Alternatives are:

* 1. Use logging, tracing and so on. Tools like DebugView http://technet.micro...ernals/bb896647 let you view win32 debug output.
* 2. Use Windbg. This is a flexible Windows debugger that can debug native and managed code, when it has the SOS extension.
* 3. Install Windbg as the default post mortem debugger. Then, if there is a crash, windbg can be brought up, and it is possible to live debug the crash. When this occurs, it is probably easiest to smooth roam the session to a Windows Receiver session, as you will get more screen real estate to examine the source of the issue.
* 4. Install Visual Studio 2010 onto your XenApp server.

While setting up remote debugging with Visual Studio may appear to be complex, it is relatively light weight in terms of its impact on the XenApp server - so you are not modifying the target environment significantly, and it provides a rich debugging experience in the target environment.



David Hwu Members

David Hwu
  • 9 posts

Posted 02 April 2012 - 11:52 PM

Hi,
I have XenApp 6.0 with all the recommended hot fixes installed... along with VS2010 SP1 remote debugging, etc.
I can run the msvsmon.exe for 64 bit and even attach to processes from a win 7 machine.
I see all the processes normally on the MS server environment, however NOT the connections over ICA.

Believe that remote debugging is working fine, but not sure how to connect to connections over ICA as these dont show up in "Attach to Process" under VS2010.

Question:
http://forums.citrix.com/thread.jspa?threadID=300244
Covers XenApp 6.5 specifically, not mentioning anything about XenApp 6.

Can you confirm if this functionality should work in XenApp 6.

Thanks
David

Attached Files



Donovan Hackett Citrix Employees

Donovan Hackett
  • 109 posts

Posted 03 April 2012 - 04:02 AM

David,

This thread references XenApp 6.5 since the Mobile App SDK is only supported on 6.5. However if you're trying to debug other apps on 6.0 (that have nothing to do with this SDK), then the principle is exactly the same.

When you bring up the Attach to Process dialog, look down the bottom and ensure the check boxes "Show processes from all users" and "Show processes in all sessions" are both checked to ensure you can see all processes on the machine for debugging. This is most likely reason you are not seeing processes that you want to attach to.

Regards,
Donovan



David Hwu Members

David Hwu
  • 9 posts

Posted 03 April 2012 - 05:36 AM

Thank you Donovan!
Too many long hours... overlooking the dumb easy stuff.
It works great!!