I don't see anything odd or nefarious about that screenshot. The size of the idle process depends on what the system is doing (as has been said some operations are performed in the idle process), the type of CPU, the number of cores, etc.
And of course you cannot shut down the idle process. Not a trojan, not a worm, and it's a bit scary that a computer literate person thinks that the idle process isn't legit. Truthfully a really nasty virus or trojan won't show up in the task manager because it will hook into svchost. If you see a lot of svchost's then that might be a cause for concern. svchost encompasses a large number of threads that are running on the system but unfortunately with the default task manager you cannot see what they are. I believe Salem's fav guys over at SysInternals have an answer to this with their own task manager app.
Sorry Mario F. I was addressing that to the OP and not you. I apologize if that was not clear. I would never question you on a simple matter such as this and hold your responses and abilities in very high regard. So to be clear I was stating the OP should know better.
That really scares me.Quote:
I can't speak for the OP but I know other than programming I'm not very good with computers.
It is particularly scary in programming languages like those mostly discussed on these forums. Not only knowledge of computer and OS operation is mandatory in order to effectively use these languages for anything other than the simplest (read useless) programs, but what strikes me most chilling is the fact these languages usually provide their users with an immense incentive to learn more about the machine.
working set size, and not the actual memory used, in XP. They may have changed things in recent versions of windows; I don't rightly know.
I believe this is correct. You need to use something like perfmon on Windows to accurately see the amount of memory being used by a process.Quote:
I believe the memory used column in taskman is merely the process' working set size, and not the actual memory used, in XP. They may have changed things in recent versions of windows; I don't rightly know.
But for efficiency, the idle-loop may look more like this:Code:
As to the "amount of memory for idle", that's probably dependant on a whole lot of things, including the stack for the idle process [we can't use the current process's stack, since we may end up in idle whan the current process has run out of stack and is waiting for the stack to be paged in]. So that makes it at least 8KB (4KB for the code, 4KB for the stack).Code:
cmp context_switch_needed, 0
cmp other_work_needed, 0
As stated elsewhere, the idle process is sometimes doing REAL WORK, in which case it will also need memory for those things.
I once had that Idle task thing, that was on Windows 7 build 7000, I havn't had it on task manager for XP, Vista or Windows 7 RC :S
Also, it did scare me when I first saw it, like I looked at the CPU usage only and it said 99%, that gave me a shock...
Also, I always have a load of those svhost processes, I always think the OS has some bug which makes it start it over and over again...
Okies, been taking a look at the innards of working sets, which essentially forced me to revisit the whole memory management thingy.
It's quite curious I never see a change on my Idle Process working set size. It boots on 16k and stays on 16k no matter what I do. With 3Gb RAM and with a very conservative memory usage, I'd expect less aging of the working sets. But I gather many things can affect this; like prefetch and an apparent preference for aged working sets over "free" memory, when handling soft faults.
It however becomes established that the discrepancy in values of the Idle Process size report on XP is mostly a function of total system RAM. Thanks.
Apparently the Idle loop runs at dispatch level (it's the last paragraph) so that'd explain it. At that level it can't use anything that'd need to be paged back in, because the page fault handling interrupt has been masked off as that runs at APC_LEVEL (the level below).
Everything it uses must stay resident, and it's most probably not allocating anything itself so it stays at a constant level. As for why 16K, no idea, but one can hazard a guess; a page for its KTHREAD, 2 pages of code, one for the kernel and one for the hal, and a page for the DPC list and/or other related structures.Quote:
Originally Posted by http://msdn.microsoft.com/en-us/library/ms795133.aspx
I'm kind of disturbed that people don't seem to have ever looked at the task manager before, then are shocked at mundane things. God forbid you use Process Explorer...