Friday, August 27, 2010 11:14 AM
Cannot get native code remote debugging working with Windows authentication enabled. Without authentication it works fine, though.
The MSVSMON app is started on the remote computer. Server name looks like MYDOMAIN\myuser@REMOTEPC. I entered the exact same name in the project settings debugging configuration on the local PC. Selected "Remote with Windows authentication", "Native Only", Attach=No. When starting the debug session from the local computer (F5), the MSVSMON window on the target logs "MYDOMAIN\myuser connected". Then on the local computer a message box says: "Unable to start debugging. The Visual Studio Remote Debugger on the target computer cannot connect back to this computer. Authentication failed. Please see Help for assistance."
Local computer: Windows 7 Ultimate x64. Visual Studio 2010 Premium. C++ native code project.
Remote computer: Windows 7 Ultimate (32-bit). Vistual Studio 2010 Remote debugging monitor installed from the VS2010 DVD. Did not enable "as a service" mode; the monitor is started as an application.
Both computers are on the same LAN, same subnet, both are logged in to the same domain (W2003 server) under the same user account. This user account has administrator rights on both computers. Both can ping each other. Both can access each other's shared drives (net use x: \\REMOTEPC\D$) without further authentication, which makes me believe that Windows authentication works fine. Both computers have been set up recently, no history of older Visual Studio versions.
I have also tried to turn off the Windows firewall on both ends, to no avail. Unauthenticated remote debugging works fine, even with the firewalls enabled.
Wednesday, September 01, 2010 12:54 PM
Triggered by a post by Fletcher James in another thread about authentication with remote debugging, I inspected the event log of the local computer. Apparently my local computer failed to authenticate with the domain controller (although logging in to the domain account was always succesful).
This might have to do with the fact that the domain once started as a NT4 Server domain, was then migrated to AD on a Windows 2000 Server, and later on moved to a Windows 2003 server. Fletcher James reported a similar situation.
I could solve the problem by removing the computer from the Active Directory domain, then adding it again.
- Marked As Answer by j66st Wednesday, September 01, 2010 12:55 PM