Slow startup of Clickonce winforms application after update

Question

We have a winforms application that is deployed to users through clickonce and uses the autoupdate functionality.

What we have noticed is that for our users, it takes several minutes for the application to appear after a clickonce update occurs. The application executable is running during this time with fairly high cpu usage, but no windows are displayed.

This is not reproducible on the developers' machines. There are 2 primary differences between the users' and the devs' machines:

1. The users are running windows xp, where the developers are running windows vista.
2. The devs are on the same domain as the clickonce server, whereas the users are on a different domain that has a 2 way trust relationship with the domain the clickonce server is part of.

The cold start performance of the application is almost instantaneous after its been run once after an update.

The following link is for someone on the msdn forums with the same issue, but there is no posted solution: http://social.msdn.microsoft.com/Forums/en-US/winformssetup/thread/5ec061c4-ec6f-4101-98a6-dc8bb5acab60

As the developers have been unable to reproduce locally, we don't yet have a profiling trace of what the application is doing during this time.

Any thoughts on why this might be occurring or suggestions on how to go about troubleshooting the problem?

Thanks.

EDIT 08/24/2009: Created a 32 bit virtual machine running XP and joined it to the same domain as the users. The issue does not manifest in the virtual machine. This seems to eliminate both XP and the domain membership as the source of the issue. That seems to leave VLAN, system configuration, and patch level as potential culprits.

Answer 1

When the application is updated, all new assemblies will need to be Just in Time Compiled. This typically only occurs once so would explain why there is a slow initial startup and why you can't reproduce on developers machines.

I have seen very poor performance (minutes vs a few seconds) for a newly deployed first run .Net application is the users are running antivirus software as the antivirus tool checks the newly Jitted assemblies are not malicious.

If you are able to monitor the initial startup of the application - check to see if mscorjit.dll is loaded and the reason the process is consuming significant CPU is because of the jitting. Also check if any antivirus tool is consuming a significant amount of CPU.