PC Crashing
PC Crashing |
|
| log in |
Questions and Answers : Windows : PC Crashing
Previous · 1 · 2 · 3
| Author | Message |
|---|---|
The first thing that starts at the begining of a work unit is that fourier transform, which takes just a few minutes, during which the machine is responsive. The as it appears to go to the next step (can't remember what its called from the previous 5.15 version when it was working) the machine locks up. Well, logically if it were the program, it is coded the same way on everyone's machines (because it's the same app), so it would lock up everyone else's machine, correct? The program doesn't interface with the hardware directly (most Windows programs don't touch the hardware directly), so it can't be a hardware compatibility issue. The science app uses standard OS procedure calls, so an OS incompatibility could be an issue, but if the program runs fine on one OS of the same type, it pretty much rules out that possibility. Then it usually comes down to a hardware issue of some sort (overheating, slowly failing components, cheaply manufactured components not up to spec, and hundreds of other scenarios/possibilities). We have to find what's different from your machine which locks up from everyone else's machine that doesn't lock up (since they are all running the same app with the same code). What's interesting is that Uapel (above) is having what appears to be a similar issue under XP, on considerably newer hardware. Hmmmm. Yes, that is interesting. The machines I'm currently running with XP SP2 that haven't locked up are: Pentium 4 3GHz (two machines) AMD Athlon 1.4GHz Classic Intel Pentium III 1.4GHz Core 2 Duo (XP x64) AMD Sempron 3400+ AMD Athlon XP 2600+(XP Media Center Edition) Intel Pentium M 1.8GHz notebook Again, the same logic applies. If we're all running the same code, then a bug in the program is unlikely. Your issue seemed unique because it was an entirely different OS so it could have been a compatibility issue with the OS, but I've got three Win98SE machines (I've only used the one so far - I've got two more) that don't show any issues. The science app can stress different parts of the CPU in different ways (stress=heat output). Are your system temps OK? Maybe to help eliminate at least one possibility would be to suggest attaching to another project to see if that one locks up your CPU. This will remove the science app as one possibility (and also the WU headers per your theory). ____________ | |
ID: 639447 ·  | |
|
strange behaviour! | |
| ID: 639471 · | |
I've been running S@H for a couple years now, since upgrading from the old classic version, with no problems. All of a sudden in the last couple days my PC would lock up a few moments after the screen saver stated. This coincided with what appeared to be the software updating itself (?) to version 5.27. I'm running a pretty clean installation of Win98SE, and have eliminated all other causes. I've had to disable it until I can figure out a solution. Any help would be appreciated. Very few people use windows 98, and SE was renowned for its bugs. As time and technology changes not many software engineers consider the very old operating systems (98 is now 9 years old!) I think the problem may lie with your old operating system, consider upgrading! | |
| ID: 639567 · | |
Very few people use windows 98, and SE was renowned for its bugs. Actually Win98SE was an excelent OS, just not as tolerant of poorly behaved programmes as WinXP is. You're probably thinking of WinME which didn't have the best of reputations. ____________ Grant Darwin NT. | |
| ID: 640132 · | |
Very few people use windows 98, and SE was renowned for its bugs. Yep, that nails it. I have never had any problems (until now) with Win98SE. Most of the problems (with any OS) are poorly behaved apps, and not keeping your system clean. Regarding Boinc, I would not even think of running an app like this on Win98SE, if the posted requirements did not explicitly say "Windows 98 or later", as they do. Now back to solving this ... | |
| ID: 640674 · | |
Maybe to help eliminate at least one possibility would be to suggest attaching to another project to see if that one locks up your CPU. This will remove the science app as one possibility (and also the WU headers per your theory). That's an interesting possibility, which I may try when I have some time. But, the fact still remains that it did work with another science app -- version 5.15 of seti. And still does if I clone my old preserved drive image. If I boot the image of my entire system as it was before the switch to 5.27, and have the clock set back to that time, and have the internet unplugged, the old app runs just like it has forever. As soon as the download & upgrade of 5.27 occurs, and it shortly after it starts one of the new-style WUs, blam. The system is locked up. The only thing that changes is the new science app. But connecting to a non-seti project may be an interesting experiment. Jeff | |
| ID: 640684 · | |
|
I have resolved most of my BOINC crashing problems updating manually the MS .Net FrameWork to the last version possible. | |
| ID: 669046 · | |
|
John McLeod VII Volunteer developer Volunteer tester  Send message Joined: 15 Jul 99 Posts: 22343 Credit: 439,209 RAC: 396  | |
I have resolved most of my BOINC crashing problems updating manually the MS .Net FrameWork to the last version possible. Now that is a solution I have not thought of. As far as I know, BOINC does not use .NET (scratches head). ____________   BOINC WIKI | |
| ID: 669115 · | |
Questions and Answers : Windows : PC Crashing
| Copyright © 2013 University of California |
