39

I've noticed that if I build my WPF application for Any CPU/x64, it takes MUCH longer to start (on the order of about 20 seconds) or to load new controls than it does if started on x86 (in release & debug modes, inside or outside of VS). This occurs with even the simplest WPF apps. The problem is discussed in this MSDN thread, but no answer was provided there. This happens only with .NET 4.0 -- in 3.5 SP1, x64 was just as fast as x86. Interestingly, Microsoft seems to know about this problem since the default for a new WPF project in VS2010 is x86.

Is this a real bug or am I just doing it wrong?

EDIT: Possibly related to this: Slow Databinding setup time in C# .NET 4.0. I'm using data binding heavily.

Community
  • 1
  • 1
Robert Fraser
  • 10,649
  • 8
  • 69
  • 93

1 Answers1

75

Actually there's 2 main reasons that the default project type for WPF applications is x86.

  • Intellitrace debugging only works with x86 and that would look pretty bad if the default project templates didn't work with one of their star features.
  • Many developers were still not aware of the fact that their AnyCPU exe's would run as x64 on 64 bit machines and were surprised to find that 32 bit DLL's they relied on did not exist in 64 bit varieties such as OLEDB drivers, certain native DLL's, etc.

As for the startup time issues you're experiencing, it almost seems like an issue with NGEN. Since there are different NGEN caches for x64 and x86 processes, it could be that the 64 bit NGEN cache either needs to be rebuilt or updated. Try running the following from an elevated command prompt:

CD C:\Windows\Microsoft.NET\Framework64\v4.0.30319
NGEN update

This is the command to re-build native images for assemblies that have already been marked for NGEN. It also probably won't do you any good to NGEN your application if the assemblies are not also in the GAC so I wouldn't bother trying to do that. But framework assemblies, toolkit assemblies, etc should all be NGEN'd.

(By the way, I did get several errors when I ran the above command about assemblies that could not be loaded. It was mostly SQL and Visual Studio assemblies.)

Josh
  • 68,005
  • 14
  • 144
  • 156
  • 15
    HOLY ****, it _WORKED_!!! I never would have figured that out. You really live up to your last name, dude. Thanks * 1000! – Robert Fraser Jun 01 '10 at 04:25
  • 3
    Jeebus, this advice works wonders! How on earth did they manage to fail to keep their cache up-to-date, seeing the impact of this? Big fail for MS. By the way, it seems that you need to redo this after installing certain updates. – Roman Starkov Jan 13 '12 at 10:54
  • Just to confirm, after a few hours spent debugging and researching this `bug`, I have run `NGEN update` and the application began to run like hell!!! Many thanks brother. – Dusan Oct 12 '15 at 22:44
  • @josh is this still relevant in Windows 10? And updated.Net version? – Yitzchak Oct 18 '18 at 12:03
  • Really thanks for this. I had a project that I needed to run as 64 bit because of dependencies, but as soon as I turned it to x64 it wouldnt' run the BackgroundWorker process. The NGEN solution fixed the problem. – Graeme Nov 08 '19 at 22:03