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 have a client that is trying to run the Validate Customer Balances process in accounts receivable and the process does not finish. What tools are available to debug this?
First of all you need to determine whether the process finishes with an error or is simply taking a long time.
This process has a specific warning stating that balance validation takes a long time:
If you see the process progress indicator spinning, it's most likely just taking a long time. In that case you should either wait until the process finishes or follow the warning to select fewer customer.
If the processes finishes with an error indicator:
Open the trace window and run the process again, error details are usually visible in traces. For example, if you see financial period is inactive in traces then you can resolve it by going to the financial period screen and activating it:
Acumatica's T190 Quick Start In Customization and T270 Workflow API documentations describe the Debugging Process while working with Acumatica.
When you install a new Acumatica version, You must put the Install Debugger Tool checkbox.
You must open Visual Studio project as Admin.
To be able to debug the site's original source code, find web.config file of the Acumatica instance. Setting of Vistal Studio also must be changed as described in documentation.
Change the "False" value to "True".
Go to Debug->Attach to Process... or press Ctrl+Alt+P. Search for w3wp.exe, select the instance you needed and Press Attach.
Then put breakpoints and do debugging as you would do in any other project not related to Acumatica.
Do my Windows 10 App Backgroundtasks unregister while you update the app with the store?
Will the app deinstall and install or do I have to unregister my backgroundtask manual if I made a change in the backgroundtask registration?
Do my Windows 10 App Backgroundtasks unregister while you update the
app with the store?
No, according to MSDN, when an app gets updated, only running background tasks get canceled, not unregistered:
The background task was canceled because the application was updated.
You shouldn't need to register your background tasks again, however, it's not a bad practice to check for background tasks in the app startup and register any tasks that are not already registered. You can get list of the registered background tasks from the BackgroundTaskRegistration.AllTasks property.
However, if you want a background task with different properties/conditions, you need to unregister the old one and register the new one again, since you need a different background task.
I just stopped an Application Pool in IIS. When trying to start it, IIS complains that,
The service cannot accept control messages at this time. (Exception from HRESULT: 0x80080425).
What gives? Whence did this error come?
Looking at the Event Viewer > System shows these warnings:
A worker process '1456' serving application pool 'MyAppPool' failed to stop a listener channel for protocol 'http' in the allotted time. The data field contains the error number.
A process serving application pool 'MyAppPool' suffered a fatal communication error with the Windows Process Activation Service. The process id was '10592'. The data field contains the error number.
A process serving application pool 'MyAppPool' exceeded time limits during shut down. The process id was '10516'.
This resolved itself after about 5-minutes, at which point we tried to restart the website, and received:
The World Wide Web Publish Service (W3SVC) is stopped. Web sites cannot be started unless the World Wide Web Publishing Service (W3SVC) is running.
So, we started the W3SVC service, and then we could start our website.
This helped me: just wait about a minute or two.
Wait a few minutes, then retry your operation.
Ref: https://msdn.microsoft.com/en-us/library/ms833805.aspx
The error message could result due to the following reason:
The service associated with Credential Manager does not start.
Some files associated with the application have gone corrupt.
Please follow the steps mentioned below to resolve the issue:
Method 1:
Click on the “Start”
In the text box that reads “Search Program and Files” type “Services”
Right click on “Services” and select “Run as Administrator”
In the Services Window, look for Credential Manager Service and “Stop” it.
Restart the computer and “Start” the Credential Manager Service and set it to “Automatic”.
Restart the computer and it should work fine.
Method 2:
1. Run System File Checker. Refer to the link mentioned below for additional information:
http://support.microsoft.com/kb/929833
In my case, the VS debugger was attached to the w3wp process. After detaching the debugger, I was able to restart the Application Pool
I stopped the IIS Worker Process (in task manager), and then started the IIS again.
It worked.
I killed related w3wp.exe (on a friends' advise) at task manager and it worked.
Note: Use at your own risk. Be careful picking which one to kill.
Restarting the machine worked for me but not every time.
If you are really stuck on this then follow below steps
Open Task Manager
A window will open. Click on Details tab.
Search for the process name you wanted to restart/stop.
Select process, right click on it, select End task option.
A confirmation dialog box will appear. Click on End process button.
Now try to restart your service from Services.msc window.
I forgot I had mine attached to Visual Studio debugger. Be sure to disconnect from there, and then wait a moment. Otherwise killing the process viewing the PID from the Worker Processes functionality of IIS manager will work too.
Restarting the IIS windows service (World Wide Web Publishing Service) and then starting the application pool has worked for me. However, as the top answer suggests it may have just been the waiting that caused it to subsequently work.
I had this issue recently,
Problem statement:
Mine was a windows service that I run locally by attaching VS debugger. When I stop debugging and try to restart/stop the service (under services.msc) I used to get the mentioned error.
Solution:
Open up Task manager.
Search for the service (based on the exe name and not service name, for those that are different).
Kill the service.
On doing the above the service is stopped.
Being impatient, I created a new App Pool with the same settings and used that.
I kept having this problem whenever I tried to start an app pool more than once. Rather than rebooting, I simply run the Application Information Service. (Note: This service is set to run manually on my system, which may be the reason for the problem.) From its description, it seems obvious that it is somehow involved:
Facilitates the running of interactive applications with additional administrative privileges. If this service is stopped, users will be unable to launch applications with the additional administrative privileges they may require to perform desired user tasks.
Presumably, IIS manager (as well as most other processes running as an administrator) does not maintain admin privileges throughout the life of the process, but instead request admin rights from the Application Information service on a case-by-case basis.
Source: social.technech.microsoft.com
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.