Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations TouchToneTommy on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Slow Clock 1
- Thread starter LDaveM
- Start date
Dave;
When the CMOS battery on the motherboard is getting low, the first thing to be affected is the system clock.
Ed Please let me know if the suggestion(s) I provide are helpful to you.
Sometimes you're the windshield... Sometimes you're the bug.
When the CMOS battery on the motherboard is getting low, the first thing to be affected is the system clock.
Ed Please let me know if the suggestion(s) I provide are helpful to you.
Sometimes you're the windshield... Sometimes you're the bug.
- Thread starter
- #3
Crustyoldbloke
Technical User
Hello Dave
Is this the same PC that you complained of on 5th. December?
You may have opened up a can of worms here. My understanding is that the clock in BIOS gives the OS clock the time on boot up. Ergo, if the time is right at boot up, then the CMOS battery is OK and it is the OS causing the problem.
Some people say that AV application and/or APM (Advanced Power management) is to blame. However, have a read of the following from someone who really has investigated this phenomenom.
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 website 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.
So now you know!
Error! Keyboard not attached. Press F1 to continue
Phil
Si fractum non sit, noli id reficere.
Is this the same PC that you complained of on 5th. December?
You may have opened up a can of worms here. My understanding is that the clock in BIOS gives the OS clock the time on boot up. Ergo, if the time is right at boot up, then the CMOS battery is OK and it is the OS causing the problem.
Some people say that AV application and/or APM (Advanced Power management) is to blame. However, have a read of the following from someone who really has investigated this phenomenom.
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 website 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.
So now you know!
Error! Keyboard not attached. Press F1 to continue
Phil
Si fractum non sit, noli id reficere.
- Thread starter
- #5
This is one of the problems I've seen, 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 compter.
So, do I replace the vtdapi.vxd file? Where do I find it, MS?
Thanks for the info and I'm sorry about the "can of worms."
Yes this is the same ad th 12/5/2002 entry, as I forgot that I enter it here.
Dave
So, do I replace the vtdapi.vxd file? Where do I find it, MS?
Thanks for the info and I'm sorry about the "can of worms."
Yes this is the same ad th 12/5/2002 entry, as I forgot that I enter it here.
Dave
- Thread starter
- #6
-
1
- #7
Dave,
The problem described above was an issue that existed on earlier versions of Win98. Even with the modified vtapi.vxd, Win95/98/SE/ME are all still vulnerable to losing time. The reason varies from pc to pc.
When your pc loads, the time in the CMOS is synched with the time in Windows. After this "synch" takes place, Windows is on its own. It will never read the time from the CMOS again until you reboot or change the time manually. So, Windows uses a 'software' clock to keep track of time. Since Win98 is less efficient than say Win2K with resource management, there are many memory leaks. The longer you leave a Win98 pc on with apps running in the background, the more time it's going to lose.
The 'software' clock may occasionally get interrupted by other processes as resources start to run low. Each interruption causes it to lose milliseconds, which eventually leads to minutes then hours.
If rebooting fixes the time, then you know the CMOS battery is not the problem. You might be faced with using a newer OS like Win2K or WinXP if you want better resource management. Win98 just isn't cut out to be left running for extended periods of time...
~cdogg
"The secret to creativity is knowing how to hide your sources."
- A. Einstein
The problem described above was an issue that existed on earlier versions of Win98. Even with the modified vtapi.vxd, Win95/98/SE/ME are all still vulnerable to losing time. The reason varies from pc to pc.
When your pc loads, the time in the CMOS is synched with the time in Windows. After this "synch" takes place, Windows is on its own. It will never read the time from the CMOS again until you reboot or change the time manually. So, Windows uses a 'software' clock to keep track of time. Since Win98 is less efficient than say Win2K with resource management, there are many memory leaks. The longer you leave a Win98 pc on with apps running in the background, the more time it's going to lose.
The 'software' clock may occasionally get interrupted by other processes as resources start to run low. Each interruption causes it to lose milliseconds, which eventually leads to minutes then hours.
If rebooting fixes the time, then you know the CMOS battery is not the problem. You might be faced with using a newer OS like Win2K or WinXP if you want better resource management. Win98 just isn't cut out to be left running for extended periods of time...
~cdogg
"The secret to creativity is knowing how to hide your sources."
- A. Einstein
- Thread starter
- #8
No, it's not common. However, I have seen some extreme cases like yours where some were losing as much as 2-3 hours per day. So, it just depends. In these type of situations, the cause is usually apps/processes that are left running in the background. For one reason or another, one or more of them are sucking your resources dry over a short period of time.
Let's face it. Win98 is not an OS known for it's accountability. Just about every 98 pc I've come across has a quirk or two about being left on for long periods of time. Sometimes tweaking the hell out of it can help slow the process. However, no amount of tweaking will prevent this OS from dying a short death!
![[bomb]](/data/assets/smilies/bomb.gif "[bomb] [bomb]")
If you insist on staying with 98, maybe because it's the only option you have at this point, then try the following and see if it helps:
1) Monitor your system resources (right-click My Computer, Properties, Performance). Immediately after booting up your computer, there should be at least 75% free (80% is better, and 90% is preferred). After a few hours of idle time, monitor this reading again. If it has dropped at all, then you've got a memory leak that will only get worse after a few days.
2) To find where memory leaks are coming from, simply use the "process of elimination". Maybe for 1 day, go without the backup app(s) running in the background. Another day, try going with McAfee disabled. Do this with all your main apps until you find the culprit that's draining resources - there may be more than one.
3) Try setting a contiguous swap file that stays static in size. With 256MB of RAM, any size will do. I recommend at least 128MB swap file, but you may want up to 384MB. Opinions will vary and there is a ton of info on the net.
4) Try partitioning your hard drive leaving a small system partition (C
with less than 10GB for system files and critical programs. Use another partition (D to store the swap file, data, and all other programs/games. It might be best to go ahead and format/reinstall 98 while you're at it to get a fresh start.
Even if you find the program causing all your migraines, you'll probably still want to use it. So, you're best bet in the end will likely be to upgrade the OS to 2000 or XP anyway!
![[thumbsup2]](/data/assets/smilies/thumbsup2.gif "[thumbsup2] [thumbsup2]")
~cdogg
"The secret to creativity is knowing how to hide your sources."
- A. Einstein
Let's face it. Win98 is not an OS known for it's accountability. Just about every 98 pc I've come across has a quirk or two about being left on for long periods of time. Sometimes tweaking the hell out of it can help slow the process. However, no amount of tweaking will prevent this OS from dying a short death!
If you insist on staying with 98, maybe because it's the only option you have at this point, then try the following and see if it helps:
1) Monitor your system resources (right-click My Computer, Properties, Performance). Immediately after booting up your computer, there should be at least 75% free (80% is better, and 90% is preferred). After a few hours of idle time, monitor this reading again. If it has dropped at all, then you've got a memory leak that will only get worse after a few days.
2) To find where memory leaks are coming from, simply use the "process of elimination". Maybe for 1 day, go without the backup app(s) running in the background. Another day, try going with McAfee disabled. Do this with all your main apps until you find the culprit that's draining resources - there may be more than one.
3) Try setting a contiguous swap file that stays static in size. With 256MB of RAM, any size will do. I recommend at least 128MB swap file, but you may want up to 384MB. Opinions will vary and there is a ton of info on the net.
4) Try partitioning your hard drive leaving a small system partition (C
with less than 10GB for system files and critical programs. Use another partition (D to store the swap file, data, and all other programs/games. It might be best to go ahead and format/reinstall 98 while you're at it to get a fresh start.Even if you find the program causing all your migraines, you'll probably still want to use it. So, you're best bet in the end will likely be to upgrade the OS to 2000 or XP anyway!
~cdogg"The secret to creativity is knowing how to hide your sources."
- A. Einstein
1>when defragging to deal with sys resources, does the type of defrag (reorder and defrag, quick defrag, etc ) make any difference?
2> how critical is the 2 partition approach to dealing with the problem and what does "critical programs" include?
3> Does Norton Corporate antivirus have the potential to be one of the drainers-if so any particular insights for that particular application?
2> how critical is the 2 partition approach to dealing with the problem and what does "critical programs" include?
3> Does Norton Corporate antivirus have the potential to be one of the drainers-if so any particular insights for that particular application?
1) Defragging normally speeds up disk access time (i.e. loading apps, storing data, etc.), but doesn't usually affect how fast your resources drain. If it takes your hard drive longer to locate a particular file because it's fragmented, no resources are spared - it just takes longer. But since you bring it up, you don't need to do a "reorder and defrag" every time. Just make sure you do it every so often and use quick defrag in between to save time.
2) The 2 partition approach isn't that "critical" to resolving this problem. However, it helps speed up your defrag time since you can choose between your system partition and your data partition, not having to do it all at once. Also, it helps to have the swap file on a separate partition, especially when trying to make it contiguous.
3) Not sure since I haven't used the corporate version. In the office, we use Mcafee. I can tell you that Norton AV 2003 Home Edition uses new processes like CCAPP and CCEVTMGR that use up a lot of resources at startup. For example, I usually might have 85% at startup. With the new 2003 NAV, resources dropped a whopping 10% down to 75%.
~cdogg
"The secret to creativity is knowing how to hide your sources."
- A. Einstein
2) The 2 partition approach isn't that "critical" to resolving this problem. However, it helps speed up your defrag time since you can choose between your system partition and your data partition, not having to do it all at once. Also, it helps to have the swap file on a separate partition, especially when trying to make it contiguous.
3) Not sure since I haven't used the corporate version. In the office, we use Mcafee. I can tell you that Norton AV 2003 Home Edition uses new processes like CCAPP and CCEVTMGR that use up a lot of resources at startup. For example, I usually might have 85% at startup. With the new 2003 NAV, resources dropped a whopping 10% down to 75%.
~cdogg
"The secret to creativity is knowing how to hide your sources."
- A. Einstein
cdogg
thank you for being kind enough to give me some "answer time" even though I wasn't the originator of the post. That has been helpful to me in thinking about my machine.
When I first started looking at this site, I was having a terrible time getting into it and keeping screens up. Since the search functions weren't working, I just attributed it to site maintenance. One day I happened to try the search again while I was having trouble, and the search worked. That and some of your comments above have led me to wonder if the issue is not resources. ( also happened to notice the other day - 5 min before a crash, running internet radio, an accting app, and whatever else dumps into my machine that I was down in the low 60s.) I have compounded my machine's problems by, after reading posts in another forum, deciding to install a win31 version of lotus smartsuite. I have experienced (particularly for an unexperienced user) an interesting assortment of dll, general protection, and printing problems, as well as trashed printer drivers and acrobat files. The other posts continue to make it look as though i'm in a minority (in regard to having problems with an installation like that) and i'll probably continue out of stubborness, but I think I have probably made significant contributions to destabilizing my machine and should be starting to plan for a reinstall at some point, hence the questions about the two partitions.
I think in this and other posts you've also answered another curiosity i've had, would an upgrade to ME help me to be more able to have internet radio going as well as my other work. (that would be NO.)
If i go to a dual partition setup, I will be doing something not present on other systems in the company and will be totally on my own as far as trouble shooting and support. I have an old QUE version of drive image and somewhere if i can find it again an old version of Norton Ghost. Although I've not been using them right now; I think I understand that with just one drive/partion I can use those tools to make restorable images of my initial restart, and then make backups later.
I don't know how I properly use those tools to keep out of trouble if I have two partitions. Is there some brief advice you could give me about that?
Dave H.
thank you for being kind enough to give me some "answer time" even though I wasn't the originator of the post. That has been helpful to me in thinking about my machine.
When I first started looking at this site, I was having a terrible time getting into it and keeping screens up. Since the search functions weren't working, I just attributed it to site maintenance. One day I happened to try the search again while I was having trouble, and the search worked. That and some of your comments above have led me to wonder if the issue is not resources. ( also happened to notice the other day - 5 min before a crash, running internet radio, an accting app, and whatever else dumps into my machine that I was down in the low 60s.) I have compounded my machine's problems by, after reading posts in another forum, deciding to install a win31 version of lotus smartsuite. I have experienced (particularly for an unexperienced user) an interesting assortment of dll, general protection, and printing problems, as well as trashed printer drivers and acrobat files. The other posts continue to make it look as though i'm in a minority (in regard to having problems with an installation like that) and i'll probably continue out of stubborness, but I think I have probably made significant contributions to destabilizing my machine and should be starting to plan for a reinstall at some point, hence the questions about the two partitions.
I think in this and other posts you've also answered another curiosity i've had, would an upgrade to ME help me to be more able to have internet radio going as well as my other work. (that would be NO.)
If i go to a dual partition setup, I will be doing something not present on other systems in the company and will be totally on my own as far as trouble shooting and support. I have an old QUE version of drive image and somewhere if i can find it again an old version of Norton Ghost. Although I've not been using them right now; I think I understand that with just one drive/partion I can use those tools to make restorable images of my initial restart, and then make backups later.
I don't know how I properly use those tools to keep out of trouble if I have two partitions. Is there some brief advice you could give me about that?
Dave H.
- Thread starter
- #13
cdogg,
Here's the latest, I shut down the AV and the system still lost time. Next, I shut down the backup, Veritas backup Exec, and the time was ok. Also, after rebooting, The sys was at appx. 85% free, after 2 days it was down to 75%.
Is there 2 problems, maybe the RAM is leaking a little, causing the slow clock?
Thanks,
Dave
Here's the latest, I shut down the AV and the system still lost time. Next, I shut down the backup, Veritas backup Exec, and the time was ok. Also, after rebooting, The sys was at appx. 85% free, after 2 days it was down to 75%.
Is there 2 problems, maybe the RAM is leaking a little, causing the slow clock?
Thanks,
Dave
If you have processes running constantly in the background, it's not uncommon for the resource percentage to drop 10% in just 2 days. As a matter of fact, that's not too bad if the pc is doing more than just sit there. I've seen idle pc's lose as much as 5% a day in resources running Win95/98.
The problem isn't anything physically wrong with your hardware. Instead, you're using one or more programs poorly written for the Win98 operating system - like you've discovered with the Veritas backup software. Either it's poorly written, or the program is "taxing" your system to a point that it cannot handle the strain. I suggest writing a batch file that will execute and restart your computer after the backup process completes. Alternatively, there are literally thousands of utilities out there that can do this for you (set to the clock).
How much are you using the system on a daily basis, besides the backup software? If you've got the patience, CTRL-ALT-DEL and end-task on every process except Explorer. If you leave the pc sit idle for 2 days and you still see a steep drop in resources, then something else may be the issue. However, seems like a software issue to me...
~cdogg
"The secret to creativity is knowing how to hide your sources."
- A. Einstein
The problem isn't anything physically wrong with your hardware. Instead, you're using one or more programs poorly written for the Win98 operating system - like you've discovered with the Veritas backup software. Either it's poorly written, or the program is "taxing" your system to a point that it cannot handle the strain. I suggest writing a batch file that will execute and restart your computer after the backup process completes. Alternatively, there are literally thousands of utilities out there that can do this for you (set to the clock).
How much are you using the system on a daily basis, besides the backup software? If you've got the patience, CTRL-ALT-DEL and end-task on every process except Explorer. If you leave the pc sit idle for 2 days and you still see a steep drop in resources, then something else may be the issue. However, seems like a software issue to me...
~cdogg
"The secret to creativity is knowing how to hide your sources."
- A. Einstein
- Status
Similar threads
- Locked
- Question