Visual Studio 2013 update 3. I have deployed several Webjobs to Azure, both manually (upload a bundle via the portal) and also published directly from Visual Studio. The webjobs I am testing with are set to run "Continuous" and have code that runs inside a while(true) {} loop; so the process never ends. The webjobs are functioning properly and I see their runtime output in the Webjobs dashboard log output screen.
I've enabled remote debugging on the website. When I select Debug, Attach to process, the webjob process names never show on the list. All I see are the remote debugger processes and w3wp.exe.
Ideas?
Instead of attaching to SITENAME.azurewebsites.net, try to attach to SITENAME.scm.azurewebsites.net. Use same credentials as for the regular debugging connection. WebJobs run under a different context (Kudu), hence the different endpoint.
Related
I'm trying to get application insights to work in azure batch job/task while running through a .net core 3.1 console application.
When I run the console app through Visual Studio debug or directly on a node in the batch pool, I get all the appropriate telemetry and logs. However when I setup a task to run the console app I'm not getting any data in application insights.
Guides I looked through:
https://learn.microsoft.com/en-us/azure/batch/monitor-application-insights
https://learn.microsoft.com/en-us/azure/azure-monitor/app/worker-service
https://learn.microsoft.com/en-us/azure/azure-monitor/app/asp-net-core
Is there anyway to get the AppInsights data when running the console app through the task?
edit
I have added a TelemetryClient.Flush and Thread.sleep to the end of the process. I can now see explicit calls to TelemetryClient.TrackedEvents but I'm not getting any dependency information, such as SQL call, api calls etc.This only happens to calls made inside a Task. If the console application gets called through a regular command line all information is visible.
Probably the issue is that the console app closes before telemetry is sent. you'll need to explicitly call "flush" on the telemetry client/etc and wait some time to allow telemetry to be sent.
see: TelemetryClient produces inconsistent results in Application Insights
We have several Azure app services live and I've ran into a consistent problem when restarting any of them.
We've right-click -> Published from Visual Studio upto an existing instance of an App Service which brings it online and functional immediately, we can update and republish new code without a problem, but restarting to app service from Azure Portal doesn't launch dotnet.exe.
When restarting or stopping/starting, the thread count instantly drops to 0 and continues to do nothing.
I have to manually publish from VS again to reboot dotnet.exe.
I can see that dotnet.exe isn't an active process via Kudu -> Process Explorer, and manually publishing up to the App Service and then refreshing the Process Explorer list again shows that dotnet.exe is now an active process and the App Service begins to function as expected.
Is there a way to prevent this, or at the very least debug why it's happening?
As it turns out this is being caused by silent failures, outside of error handling I'd put in place. IIS would spin up the associated processes but dotnet would throw and error and "silently" die.
I use quotes because I'd failed to utilise Azure's indepth logging, which hid the error message from plain view until switched on.
For some basic debugging steps:
Open up your Kudu console (Advanced Tools -> Go -> Debug Console) and navigate to LogFiles, open up eventlog.xml, the latest events are listed at the bottom.
Run dotnet myDll.dll against your debug folder locally, where myDll.dll is the main dll in your project. This will typically throw the error causing dotnet to exit out, which wasn't obvious at design time.
Ensure that your server-side appsettings.json (or the associated appsettings.[development/release].json contains the connection strings you're attempting to access.
The errors that were occuring we'ren't due to design-time bugs, it generally fell over when trying to access run-time resources (such as appsettings).
I noticed I have multiple functions running but never ending because they never get to the context.done() call. (This is a NodeJS function).
How can I stop these running functions without having to delete the entire function?
Disabling the function in the Manage tab prevents it from starting more, but doesn't end existing instances.
Kudu doesn't give me access to TASKKILL.
You have the ability to simply restart the Function App site, which will kill any functions (Function App Settings > Go To App Service Settings > Restart).
If you are running on a dynamic plan, please make sure you have upgraded to the latest version of the runtime, as a timeout feature is now in effect and will prevent functions from executing indefinitely.
For automation purposes, you can use the Azure CLI 2.0 (local azure shell) which makes this so much easier than clicking around in the portal blades.
This also works in the portal cloud shell if so desired.
Option #1: Restart Entire Function App (via Azure CLI)
az functionapp restart --name <functionappName> --resource-group <resourceGroup>
You can also restart the function app by killing the running w3wp.exe process - there is a watchdog that will automatically restart it.
Option #2: Restart IIS Worker Process (via Powershell)
#powershell kill -name w3wp
Kudu will allow you to do this manually via Debug Console and entering the command above or clicking thru Process Explorer->Properties->Kill.
Note: Killing the IIS worker process is all that is required as any spawned child processes will also be terminated (dotnet.exe, node, etc.)
This is the order of clicks starting from the portal home page to restart a function app in azure:
-> Function Apps (Found on the very left-hand sidebar, or on dashboard)
-> yourFunction (mine is called 'myFunction')
-> Platform Features (found near the top right of the screen)
-> All Settings (found under the General Settings section)
-> Restart (found near the top of the screen)
It seems the portal has been updated as I couldn't find the Restart button using the given instructions.
As of 17/7/2020 you can restart a Function app by navigating to the App Service page then clicking the Restart button which is found in the Toolbar:
I have developed a custom timer job for SharePoint 2013 in visual studio 2012 which sends email notifications. The issue is that it works fine on development server.
I have followed the following steps to debug it on the development server 1.) Deploy the timer job on respective site. 2.) Restart the timer service in services.msc 3.) Then is do attach to process OWSTIMER in visual studio. 4.) And finally Go to SharePoint 2013 Central administration->Monitoring->Review Job Definition and click on the respective timer job and say run now.
After doing this the breakpoint is hit in visual studio at the Execute() method. So in the development server it is running.
Now on the production server I cannot debug using visual studio so I have deployed the packaged solution(.wsp).
I can see the feature is activated in Site Collection Administration-> Site Collection Features.
Now on the production server I follow the following steps 1.)Restart the timer service in services.msc 2.)And finally Go to SharePoint 2013 Central administration->Monitoring->Review Job
Further to test whether the timer job is working on production server or not I had used PortalLog.LogString("Flow test1"); at the start of the Execute() method. Now this runs on the development server and I see the message in the SharePoint logs but on the production server I can't see "Flow Test1" in the logs after I click Run Now in central admin.
Can anyone suggest what is the issue and a possible solution?
It seems to me that there are two issues:
You should use other way for logging LoggingService should be preferred way. Use WriteEvent to write to EventLog or WriteTrace to write to ULS log.
Running job. Be sure that Owstimer.exe service on all web servers are restarted (can be done by this powershell script). I expect that you have correctly scheduled your job either in your powershell script or in your feature receiver.
Here are a few things to try:
Go to Central Administration and run the timer job from there. Then go to the job history page and check whether it finished successfully or not. If there was an error, you should see the error message from there. That will give you a clue on whats happening.
As Mazin said, restart the timer service in all servers. After deployment, the DLLs are cached by the process and you don't see your changes reflected.
Browse the SharePoint logs and search for an exception or error. You can narrow your search by selecting the timeframe on which your job ran. You can use the following PS script:
Get-SPLogEvent -StartTime "02/02/2014 11:00" -EndTime "02/02/2014 13:00" | Out-GridView
As stated here it seems your job assembly is not deployed in the GAC. Verify that the assembly is present there.
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.