10

I'm currently experiencing a problem in WPF. The UI loads fine, but whenever the first user interaction is made, such as a button click, the application seems to stall, or example if I had two buttons that display a MessageBox, the first click will wait for a few seconds then show the MessageBox, but any subsequent interaction is instantaneous and responsive.

Has anyone else experienced this? And if so, is there any solution?

Thanks

JanW
  • 1,799
  • 13
  • 23
Gary Connell
  • 305
  • 4
  • 10
  • If you are showing the message box using the overload version with parameter `this` refrence, it won't allow you to do anything until you close the messagebox. –  Oct 14 '12 at 20:08
  • 1
    I guess that's because of DLL loading, since .NET loads only what is referenced, so when the first reference of any object occur, it may cause a delay. That's what happening ... – Mohsen Afshin Oct 14 '12 at 21:06
  • This may help you, http://stackoverflow.com/questions/2947118/wpf-slow-to-start-on-x64-in-net-framework-4-0 – Mohsen Afshin Oct 14 '12 at 21:08
  • 3
    I think I've figured it out , it appears to only be slow when debugging. If I build in release and run the app from the release folder in the bin directory, the stall or delay doesn't occur. Thanks for the help anyway :) – Gary Connell Oct 14 '12 at 21:56
  • I have noticed the same behaviour, but only in 64-bit builds (or AnyCPU on 64-bit OS) during debugging. The debug builds run without delay if started from the `Bin\Debug` directory. The delay is only present when the program is run with F5 in the IDE. – John Reynolds Apr 08 '13 at 14:29

2 Answers2

7

I had the same problem. Every time I called the first interaction from a Button or ICommand the UI would freeze for like half a second.

I tracked down the issue with the hint of the author to start application directly from the folder. This solved the issue, but I also wanted to know why this happens and thought about what the difference is between direct execution and debugging.

So I figured out that IntelliTrace caused the freeze, which was still enabled since I activated it once for debugging an ADO.NET application. After disabling, the UI Freeze is gone. To disable it go to Debug -> IntelliTrace -> Open IntelliTrace Settings -> untick "Enable IntelliTrace".

JanW
  • 1,799
  • 13
  • 23
  • 2
    We are investigating this issue to see if it can be resolved for a future version of Visual Studio. In the meantime, you may wish to just disable 'Gesture' events instead of completely disabling IntelliTrace. To do that go to 'Tools->Options->IntelliTrace->IntelliTrace Events' and disable 'Gesture' collection. – Colin Thomsen Aug 27 '13 at 17:35
  • Thank you for your response Colin. I followed your instructions and it now seems to work with IntelliTrace enabled. Maybe you should also post this as answer, since it is actual better than my solution. – JanW Sep 02 '13 at 09:19
3

Thanks for reporting this performance issue. We have looked into it and tracked it down. We are looking into fixing this in a future release. Below are steps to work around this issue. Once the work around is applied there is no need to disable ‘Gesture’ events or IntelliTrace.

  1. Open up a cmd window under Admin account
  2. cd /d "%programfiles(x86)%\Microsoft Visual Studio 12.0\Common7\IDE\Remote Debugger\x64"
  3. %windir%\Microsoft.NET\Framework64\v4.0.30319\ngen.exe install /NoDependencies /ExeConfig:.\msvsmon.exe Microsoft.VisualStudio.vil.host.dll

If you are using a VM you might want to first save a snapshot before applying the work around. Let us know if you run into any other issues. Thanks.

Azeem Khan

Azeem Khan
  • 31
  • 1