1

My program is a slideshow. It runs on a machine with other processes, so while it's waiting to display the next slide I call SleepEx(N, false), expecting it to reduce to near-zero the amount of CPU it uses (N is between 100ms and 5000ms). On my development XP Pro machine that's exactly what happens but on my customer's XP Home machine it registers 30-80% CPU during the SleepEx(). The code is a single thread so whatever is using all that cpu is within the call to SleepEX(). Has anyone seen this before?

Burgh House
  • 11
  • 1
  • 1
    Do you call something high level which starts a thread, such as a video player? – Prof. Falken May 23 '11 at 10:13
  • Not knowingly. I use the FreeImage library to handle the image conversions but there is no reason for that to be doing anything at this point. And the fact that it works OK on my machine but not on the customer's is puzzling. – Burgh House May 23 '11 at 10:16
  • 4
    Offtopic: calling Sleep is an odd way to do this. When you do this you will make your app non-responsive. It would be better to use a timer to trigger slide changes. – David Heffernan May 23 '11 at 11:01

2 Answers2

1

Which process is taking all that CPU? If you break into the process with a debugger - where in the stack trace is it spending time?

Try to use ProcDump to create a dump of the process when it reaches that CPU spike. Then analyze the stack trace to see where it's stuck. Do this several times you get a good sampling of where it's spending time.

Assaf Lavie
  • 73,079
  • 34
  • 148
  • 203
  • I suggest you trigger a remote dump of the process during this busy time and analyze the stack trace to see where it's spending time – Assaf Lavie May 23 '11 at 10:23
  • Sorry - hit prematurely. I don't have a debugger available. – Burgh House May 23 '11 at 10:23
  • I did a ProcDump and now have 1.5Mb of dump file but don't know what I'm supposed to use to analyse it. CPU was 59% and the dump was taken about 5s after a screen refresh (35s before the next one was due) – Burgh House May 23 '11 at 11:00
  • This is something you should read about. A very powerful debugging tool. Basically you're supposed to be able to drop this dump file into Visual C++ or WinDbg and then see a stack trace (as if you hit a breakpoint). – Assaf Lavie May 23 '11 at 11:26
  • Thanks for trying to help, but I'm not sure I understand where this is going. I know the program is executing the SleepEx() and I know the high CPU is occuring while SleepEx() is active because the command immedaiately after the SleepEX() hasn't executed. So it looks like you're asking me to debug the API call. Or have I musunderstood? – Burgh House May 23 '11 at 11:40
  • you say you have a process that's single threaded and is busy even though the OS is supposed to relinquish its CPU time. This is probably not the case because that's just not how things work. So I'm suggesting you look into what's actually happening in your main thread. Break into it and see where it spends its time. If it indeed is waiting for Sleep to return then it's a mystery. But I suspect it's not. I suspect it's actually doing something else, and since you haven't debugged it yet you can't eliminate this option. Just try the dump. – Assaf Lavie May 23 '11 at 11:44
  • Tks. I'm currently trying to obtain a copy of WinDbg and will come back when I have some results. – Burgh House May 23 '11 at 11:50
  • these tools are all free... just download the whole sysinternals suite. these are very strong tools you should get to know. btw there are some questions here on SO on how to do what you're trying to do right now. e.g. http://stackoverflow.com/questions/734272/how-to-use-windbg-to-analyze-the-crash-dump-for-vc-application – Assaf Lavie May 23 '11 at 11:54
0

I have seen this before. You block main window message processing thread.

You should not place Sleep() function in single-threaded application if it has main window message processing function. Windowed application always should process window messages without noticeable delay, in another case it will cause deadlock at least for application. Consequences depends on windows platform, compiler settings and CPU configuration, usually application in debug mode has temporary workaround. But if you start such application compiled with release settings it can consume one CPU core with function, which have blocked his main window message processing thread.

Remarks section at MSDN Sleep() function description clearly states this situation.

You just have to lauch new thread, to use Sleep() function right there to allow free flow of window messages in main thread.

Lyubomyr
  • 51
  • 1
  • 4