I have developed a windows service on my system and have deployed the service on a target machine which does not have visual studio. Therefore, I need to debug the application from my PC. I already know how to debug a windows service on a local machine.
MY STEPS:
Copied the complete bin folder (containing .exe as well as .pdb files) to the target machine.
Installed the service on the target machine using InstallUtil.exe (i.e installUtil.exe "pathToMyServiceEXE/myService.Exe")
Started the service
Installed Visual Studio Remote Debugging application (started in "No Authentication mode" with Debugging option checked)
Attached to the service in Visual Studio (which is running on my PC)
PROBLEM: I am able to successfully attached to the windows service of the target machine. But it cannot find the symbols.
I have checked other SO questions about the same problem but could not find the correct solution so far. I have tried the following things to solve the problem:
Opened Tools->Options->Debugging->Symbols and then put the path of .pdb files on my local PC. (Didn't work)
Opened Tools->Options->Debugging->General and unchecked "Enable just my code".
In addition to above two, I have already made sure that I am running the x64 version of the Remote debugging tool, Debug/x64 version of windows service and debug/x64 on my local PC.
The best advice that I can give you - which is not the easiest now, but will pay off in the long run - is to use WinDBG debugger on the target machine. This is next to zero setup on the target machine but will require you to learn the basics of WinDBG. This is not trivial but will pay off in the long run.
Regarding why you cannot load symbols:
Maybe PDBs do not match binaries?
Maybe path is not accesible to the current logged-in user? (such as mapped drive, etc)
Maybe permission issue?
Other then that I think it should work
Related
When I tried remote debugging with Windows Store applications (Metro applications), it was very easy. In the Start drop down I could choose one of the remote computer. Then VS built the project and automatically deployed the executable to the remote computer and ran it. It felt as if it were local debugging.
Now that I want to try remote debugging with an Windows application (simple C# Windows Forms), it was not that easy. I read the following page: http://msdn.microsoft.com/en-us/library/vstudio/8x6by8d2(v=vs.110).aspx
Does this mean I have to copy the built exe to the remote computer manually every single time when I build the project? Is there any way to make it work easily just like the Windows Store apps? Possibly a third-party extension or something?
I recently set this up for a work project, and encountered your post after experiencing similar issues. I detailed my solution on my blog.
Remote Debugging with VS2015
I changed the output folder to be a network share that my debugging account has access to, and the project build just creates output at that location, making it available to the debugger. I simply press the play (Debug) button on my toolbar with the 'Remote Debug' profile selected.
Open Configuration Manager for the solution
Add a new configuration and name it appropriately. Select the box to automatically do so for all projects.
Open the project properties of the executable project you wish to remotely debug.
Ensure that the remote debugging profile is selected.
Set the build output to the network share on the remote debugging computer.
Set the remote debugging host address and port.
Does this mean I have to copy the built exe to the remote computer
manually every single time when I build the project?
Yes.
Is there any way to make it work easily just like the Windows Store
apps?
You can create a post-build event in which you can do practically everything. In this case you can set up a xcopy/robocopy command which would copy the stuff to a network location.
Possibly a third-party extension or something?
Don't think so.
Is there a way to set up Remote Debugging (Msvscom.exe) on a machine that does not have Visual Studio installed?
I would like to attach to the service running on the VM so I can debug an issue in the code. I've done this before but both machines have had VS installed.
The Dev box is running Visual Studio 2010/Windows 7. The VM is running Windows 7 without Visual Studio.
I'm going to resurrect this because anyone who's tried to do this knows it's a complete pain in the ass every time, and that it changes slightly with every possible combination of host/remote system you can have.
Visual Studio Remote Tools Links:
Visual Studio 2010 remote debugger. (Working as of 21/Oct/2016)
Visual Studio 2013 remote tools (working as of 21/Oct/2016)
Visual Studio 2015 remote tools x86 - Direct download link
Visual Studio 2015 remote tools x64 - Direct download link
Visual Studio Tools (Thanks Robo Burned)
Visual Studio 2017 Remote Tools x64 - Direct download link (Thanks Isaac Baker)
Visual Studio 2017 Remote Tools x86 - Direct download link (Thanks Isaac Baker)
Visual Studio 2019 Remote Tools - download link
This is the setup I succeeded with today:
Host (Dev) Machine:
Windows 7 Ultimate SP1 x64. Running Visual Studio 2010, .NET Framework 4.
Remote Machine:
Industrial/Factory Floor PC running Windows Embedded Standard 32-bit. It looks/feels exactly like Windows 7. Running SP1. Visual Studio is not installed. Has the .NET framework 4.
Network:
Both machines are on the same subnet. I access the remote machine via RDP and run my application that way.
Microsoft-Proprietary Follicle-Deterioration Implementation:
Make note of your dev machine's user name and password. For some reason you have to create exactly the same user name and password on the remote machine. Because Microsoft.
How I did it:
I downloaded the Visual Studio 2010 remote debugger from the link provided by #sJhonny. I had to switch off of Visual Studio 2013 in that article and over to 2010. If you care to go over the 2010 article with a fine-tooth comb to find the download, the link is right next to the "No one ever finds this helpful" link at the top. If not, just follow my link above.
Install that on the remote machine and run the configuration wizard. I left the defaults for the wizard:
"Run the 'Visual Studio ....." was checked off
Username is LocalSystem and password is blank
Allow only computers on the local network....
Run the Remote Debugger on the remote system and you'll see
Msvsmon started a new server named 'username#machinename...'
in the interface. So far so good. Run the application on the remote machine. On the dev machine, Ctrl+Alt+P in visual studio will open "Attach to Process" (It's also under the tools menu). I got a popup about my dev machine's firewall not being configured properly and was asked if I wanted to allow the connections etc... Say yes obviously.
Enter the 'username#machinename' combination into the qualifier box... press Refresh and pray a little. Pray a little more a lot harder and you should see a list of the processes running on the remote machine. Select your process and attach to it.
But my breakpoints don't work!? Of course they don't... because using the breakpoints in the same directory as the application on the remote machine would make too much sense. If you were lucky enough, you got warned about a breakpoint cache and got shown a dialog with a path.
The dialog mentions something about it being correct relative to the remote machine. It's lying. It has nothing to do with the remote machine except that it forced you to create a brand new user over there with the same name as your current user because Microsoft. To get your breakpoints to work, follow the path on your dev machine (customizable in Tools>Options>Debugging>Symbols: Cache symbols in this directory) and copy your application's .pdb files over to that directory. You have to copy them over with every new build, unless there's an option to do it automatically; I haven't checked because I have yet to stop celebrating my remote debugging success.
Everything should work now.
certainly there is.
You can install msvsmon without installing visual studio.
I've done this myself on several machines.
the tricky part lays in authorization- the user running VS on your local machine needs special priviliges on the remote machine.
ms has some articles explaining the details- http://msdn.microsoft.com/en-us/library/bt727f1t.aspx,
Update:
Here's the links for 2017 which are not obvious to find either.
Visual Studio Remote Tools Links x64 direct link
Visual Studio Remote Tools Links x86 direct link
Taken from:
how-to-implement-remote-debugging-in-visual-studio-2005
Let's consider an example to understand this situation clearly. Molly
Clark and Adam Barr are both employees at Adventure Works. Adventure
Works has a Microsoft Windows NT domain named adventure-works.com.
Adam is having trouble with some software that Molly wrote. Molly
would like to debug this software on Adam's computer. Molly and Adam
follow these steps:
Adam doesn't have the remote debugger on his computer. To set up the remote debugger, Molly decides to share out the Program
Files\Microsoft Visual Studio 8\Common7\IDE\Remote Debugger directory
on her computer. She creates a file share called Remote.
Adam runs \MollyComputerName\Remote\x86\Msvsmon.exe.
After the remote debugger starts, Adam clicks Permissions on the Tools menu to configure the remote debugger by using the Permissions
dialog box. He gives Molly permission to debug.
Note Adam could also configure the remote debugger by passing the /allow option when the remote debugger starts.
Molly starts Visual Studio 2005.
To open the Attach to Process dialog box, Molly clicks Attach to Process on the Tools menu.
Molly connects to Adam's computer by entering adventure-works.com\Adam#AdamComputerName in the Qualifier box.
Under Available Processes, Molly selects the worker process that her application is using and then clicks Attach.
Molly opens a browser and provides the URL to the remote application. The execution stops where the breakpoint is placed in
the application.
There's also another way which I prefer (if you have fast internet connection).
You don't have to download or install anything on remote desktop connection.
You can share your disk C: while connecting via Remote Desktop Connection.
On the remote desktop go to location (depending on your local location)
\\tsclient\C\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\Remote Debugger\x64
(optional) Create shortcut to folder or msvsmon.exe on desktop
Run it remotely from your local disk via shared disk. (start can take few seconds depending on your connection quality)
Option2: Copy Remote Debugger\x64 or x86 folder to the remote location and use it.
I was able to get it working with asp.net core 2.1, the only difference from the answers above was that the process you attach to is dotnet.exe.
I have a problem when I try to Run published Application. When I Run Release or Debug Version from VS (key F5) everything work well. So I try to publish my application (no problem). After this I Installed application by oneClick installer. Instalation was finished without problem, but when I try to run this installed application, I only see message: Program has Stop Working.
Please, does anybody know where should be a problem? It´s really wierd, I suppose, when the application run correctly from VS, then it Should run after installing to!? Or am I wrong?
Or is there some option to reset Publish settings in Visual Studio?
Thanks a lot!!!
It depends how you have ClickOnce setup, but the main reason this happens is the ClickOnce system encounters an error while checking for updates or running the .application from the remote location.
It should give you the option to see a log of the problem (or at least the nasty temp file it threw it in).
From here you can determine the problem ClickOnce is having.
Most Common Problems I would Suspect:
The User's having trouble communicating thier auth token / credentials to the web server the ClickOnce app is on.
There's another web-related issue downloading the app manifest or .application from the server
Group / Local Policy Problems
Broken install in on local machine's ClickOnce somewhere causing it to have problems overwriting on disk or finding an appropriate location to setup the clickonce package.
Broken install in on local machine's ClickOnce causing a GUID Conflict (I.e. your app and the broken install can't be upgraded, but share the same GUID)
Antivirus / Firewall blocking access to the web component from the executable clickonce deploy.
These are all the problems I've encountered with ClickOnce and the reasons we've primarily moved away from it to a Wix style installer.
I have been working on an application using .NET 4 and c# in Visual Studio 2010 Express. It's purpose is to watch a directory and import any documents it finds into our imaging system.
I included an installer class which provides the information needed by installutil.exe.
So to install locally, I build the solution, and then at command line:
installutil.exe MyProjectExecutable.exe
Which installs it as a service. This works fine in my development environment.
To deploy to the test environment, I use the same method:
installutil.exe MyProjectExecutable.exe.deploy
Except of course the executable has a second extension, .deploy. This is the way the application is published by Visual Studio. Everything works up tot his point
Here is the problem: once I have done this, I run the service and it starts properly, as indicated in the log file. However, once it detects files in the directory, the service will not do anything with them and will eventually crash. The only way I can tell it has crashed is to look in the windows Event Viewer. It will show the message:
"An unhandled win32 exception occurred in MyProjectExecutable.exe.deploy [4108]. Just-In-Time debugging this exception failed with the following error: Debugger could not be started because no user is logged on."
Two questions:
1) What could be causing this
2) Am I going through the correct steps to install a windows service, or is there a better way?
Both environments have .NET 4 installed.
In both environments I am placing the same documents in the import directory.
In both environments the service runs under the Local System account.
If my question reflects a lack of C# experience, my apologies in advance.
subscribe to AppDomain.UnhandledException Event
Are you watching a directory under 'Documents and Settings?' You mention that you're running under Local System, but is that in the C# code or in the Services Panel?
Start->Run
services.msc
< Find your App >
Right-click, Properties
Log On Tab
Log On As
This Account
< Plug in a user / pass with permissions >
In my experience this it is always a security problem. Check the rights that the service running user has. Can it access the folders you are monitoring and make the needed changes?
I have found the problem. in the config file, the listen directory was "c" whereas it should have been "C". Until now, I didn't think Windows was case-sensitive. Thanks for the help guys.
I am trying to remotely debug wcf service on IIS 6. It has been working fine until yesterday. Now breakpoints are not being hit and warning message says "No symbols have been loaded for this document". I've solved this by restarting iis and app pool, but it worked just for a few days. Now I have the same problem. I've read almost all advices on the Internet about this, I've checked build options, GAC, ASP Temporary folder. When the service file is loading the VS is writing that my dlls is loaded. But when I looking at the debug->modules window it shows that this modules haven't been loaded. I still can see exceptions while debugging. Now I am temporarily using Debug.WriteLn() for debugging, but it takes a lot of time and effort. Any help will be appreciated.
P.S. I use VS 2010, WinXp Sp3 on my PC and Windows Server 2003 on server.
[Updated] Is there any patches for VS 2010 that can fix remote debugging problem ?
[Updated] I've noticed that w3wp process type is x86 now, although my service was called by client before and it should be managed type.
Finally, I 've found a solution. I copy my WCF output files to the same location on the server as in my pc. It is quite wierd but debugging works perfect.
Here is your answer, and the issue I ran into:
I've noticed that w3wp process type is x86 now, although my service
was called by client before and it should be managed type.
Typically to get the w3wp.exe process to actually show in the Attach to Process debug dialog is to just browse to a site in IIS locally. This will spin up that process and make sure it is available to select.
However, you must browse to a site using the same app pool type as the WCF service you want to debug. If you select an app pool using a 32-bit process (x86) and attach to this for a WCF service expecting a x64 version, the resulting "No symbols have been loaded for this document" will be displayed and breakpoints will appear as 'hollow' red circles.
First: Please Install IIS 7, its much recommended!
2nd: it happens sometimes with everyone I guess, deploying the service again with the options (Delete existing files (checked), with source code (checked) ), resolves the problem.
Actually that's the only solution is working in my case
Regards,
Mazhar Karimi