Massive cpu from diahost.exe

Question

All morning my machine has been working hard on some long-running task within the diahost.exe. (Some portion of the integration runtime)

Based on research within procmon, it looks like it is accessing an msi file or something. Perhaps it keeps trying and failing to upgrade? The cpu goes up and down a bit.

There are no notable failures in the Application log or in the Integration Runtime log. My machine is Windows 10.

The Microsoft Integration Runtime is installed for the benefit of ADF
Installed 5/27
version 4.9.7441.2

My next attempt to solve this is to stop and disable the Integration Runtime Update Service. I assume it is having problems. (although, based on the event logs it doesn't realize that it is having problems).

Any help would be appreciated. I can't afford to be wasting all that CPU. Is it common for this "integration runtime" to be misbehaving? Is the event log the right place to receive notifications when there is a problem? Does anyone else have this problem?

Thanks, David

Answer 1

I think I found the related message. It gets part-way thru the upgrade and then stops.

As you can see above, there is a simple (informational) event in the log that says it won't install due to space. It wants 10 GB and doesn't think it has that. (despite the fact that my C: drive reports as having 12 GB free).

I think it would be better if these upgrade failures were reported as errors rather than information. Also it seems odd to me that the upgrade attempts were so persistent, running over and over again without taking a breath. Maybe one attempt per hour (or day) would be sufficient? It is unfortunate that it consumes so much CPU during its continuous attempts.

I will try to clean up some space or move this stuff to another drive. Thanks for taking a look.

...Side question - do you know why Microsoft (and friends) say this service can't be run on a machine being used for the Power BI gateway? It seems like the two of these services are two peas in a pod. They essentially accomplish the same thing (tunnel data out of the organization into azure). It is odd that we couldn't build one integration VM and run them both, provided there is sufficient CPU and network available.

Answer 2

I disabled the Integration Runtime Update service and that seems to help. I don't see diahost.exe hogging cpu anymore.

Obviously it isn't a long term solution, but maybe the ADF guys can fix this before I need another version of the integration service.

Answer 3

Yes, if the update service is running, it consumes CPU all day.

Above is the CPU. The humps are due to this service.
In procmon I see that an msi is being read from a directory over and over:
C:\ProgramData\Microsoft\Data Transfer\DataManagementGatewayUpgrade\Version\4.9.7445.1

The upgrade service runs as DIAHostService.

It doesn't write status or diagnostic information to logs on disk or to the event log either. There is no way to tell what it is doing.

Answer 4

The ADF instance name is DKBADF and the integration runtime name is DkbIntegrationRuntime24651.

Can you test this on your side and see if that msi gets accepted and applied?

Should I just uninstall the integration runtime and reinstall? Is that how others are doing it? I'm new to ADF and confused by why I'm running into problems so quickly. I'd rather be using this the same way as everyone else.

Do you know whether this update service is auditing any of its activity to disk or to the event log? It seems to operate quietly without any way of troubleshooting. Ideally it would tell us what it is trying to accomplish and why it is failing.

Answer 5

I have done some looking on my side. Thank you for telling me the details.

At the moment, I have the same version number as you (4.9.7445.1).

During the last actual update installation, I was able to locate some logs of the process. Below is picture of the steps to find them. The actual log pictured is not from my last upgrade.

First, open the Integration Runtime app

1. Click view logs
2. View the Integration Runtime instead of its connectors
3. Use Find to search for 'up' as in 'upgrade' / 'update'.

There is another log, which seems more related to
C:\ProgramData\Microsoft\Data Transfer\DataManagementGatewayUpgrade\Version\4.9.7445.1
than to
C:\Program Files\Microsoft Integration Runtime\4.0\Upgrade

C:\ProgramData\Microsoft\Data Transfer\DataManagementGatewayUpgrade\Activity\<some_uid>\autoupdate_install_<some_datetime>

There are multiple uid folders, so sort by last-modified-date and look inside.

If that does not help, please open a support ticket for a deeper dive. If you do not have a support plan, I can provide a 1-time support ticket.
They will ask for the Factory and IR details you shared with me, also the logs (click the "send logs" button seen in above picture), and the other log I helped you locate.

Please send me an email at azcommunity@microsoft.com with the below details, so that we can create a one-time-free support ticket for you to work closely on this matter.
Thread URL: https://learn.microsoft.com/en-us/answers/questions/32613/index.html
Subscription ID: <your subscription id here>
Subject : Attn MartinJaffer-MSFT

Let me know when you send the email.