Random PC Freezing - no pattern

I didn't want to jinx anything, so I haven't provided an update. But I will now.

Still up and running after 17 hours on the M910t. That means so far it looks like the suggested "high performance" power plan tweak has certainly not been harmful, and if anything seems beneficial. Of course I've been this naively optimistic before, only to be eventually disappointed. So we'll see how much longer this goes. But for now it looks "promising". And as I mentioned I'm back to running full-Aida64 as well as PERFMON, which apparently are both not "culprits" but in fact were simply other "victims" of the underlying cause of the freeze.

If I can see the M910t remain up for at least 5 days I will begin to think I've actually accomplished something, and that maybe I'm finally out of the woods. Note that I have never seen this symptom on a Win10 machine (neither desktop nor laptop, both of which I routinely see up and running for weeks or more consecutively), but I suspect the power management of Win10 is much improved over that of Win7.

And yet, other than my own Win7 high-end desktop machines (running WMC), I have never ever seen the freeze symptom on any other Win7 machines for friends and family. Just like with my Win10 experience, all of these other Win7 machines routinely remain up indefinitely, for days or weeks or even months at a time (until I manually re-boot them for some reason), without any freeze.

So it's not necessarily something inherently problematic about Win7's power management if that does turn out to be the "solution" on my own desktop WMC machines. I suspect it's that my own desktop WMC machines are a bit more "tricked out" and in a much more sophisticated hardware/network environment, which perhaps brings to the surface the unintended consequences of running with the simple standard default power-plan setup which simply may not be adequate for a high-end high-performance desktop machine such as mine.

We shall see.


P.S. - turns out my ASUS machine finally pooped out and froze after 3 days 13 hours. I will re-boot it and make the same high-performance power plan tweaks on it as I've done on the M910t. So I'll have a second data point to draw a conclusion about whether or not this is simply something that might help, or something that will help.

We shall see.

M910t is now up 1 day 14 hours.

ASUS is now up 20 hours.

In fact, although I might have had the recommended "balanced" power plan previously selected for ASUS and "Thinkpad Default" previously selected for M910t, in fact I had actually modified a number of the items as previously described. For example I'd already previously disabled screen saver and monitor power-save, disabled all USB devices to prevent power management from putting the device to sleep to save power, disabled SLEEP and HIBERNATION, etc.

So going to "high performance" power plan changed almost nothing. So perhaps the fact that both machines have not frozen yet might just be luck, coincidence, and not proof of anything.

I looked at pretty much the one and only real difference in the prior power plan and current power plan, and it is in the "processor power management" group. With "high performance" the minimum is 100% and maximum is 100%. TomsHardware recommended tweaking the minimum to 7% so that's what I've gone with. The default for "balanced" and "Thinkpad Default" is 5%. Seems like this tiny difference is really too inconsequential to actually be of any real consequence, but I don't know.

Otherwise, I don't think there actually is anything else set with "high performance" that I hadn't already previously had in place. In fact I'm still going with spin-down of hard drive after 15 minutes, rather than disabling this as Toms recommended, and it doesn't seem to have been detrimental.

In other words, I really have to be honest in expecting that this power plan change won't actually return my machines to 100% stability. It's just a matter of time. Makes me crazy to look in on other Win7 machines that have now been up for 27 days and still counting, and I'm lucky to get 3.

ASUS is now at 1 day 11 hours, and M910t is at 2 days 5 hours.

This is genuinely unheard of in my recent history of the past few months. It is wonderful (even if it turns out to be short-lived) to be able to sit at either machine and do anything I want without fear, while watching TV via WMC extender wherever I happen to be, and not be shocked back to reality with the effects of a freeze on one machine or the other. I shouldn't be talking about this after only 1-2 days of non-freeze but it does feel like something might be going on here now that is different.

I looked more closely at the true differences between my own customized "balanced" plan previously in effect for ASUS vs. what is now in effect through "high-performance" customized slightly as suggested by TomsHardware. And there really are only two differences: (a) processor power management minimum being set to 7% instead of 5%, and (b) USB selective suspend setting which had been "enabled" and is now "never".

Now I'd already previously disabled all "allow the computer to turn off this device to save power" on all USB devices which had a power management tab available, so I'm not sure this "USB selective suspend" setting still has any action possible. But it was set to "enabled" and now it's set to "never".

How these two settings might account for those 6008 "unexpected shutdown" events which corresponded to each and every freeze, well I'm kind of just naturally skeptical.

Nevertheless the current zero-freeze results over the past day or two speak for themselves. There must be some explanation and it's not because of any less usage by me of the two machines. In fact if anything there is more TV usage from the M910t simply because it's actually been operating 100% for over two days now.

I was working today on two remote Win10 laptops (of friends and family) that I support, manually installing the October 1809 update which had not been automatically pushed out to these two machines. One of them had been up for 27 days, and the other had been up for 29 days, and of course this is what I'd always expected of my Win7 desktop machines as well... at least until these past 4 months or so.

The saga continues. Could the weather be improving? Sky clearing?? Sunshine coming?

Hi, I think I found a solution.

I have the same problem, my PC freezes ramdomly. I had updated the Nvidia driver for my 1080Ti. I installed the 418.81 WHQL version. Then I searched for a solution in google and I ended up here.

After reading this thread, I tried to reinstall the nvidia driver with the DDU method suggested by Guru3d

I did the following:
After downloading the program, you need to restart in safe mode and then run as administrator. In the main window I chose "Clean and restart" and once it restarted in normal mode (without any display driver) I installed an older version of the Nvidia driver, the 411.63 WHQL version.

This works just fine, the PC never froze again. I hope that this helps for you.

Regards.

mastropier0 said:

Hi, I think I found a solution.

I have the same problem, my PC freezes ramdomly. I had updated the Nvidia driver for my 1080Ti. I installed the 418.81 WHQL version. Then I searched for a solution in google and I ended up here.

I installed an older version of the Nvidia driver, the 411.63 WHQL version.

This works just fine, the PC never froze again. I hope that this helps for you.

Regards.

Actually, suspicious that a more recent NVidia driver for my GTX 1050ti might in some way be responsible for the freeze symptom I've been coping with for the past four months, as I mentioned I was doing a bit earlier in this thread I have already back-leveled my NVidia driver all the way to 391.35 which was released last year back on March 27 2018. I've been running that way for about two weeks now, but still have experienced the freeze. So I now don't think it's a factor.

However...

Not surprisingly, this morning my M910t finally froze again (after 2 days 19 hours), which I noticed at about 11:20AM. Aida64 was frozen at 11:02AM. Strangely, looking at the System Event log there was not the expected 6008 entry which would presumably mention an earlier "unexpected shutdown". When I manually powered down and then backup up and re-booted at around 11:55AM and eventually looked at the log, there was a 6008 entry but it was stamped at 11:55AM but made reference to an "unexpected shutdown" at 11:33AM. This has baffled me, since it seems this doesn't correspond to the Aida64 freeze at 11:02AM.

However looking more closely at the log, it turns out that this morning there was a whole stream of new 2017 "srv" error entries whose detail says "the server was unable to allocate from the system nonpaged pool because the server reached the configured limit for nonpaged pool allocations". Intermixed with these 2017 errors are a whole mess of 11 errors fromn "Disk" whose detail says "The driver detected a controller error on \Device\Harddisk2\DR2" as well as "The driver detected a controller error on \Device\Harddisk3\DR3". And there were still other 36887 errors from "SChannel" described as "The following fatal alert was received: 40".

These messages have actually been going on FOREVER, i.e. ever since way back in early January when I received my M910t and built it out and put it into production. I believe the references to Harddisk2 and Harddisk3 pertain to the two 3.5" SATA drives I removed from inside my now dead ASUS machine and installed in an external USB/SATA enclosure (connected via USB 3.0 to the M910t) for use with the new M910t. All of these messages suggest to me some kind of problem getting to these two external SATA drives in the USB enclosure I purchased.

But there are other indications that these disk-related errors commonly occur (in a continuing "rash") around 1AM when my nightly NovaBACKUP "incremental data" backup runs, and also at 5AM when my nightly Macrium Reflect "system image" backup runs and writes to a separate external USB backup drive in a second external USB enclosure.

In other words, I think this morning's freeze on the M910t was unrelated to and unaffected by the "high performance" power plan tweak I've been running with for the past 2-3 days. I think it occurred because of an accumulation of serious disk-related errors relating to access to my three external SATA/USB drives.

I don't know how I missed these serious errors on the log before today, but obviously I just never looked for them the right way. Anyway they have been occurring ever since day one. And my "error" log has 4250 entries going back to January 8!

So, I have now taken a new course correction to try and address these problems obviously created when I tried to retain usability on the new M910t of these two SATA "data" drives from my old now-dead ASUS machine through the use of what I thought would be a perfectly functional external SATA/USB enclosure that was highly rated and not cheap. And yet, something is clearly not right here.

My new approach today was to buy some replacement hardware:

(1) two new WD Black 4TB 256MB cache drives, to replace (a) the two old 2TB WD Black "data" drives in the 2-bay SATA/USB enclosure, and (b) the old 2TB Verbatim "backup" drive (actually a Toshiba SATA drive include the Verbatim enclosure). This will give me 2TB of increased capacity as well as much improved performance.

(2) two new external 1-bay enclosures providing both USB 3.0 as well as eSATA interface. Each of the new 4TB WD Black drives will go into one of the two new enclosures.

(3) StarTech ESATAPLATE2 adapter bracket to go into an available expansion slot on the rear of my M910t. This adapter has two internal SATA data cables which will connect to two currently available unused SATA connectors on the M910t motherboard. This will provide two new eSATA connectors on the rear of the M910t, which I will use to connect with two eSATA cables to the two new external USB/eSATA enclosures... which I'm going to be using in eSATA mode instead of USB 3.0 mode. Again, this will provide improved SATA-III max 6Gb/s performance for the new WD drives as compared to 5Gb/s max from the USB 3.0 interface which I'm no longer going to be using.

I'm obviously hoping that this hardware modification going from USB to eSATA for the three current SATA/USB external drives (which will be two eSATA external drives next week) will directly address and eliminate the massive stream of errors which apparently have been occurring ever since day one of my M910t tied to external SATA/USB drives.


In addition...

After seeing that my M910t had frozen at 11:02AM this morning, I went upstairs to check on ASUS. And sure enough it too had frozen. But its Aida64 had shown its freeze at 9:05AM (1 day 23 hours). Again, mysteriously, when I manually power-cycled and re-booted and looked at the system event log, the 6008 entry logged at 11:31AM made reference to an "unexpected shutown" at 11:22AM? Once again I couldn't relate this time to why Aida64 showed a freeze time back at 9:05AM.

Looking at the event log for "errors" there are no "disk" occurrences as there are on the M910t. The new 2-bay enclosure is only on the M910t. There is no similar box on the ASUS. However there is an external Verbtaim "backup" drive on ASUS which is connected via USB, but obviously it's not causing any issues (which might suggest it's due for replacement perhaps through eSATA this time).

Looking at the "SChannel" 36887 errors on ASUS (which also occurred on M910t), I think the time-of-day of these errors (which is around 2-2:30AM each night) suggests this is tied to the nightly MBAM anti-virus scan that occurs regularly around then. Don't know why there are "error" events being logged, but this could be just totally irrelevant to the freeze.


Anyway, for now until the new eSATA-facilitating hardware arrives next week I have taken several hopefully beneficial new actions:

(1) I've stopped running Green Button, which is the software that came with my Verbatim backup drives which spins-down the external Verbatim USB drive after 10 minutes of inactivity. Turns out it was also spinning down the other two "data" drives drives which resided in the new 2-bay external SATA/USB enclosure I was using on the M910t. So all three of these drives were being spun-down after 10 minutes, and thus had to be spun-back up the next time they were needed. If the disk controllers were "unhappy" with the unexpected delay, perhaps that is something that's not good and contributing to the rashes of "error" events being logged, perhaps eventually leading to a freeze.

So by no longer running Green Button presumably these external drives will never be spun-down any longer, thus making it no longer necessary to wait for them to spin back up when next needed

(2) I've gone ahead and changed the power plan for disk drives to show "never" rather than 15 minutes, for when Windows should spin down drives. Same thinking here as with the external USB drives and Green Button.


No idea yet whether these "temporary" measures might have a positive effect, but both machines have now been up again for about 16 hours since yesterday morning's dual-freeze.

We shall see.

At the very least, I believe converting from external USB to eSATA next week should have a positive effect on reducing what's going to the "errors" system event log, which seems like it has to help.

New eSATA bracket+cables and drives and external enclosures still arriving. Will be here by end-of-week. So I haven't yet gone from all-external USB 3.0 to all-external eSATA on my M910t, but this should be complete in a few moredays.

In the meantime I do report terrific results (again, naive optimism???) from my change two days ago mid-day on 2/9/2019 of no longer running the Green Button software which was supposedly managing the spin-down of my external USB 3.0 drives after 10-minutes of inactivity. And I also changed the "high performance" power plan option to NEVER spin down disks, from the 15-minutes it had been set to.

On ASUS I have one Verbatim external USB 3.0 drive (for backup) so this was the only drive being managed by Green Button. And on M910t I have one Verbatim drive and the new 2-bay Yottamaster USB 3.0 enclosure holding my two "data" drives, so on the M910t Green Button was managing three drives. Apparently it was the Yottamaster enclosure which although presumed acceptable for Green Button to manage, it actually was causing countless "disk error 11" occurrences. So I'm not convinced Green Button and the enclosure were truly compatible.

As you can see from the following screenshot from the system event log, there were about 3600 "disk error 11" occurrences on M910t since installing the machine 30 days ago back on 1/11 up through today. But also notice that between 2/9 (when I stopped running Green Button and set "sleep disk drive after inactivity" to NEVER) there have been ZERO!!! I'd say this issue has been addressed properly.



I'm still going forward with the upgrade from external USB to external eSATA, but for now am at least satisfied I've identified something about the Yottamaster enclosure that doesn't play nice with Green Button.

Interestingly, even though Green Button is no longer running on M910t (thus potentially leaving the Verbatim drive always spinning), I can hear the drives inside the Yottamaster enclosure actually spinning up when accessed after a long period of inactivity (and there is the associated delay from the program accessing that drive, waiting for it to become available). And this is without Green Button active to also theoretically spin down these drives. So I'm suspecting there is already something inside the Yottamaster enclosure SATA/USB interface electronics which is perhaps also doing its own spin-down/up management even without the involvement of Green Button software (which thus may be a software/hardware conflict causing the disk error 11 events I'm seeing). There's no question these two drives in the Yottamaster enclosure are absolutely occasionally spinning back up from a spun-down state, so there must be something causing the spin-down and spin-up and it's no longer Green Button.

Anyway, all these disk errors of the past month on "drive 3" and "drive 4" are now gone.

Also note that there was NEVER any such "disk error 11" on ASUS, which also uses a Verbatim drive and has always run Green Button software to manage it. So I believe the issue on M910t was that Green Button should not have managed the drives in the Yottamaster enclosure which appears to have its own hardware spin-down/up circuitry built into it.


On the second front, of actual "freezes", I was very disappointed two days ago after de-commissioning Green Button and setting "disk sleep" to NEVER on both ASUS and M910t that I still saw one more freeze on ASUS and two more freezes on M910t. But since the latest re-boots on both machines I've seen none (again, naive optimism???). So that's two days for ASUS and almost two days for M910t.

Here's the freeze record for ASUS over the past two weeks:



And here's the freeze record for M910t over the past two weeks:




I'm still going to proceed with the replacement of the Yottamaster USB 3.0 enclosure with two eSATA enclosures from OWC which will be connected to one open SATA connector and the open eSATA connector on the M910t motherboard through the StarTech 2-port eSATA backplane bracket. It will be interesting to listen and see if the SATA drives placed in the new OWC enclosures will also be spun-down automatically by the enclosure, since they will not be managed by Green Button and also I have "disk sleep" set to NEVER.

Haven't decided if I should stay with the Verbatim USB 3.0 drive on M910t, and also re-activate use of Green Button again on both M910t and ASUS (which NEVER had any disk error 11 events, as it never had an attached Yottamaster enclosure).

I'll sort out these decisions later this week after getting the new eSATA installation going.

You haven't heard from me for the past week, because I've simply been exhausted continuing with this ongoing battle which continues (or at least it DID continue, until two days ago). I did follow through with everything I intended to do, focusing on the new M910t and trying to get it to stabilize.

I did replace the one 2-bay USB Yottamaster enclosure with two OWC Mercury Elite eSATA enclosures, and also replaced my two old 2TB WD Black drives with new 4TB WD Black drives which now live in each OWC eSATA enclosure. I even replaced the external USB 2TB Verbatim drive with a new 4TB WD Black drive that I installed into one tray of the 2-bay Yottamaster enclosure, just to complete the drive updates and enclosure changes.

I also once again powered off and disconnected the ASUS machine, so that the M910t would be by itself in the environment. I disconnected the ehome USB infrared receiver used by the WMC remote, just on the off-chance it was one more USB device that I could eliminate to see if that made any difference.

I also completely stopped running Perfmon and Aida64, activated screen saver (so that I could at least be able to tell that a freeze had occurred if it did) but turned off power-save mode for the monitors. I also stopped running Verbatim's Green Button software (that only seems to work when its own enclosure/electronics is detected) since I'm no longer using the Verbatim external USB drive. I set "hard drive sleep" to NEVER, although that's not really how I would like to run.

I've been looking at the Windows Event Log regularly, researching every unexpected or surprising entry to see what might cause it, and if appropriate taking some suggested recommended action to eliminate it. This has been quite productive, with the events which continue to get generated at least now be understood and accepted as "normal" and non-critical.

And yet still... no matter what I did and how clever I thought I was, the M910t continued to freeze seemingly every few hours (but obviously not predictably or regularly). I was genuinely at my wits end, since I had just about run out of any remaining "removable" hardware I could unplug or temporarily disable, which might be contributing to whatever it was that was triggering the occasional freeze. Again, Windows itself was absolutely NOT FROZEN, since I was still able to connect to shared drives from my Win10 laptops even while the screen and keyboard and mouse-clicks on the M910t was truly frozen (but not the mouse cursor itself). If a WMC recording was in progress, it would typically continue throughout the freeze, although new recordings would not start on schedule as their time arrived. If a WMC playback was in progress at my second monitor, typically the sound would continue even if the screen had frozen.

Most annoyingly, the freeze would often occur at a time when essentially NOTHING WAS GOING ON except for the screensaver running around, maybe for hours. And then bingo, for absolutely no reason the screensaver would freeze. Just astonishing, and frustrating.


Well a few days I had one of these screensaver freezes, and decided to think about it some more. I had actually re-installed the latest 418.91 NVidia graphics driver (having been convinced that my experiment from a few weeks ago when I went back to 391.35 from 3/27/2018 did not accomplish restoring stability which I was sure I'd had last year, at least before this freeze problem began showing up on both my ASUS machines around mid-year so I thought). So there was really no reason to stick with the back-level NVidia driver when the latest one should potentially have important fixes.

I then reviewed history, and recalled that I absolutely had 100% stability (on both my ASUS machines at the time) during the summer of 2018 when I recorded (without any failure) every single day of the Tour de France, which is broadcast for three weeks every July. Even further back than that I also recorded virtually continuously and on as many as four channels simultaneously the two weeks of the Winter Olympics back in February 2018. Not a single failure.

So that meant something I did or changed after the summer must have been the "culprit" that began this instability. So this has been going on probably for the past 8 months, but not before that. It was also possible that some piece of hardware might have developed some flakiness after the summer, but not very likely to have happened on both my ASUS machines "simultaneously". Much more likely was a software upgrade after the summer, which I applied to both machines, which must be responsible.

This, of course, is what had prompted me to try going back to last year's Aida64 and NVidia graphics driver, when I know I had 100% stability and zero freezes at least through in July. Surprisingly, neither of those back-level software installs seems to have returned my stability, so I had let them both off the hook a few weeks ago as possible culprits... promising though it seemed that they were involved.

Well the other day when I saw my screensaver freeze when absolutely nothing was happening in the machine (and again I was NOT running Perfmon or Aida64), I decided that maybe I actually needed to go back even further with the Nvidia drivers, since I actually did have an even older 390.77 from 1/29/2018. For sure that version (or an even older version) must have been running back in February 2018 when I recorded the hundreds of episodes of Winter Olympics programs flawlessly over those two weeks. So maybe I should give that very old driver a shot.

Also, examining the Windows Event Log I noticed that there were some entries dealing with printer sharing not starting properly (although this didn't prevent printing on the ASUS host from other machines when the ASUS machine was still powered on). And I noticed that there were some entries seeming to deal with Microsoft Security Essentials, which is the anti-virus I run (along with Malwarebytes Premium).

So two days ago I decided to power back on my ASUS machine, and do some software maintenance on both the ASUS and M910t machines, both of which have the same GTX 1050ti graphics card and also both run MSE and MBAM. So I did (a) a "cold install" of that very old 390.77 NVidia driver from January 2018, (b) uninstall/reinstall of a fresh download from Microsoft of the latest MSE 64-bit version, and (c) uninstall/reinstall of my HP 2605dn printer driver with a fresh download from HP of the latest driver version. Did this on both machines... two days ago.

There has not been a freeze on either machine for two days. I've been using both machines normally, and doing all of my regular TV recording and playback, and no freeze for two days. Screensaver running around on both machines, and no freeze for two days.

Yes, I've been here before, but this one feels very very different. This feels very good. Of the three software things I did I would guess it's most likely that very old 390.77 NVidia driver from January 2018 which is the probably the key here, remembering that February 2018 was problem-free so for sure I could not have been using a newer driver than 390.77 at that time. Perhaps the reinstall of updated MSE and HP printer driver couldn't hurt, but it seems reverting to the January 2018 NVidia driver would be something much more likely to impact screensaver behavior and its freezing randomly.

I've also gone back to "disk sleep after 15 minutes" instead of NEVER, and have been running that way for these same two days... apparently without any negative consequence. I can hear the drives spin down when idle for a while, and I can hear them spin back up when needed... apparently without any negative consequence. I've gone back to reconnecting my ehome USB IR receivers for the WMC remotes on both machines, apparently without any negative consequence. I've gone back to plugging in the USB connecting cable to all of my Eizo monitors (so that their side USB ports are once again usable if I need them), apparently without any negative consequence. I've even gone back to powering off one of the two Eizo monitors on each PC, which I don't normally need unless I'm working on something special or watching TV at the HTPC while I'm working in which case I'll turn on that second monitor.

In other words for the past two days I've been running exactly as I always used to on my ASUS machine (which used to be my HTPC when I recorded the February 2018 Winter Olympics and the July 2018 TDF). And although the M910t is a total replacement of my now dead other ASUS machine, and almost all of the HDD spinner drives have been replaced and newly installed in external eSATA and USB enclosures, it is now functioning as my HTPC and configured exactly as my old ASUS machine was, and for the past two days it too has been flawless.


So, once again I don't really want to jinx this. And it's only been two days.

And I know I've been foolishly naively optimistic over the past few months during occasional bursts of seeming stability, only to have my hopes dashed when a new rash of freezes suddenly attacks both machines and will just not go away.

But this time it kind of feels different. My intuition says that maybe there really is some "good" that has been done by reverting to the late January 2018 NVidia driver. And although I know I must have upgraded the driver sometime later in the year as new versions were released, perhaps I just forgot about that until after the summer, so that I was running with that January 2018 driver for six months or so. And maybe upgrading beyond that January 2018 version to whatever NVidia put out next is significant in explaining my freeze story.

Anyway, time to close out this post with fingers crossed (again). Two days is only two days, and in my recent past even this is an accomplishment. If I make it on both machines to Wednesday without a freeze I will have set a new record for sure, since this whole freeze symptom started sometime on both of my Win7 desktop HTPC-enabled machines running GTX 1050ti graphics and two 1920x1200 Eizo monitors back in late summer 2018.


Oh... and on another note, I have also recently emerged victorious with my purchase of a Vantec external USB/SATA enclosure for my Panasonic 5.25" BluRay burner optical drive which I'd taken out of my now dead ASUS machine and wanted to use on the M910t, but didn't have an internal 5.25" front bay to use.

I was concerned because the Panny drive is 7.5" long with the front bezel attached, and the Vantec enclosure (which is larger than the comparable but slightly shorter OWC optical drive enclosure) says it only supports drives of about 7.25" in length. Miraculously, I was able to push the Panny drive all the way in (installed on the internal tray of the enclosure) and have just that little remaining .25" of the front bezel peek out a bit from the front open "nose" of the enclosure. This doesn't impact open/close tray performance at all and the drive works perfectly, and the all-black drive bezel plus the all-black metal enclosure makes it all look perfect. It looks like it was designed to have that .25" protrusion of the Panny front bezel showing.

So now I have an external BluRay drive attached to my M910t.

Yes... still no success.

But we now have another new thread omplaining of "Windows random freezes" reported by yet another user having the same problem. This time it's on a new ASUS laptop running Win7.

I've just posted my latest updated status and summary ramblings onto that thread, rather than here, just to try and consolidate new postings for this subject going forward.

Note that in addition to that new one plus this old one complaining of "random PC freezing no pattern", there is also yet another thread complaining of "computer freezing on screensaver exit" (which of course I've already talked about in my own assorted postings). I will add a similar comment at the end of that three as well, pointing to the "new thread" from today that I'd like to suggest we all use as an ongoing common discussion thread for this problem from today forward.

We're all experiencing the same symptom.

Everything I've tried recently has continued to NOT eliminate the freeze.

I've now taken a bit more extreme approach, being of the opinion that there must be something relating to the fact that my two failing Win7 machines are both HTPC's, enabled to run Windows Media Center and with TV tuner cards and related driver software installed. This makes my two PC's very unique, even though virtually all the rest of the non-WMC software on these machines is identical to all the other Win7 machines I maintain and which are NOT freezing.

Anyway, I know that there is an issue with Team Viewer 14, having a conflict with WMC when an extender session is active. Extenders connect to the HTPC via Remote Desktop Protocol (RDP), exactly as a human would "remote in" from home to an office machine using RDP techniques. I don't believe this problem existed in Team Viewer 13, but originated with TV 14 which came out last year after the summer. Suspicious timing with the beginning of my freeze symptom.

Anyway, I've now uninstalled Team Viewer completely.

Also, there was a major reported issue with freezing and Win7 caused by Malwarebytes late last year. Until they figured out what it was the suggested workaround was to back out to a previous version level, or to uninstall completely. The issue is now "fixed" but I'm not so sure.

So I've now uninstalled Malwarebytes Premium.

Also, to make up for the uninstalled Malwarebytes and resulting loss of protection (since I use Microsoft Security Essentials as my anti-virus), I've decided to just completely replace my protections with BitDefender Total Security.

So I've now uninstalled Microsoft Security Essentials, and installed BitDefender Total Security to replace MSE as well as Malwarebytes.

Let's see what happens.

DS, sorry to ask, but did you do the basic:
Check disk /f
Sfc /scannow
Memory test
system stress