Remote debugging
Over the weekend I was trying to figure out why a service that worked perfectly on my workstation in the debugger would not cooperate on the test server.
Remote debugging is the obvious answer, and I duly installed the remote debugging service on the test server.
My login is a member of the Local Administrators group on the test server, conferring the permissions required for remote debugging, and attaching to the process is not so hard, but mysteriously I could not set a breakpoint.
Skipping the details of the quest for clues, the answer is that it’s a bit retarded about looking for symbols, and you have to tell it where the PDB files are. The help and messages on this topic are vague about the frame of reference in which this path is express, so I set up a network share on the target computer and put the symbol files there. This allowed me to express the location of the symbol files in a machine independent way, rather than using a local path that might be invalid out of context.
At this point it all started to work across the network in the office.
Over a VPN
Unsurprisingly. the VPN host is a gateway machine, rather than the test server. This has several consequences:
- Name resolution failure. I couldn’t resolve the name of the test server. Adding it to my hosts file fixed that, and I promptly found that the test server couldn’t resolve the name of my notebook, resulting in another hosts file hack. Messy, and very fragile in the presence of DHCP.
- Authentication problems. Lacking the required authentication token I could not connect to the debug service.
The only solution I can think of – and happily it should also resolve the name resolution issues – is to make the debug server a VPN host.