I've been refactoring some code which was previously working.
Now when debugging I get to a break point in the refactored code and when I step into the Property in question I get a message saying that Windows firewall is currently blocking remote debugging.
It doesn't make sense because the application is a console application being debugged through visual studio on my local machine. I am using VS2010 and .net 4.0.
Does anyone know why vs might be trying to remote debug?
what does your code do? does it access any external files and or databases?
It could also be an administratrion issue, try rightclicking VS and run as admin first off and see if that fixes the issue.
secondly trace your code and see if there is any links to externals, and thirdly go to windows firewall and change the settings to allow access to Visual studios~ and or databases/.net instances.
Related
I've upgraded my Windows to 10.0.16299 (latest) and my Visual Studio to 15.5.1 (latest). Since then, I am seeing this error message when I clean or build my Xamarin solution containing an Android project:
obj\Debug\android\src\android\support\customtabs\CustomTabsClient_CustomTabsCallbackImpl.java:4:
error: error while writing CustomTabsClient_CustomTabsCallbackImpl:
obj\Debug\android\bin\classes\android\support\customtabs\CustomTabsClient_CustomTabsCallbackImpl.class
(The process cannot access the file because it is being used by
another process)
I figured that the locking process is Visual Studio itself after I tried to run and debug the app.
The issue appears no matter whether I want to run the app on an emulator or a connected real device.
There's lots of advice what to do when a process locks a file including SO such as the famous the process cannot access the file because it is being used by another process. However, all provided answers don't help as Visual Studio itself locks the file and the only workable workaround is to restart Visual Studio - that's not a solution.
What is causing this file to be locked? Any idea? Any advice?
Sometimes it helps to kill the MsBuild.exe. Also, you could find other solutions such as described here: Xamarin Android project cannot build....
Basically, it seems to be a problem with Studio 2017 Version 15.5. It will be fixed with the next versions probably.
Darn it, my suggestions won't fit in the context of a comment, so here goes:
Sounds like the process being debugged, or the emulator hosting the debugged process, itself, has not fully closed down, and is in a hung or semi-hung state. Have you checked the process manager to see if this is the case? You may want to to try adding Environment.Exit() to see if this helps come back to a good state.
Another thing to check is, whether your access levels are the same between the two machines. Check not only the PC, but also at the emulator as well. Check everything, and ensure the access levels/modes are identical.
Finally, try running VS 2017 in administrator mode, and see if the problem persists. It's entirely possible that the level of access that you used to run pre-Windows 10 is different in the Win10 world that you live in, now.
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. =\
Currently I debug my C# application locally and use watch, breakpoint and commands like step into and the debug inspector.
setup remote debugging with another machine as described here: http://msdn.microsoft.com/en-us/library/bt727f1t.aspx
Is it possible to see the source code of remote application and go through it step-by-step as one can do locally?
Yes, you can. Just make sure that your symbol files (your .PDB files) are deployed remotely with your application.
Yes. Attaching to a remote process is just the same as attaching to a local process.
So I have an unmanaged C++ dll which I am calling from my ASP.NET application, it has a single entry point and a couple of structures for passing data. If I create a C# console app to call the dll it works fine. If I hook it in to my asp.net app running on my local WinXP machine (IIS 5.1) then it works fine.
When I publish it to our development environement which is running Windows 2003 and IIS 6 then the first 1 or 2 calls works fine but then it simply stops responding. I'm getting no error messages, warnings etc... but I am fast running out of hair!
I've set the virtual directory which runs the asp.net app up inside of its own application pool but this seems to have had no impact. Any help would be greatly appreciated.
Cheers
What do you mean when you say that it stops responding? You could try putting logging statements that would trace the input/output around the call to see where exactly it blocks. Also make sure you check the server Event Log where unhandled ASP.NET errors are written. As a last resort you could install Visual Studio remote debugging tools (msvsmon.exe) on the server and step through the code by attaching to the corresponding w3wp process. Actually the debugging tools doesn't require installation, a simple copy is enough (C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\Remote Debugger).
The failure appears actually to be with the C++ code itself, it has some code to handle locking for a threaded environment and this appears to be failing. Not sure why it works on my local machine and not the dev environment but that's another question.
Thanks all
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