-1

On occasion my app begins to consume maximum CPU and the GUI becomes unresponsive. Maybe 1/50 attempts to reproduce this succeed.

Based on the high CPU usage it obviously is running (not blocked externally) but I'm not sure how to identify in the debugger where the execution is taking place.

The scenario of this problem goes like this:

  • App starts
  • User causes new modal window to open
  • User works in this window for a while
  • Eventually the window "freezes" (sometimes)

It is this last event which I am trying to debug.

I have followed the advice in Find infinite loop in progress? but when I break in the debugger it just lands on this line:

return f.ShowDialog();

I'm not sure why this is what the debugger considers to be the current executing line. I am not creating any threads.

Is there any way to debug this situation in the context of a modal window?

StayOnTarget
  • 11,743
  • 10
  • 52
  • 81
  • 2
    99% of the time this happen when you have custom / third party control in the window that cannot initialize properly due to impossible configs. I am very familiar with this when using `Telerik` stuff. – Franck Jul 25 '19 at 19:44
  • @Franck thanks; I'm not sure that matches my situation but it reminded me of some more detail to add to the question. – StayOnTarget Jul 25 '19 at 19:47
  • Ok so from your update it's definitely not a loading issue as i mentioned. But if you are not creating thread and it freeze there the other option is that it also can happen when calling unmanaged code and that this code freeze and sometime you might get a RPC error if very lucky. Do you have any calls to a non .net DLL ? – Franck Jul 25 '19 at 19:53
  • Using task explorer, you can identify the thread IDs consuming your CPU. In the debugger, look at the threads list and inspect those threads. The debugger landing on a particular line doesn't mean much; it just happened to be in that thread at the time. –  Jul 25 '19 at 19:54
  • @Amy - sounds promising. Did you mean Process Explorer? I could be ignorant of what Task Explorer is. – StayOnTarget Jul 25 '19 at 19:59
  • @DaveInCaz Task Manager, built into windows. I mentally combined the names and confused both of us. Process Explorer works too, even better than Task Manager. –  Jul 25 '19 at 19:59
  • 2
    You might also consider purchasing a product like Redgate to profile your application. Run it inside the profiler until it freezes, give it a moment, then kill it and inspect the profile results. It can drill down into time spent in individual functions, quite handy. There are other profilers, but Redgate is the only one I have experience with. –  Jul 25 '19 at 20:03
  • @Amy thanks for the suggestions – StayOnTarget Jul 25 '19 at 20:33
  • 1
    If you're using shadowing effects, drop shadows, expecially around windows borders, remove them all (if this is under your control and it's not instead a 3rd party control or library). It happens that when a shadow (or a similar effect) is drawn around the edges, it breaks the rectangle calculations and the window is redrawn continuosly, even when it's not required. CPU usage goes very high. – Jimi Jul 25 '19 at 21:27
  • @Jimi I don't think we are using those particular effects but your description does seem to fit closely. I may try to disable certain things just to see if I can stumble across the cause. – StayOnTarget Jul 26 '19 at 12:12
  • @Jimi this question was starting to diverge from its original purpose so I asked a different one: https://stackoverflow.com/questions/57219993/app-frozen-inside-wpfgfx-v0400-dll-utility-polygonbounds-and-utility-pathgeometr – StayOnTarget Jul 26 '19 at 12:48
  • @Amy your comment was a key piece of info, if you want to post a full answer I would accept it. – StayOnTarget Jul 26 '19 at 12:49

1 Answers1

0

Thanks to people who commented, this was the approach that turned out to be successful. Or at least, it shed some valuable light on the issue:

  • Run the app until the problem occurs

  • Run Process Explorer and find the app's process

  • Open the properties window for that process

  • View the threads which are running and identify which one is using all the CPU.

  • View the stack trace of that thread

In my case, I could see that in the stack trace nearly all the time is being spent inside functions in wpfgfx_v0400.dll, mostly in functions Utility_PolygonBounds or Utility_PathGeometryBounds.

enter image description here

I'd also set zillions of breakpoints in any WPF-related code / code-behind, and none of them are hit. So it really seems to be getting stuck inside that library. I have posted a separate question specifically about that issue: App frozen inside wpfgfx_v0400.dll Utility_PolygonBounds and Utility_PathGeometryBounds?

StayOnTarget
  • 11,743
  • 10
  • 52
  • 81