Process monopolizes CPU; over 90%.

September 8, 2010 at 06:30:53
Specs: Windows XP, P4 2.66
What is this?
Process Name [System Process]
Process ID 0
CPU 93.8
Creation Time 1/1/1601 6:00:00AM

See More: Process monopolizes CPU; over 90%.

Report •


#1
September 8, 2010 at 06:36:58
Are you sure this is not System Idle Process as this usually has PID of 0.

Windows Task Manager > Processes will confirm it.

If it is the System Idle Process then this is normal. It is what the CPU does when it has got nothing else to do. Like a motor vehicle in neutral with the engine ticking over.

Stuart


Report •

#2
September 8, 2010 at 06:50:11
It is only listed as [System Process] .

The strange creation time also made me suspicious: Creation Time 1/1/1601 6:00:00AM

My concern is that it may be malware, or controlled by it.


Report •

#3
September 8, 2010 at 06:59:19
While in task manager highlight the process and right click. Choose properties. The information there may yield clues as to what the process is linked to.

Also, Googling for the exact spelling of the task may also yield the origin of the process.

If you suspect malware or worse then you should take the necessary steps to clean you system.


Report •

Related Solutions

#4
September 8, 2010 at 08:03:11
What utility are you using to get this information? XP Task Manager cannot show creation date.
Some utilities do show the System Idle Process as "[System Process]" but the process PID will always be 0 in XP. The creation date of this process has no real meaning. Do not confuse this process with the "System" process which will always have a PID of 4 (in XP).

As StuartS said, it is normal and desirable for the CPU usage of this process to be high. In fact, the higher the better.


Report •

#5
September 8, 2010 at 08:11:21
Yes, it seems to be System Idle Process. It is listed as System Process in the "What's Running" program, but as System Idle Process in Task Manager. I found an interesting explanation for the 1/1/1601 date at this URL: http://blogs.technet.com/b/heyscrip...
"In case you’re wondering, a number of years ago the American National Standards Institute (ANSI) adopted a system of counting days; this system began with December 31, 1600 as Day 0. In turn, that made January 1, 1601 the first “official” day in history, with all subsequent dates and times being based on the number of nanoseconds elapsed since the 0 hour on January 1, 1601. (That day was a Monday, by the way.) These so-called ANSI decimal dates were originally designed for use with the COBOL programming language and have continued to be used by Windows and other operating systems."

Report •

#6
September 8, 2010 at 09:21:00
These so-called ANSI decimal dates were originally designed for use with the COBOL programming language and have continued to be used by Windows and other operating systems."

It doesn't though. Windows uses a date that starts at 31/12/1899 with day One being 1/1/1900. It also stores date and time by the second which is converted into a 32 bit floating point number where the number before the decimal point is the number of days since day 0 and the number after the decimal point the fraction part of the day since midnight. Doing split second timings via Windows can be done but it is not very accurate.

That probably why the date was wrong because whoever wrote the application failed to appreciate the way that Windows does dates.

I have a formula somewhere for converting ANSI dates to Windows and vice versa but I cant find it at the moment.

Stuart


Report •

#7
September 8, 2010 at 09:53:19
StuartS: Windows uses a date that starts at 31/12/1899 with day One being 1/1/1900.
I'm curious as to where you found this information. The Win32 API expresses date/time in two different structures (SYSTEMTIME and FILETIME), neither of which use floating point, and both have a resolution of 100-nanoseconds.

Report •

#8
September 8, 2010 at 12:49:32
Filetime and Systemtime, as well as LocalTime are derived from the floating point number I mentioned. The information that is returned from these API calls that you mention are not actually stored anywhere in that format.

I found this out when writing an application that reads the time from an atomic clock. The time is returned in Unix time which is different again having its Origen in 1970.

Here's the VB formulas I use to convert the information back to its floating point original.

GetGMTTime = DateDiff("s", #1/1/1900#, CDate(DateSerial(.wYear, .wMonth, .wDay) & " " & TimeSerial(.wHour, .wMinute, .wSecond))) + CDbl(.wMilliseconds) / 1000

This value returned in GetGMTTime is used to update the clock. If it were wrong the time would be wrong every time I called the function, which it isn't.

Stuart


Report •

#9
September 8, 2010 at 14:37:42
VB6/VBS/VBA might represent the date/time as a floating point number, but I think that's more about programmer's ease of use than an accurate representation of what the Win32 kernel is doing. For one, floating point is horribly inaccurate.

From the DDK: "System time is a count of 100-nanosecond intervals since January 1, 1601."


Report •

#10
September 8, 2010 at 14:57:23
StuartS:

Based on your information, I don't understand why "System Process" has a noted Creation Time of 1/1/1601 6:00:00AM.

That is: if it is truly "System Idle Process", a Microsoft XP program as noted in Task Manager, (but as System Process in the "What's Running" program).


Report •

#11
September 8, 2010 at 15:08:02
OK, I followed http://msdn.microsoft.com/en-us/lib... as noted in your post. So, the 1601 date must be correct for that program.

Report •


Ask Question