I am trying to debug an IIS Web Service using remote debugging. Because of our domain configuration (which we CANNOT change) I get an Access is denied when remote debugging via the Default option. The only solution I've found is to switch to Remote (Native only with no authentication) option in VS 2008.
The problem is that when I connect to the remote system the w3wp.exe is grayed out and oddly enough it's the only one in the list that is. Does this have to do with the Remote choice? Is there a way around this?
I actually solved mine problem. The w3wp.exe was grayed out because I had installed Debug Diagnostics Tool on the server machine and set it up to follow IIS for crashed. Even though the program was not running it still had the "marked" the process for debugging (This might be totally wrong assumption). After removing the "markers" I could attach to the process.
So check out your services/programs if something is already attatched it self to the process. Does not solve the problem of not beeing able to debug managed code at all.
When you switch to "Native only with no authentication" mode, you're explicitly saying that you only want to debug "native" i.e. Win32 code, rather than .net code. There is, unfortunately as far as I'm aware, no way around this (I've tried! :().
Related
I'm trying to debug Azure Function scripts locally, in conjunction with Unity, but getting Timeout errors every time.
I have a few things here, and I'm not sure which one is actually causing the problem... It might be a settings on Windows, as oppose to one of the softwares.
I'm building in Unity 2019.4, and and using PlayFab and it's ability to use Azure Functions. When I try to execute scripts from the Azure servers, it functions correctly. But when I try to run it with Local Debugging, I get WebException: The request timed out System.Net.HttpWebRequest.GetRequestStream (See full error below).
Here's what I'm doing to setup:
Set PlayFab to Local Debugging (via VS Code Extension)(and confirming the json file is made in the temp folder)
Install Azure Functions Core Tools from Here
Start Azure Functions debugging from VS Code (terminal output shows that the the localhost is running it correctly)
Timeout error references the correct address http://localhost:7071/api/CloudScript/ExecuteFunction as confirmed in the VS Code Terminal when the AzFunc debugging is started.
When I clone the project to my MacBook Pro, everything runs smoothly in local debugging.
So, because of this, I've tried checking to make sure ports aren't blocked via PowerShell: netsh firewall show state,and told Windows Defender to not block anything from Unity or Code. When I run Netstat -ab in PowerShell/CMD, I do get:
Can not obtain ownership information
TCP 0.0.0.0:7071 DESKTOP-COMPUTER:0 LISTENING
[func.exe]
TCP 0.0.0.0:7680 DESKTOP-COMPUTER:0 LISTENING
I don't know if this is a problem, or normal...
I don't even know what else to check for. This problem is beyond me. If anyone knows the solution, or can point me in right direction, I'd be very grateful!
Below are the two errors from the Unity log whenever I execute an Azure Function script through PlayFab while local debugging:
WebException: The request timed out
System.Net.HttpWebRequest.GetRequestStream () (at <14e3453b740b4bd690e8d4e5a013a715>:0)
PlayFab.Internal.PlayFabWebRequest.Post (PlayFab.Internal.CallRequestContainer reqContainer) (at Assets/PlayFabSDK/Shared/Internal/PlayFabHttp/PlayFabWebRequest.cs:319)
Rethrow as WebException: Timeout: WebException making http request to: http://localhost:7071/api/CloudScript/ExecuteFunction
UnityEngine.Debug:LogException(Exception)
PlayFab.Internal.PlayFabWebRequest:Post(CallRequestContainer) (at Assets/PlayFabSDK/Shared/Internal/PlayFabHttp/PlayFabWebRequest.cs:332)
PlayFab.Internal.PlayFabWebRequest:WorkerThreadMainLoop() (at Assets/PlayFabSDK/Shared/Internal/PlayFabHttp/PlayFabWebRequest.cs:252)
System.Threading.ThreadHelper:ThreadStart()
Timeout: WebException making http request to: http://localhost:7071/api/CloudScript/ExecuteFunction
UnityEngine.Debug:Log(Object)
DemoScript:onPlayFabError(PlayFabError) (at Assets/PlayFabPartySDK/Examples/DemoScript.cs:264)
PlayFab.Internal.<>c__DisplayClass30_0:<QueueRequestError>b__0() (at Assets/PlayFabSDK/Shared/Internal/PlayFabHttp/PlayFabWebRequest.cs:395)
PlayFab.Internal.PlayFabWebRequest:Update() (at Assets/PlayFabSDK/Shared/Internal/PlayFabHttp/PlayFabWebRequest.cs:480)
PlayFab.Internal.PlayFabHttp:Update() (at Assets/PlayFabSDK/Shared/Internal/PlayFabHttp/PlayFabHTTP.cs:364)
Okay, TLDR: The answer to the problem is that not everything was updated. So, update everything if you're experiencing the same problem.
More specifically in my case, the "Visual Studio Code Editor" asset in Unity's Package Manager.
I just wanted throw this out there in case anyone has a problem like this in the future. It may not be the same specific thing that needs upgrading, but search around for everything involved and make sure it's updated. Not just the big, obvious things (like Unity or your IDE). Thankfully for me in this case, the update was starting to cause other problems, and after much headbanging trying to solve those, I came across it.
Good luck, future fellow idiots!
I wrote a classic ASP script (.asp) for a customer a while back. it was running on IIS v6.1 Windows 2003. The customer contacted me and said they had a catastrophic server failure and restored from backup but my script isn't running now. I logged onto their server to check it out and IIS is serving the file (I am prompted to save when I browse to the script) but not executing the script.
Several people's hands were in the server before they called me, I think this is probably a simple config setting someone tried before they figured out how to enable the "ASP" web server roll feature. But for the life of me I can't figure out how they did it. this is obviously not the default behavior. If I was trying to get this behavior I would add the .asp extension to the MIME types, but I checked and it isn't there.
What could cause IIS to serve the source of the ASP script without executing it?
Based on your question I am assuming your restored server is also windows server 2003 ... in that case you will go to the file\folder and the permissions and select execute permission to enable a server side script processor to handle that request. Been almost a decade that I have touched a 2003 server so I can’t give you the exact steps ... but, you want to enable script permissions on that folder(I think, don’t remember if it’s granular enough to drill down to a file). Also, why on earth are they still running server 2003? Is that version even supported yet?
If it’s IIS 7, you want to make sure your app pool is in Classic ASP mode first off. Then go to site and then the handler mapping section, click edit and configure it that way.
I have set two websites in my IIS 8.5. I have one for production version and one for development (need this for the team work purposes). The structure is simple. Website is simple static page using BackboneJS and API calls to get all the data. All virtual paths and applications were set at the beginning manually by my self. For some reason some API calls didn't worked in dev site. I found out the physical path to the API project has changed. Do you have any idea, where can be the problem? Actually some of my collegues face this issue too.
Only think that cames to my mind is that when bdebugging the API, I use "Attach to process" in Visual Studio, where I connect to the correct IIS process - w3wp.exe with user name IIS APPPOOL\Dev or IIS APPPOOL\Prod according to the site I'm debugging.
Nevertheless I don't think the path should change itself. Where can be the problem? Does anyone have any idea how to prevent this strange behaviour?
I am trying to launch a remote performance and diagnostics session on my Surface RT machine in Visual Studio Express 2013 by selecting Debug -> Performance and Diagnostics. However, I get the following message:
Diagnostics session failed to start.
Unable to connect to the Microsoft Visual Studio Remote Debugging Monitor named '192.168.11.43:4018 (< device name >)'. Connection request was rejected by the remote debugger. Ensure that the remote debugger is running in 'Windows Authentication' mode.
OK, fair enough, so I change the remote debugger to Windows Authentication mode, but no matter what I do I can't authenticate because my PC and tablet are on different domains (that is the way it seems anyway). The tablet is running Windows RT, of course, so it is impossible to change the domain. I have tried to start the remote debugger from the command line using the -u switch with the username and domain from my PC but that was no good either since the tablet can't authenticate it. I also tried to join the tablet's domain on my PC using the script from this answer but I don't get a successful return value (the return value is 5).
Most of the blogs I have come across say "just save yourself the trouble and switch to 'No Authentication' mode" which is what I did in the first place, but the diagnostics session refuses to run this way. What hoops do I have to jump through to get this to work?
Unfortunately I don't think you can get this to work on an RT. Our team has Pros for exactly this reason. Not being able to join a domain is the killer. :(
I now have my Windows Azure environment set up so that I can access my Worker Role with Remote Desktop. However, I'm not sure how to proceed at the moment. After much digging I found a web site that was offline but in Google's cache there was mention of attaching to the Worker Role running in the Azure Cloud from the Visual Studio debugger. But I only have Visual Developer (not studio) 2010 and I have searched all over and as far as I can see there is no such option to attach to a remote server. I am able to publish my project to the Azure Cloud without error and I have a "healthy" instance of my Worker Role showing as active and running.
I did connect with RDP through the Azure Management portal. The login worked fine and up came the remote desktop window. I searched through much of what I could find and was unable to find my Worker Role. I must have the wrong impression of RDP, because I had hoped to see the Worker Role's main display form when I logged in, just like I do when I debug it locally in the Cloud Emulator. But instead all I saw was a blank desktop with some base level server inspection and management routines. I even checked the Event Viewer for Application related messages and saw none.
So now I'm stuck wondering if my Worker Role is actually running or not, despite the seemingly positive status messages from the Management Portal, and I still want to attach to my Worker Role for debugging through Visual Developer, if it's possible, but I am unable to figure out how.
Anyone with experience in this area that can give me some solid tips on what to do next, please respond.
UPDATE: I believe my worker role may be running because I opened a command window and did a Netstat and saw it listening on the correct port. However, that may just be my Worker Role shell class that starts the custom EXE I have it launch as a spawned proces. I still haven't confirmed if my custom EXE is running yet.
UPDATE-2: Just ran TaskList from a command window and the custom EXE is listed.
UPDATE-3: Everything is working as I just ran a remote test of the service so that's not a problem. Still want to know how to attach to the Worker Role from Visual Developer 2010 for remote debugging, and if it's possible to see the custom EXE's display form like I do when doing local debugging in the Cloud Emulator.
-- roschler
There is a set of articles here which goes in length on how to set up for remote debugging in Azure:
http://blogs.u2u.be/peter/post/2011/06/21/Remote-debugging-an-Azure-Worker-role-using-Azure-Connect-Remote-desktop-and-the-remote-debugger.aspx
http://blogs.u2u.be/peter/post/2011/06/24/Remote-debugging-an-Azure-worker-role-using-Azure-Connect-remote-desktop-and-remote-debugger-part-2.aspx
http://blogs.u2u.be/peter/post/2011/06/26/Remote-debugging-a-Windows-Azure-Worker-Role-using-Azure-Connect-Remote-desktop-and-the-remote-debugger-part-3.aspx
The key takeaway is that you don't need to actually install Visual Studio on Azure, you only need to copy the Remote Debugger bits and then use Azure Connect to add your developer machine to the Virtual Network.
You can setup Remote Debugging with Visual Studio 2012
http://code.msdn.microsoft.com/Remote-Debugging-Windows-dedaaec9
When you say:
But instead all I saw was a blank desktop with some base level server inspection and management routines.
this is exactly what you get with an Azure VM. It's a basic OS install, plus the bare minimum of Azure stuff it needs to run and the code you've uploaded. There's no fancy monitoring or health checks available on the machine by default, you're expected to have provided those yourself to have them available without having to RDP into the machine to check on it.
RDP is very good for tracking down certain problems, like checking that a startup task will run, checking which directories items are installed in and just generally being nosey. If you need extra tools to track down a problem, you can just install them while you're connected to the server. For example I have RDPed into a server and installed the Microsoft Debugging Tools, to track down a memory issue.
I suppose you could remote into your VM, install Visual Studio there, and debug the process...
I also suppose it might be possible to enable remote debugging (not sure what's involved there, but such a thing exists, and it works over TCP) and debug from a local instance of Visual Studio.
To my knowledge, neither is commonly done.
Based on other answers, you would be better off writing a log file to a local storage. You can read the file from RDP if you reallyhace to. Keep in mind, debugging on Azure isn't really simple, and rightly so.
What I was thinking though was, maybe you could run the process using the user's credentials. I can't verify at the moment, but you have a better shot of seeing the ui when you rdp.