I'm getting crazy with Visual Stusio 2015 remote debugger.
What I want:
I have running a .Net console application on a Azure VM.
I want to remote debug my application and make some performance measure.
What I've done so far:
Application was compiled in debug mode and is running on the remote machine.
Over the Server-Explorer of VS2015 I added the Remote Debugger extention to the VM. Firewall on the VM is down for testing. Tested on two devices with the same result.
What I get:
I select my VM over the Server-Explorer and choose 'Attach debugger'.
I select my process of my running application (yes all processes running are shown).
Then after a few seconds I get the great error window 'Not implemented'!?
Where I need help:
Does anybody have a similar problem? Where can I find an error log to get more information on whats going on?
Further
I also created a Connect entry for this (Thanks for the hint #Vova). So if you have the same problem you can upvote it. Microsoft Connect
I'm thanksfull for every help. Greetings Steffen
According to Microsoft Connect guy (Eliver) its a bug. It only effects Visual Studio 2015 with display language other then english.
Solution 1
Wait for next Azure SDK release with fix inside
Solution 2
Install english language pack from here and switch ths VS language to english from option dialog.
Update - 2015-11-21
I just wanted to let you know that the Azure SDK 2.8 has been released and this bug I'am facing have been resolved in this.
https://azure.microsoft.com/en-in/blog/announcing-the-azure-sdk-2-8-for-net/
Related
I have my development environment as follow:-
Visual Studio 2012 Professional. version 11.0.50727.1
Windows Server 2012 R2.
asp.net mvc4 web application.
now since last week i am facing these problems:-
when i run my asp.net mvc web application inside visual studio, i will receive the following error, when i access my asp.net MVC home page:-
500 Internal Server Error
after many runs, the CPU will reaches 100% and my development machine will automatically get restarted. now i check with our system admins and they mentioned that the VM got restarted because of high CPU...
so i am not sure if the problem is within VS 2012 , or within the VM itself.. baring in mind that the VM host some test applications inside IIS,, and we can access these application without any problem. also i can open the sql managemnt studio and work with the DBs without any problem. so before asking to expand the DEV machine specifications to avoid high CPU , i want to make sure that the problem is not within Visual Studio itself ??
here is 2 screen from the server manager after the VM got restarted :-
now i am not sure how i can fix this?
Thanks
The 500 Server Error is the standard error report from IIS if an MVC application throws an unhandled exception. So your code inside your MVC application is faulting somehow.
If this occurs you would normally run your site in debug mode in Visual Studio to trap the exception and debug out the problem. I have not idea what your application actually does but I can speculate the following possible cause;
1) IIS receives your call.
2) The MVC code generates a high CPU load doing some faulty code.
3) The calling application times out its HTTP call, and calls again.
4) Another IIS Instance is created to deal with the new HTTP Call (depends on your IIS Setup)
5) The second IIS instance does the same as (2) but in a different thread, causing more resource consumption.
Eventually you get a 500 server error as one of your IIS instances times out or throws and exception. Your "helpful" sysadmin kills your VM.
The killing of the VM is entirely uneccessary - IIS has perfectly adequate safeguards against runaway IIS processes, including IIS Application Pool timeouts, automatic IIS Application Pool recycling, IIS Application Pool CPU Throttling, and IIS Application Pool maximum memory usage. All of these configuration options prevent the operating system from being destabilised by a runaway IIS application.
Without any insight into what your website does in the background we cannot go any further, but if you mod your question and give some of the MVC code its possible something might be spotted.
I had a similar error with Visual Studio 2013. The error turned out to be one my Addins. If you are using add-ins, try disabling the suspected plugin from the Tools --> Add-in Manager..., then restart Visual Studio. If you are using extensions try reviewing those as well from Tools --> Extensions and Updates...
You can optionally choose to run Visual Studio in Safe Mode which will essentially do the same thing but will disable all plugins. devenv.exe /SafeMode
Hope this helps.
I had some similar issue in Windows Server 2012 running Visual studio 2012.
Upgrade your Visual studio and Windows server both. It will solve the issue
So, I have a question someone here may know the answer to... I am trying to debug and trace through some C# code on a remote Windows Server 2012 R2 with Visual Studio installed. I am using a Debugger.Launch() call to hook into the program and Visual Studio properly launches and shows me the proper break point.
However, once I try to step-in, step-over, or even just resume execution, the entire server crashes and reboots. There is absolutely nothing being recorded to explain what the problem is in the event log other than the usual 'previous reboot was unexpected' message. This problem happens regardless of whether I try to debug the application as a console application or as a Windows service.
The server is being accessed via Remote Desktop and the source code files are located on my local drive (e.g. "\tsclient\X\path\to\source.cs"). I've already scoured the web for a few days trying to find anything and everything that might help but I have not found anything that helps. I have even tried to make sure that VS is excluded from DEP and that did not change the end result either.
This is happening with Visual Studio 2012, 2013, and 2015 (all with the latest updates applied). In addition, all Windows Updates have been applied to the server. The strangest part is that this was all working as of about a month or two ago when I needed to debug a different application.
So gurus of stackoverflow, does anyone know a) what would cause this and b) how to fix it?
eG
EDIT: Fixed path example which didn't like angle brackets. =\
This is my first application I have ever released. I built it with Visual Studio Express in c# using winform application.
I'm fairly new to this and I can't manage to find an answer to my problem.
When I try to open (launch) my application on various other computers I get a "Winformapplication has stopped working" and the application does not start. I have tried to include all the resources I use in the folder but still couldn't make this work.
Strangely enough, the application works on all the computers I have Visual Studio installed (at least I think so). It worked as well on a random laptop I tried it on and it does not have anything special I could figure out (no VSE installed).
So my question is pretty simple : how do I make this work ? what am I missing ?
I can provide more information about the application itself if required.
Thank you a lot.
edit: removed code as it was not relevant.
My error came from : "'Microsoft Office 12.0 Access Database Engine OLE DB Provider' Provider is not registered on the local machine.
A temporary fix would be to install 2007 Office System Driver: Data Connectivity Components as stated on this thread.
Thanks for the help everyone.
I'm still looking for an alternative though.
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'm working with a handheld device running Windows CE 5.0. The program runs, however I'm not able to debug and hopefully its something simple and stupid burried in project settings somewhere.
So, as to not mess up the main app, I decide I'll start a brand new SmartDevice application. So MS builds its default settings, environment, path for the new project and defaults it's first form "Form1". I shrink the form up some and put a single button on it with code in its CLICK event for "This.Close();"
Compile and try to debug and it comes up with the empty circle with warning triangle icon...
"The breakpoint will not currently be hit. The specified module hasnot been loaded."
What's up...
To answer Bryan's question... I'm connected via USB via ActiveSynch 4.5 the other programmer in our office uses the same configuration for debugging but he's out of town this week and I've been tasked with some review of processes.
Also, I'm using Visual Studio 2005, not 2010...
It is possible your device may be "locked down" by the device manufacturer or the mobile operator making it difficult to debug a running application on the device.
MSDN has a great resource center on debugging Windows Mobile applications at:
http://msdn2.microsoft.com/en-us/library/bb158521.aspx
In the middle of the page you will find a note about default security settings and a link to an article titled "Deployment, Setup, Security and You".
You may want to sign your application before having Visual Studio deploy to it to your device. You can find more information about that at:
http://msdn2.microsoft.com/en-us/library/ms839681.aspx
Problem was the version of Compact-Framework SDK. I had to uninstall, re-install and put CF SDK SP1 in... Debug now working...