CODEWITHSUNDEEP
.netwpfstartup
Zebi
Zebi

Reputation: 8882

.net wpf application startup issues

I've got a quite strange startup behavior for my application.

The first time the application is started the process takes up one CPU Core (50% on dual core, 25% on quad core) and RAM consumption stops at a specific value (each start the same, different on other machines/different build versions as we change the application around to test).

If I start an other instance while the first is running the second instance starts normally.

I inserted some logging into the application and it seems the application crashes the first time a UI element is shown. Initially logging ended just before the splash screen should show up - after removing the splash screen it stopped as a Messagebox Control should be shown.

The issue happens on some machines, not all. Copying the same files to an other machine can "fix" the problem. If I deploy a debug compiled build, builded by my workstation the issue disappears completely.

Additional Info (March 18th): The required "hanging" instances count seems to depend on the number of available cores.

If the machine runs on a dual core* system, the second process starts, the first taking 50% CPU (= 1 core@100%). If the machine runs on a quad core system the *fourth proces*s starts, the first three taking 25% CPU each (= 3 cores@100%).

Update (March 19th): So... we solved it! A colleague wrote a thread manager with some code to wait on something. This manager is called when UI elements are shown. Running a debug version or running the release version on a very slow VM (the machine which functioned fine has been a virtual one on a really busy machine) seem to change the timing and make it work.

He said he implemented some sort of timeout to fix it.

I will take a closer look at his solution (and why such strange things are required) on Monday and post an update here to provide a proper solution to my question for following visitors.

The bounty goes to Stephen Chung, thank you all for your help.

Upvotes: 0

Views: 622

Answers (3)

RandomNickName42
RandomNickName42

Reputation: 5955

Yeah, you should target all the same version's of runtime, also you should look at the fusion log (logs of .NET loader trying to get the correct version of your binaries).

Check out Suzanne's blog she has lots of info about cold startup performance issues/tweaking.

Upvotes: 1

Emond
Emond

Reputation: 50672

Try stripping down the application startup code. If the problem shows even before the splash screen is visible either you have code that is stalling the machine or there is something wrong in WPF.

Are you running any code in the Application object constructor?

Upvotes: 0

Stephen Chung
Stephen Chung

Reputation: 14605

Your question is not very clear. You should try to provide as much debug/error log info as possible.

Hunch below

However, considering that you are using 100% of a CPU core, this sounds suspicious. Are you hogging threads? Are you using ThreadPool? .NET programs require at least a few spare ThreadPool threads to operate -- a couple of years ago, it used to be that if you hog up the threads in the ThreadPool (running never-ending loops etc.), and the number of free threads drop below 3, the system will crash. You should check the number of free threads in the ThreadPool if that's what you're using.

This is only a hunch.

Summarizing the problem

However, I am trying to summarize your problem below. See if I get it right:

  1. Program will hog 100% CPU time on one core only -- which suggests only one single thread (as more threads will be scheduled on another CPU) -- what kind of thing are you doing to that poor CPU core that will strain it like this???!!! Are you doing System.Threading.Thread.Sleep() occasionally to yield some CPU time back to the system? Have you marked your process as background priority instead of high?
  2. n-1 program instances will run fine (n = number of cores).
  3. The n-th program instance will fail (n = number of cores).
  4. Failure is always with the inability to open up a window in the Windows UI.

Failure pattern

This pattern seems to suggest that, when your last program hogs up 100% time on the last CPU, Windows processes are left fighting for CPU time.

If you have one core free, then Windows processes can always run on that core and your UI will be responsive. Once you hog that up too, you may be seeing a time-out detected by Windows on unresponsive applications -- you may be straining the machine so much that Windows cannot function.

To Test: Run n program instances (n = number of cores). Then run other programs. Will they be sluggish, or will they run fine?

Upvotes: 1

Related Questions