Tone's Notes

The following notes apply to debugging an application running on a Windows XP SP2 box that is intended for stand alone deployment and does not want to (or is not able to) join the same domain as the development machine. The development machine is running Windows XP SP2 as well and is a member of a domain. These steps are known to work with Visual Studio 2005 beta 1 (Whidbey) and will probably also work with Visual Studio 2003.

The first problem you might run into is not being able to see the workgroup machine from the Visual StudioàDebugàAttach to ProcessàBrowse… dialog. Doing the following will cause the non-domain machine to begin advertising itself as a workgroup machine to other networked machines, including your domain development machine.

1. System control panel, Computer Name tab, Network ID button. Told the "Network Identification Wizard" that this computer is part of a business network that does not use a domain.

The next thing your likely to run into is an error dialog after selecting the workgroup machine from the Attach to ProcessàBrowse… dialog. There are a number of things that can prevent the connection from being made and the error dialog may or may not point you in the right direction. Another thing to try that can help get things configured is to run the Remote Debugging Monitor on the workgroup machine manually. It has some good diagnostics that it displays at startup if there are connection issues.

2. Run Visual Studio Remote Debugging Monitor (msvsmon.exe) which you may find under Visual Studio->Tools. Install Remote Debugging Support from the Visual Studio installation CD if you can’t find it.

One way to satisfy the authentication requirements when debugging a workgroup machine from a domain machine is to create a local account on the domain machine that matches the account being used on the workgroup machine. You may also need to modify the local security policy on the workgroup machine to prevent all remote accesses from mapping to the guest account.

3. Run Administrative Tools, Local Security Policy and configured Local Policies->Security Options->Network access: Sharing and security model... from "Guest only" to "Classic". This keeps all remote access authentications from mapping to the guest account.
4. Created a local account on development (domain) machine to match local account on the workgroup machine (the machine being debugged). Add account to administrators group. Add access to the source tree to the account.
5. Run Visual Studio as the local account.
6. Open the project/solution.
7. Run the application on the workgroup machine.
8. Attach to the process from the domain machine: DebugàAttach to Process