Archive for the ‘Vagrant’ Category

Take a load off Fannie – Chefdk, Rundll32.exe and constant cpu load

In Chef, DevOps, Packer, Vagrant, Windows 8.1 on February 4, 2015 at 21:59

If you like my content please do check out my new blog at ! 



First of all – quite some time ago I decided to move my blog to a new platform, a new server and a new domain. But for some reason that just didn’t work out. So I’m back here.

Luckily the personal change that motivated me to move my blog did work out – I’m still very happily employed at Schuberg Philis.

Secondly, after some hesitation, I’ve fully embraced both Chef and Ruby and quite honestly can’t quite imagine doing things any other way right now.

However even in a perfectly automated and continuously tested environment stuff still breaks. And  working with Chef and related technologies can be daunting – not in the least due to the cultural differences between a classic Windows environment and the Linux world where things like versioned configuration management and configuration mainly based on files has been commonplace for quite some time.

But that is not the topic of this particular post. When I was setting up my new Windows 8.1 laptop I ran into an issue after installing my development tools such as Vagrant, Chefdk and Github for Windows. After a while I noticed that my fan kept blowing and task manager showed that there was an average 25% cpu load ( so basically 100% on one logical core). The process consuming the core was rundll32.exe. I fired up process explorer and found out that rundll32 was loading aeinv.dll, with the parameter: UpdateSoftwareInventory. This pointed towards the Application Experience service.

The Application Experience service is basically the service that helps you when you run a program that has compatibility issues:




I disabled the service however that did not solve the problem. Every now and then the process would turn up again. So I checked some blogs and forum posts and found out that there a couple of scheduled tasks that are enabled and run even if the service is disabled and stopped. I triggered each service and found out three of them spawned the rundll32 process. So I disabled all three of them – problem solved.

Now how is this related to Chefdk? Well procmon showed that all the rundll32 process was doing was iterating over the c:\opscode folder and its children. Why? I’m not sure – at first I thought it might be the sheer number of files ( 41k files on my box to be precise) – but I’ve seen other users question that.

Anyway if you are faced with this problem – the solution is actually pretty simple and painless.

P.S. – was so kind to point out that only one of the three tasks actually causes this problem – the ProgramDataUpdater task. To me that name sounded  familiar – I’ve seen that task pop up a couple of times in VMware View and Citrix XenDesktop optimization guides as well ( one of them by Microsoft).

I’ve also seen some people associate this with MSI file checking behaviour  – maybe that’s something to check at some point as well.