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.
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
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, reported to MS (and then closed as 'external') via Connect here: https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=508455
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.
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) Install the x64 version. This also installs the x86 debugger but does not create a shortcut.
2) You can find the executable for x86 process debugging here... C:\Program Files\Microsoft Visual Studio 14.0\Common7\IDE\Remote Debugger\x86\msvsmon.exe
3) If you want to, pin it to the task bar.
Worked for me without installing additional software. I just copied the C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\Remote Debugger folder on the VM and started the msvsmon.exe from the x86 folder. Both my guest and host are x64.
Sometimes this error occurred, I just close visual studio and open it again, everything is OK!
Very strange behavior from vs
I ran into this issue today (64 bit OS and VS 2019). I changed Configuration to use x64 for the project, IISExpress to use 64 bit and Platform target to be x64. It still used the 32 bit debugger and complained. Finally, when I enabled Script Debugging it started using the 64 bit debugger. So I would say the combination of all did the trick.
Related
I want to remote debug an executable that is running on a Windows XP machine. This machine does not have Visual Studio installed. I am running Visual Studio .NET from another machine on the network. (I'm easily able to remotely debug other XP machines which have Visual Studio .NET installed).
I located the remote debugging tool (msvsmon.exe in this case) copied the folder to a local directory on the machine I wish to debug and ran it. The cmd window indicated that I was running "Visual C++ Remote Debug Monitor (x86) Version 7.00.96"
I attempt to select the machine from VS in order to attach to the process and I received an error:
Unable to connect to the machine . The debugger is not
properly installed. Run setup to install or repair the debugger.
As I'm not able to find debugging tools online that are old enough, I'm not sure how to proceed.
While there is still time, you should get a copy of VS2010 Service Patch 2, and install it, the version of msvsmon.exe in VS2010 is the LAST release which supports XP remote debugging. In my work we develop for XP Embedded, and have a large installed base used in manufacturing globally. Our customers would scream bloody murder if we changed the runtime which would break/damage/shutdown manufacturing. So we are now forced to migrate to VS2019 and yet we build for XP clients. Our new products do run newer Windows Embedded versions, but the legacy products are still in demand, and are XP embedded based. There is no remote debug capability to my knowledge with VS2019, and our firm is not allowed to distribute VS2010 to our clients so they can single step debug. Very frustrating.
I've written a Windows driver sample (WDM) with Visual Studio but I'm encountering issues when trying to debug it. The target is running in a Virtual Machine (VMware)
I've followed the documentation (http://msdn.microsoft.com/en-us/library/windows/hardware/hh698272(v=vs.85).aspx) to configure everything.
It's compiling fine but there are problems when debugging.
I have tried various configurations and have different problems on each.
Visual Studio 2013 Preview on Win7 (host) / Win8.1 Preview (target) - VMware
It seems the debugger isn't working properly. Indeed it's like if nothing was loaded, the Modules Window is empty, when I click on "Break all" nothing is happening. As you can see in the logs, the debugger session isn't created.
Screenshot:
Logs: http://pastebin.com/DfVzGR4Z
Visual Studio 2012 on Win7 (host) / Win8 (target) - VMware
It's working correctly at the first try but if I stop the debugger to modify the driver, it'll freeze the VM. I'll then have to restart the VM, Visual Studio and kill the process ntkd.exe because otherwise I have these errors:
Failure to create process instance prevents debugging
Unable to start (null), Error 80004005. (Unspecified error)
Followed by a crash of VS (Event Name: CLR20r3)
I've tried with other samples downloaded from the MSDN but it's the same problem.
I've been stuck on these issues for weeks and I'm starting to desperate, so any help would be appreciate. I haven't tried WinDDK but since VS has everything needed, I don't see why I couldn't use it normally.
I recommend to forget using Visual Studio for driver development/debugging because, on my opinion, is not solid enough.
But targetting the debugging process, it is better to install VisualDDK and then launch vmmon/vmmon64.
In the installed application you will find a folder named "target" with an application named DDKLaunchMonitor.exe, install it in the virtual machine (it will create a boot menu option to activate kernel debugging)
When you want to debug your driver, launch vmmon, activate the option to launch windbg at vm startup, start your vm and when windows boots it will load windbg and attach to the vm.
The install your driver as desired and learn windbg.
I know this answer does not solve you problem with VS but using windbg directly is faster and better.
I was having a similar problem with: Visual Studio 2015 Community Edition, Windows 10 host, Windows 10 target, VirtualBox with host only network.
Provisioning and remote driver deployment worked, but the debugger would not connect.
Edit: In the last step of provisioning in VS2015 the Host IP can be selected. The manual method below is an alternative.
The manual setup guide for kernel mode debugging says to run the following:
bcdedit /debug on
bcdedit /dbgsettings net hostip:w.x.y.z port:n
Visual Studio automatically runs these during the provisioning process. Notice the hostip parameter - this has to be the address of the connecting machine (the one with the debugger) on the interface it uses to connect to the target. Visual Studio may set this incorrectly if you have multiple network interfaces. In my case the VirtualBox host only network created the extra network interface.
Provision the target machine in VS, if you haven't already. Then run the two bcdedit commands above and reboot the target machine. After this, the debugger should connect properly.
I came across the same problem. The windbg connection is hang. I found there is something wrong in my configuration for Kernel mode debugger settings( Visual studio 2012 Driver->test->Configuration). I set the port simply com1. Actually, it should be \.\pipe\com_1.Then it works
In your case, there maybe other configuration problems. You can check through the points on webpage http://www.codeproject.com/Tips/545835/Kernel-Mode-Debugging-in-a-VM-using-Visual-Studio.
I am trying to run my visual studio (2010) C++ project on an old Windows XP machine that is running VS2010. However, when I run it, I get the error listed in the title of this question. Why is this, and how can I fix it?
Same error was throwing for me when I had Silverlight debugger enabled. To resolve this issue
Open project properties
Under web tab look for Debuggers
Remove the tick mark on "Silverlight"
In general, a debugger should be the same bitness as the debuggee (or at least it must be able to understand the architecture of the target). In any common siutation, an x86-based debugger will not be able to debug an x64 application.
The Visual Studio documentation says:
To debug a 64-bit application that is running on a remote computer,
you need to install the 64-bit remote debugger on the remote computer.
The 64-bit remote debugger is available on the last disc of your
Visual Studio installation set.
I have a test machine that runs Windows 7 Enterprise x64. I setup MSVSMon (tried both 64 and 32 bit versions) on it and made sure that the Firewall settings would not block the remote debugger. Now I'm trying to connect to this from my dev box running Windows 2008 R2 and Visual Studio 2010. However when I try to connect to the remote debugger, it shows me the following error message:
"Unable to connect to the Microsoft Visual Studio Remote Debugging Monitor named "xxxxx". THere is no server by the specified name running on the remote computer.
Some obvious things:
- I have verified that the name I'm using is correct (picked it up from teh MSMSMon.exe options dialog)
- The dev box does have access to the remote machine, I can check that by connecting to it's file shares.
- The same instance of visual studio is able to connect just fine to another similar test machine, but one running a 32 bit Windows 7 Enterprise.
Any ideas?
Vin
Make sure if you are debugging from VS2010,its the debugger for 2010 and not 2008, and/or vice versa
I would check your firewall is not blocking the connection. Just because you can connect to the fileshare doesn't mean it's allowing the DCOM connection to the Remote Debugger.
See http://msdn.microsoft.com/en-us/library/bt727f1t(v=VS.100).aspx
I generally run MSVSMon on the remote machine from a share on my dev machine where I have several versions of Visual Studio installed. I get "There is no server by the specified name running on the remote computer" error when I run the wrong version of MSVSMon. For example if the VS2008 version of MSVMon is running on the remote machine and I am trying to attach to the process from VS2010.
Default location of MSVMon for VS2008 :
C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\Remote Debugger
Default location of MSVMon for VS2010 :
C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\Remote Debugger
I've found alot of ppl bump into this scenario. Tried to cup the solution in my blog post:
http://livshitz.wordpress.com/2013/02/26/remote-debugging-visual-studio-unable-to-connect-to-the-microsoft-visual-studio-remote-debugging-monitor/#more-144
Here is the snippet of the solution:
Make sure firewall is not blocking your request
Make sure the installed version of Visual Studio Remote Debugging Monitor is supported by the running Visual Sutdio
Create local user on remote target, with the exact user name and password as the debugging user (that runs VS process)
If dns resolving is unavailable (source and target on different domains) open this file
"c:\Windows\system32\drivers\etc\hosts"
and add a new line at the bottom:
"xxx.xxx.xxx.xxx TargetHostName" (without quotes)
This will map the target host name with an IP.
I am trying to remote debug my application in VMware workstation 7 and Visual studio 2010 ultimate. I habe several images (win 7 ultimate,vista,etc).
I am following this tutorial: http://kristofmattei.be/2010/01/20/debugging-applications-in-virtual-machines-with-vmware-workstation-7-and-visual-studio-2008-sp1-2/
Whenever I try to start msvsmon.exe on the remote computer it will say :
"The visual studio remote debugger does not support this edition of windows"
tried it with win 7 ultimate, vista premium and xp home, same situation.
Could someone help me out here?
Thanks!
The error message "The visual studio remote debugger does not support this edition of windows" appears because the remote debugger tries to use Windows Authentication by default, and this is only supported in the "Pro" versions of Windows, and up.
However, the remote debugger does work with the "Home" versions of Windows, you just have to tell it not to use authentication via the command line.
(Why it doesn't let you do this after launching it without any arguments, why the error message is so misleading (and contradicts the official list of supported OS), and why there is so little info about this on the web, I don't know. :))
To launch it, run this:
msvsmon.exe /noauth /nosecuritywarn
Of course, this launches it in the lowest security mode, so you'd only want to do this on a secure network. (But that's usually the mode one ends up using msvcmon in anyway, as the other mode is an even bigger PITA to set up than it is normally. Very useful tool, but really could use some streamlining.)
No need to use VMWare features.
Inside the guest VM run the version of msvsmon that came with your copy of visual studio 2010 (A setup package for just the remote deubgging stuff can be found on the disc/image) (use x86 if debugging a 32-bit process or x64 if debugging 64-bit one ,Itanium if you need to laugh).
through the msvsmon GUI disable authentication and select allow any user to connect.
disable the firewall in the VM.
on the host machine you should be running visual studio 2010, under the debug dropdown select "attach to process..." and then on the window that pops up select remote from the dropdown that should say local or something initially, enter the IP address (should be private network IP i.e. 10.1.?.?) of the guest VM, alternatively use the server name displayed by the msvsmon GUI. You should get the process list for the guest and should only attach to any process that matches the version of msvsmon you ran (x86 or 64 ...or Itanium laugh).
NOTE: These are basic instructions to show you it definitely works but these instructions will only work for native code since managed requires a secure connection.
If you are debugging a .NET app using the VMWare VS Plugin and are getting a "file not found" type of error...make sure you have the .NET runtime installed! :)
Like a moron, I set up a fresh XP VM and forgot to install the .NET runtime and wasted a good day trying to get the VMWare VS Plug-In to work!
VSID is not supported by visual studio2010 http://communities.vmware.com/thread/282407