9

I'm having a weird bug in Windows 10.

After 5 minutes of idle, my cpu goes high. I used Win Performance Analyzer and found that it happens inside the ntoskrnl.exe on the thread GetStackLimits.

I have updated all drivers and everything is functional. Idle tasks are all disabled and deleted. I also ran sfc /scannow and chkdsk with no errors.

How am I supposed to find the error when it is inside the kernel?!

4 Answers4

12

I found the answer to my problem a long time ago, but forgot to add it in here.

It was the maintenance functionality in Windows 10 called:

RunFullMemoryDiagnostic

Found under:

\Microsoft\Windows\MemoryDiagnostic

After disabling this my maintenance tasks can finish instead of just using CPU on this task.

I do not have any memory problems or BSODs lately, but I do have 32GB of memory, which might play a role for this task to finish.

I did run it for some hours, but it never finished, so I am much better off without it.

Thank you for the help though!

1

Unfortunately, I don't know if this behavior stops when idle conditions disappear, but it's a normal thing for the mpengine (Microsoft's AV stuff) to run the MRT tool and scan like mad, which results in high CPU usage for some time (that the tool needs to run its scans), after a small period of idle when a user is logged on.

If CPU use goes back to normal after you do something like move the mouse or touch a key, this is probably what's happening.

I find this easiest to see with Process Explorer.

If activity remains high when idle conditions cease, it's something else.

fixer1234
  • 28,064
Dvj
  • 11
0

i found the true problem about this cpu usage when your pc is idle from about 4-5 mins.

For me, it was the task sheduler ... it is pretty hard to find because all microsoft crew prefer let users in total blindness and prefer let those do a blank windows recovery who dont arrange anything.

For the best result, follow those instruction:

  • first, download TWEAKBIT PC SUITE 10
  • Now, before to clean or suppress or erase all you want, go to Tweakbit STARTUP MANAGER
  • DELETE ALL USELESS STARTUP PROGRAMS
  • Find the TASK SHCEDULER MENU
  • In the list, UNCHECK ALL LINES (all scheduled tasks) !!!
  • Restart, and its done !

SECOND METHOD WITH REGISTRY ONLY:

1- Go to Start > Run > Regedit

2- Set the following registry key to 0x0000004 (4)

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Schedule\Start

AND YOUR PC WILL NEVER IDLE HEAT

For me , TweakBit help me to understand how computer work.

Please dont hesitate to share others methods for disable those over cpu usage operations of the task scheduler .

Hope it will help you guys. Take care.

Cudex.

Cudex
  • 1
0

Martin, in my case it was caused by Hyper-V being enabled (before upgrading from Windows 8.1 to 10) and probably using bridged network connections that were not compatible with the Realtek PCIe GBE Family (Ethernet) controller that came with my desktop system that originally had Windows 8.0 installed on it. The only reason I was using Hyper-V was for Windows Phone 8 development. I haven't been using this for years, but the network was running on bridged connections and I could never get it to work without the bridge. I know nothing about setting these up. The Visual Studio installer did all the Hyper-V and virtual network setup.

To fix the problem, I simply removed Hyper-V in the "Turn Windows Features on or off" control panel dialog and this automatically removed the bridge connections. Then I spent a couple of hours getting my direct ethernet connection to work again. The diagnostics were no help with this. I finally resorted to the old trick of swapping the connection port used on the router with another one (of four) and Windows could finally see the other computers on my home network again.

To help diagnose the problem, I used MagicAndre1981's xperf cmd setup to generate an etl. (See Install the WPT.) I then opened this file in "Windows Performance Analyzer" and added the "Stack" column as in MagicAndre1981's example. The module names under the System root gave me the clue that it might be the Hyper-V as I suspected all along.