Sometimes when I boot my computer (read: several times a week) it starts with one core (of two) completely occupied by the System process. Rebooting doesn't help, and neither does safe mode, but it usually goes away after a day or two.
Process Explorer shows that one thread, "ntoskrnl.exe!KeAcquireInStackQueuedSpinLockAtDpcLevel+0x1e0", uses 50 % CPU.
One interesting observation: Whenever this happens, the time displayed in Windows seems to have stopped when I shut the computer down. E.g., if I turn my computer off at 11 PM, the clock will still show 11 PM when I start the computer the following morning.
I've done some googling, and it seems that ntoskrnl.exe can do this due to some driver error, but because of the clock thing I suspect my problem is hardware related. I really don't know, though.
Did you ever figure out what the problem was? If you did. and can articulate the specifics, I'd really like to know - - -
I've got a Win 7 64-bit Ultimate SP1 system also (though on Intel CPU) and I've run into that same exact System TID string (ntoskrnl.exe"!KeAcquireInStackQueuedSpinLockAtDcpLevel) eating up 50% of my CPU. Saw some other posts on windowsseven forum - they didn't help - I still have the problem after disabling every Service I can and detaching all USB devices as well.
There was a driver from "New Software, Inc." for a product called "Folder-Lock", which is used to be able to assign a password to access windows folders, that was getting invoked by the Win7 System Kernel. I uninstalled this product, and presto, problem gone - no more 50% of CPU being used by system - - -
How I Did It::
I couldn't find any software or features within "Xperf", "Windows Process Monitor", or "Windows Process Explorer" that allowed me to "map" the offending Thread ID to the responsible driver. However, Windows Process Explorer does display info for all the Drivers being loaded/invoked for a given process - including the "System" kernel process.
So I just went and slowly browsed thru all 173 of them, and thought about what non-Microsoft drivers might possibly have something to do with locking up resources - a clue given to me by the Starting Address for the offending TID from Process Explorer:
^^ Makes sense; it looks like that the kernal process was getting stuck with a spin-lock in place, which would basically kill all IO until it gets resolved. As a result, the process thread was never getting replaced by another thread, as it too would have been locked out due to the spin lock.