Ever since I upgraded to win98 from win95 my cpu clock loses time rapidly. When I reboot the time is correct (indicating CMOS is OK?). I've flashed upgraded bios, to effect. Does anyone have any ideas?

Time loss is usually due to a battery going bad. Replace the battery and see if the problem stops.

I had the same problem. I make use of time synchronizers, such as Atomic available from software download sites. It basically connects to one of the atomic clocks using your modem/internet connection, using parameters you set (ie every 4 hours), and resets the time.

I am having the same problem. I don't think it is the battery though. I recently installed Win98 in my computer (1 year old) and my wife's computer (~3 year old) and both are having the same problem. They are not networked, have plenty of ram, and had no problems under Win95. I think somebody knows something and isn't telling.

My pc is 5 yrs old, went from Win3.1 to Win95 to Win98. I lose about 20 seconds a month. My other pc is an old 33MHz junk box with Win98 and loses no time. Another one is a Toshiba with Win95 and loses no time. There isn't anything we arent telling you. Did you try a new battery just to make sure? They aren't that expensive, really.

Are you running any programs that rely on clock, such as games?

What is up with the clock issue? I had an old computer that for years ran slow, at times really really slow- October in late December- that type of thing. Batteries?..Plenty. More than necessary.
I find it interesting that this issue never really gets addressed- software/hardware/batteries-
It's all so perplexed but yet compelling and tragic in a hideous, horrendous sort of way.
Perhaps the DC, as in electrical current, has a factor. I recall Thomas Edison, the inventor, was a big proponent of DC, not AC (alternating current), but that DC failed as the current used for electric chair executions.

The only way a battery will drain, is if there is a drain on it, like a short, or the battery was old or discharged from the start. Something is putting a constant drain on the battery. If there are no programs that constantly put a load on the battery, and no setting in the bios that might do that, take the pc to a shop and have them test for a short on the board. Check the mfg of the motherboard to see if there is info on that problem at their site. Could be an issue between the specific brand of motherboard and Win98. I've never experienced this problem myself, or has anyone I've asked in the last week.

I have just upgraded my machine - virtually brand new m-board, Pii300 CPU - now Win98 is seemingly gaining time ! Previously it was losing a few minutes every few weeks or so.

I never noticed this problem in Win95.

I have two computers they are independent of each other (not networked). Both of the computers where upgraded to windows 98 and both are losing time, I replaced the battery in each, and no change.... Does any body no the answer to my problem....????????

5/12
My cpu is constantly losing time, I have to reset it quite frequently. I never noticed this when I first got it last fall of 98'.
Strange if you ask me. but why???

Losing time also, but where do I locate the battery in my system...in what area?

Hi,

Look, the Real Time Clock is battery backed up. If your system always has the right time when you first boot it, then the battery is OK.

Once you boot your system, the computer keeps time (system time). If Windows missed interrupts then time will be 'lost' until you next reboot.

I know about six colleagues who have upgraded from 95 to 98 and they all complain about losing time (one of them up to 7 hrs per weekend!).

Try this - find a folder with lots of Excel spreadsheets (the larger the better) then Select All the .xsl files and hit return.
Excel will load them all up - a minute or so later, when all loaded, look at your computer clock - any time lost ??

P.S. When running the Time/Date applet do NOT click on the OK button to dismiss it. Every time you do it will lose 1 second!

Let me know how you get on (by direct email as well if poss).

cheers

Steve

i would like to poll.. i too am losing time. have run win 98 since its release. never had a problem until i went cable and have not been rebooting very often. i would ask those also having this problem of "lost time" to state if they too are cable or if they are not rebooting at least once daily. thank you.:-)

I have also been losing time at about a rate of 8 to 10 minutes per 24 hour period. This has been the case since upgrading from Windows 95 to Windows 98. The battery tests out at 3.000, so no problems there. The calibration of the tester had been validated prior to the battery test and then validated again after the battery test. So, the validity of the battery tester or the battery should not be suspect.
Re-booting brings the clock back to the proper time.
Not running any games or programs that rely on clock.
Computer is 450, Pentium II, with 128 meg of ram and a Shuttle P2BX Motherboard. Wintune 97 shows no performance problems with any portion of the system test (CPU,RAM,Accessories,etc.)after monitoring performance daily for more than a 7 day week (during which time the clock lost 66 minutes!)
If this helps someone find and/or isolate the problem....Good!! Please let me in on any solutions.

I have a similar problem with a twist
I would not be bothered by just losing a few seconds or minutes every now and then because I don't rely on my system clock. But, after loading memory intensive applications (even after closing them) my system will stop for a few seconds at a time and refuse to accept any form of input. I timed it once, and it would go exactly two minutes, and lock up for 3-5 seconds. During that time, the cursor locks up, and any keys typed are dropped.

Download the "Continuous Operation Patch" for the 49.7-day system crash bug, available from the Microsoft Windows Update Page.

UPDATED: 4/10/99

SUMMARY: Users began reporting their clocks were slowing down after crashing (i.e., not correctly shutting down). Most of the users reporting the problem were developers who were using our SDK with Visual Studio 5 (97). Developers reported their clocks were losing as much as a second every minute. The problem became more extreme the more often the audio engine was "crashed". This problem was recreatable by quitting the Visual Studio debugger while the audio engine was running. (Using End Task in the Task Manager, a proper way to shut down the audio engine, did not re-create the error.) The longer the error was allowed to exist, the slower the computer began to operate; eventually the mouse would slow down to a noticeable drag, file operations would cease, etc. The only way to rectify the problem was to re-boot the computer.
RESEARCH:
08/20/98 The audio engine follows all preferred methods for releasing a thread; after much testing it was concluded Visual Studio was releasing the thread but somehow not deleting the multimedia timer opened by the audio engine.
Further testing revealed this problem could be re-created outside of the audio engine, and therefore could potentially be a problem in one of the DirectX dlls
It was decided to contact Microsoft to see if there had been any other reports of the "system clock slow down" problem.

12/15/98 Microsoft responded to our first e-mail request (sent 08/20/98) on 12/15/98:

To simplify I am broadcasting to all parties who we've been talking wrt the
clock slow down bug. As you can see from the below it is an OS problem.
The problem can be avoided by taking the steps outlined in the text.

> Heres the story on the slow clock bug:
>
> The reason that the system clock was slowing down was that interrupts were
> being turned off repeatedly for a very long period of time. The questions
> were, where and why.
>
> We initially traced the return path after the interrupt by using a
> specially instrumented VTD that would break out on its interrupt handler
> when it determined that the interrupt came late. We found that
> consistently the routine hit was End_Process_Event. We then examined the
> events that were processing and determined that the routine that was
> taking the longest to return was located at VTDAPI(1)+BA, this routine
> turned out to be VTDAPI_Timer_Event. We now knew the event that was likely
> taking the time, but we still had trouble seeing how this code could be
> taking that long with interrupts off. The code did one of 3 things, it
> either signalled an event, pulsed an event or scheduled a win32 APC and
> that's all. We didn't believe that any of those could take long enough to
> slow the timer down.
>
> VTDAPI is a vxd that provides highly accurate timing services through an
> IOCTL interface. The primary client of this interface is the multimedia
> system functions. This lead us to believe that the problem must be
> related to the multi-media system code. We had also heard that the
> multi-media system code had caused this problem for the DSOUND team and
> they had blown off using multi-media timers as a result.
>
> On a Plane Crazy machine that was exhibiting the problem, we found that
> one of the events being scheduled was every 20ms with 20ms accuracy. This
> is the initial period of the periodic timer that DirectPlay creates. We
> decided to follow the timer through its scheduling into the APC. We found
> that during the queueing of the APC descriptor, it queued itself on the
> end of the APC list on the thread control block. The list of APC's
> contained over 300,000 entries. The insertion in the list was done with
> interrupts turned off and was done by walking to the end of the list (i.e.
> the list had only a head pointer). This seemed like a likely candidate
> for the cause of the slow clock. We then NMI'ed one of the machines
> exhibiting the problem and determined that it was in fact IN the scan at
> the time.
>
> To absolutely verify the problem, we emptied the list manually.
> Immediately the time on that system started running normally, but slowly
> began to slow down as the list grew again. We then wondered if the list
> was growing because the thread was not keeping up or because the thread
> was not running events at all.
>
> We determined the thread was not in fact running the events at all. The
> question then became one of how this could happen. I then ran Plane Crazy
> on my computer and found that even the single player version intialized
> DirectPlay. It did not however free DirectPlay. This led to directplay's
> periodic multimedia timer not being shut down. After exiting Plane Crazy,
> VTDAPI still repeatedly tried to schedule the timer event into the thread,
> which no longer existed. If a new thread happened to be started with the
> same ring0threadid then the events would be scheduled to that thread. If
> however the thread was not in an ALERTABLE state, then the events would
> not run. If the event ran they wouldn't work anyway since the event code
> would not be present.
>
> To cure the problem, I added code the VTDAPI.VXD that has it remove the
> timers owned by threads that are being destroyed. This code should have
> been in VTDAPI.VXD from the beginning. Its omission is essentially a
> coding error in VTDAPI.VXD.
>
NOTE: This problem (and its fix) is now being turned over to the OS group's
quick fix engineering group for handling. If I can send out the fix, I
will.

2/7/99 Since we had not heard what steps had yet been taken we sent another request on 2/6/99 for an update; Microsoft responded on 2/7/99:

The windows group will be posting a fix for this at the winupdate web
site sometime in March. If you need it sooner, you'll have to work w/ our
evangilists to try to get it. I understand that the fix we provided to them
wasn't a 100% and more work is required. That may explain the delay of
posting.

4/9/99 Microsoft's fix for a similar clock error, the "49.7-day continuous-operation bug", appears to correct the system clock slowdown bug as well; the installer replaces vtdapi.vxd in the SYSTEM directory with a newer version. Short-term testing indicates this could be the resolution, but we are waiting on official word from Microsoft beforing closing this issue.
4/10/99 Microsoft's Paul Donlan has informed us the patch sufficiently rectifies the system clock slowdown problem, so this issue is resolved.

I have a windows 98se machine and there is no vtdapi.vxd in the windows/system directory. The update I downloaded does not support 98se. Any suggestion or help
Thanks

I too am running 98se like Scott and my situation is that every once in a while my clock will lose 1 hour exactly. The minutes are not impacted. This also happend before I upgraded to 98se from 98. The Gateway techs suggest I reformat my hard drive and put the original configuration back on the machine. Since I have changed the battery and upgraded the BIOS they are now telling me that it is a software problem. Several other techs were telling me the motherboard had a problem. I've read the literature from Microsoft and it doesn't sound like I fit in with the scenario they gave. If I remember right, they said the patch was not for the 98se version. I've asked Gateway to replace the machine and/or give me a new motherboard to try but they have refused stating that I need to reformat and not introduce any 3rd party software until the problem manafests itself again or several months have passed without losing time. I think I am leaving the Gateway family.

My system has been losing about 5 minutes every day and as days go by the system becomes sluggish to the point where the mouse becomes erratic. After reading the comments on the CMOS time problem on this site I decided to uninstall Norton System Works (ver. 2). For the 3 days following the uninstall my system has clock has slowed down only 40 seconds. I have a Toshiba lap-top, 233mhz, 64mb Ram running Windows 98
.

Nobody has posted the real answer for this problem yet, so I will give away the secret at last. APM-Advanced Power Management
This and/or an anti-virus program will cause this effect. I too was plagued by this in several PC's, but did what I always do--Instead of asking the guys that want you to think they no it all, I go to Microsoft's Knowledge Base and do a couple of queries and before long I have the answer I am looking for.
As a veteran of the PC wars, I encourage all up and comers to UTILIZE your RESOURCES. A few simple web searches reveal amazing amounts of information, and you do not have to sit and wait for an answer.

Lenny is right... I've had a couple of machines lose time and it was always anti-virus program. In particular, if you are running Norton, disable the auto-protect.

Why doesn't Norton have a direct answer for this? They know that Antivirus 2000 is causing a conflict with Windows 98. It is documented, but they keep sending me to a hundred different sites. Has anyone recieved a real answer from Symantec?

I've had the whole losing time problem with accompanied system lag... disabling Norton did not work for me (although it interests me that this may have contributed). After sitting on the phone with a tech-advanced friend, I did two things that resulted in the problem being fixed. (Unfortunately I do not know which was the cause nor do I care to play with this issue any more)
1. Went to NetworkNeighbourhood/Properties/Configuration and removed everything I didn't need (i.e. Dial up adaptor - I use cable, and old network card drivers) – be careful, but remove it if you don’t use it – consult a friend.
2. In that same place I looked at the properties of my TCP/IP settings and Disabled the WINS Resolution under the WINS Configuration Tab – don’t know what this is, don’t care.
All of a sudden… I got Time back, my siblings are no longer disappearing in the picture, the Libyans do not get the plutonium – all is good.
Good Luck