none
“System Interrupts” suddenly eats up to 50% of CPU

    General discussion

  • The system is ok after boot. After indefinite time (usually not less than one hour) CPU usage grows up to half with no reason. One can think that there are some background process is running. But there is not. Is it worth to say that my antivirus updates quite often and there should be no viruses? So I can't figure out where the problem starts. I tried to disable anything background processes I can to, and those I can't were carefully watched for being guilty. I thought it some kernel-level (driver) problem. If so, what is the best way to determine the source?

    Ok, here is a pair of screenshots. The first one was shot when everything is fine:

    http://smages.com/i/3c/8d/3c8d48d8e41543ac92d9d3a9adb6f86f.png

    The second one shows “System Interrupts” eating up a significant amount of resources:

    http://smages.com/i/b7/41/b7411950c9881ee0528f18f5f721e3e0.png

     

    As the problem starts the mouse cursor periodically goes choppy (some minutes is choppy, then some minutes is not).

    Please tell me what can I do. Thanks.

    Thursday, June 11, 2009 7:57 PM

All replies

  • Hi Entrase,

    Seems it would be useful to try capturing an xperf trace.  For Windows 7, download and install the Windows 7 RC1 SDK  which contains xperf 4.5.  Find xperf.exe on your system (may need to look for an MSI for the Windows Performance Toolkit and install that first).  Then, from an elevated CMD prompt change to the folder containing xperf.exe and execute:
     xperf -on DiagEasy+PROFILE

    Then, just after reproducing the problem, run:
     xperf –d merged.etl

    Then, ZIP merged.etl and password protect it.  Upload the ZIP file somewhere, and share the location either publicly or privately.  Share the password privately with those you would have analyze the log.
    Thursday, June 11, 2009 8:50 PM
  • Hello :) I tried to lanch xperf as you said for some minutes and it gives a 50 MB file. The problem here is that I need to log perfomance for some hours. Is this tool reliable in a long-time usage? Of course I'll try to start it right now and keep until problem comes, but I need to know what to expect after many-hour logging. Also not much people would like to download gigabyte-long file.
    • Edited by Entrase Friday, June 12, 2009 7:47 AM A typo
    Friday, June 12, 2009 7:45 AM
  • Yes, your reaction is not atypical.  WPT will be more readily available once Win7 hits RT, I presume.

    The logging will continue to a file named kernel.etl at the root of the drive, until you run the xperf -d command.  The longer you let it run, the more events there are captured, and the larger the file will be. Depending on the length of time you let it run, the file could easily be several hundred MB or even larger.  Ideally, you would use the system with a CMD prompt that has the xperf -on ... command typed in, ready to execute it.  Then when the behavior picks up, you would switch to the CMD prompt, hit enter, and capture data for, say, 3 minutes. Then run the xperf -d ... command to stop capturing.  Provided interrupts were indeed the cause of the behavior, while you were capturing, this should provide plenty of data to attempt to gather more information about the cause...
    Friday, June 12, 2009 9:49 AM
  • I think that it may be not enough to have only data captured after the start of This. A crucial moment must be caught too. So I scheduled a .bat with commands you gave me and a little prog I made few hours ago to save logs with different names :) So there is a new 15-min log every 15 minutes. Thank you one more time. My next posting will be more on the topic. And while I'm trying to catch the problem into log… What else can I do?
    Friday, June 12, 2009 2:52 PM
  • Check the event logs, perhaps?  Really, short of trying to repro and capture the behavior, I don't expect there to be much one can do...
    Friday, June 12, 2009 3:03 PM
  • Now things finally get confused. I caught the moment into logger but as it happens the file begins to grow very fast (1.5 GB in 5 minutes; normally there are 150-200 MB in 15 minutes). So when I stopped logging (it was stopping few minutes!) the file was 2.3 GB. Viewer just can't open that and says there in not enough disk space (not memory; btw I have a lot of disk space). I rejected the idea to catch the crucial moment and tried to start logging after it happens. And I couldn't get logging started! :( xperf just reports different errors. I tried some different arguments and that didn't help. So the only way to apply xperf is to stop it just right after That happens. But it may not happen for some days. Should I wait?! Not a good idea. What's now? What can I do?
    Monday, June 15, 2009 6:26 PM
  • The only data that may be necessary, at least for an initial attempt at identifying the problem, is a few seconds of activity when the interrupt storm is taking place.

    Perhaps, check out xperf 's sessions - maybe, try a circular log file...
      xperf -on DiagEasy+Profile -FileMode Circular -MaxFile 2000
    Monday, June 15, 2009 6:46 PM
  • I got it! The interrupt summary table is here (normal at the bottom to compare):

    http://smages.com/i/98/86/98869f063f8fff0201d6d8f1633b4b99.png

    Should I have symbols or whatever installed to view something more meaningful? It seems that I'll have to wait for the storm again because function addresses are actual only during the session. Right? Ok, I cease guessing. What the next step(s)?

    Unfortunately, I can't share the file atm because of slow and expensive connection (the file containing 7 seconds of logging is 50 MB long).
    • Edited by Entrase Thursday, June 18, 2009 11:48 AM
    Thursday, June 18, 2009 11:42 AM
  • Did you run xperf -d merged.etl ?

    You should adjust the symbol configuration to get the symbols from (preferable) the MS symbol server.  Unfortunately, that's more data to download...  The symbol engine will take care of translating addresses to more meaningful values, where possible...
    Thursday, June 18, 2009 12:35 PM
  • I got WinDbg and ran it as a local kernel debugger. Then I went in memory to the place where xperf interrupt summary points. After that I scrolled memory window up some pages and found a string. I searched this string in “drivers” folder and found “dxgkrnl.sys”. Some days ago I also confronted ISR address (is this ISR?) to Base address of drivers in memory and that was “dxgkrnl.sys” too. Looks like a good result, right? By the way, it is like there is no symbols for “dxgkrnl” and that explains why there is only numeric information in xperf. Is there are any mistakes in my actions? Is this right to compare address of ISR and base address of module to say that one belongs to another?
    After all if anything is ok in my actions then it's a bug in (around a) “dxgkrnl.sys”, that is from MS. Should I report it somehow for they to fix it?
    Wednesday, June 24, 2009 8:05 AM
  • Since you're mentioning DirectX, it sounds like you suspect the video driver?  I'm not sure that your investigations provide any conclusive details, and it is difficult to speculate.  If xperf only shows numeric offsets for a module, then it would seem that public symbols for the module are not available.  Try adjusting symbol configuration in xperf.
    Wednesday, June 24, 2009 10:27 AM
  • Just wildly curious - do you have Alcohol / Daemon Tools installed?
    Wednesday, June 24, 2009 6:28 PM
  • No, I don't. Though there is “UltraISO” for image mounting purposes. It creates virtual drive as well. I can't guess how tools like DT or the one I have can influence on graphics subsystem. So what's wrong with Alcohol / DT? At the moment I have installed older video driver. For now all I can is just wait for storm for some days. The first day with older driver ends up without problems.
    Friday, June 26, 2009 9:04 PM
  • I've seen a few cases where DT has been linked to high CPU usage attributable to interrupts / DPCs.
    Saturday, June 27, 2009 3:10 AM
  • One week with older video driver elapsed (Intel 82945G, driver version: 7.14.10.1132). Everything is fine. NC, thank you for all the help you gave me :)
    Friday, July 03, 2009 3:41 PM
  • Good to hear things seem to have stabilized for you, Entrase. :-)
    Friday, July 03, 2009 9:04 PM
  • Hello i think that i am having the same problem but i am really new to the pc world and i cant seem to solve it.My computer in periods starts making a noise (like i connect a usb flash and disconect it again) and while it does that the whole pc is jamming.From the Ie to the WMP everything jams and runs slowly like i am using the whole cpu.i cant take any pics of anywhere cause i dont know how! please tell me if you can help me or if i should throw it out of the window. Thanks
    Monday, October 03, 2011 11:54 AM
  • FIXED:

    CPU was maxed out, with 50% going to the "System Interrupts".

    It was a problem with my video driver.

    I was using the Intel 82945G driver from Microsoft, defaulted with the installation of Windows 7.

    I went to to the Intel website, and was able to load a newer driver, and resolved the issue right way.

    Wednesday, May 09, 2012 3:45 PM
  • This could also be a driver issue. If it is not the video driver, it could be a result of an incompatible audio our sound driver. It would be my recommendation to see what it would take to install a new sound card driver on your system to resolve the issue. (To test try to disable the sound. If that is the problem, it will fix the issue temporarily).
    Wednesday, May 09, 2012 3:47 PM