views:

2711

answers:

5

Is it possible to install the x86 Remote Debugger as a Service on a 64bit machine? I need to attach a debugger to managed code in a Session 0 process. The process runs 32bit but the debugger service that gets installed is 64bit and wont attach to the 32bit process.

I tried creating the Service using the SC command, and was able to get the service to start, and verified that it was running in Task manager processes. However, when I tried to connect to it with visual studio, it said that the remote debugger monitor wasn't enabled. When I stopped the x86 service, and started the x64 service and it was able to find the monitor, but still got an error.

Here is the error when I try to use the remote debugger: Unable to attach to the process. The 64-bit version of the Visual Studio Remote Debugging Monitor (MSVSMON.EXE) cannot debug 32-bit processes or 32-bit dumps. Please use the 32-bit version instead.

Here is the error when I try to attach locally: Attaching to a process in a different terminal server session is not supported on this computer. Try remote debugging to the machine and running the Microsoft Visual Studio Remote Debugging Monitor in the process's session.

If I try to run the 32bit remote debugger as an application, it wont work attach b/c the Remote Debugger is running in my session and not in session 0.

A: 

Can you give more details about the problem? what is the 32 bit service in question? What exactly is the error - you imply it's the bitness but the 64bit debugger should be able to load 32 bit managed code, afaik.

x0n
+1  A: 

I haven't tried this, but here's a suggestion anyway:

Try installing the x86 remote debugger service manually.

sc create "Remote Debugger" binpath= "C:\use\short\filename\in\the\path\x86\msvsmon.exe /service msvsmon90"

Two notes:

  • You'll need to use short filenames in the path to msvsmon.exe to prevent having to quote the path (since the whole command needs to be quoted)
  • there must be a space after the "binpath=" (and no space before the '=' character). Whoever wrote the command line parser for the sc command should be cursed.

Then you can use the services.msc control panel applet to get it running with the right credentials.

You'll probably have to stop or maybe even delete the existing x64 remote debugger service.

Michael Burr
+3  A: 

This works on my machine(TM) after installing rdbgsetup_x64.exe and going through the configuration wizard:

sc stop msvsmon90
sc config msvsmon90 binPath= "C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\Remote Debugger\x86\msvsmon.exe /service msvsmon90"
sc start msvsmon90
+2  A: 

I can confirm that what you want to do will indeed work. I often connect my 32 bit xp worstation to a x64 win2003 server with VS2008 remote debugger.

+1  A: 

We had the same problem when trying to remote debug a website that is running as 32 bit inside 64 bit IIS.

You can also do this:

  • Stop the default debugging service (which will be x64 as the installer will have been clever and configured that one to run).
  • Navigate to the Remote Debugger start menu folder and run the x86 debugging service. Ignore the warning about
    32bit/64bit.
  • Open the Tools->Options window of the remote debugger app window and make
    note of the value in the 'Server
    Name' text box.
  • Now you can attach your visual studio to it by copying the 'Server Name'
    value into the 'Qualifier' text/combo box on the Attach To Process dialog
    of Visual Studio.

On a related note, there is also a low-level bug with Kerberos authentication if you are attaching from Windows 2008/7/Vista to a 2003 machine, described here: http://www.labs.jobserve.com/Articles.aspx/Remote-debugging-code-on-Windows-2003-from-Vista-or-Windows-72008-R2 and reported to MS (recently closed as 'external') via Connect here: https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=508455

Andras Zoltan
We've filed new bug with MS Connect about the Kerberos authentication issue here: https://connect.microsoft.com/WindowsServerFeedback/feedback/ViewFeedback.aspx?FeedbackID=518848.If anyone else encounters this problem, then please vote for it - I have a sneaking suspicion that the Windows team will simply bounce it back out to the VS Team.
Andras Zoltan