Force Run .Net Runtime Optimization Service before boxing

[kensykora]

Since I have to work on other stuff today, I'm dropping in notes for a few issues I'm planning on working on over the next week or so, but someone else can feel free to jump in and let me know if they're not great ideas or not:

Each time the box starts up from a fresh init, the .NET runtime optimization service pegs the CPU for what seems like 10-15 minutes which is a background task with low priority that compiles/optimizes the .Net framework for the current CPU type. This process can and should be forced to complete before the box is packaged up so that users don't have to deal with the CPU pegs on fresh init's.

http://support.microsoft.com/kb/2570538

[dylanmei]

I've seen this myself. According to the article

Important Run these commands immediately before you apply the update. Otherwise, these commands are less effective.

On a computer that is running a 32-bit Windows operating system %windir%\microsoft.net\framework\v4.0.30319\ngen.exe update /force /queue

On a computer that is running a 64-bit Windows operating system %windir%\microsoft.net\framework64\v4.0.30319\ngen.exe update /force /queue

This is strange voodoo. How would we even know it's started/finished?

[kensykora]

IIRC there is a way to do it synchronously, leaving out the /queue argument perhaps. This article covers it a bit more (http://msdn.microsoft.com/en-us/magazine/cc163610.aspx) but the actual tool documentation doesn't indicate anything explicitly about a synchronous operation. (http://msdn.microsoft.com/en-us/library/6t9t5wcf(v=vs.110).aspx)

Worst case scenario, you could write a script that triggers queue with priority 1 and poll it until it completes.

[dylanmei]

Duh yes, take /queue off and it just runs with output.

Microsoft.WSMan.Runtime, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35
    Compiling assembly MSBuild, Version=3.5.0.0, Culture=Neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=amd64 (CLR v2.0.50727) ...
Specify the input as a .EXE for ngen to pick up the config-file
MSBuild, Version=3.5.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
    Compiling assembly PresentationBuildTasks, Version=3.0.0.0, Culture=Neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=msil (CLR v2.0.50727) ...

and so on...

[kensykora]

Yeah -- the only thing I'm questioning is running it "before" updates, seems like you'd want it to run after updates, since they likely update the .Net framework.

[dylanmei]

I agree with you here. Running it at the end of the packer run will spare the poor guy doing the vagrant up, which is where I was seeing the problem.

[joefitzgerald]

LGTM. Pull Request?

[dylanmei]

Still watching this, Joe. On 2012 R2 it's still running "Windows Modules Installer Worker" (TiWorker.exe) with crazy CPU after ngen exits.

[kensykora]

Yep, definitely will submit one, but probably won't be this weekend, possibly Monday since I have the day off.

[dylanmei]

FYI my CPU was still at 50% exactly one hour later / 50 minutes after ngen was done. I restarted it and all was quiet again.

[joefitzgerald]

Windows is so awesome and predictable. :facepunch:

[ferventcoder]

:+1:

[kensykora]

I have a hard time justifying being a .net developer sometimes

[joefitzgerald]

Come and be a go (golang.org) developer – https://github.com/joefitzgerald/go-plus. It'll feel dirty at first, and then you'll have an epiphany. Requires unlearning OO and then learning to use composition instead of inheritance.

Bonus: output is static binaries and cross compilation is trivial. Windows is a first class citizen.

[dylanmei]

Funny, that project you link to is all Node.js. Also a first class citizen on Windows. :wink:

[dylanmei]

Funny, that project you link to is all Node.js. Also a first class citizen on Windows. :wink:

[joefitzgerald]

I agree - the irony is not lost on me!

[danbarua]

I had no problems running this in a .bat file as part of my windows build - thanks for the tip!

[kensykora]

This is on my radar, working on it this week likely.

[kensykora]

Tested this on server 2012R2, seems to work. Spits out a bunch of output to the console to show what it's compiling.

[joefitzgerald]

What's the current status on this? Is a PR required? Looks like we've already merged one and this can be closed.

[erincerys]

This should be using the windows-shell provisioner. I was unable to make this work with packer 0.10.2 on Windows Server 2012 R2 until I did. packer always simply hung otherwise. I'd submit a PR, but a lot of other stuff that I won't test (since I don't use vagrant) is bundled in that provisioner step. Someone might want to look into this tho.