Random PC Freezing - no pattern

[dsperber]

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.

 

[dsperber]

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.

 

[dsperber]

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?

 

[mastropier0]

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.

 

[dsperber]

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.

 

[dsperber]

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.

 

[dsperber]

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.

 

[dsperber]

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.

 

[dsperber]

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.

 

[Megahertz07]

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

 

[dsperber]

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

Good question. The answer is no, at least not in a systematic way.

And while I am suspicious of the ASUS Z170-Deluxe motherboard in what was my original HTPC desktop machine on the LAN, all of my work of late has been specifically on my brand new (not 3 months old yet) Lenovo M910t second HTPC desktop machine running "isolated". I have powered off the Z170 so it doesn't even appear on the network, at least until I can hopefully re-establish 100% 24/7 stability for the M910t running standalone, all by itself, with no other possible LAN-related handshakes to possibly be factors.

Every so often I may fire up one of my two Win10 laptops, but they don't seem to be factors in the freeze story and also seem to be completely immune to ever freezing themselves... despite the fact that they run EXACTLY the same collection of assorted 3rd-party A/V, anti-malware, remote connectivity and hardware monitoring software products as both of my failing Win7 desktop machines do and as do all of the other Win7 machines do that I maintain remotely for friends and family.


On several occasions the re-boot of M910t was forced at such a time that when I came back up there was an automatic CHKDSK. But that was random and very rare, and even then was only on C (which is M.2 NVMe SSD) so it's not going to discover "bad spots on disk" but rather only file system errors if any. And I've not actually ever seen anything fixed, that I can recall.

But for sure, I haven't run CHKDSK on ALL of my partitions of all my physical drives, some of which are also on NVMe SSD and the rest of which are on HDD spinners. However two of my original 2TB WD Black drives (partitioned MBR) that were probably more than 5 years old have very recently been replaced (as part of the general approach on this freeze-eliminating effort) with brand new 4TB WD Black drives (partitioned GPT). Because the M910t doesn't have more than one internal 3.5" bays these two 4TB drives are connected through two eSATA external enclosures.

I've also replaced the Verbatim 2TB external USB/SATA 3.0 drive I use for backups (which itself is also perhaps 5 years old) with another brand new 4TB WD Black drive (partitioned GPT) enclosed in another USB 3.0 external enclosure.

I have one more internal 6TB WD Black drive (partitioned GPT) that is perhaps three years old, and which was not replaced.

Anyway, I have not run CHKDSK systematically across ALL of the partitions C-M on my M.2 NVME SSD and four HDD spinners. But I'll put it on the to-do list.


As far as SFC goes, I have actually run that several times, even though this is a Lenovo-generated new Win7 Pro x64 machine. The log showed that just about anything which needed repair was repaired, other than a very small handful of errors which I didn't fully understand but appeared directly related to Windows Media Center files.

After a second SFC run, these rew WMC-related messages remained. I took this to be "normal", perhaps because of the WMC EHRECVR task that's always active or something like that.

Haven't run SFC very recently, and I'm not sure the log is supposed to be 100% error-free or if the few messages that did appear are "normal and acceptable" or perhaps indicative of possible root cause culprits for the freeze symptom.


Definitely have not run MEMTEST or any stress testing. Again, this is a brand new Lenovo M910t machine with brand new Lenovo-provided 2x8GB=16GB of memory (Samsung DDR4-2400 and Hynix DDR4-2666, both slowed down by BIOS to run at Skylake DDR4-2133 speed). So I have no suspicion that memory is at fault here.

And besides, the freeze symptom was already occurring with the predecessor homebuilt ASUS P8Z77-V Pro HTPC machine (before it died and was replaced by the M910t). There was physically different memory in that older ASUS machine.


Anyway, M910t has now been up about 8 hours since its last re-boot following the uninstall of Team Viewer 14, Malwarebytes Premium 3.7.1 and MSE, and the brand new 1st-time install of BitDefender Total Security.

Fingers crossed.

But unless these three software products (or at least one or two of them) are actually the "culprit", I won't have a good feeling until I pass three days of freeze-free operation. Over the past 8 months I've managed to at best make it to just over two days between freezes, with worst case of being unable to even complete a re-boot and making it to a stable Windows desktop before freezing.

So something VERY fundamental is obviously responsible for the freeze symptom. And it has to be a basic common component on three otherwise different Win7 machines both new and old, all of which have multiple internal drives with multiple partitions on each drive, and have Ceton/Hauppauge TV tuner cards and run WMC, and all of which run the same 3rd-party software products, all of which have external USB 3.0 backup drives, and have NVidia GTX 1050ti graphics and two Eizo monitors and use Logitech MX wireless mice and IBM PS/2 keyboards running through an Adesso PS/2->USB adapter.

I'm hoping that by temporarily shutting down my ASUS machine and letting the M910t run by itself on the LAN, that I will at least eliminate possible network-based causes for the moment. Whatever continues to cause the freeze must therefore be "local" to the M910t, making it hopefully easier to chase down... although it's now been 8 months without success.

 

[Megahertz07]

I have seen this kind of issue due to chipset failure.
Try to make it simple as possible.
- Detach all drives leaving on only the OS drive.
- If you have overclock, disable it.
- On BIOS, set the main clock from 100MHz to 80MHz.
Run it for a while. If it doesn't freeze, undo the changes step by step.

 

[dsperber]

Anyway, M910t has now been up about 8 hours since its last re-boot following the uninstall of Team Viewer 14, Malwarebytes Premium 3.7.1 and MSE, and the brand new 1st-time install of BitDefender Total Security.

Fingers crossed.

But unless these three software products (or at least one or two of them) are actually the "culprit", I won't have a good feeling until I pass three days of freeze-free operation. Over the past 8 months I've managed to at best make it to just over two days between freezes, with worst case of being unable to even complete a re-boot and making it to a stable Windows desktop before freezing.

So something VERY fundamental is obviously responsible for the freeze symptom. And it has to be a basic common component on three otherwise different Win7 machines both new and old, all of which have multiple internal drives with multiple partitions on each drive, and have Ceton/Hauppauge TV tuner cards and run WMC, and all of which run the same 3rd-party software products, all of which have external USB 3.0 backup drives, and have NVidia GTX 1050ti graphics and two Eizo monitors and use Logitech MX wireless mice and IBM PS/2 keyboards running through an Adesso PS/2->USB adapter.

I'm hoping that by temporarily shutting down my ASUS machine and letting the M910t run by itself on the LAN, that I will at least eliminate possible network-based causes for the moment. Whatever continues to cause the freeze must therefore be "local" to the M910t, making it hopefully easier to chase down... although it's now been 8 months without success.

Very good news!

M910t:

Z170:

After M910t made it to about 2 1/2 days without a freeze, I got cocky and decided to bring Z170 back up , in order to uninstall the same delete Malwarebytes 3.7.1 and MSE, and install Bitdefender.

And sure enough, it is now about 3 1/2 days on M910t and about 1 1/2 days on Z170, without any freeze or other anomaly. This is truly unheard of over the past 8 months. It honestly looks as if total normal operation and 100% stability has returned... to BOTH machines.

==> After thousands of dollars spent on new and replacement and upgraded hardware (thinking it was failing hardware), and hundreds of hours spent in try to swap things in and out, turn things off and on, etc., trying to determine exactly what single factor made any difference and therefore was probably relevant, it comes down to Malwarebytes which appears to be the culprit.

Apparently, in my opinion, the "Win7 freeze" problem with the product which started late last year seems to have been much more applicable to my own unique WMC Win7 machines than to other people's machines. When Malwarebytes claimed that after one month of research they had finally isolated and corrected the underlying defect they themselves had given birth to in a version upgrade which came out late last year, my guess is that they didn't test this on a WMC machine. My guess is that the same (or unwittingly remaining) bug wasn't completely fixed after all, and it is this which has been the source of my own "freeze" symptoms for the past 8 months.

At least that is the theory I'm now operating under. And all I can say is that with Malwarebytes (and MSE) now completely uninstalled on all four of my machines, and Bitdefender Total Security 2019 now installed (on both my Win7 WMC desktops and both Win10 laptops), I have now been freeze-free for almost 4 days. Unheard of over the past 8 months.

I had honestly thought Malwarebytes to be "above reproach", and that when the software vendor claimed "it is fixed"... that this was true. Apparently not so much.

 

[Megahertz07]

The main problem with Malwarebytes is that it's a memory resident program.
The free version is the same as the paid one but it isn't active. And it can conflict with other antivirus.

I have Avira free antivirus and I have superantispyware free that I run regularly.
SUPERAntiSpyware Free Edition

 

[dsperber]

Just wanted to post an update...

M910t continues to run freeze-free ever since installing Bitdefender to replace MBAM + MSE. It's now been ALMOST 20 DAYS of uninterrupted 24/7 100% stable operation. Obviously I finally discovered the culplrit for my unique Win7 desktop HTPC/WMC machines, and that culprit was MBAM.

I started a thread on the Malwarebytes Forum to talk about this freeze symptom and my discoveries. and appear to have attracted one of their technicians who invited me to help shoot this bug if I was willing, by temporarily uninstalling Bitdefender and reinstalling MBAM + MSE on my ASUS machine and hopefully recreating the freeze. Since I'd already established stability on M910t which is my production HTPC, I had no problem turning my ASUS machine into a lab animal for a while, in order to really get to the bottom of what is causing the freeze.

He provided me with instructions on how to produce a forced BSOD and resulting complete memory dump when a freeze occurs, and sure enough within 12 hours of reinstalling MBAM I had a freeze event occur from which a dump was produced that I sent to him. I also was able to produce two more freezes (with different circumstances), and passed along the additional two dumps for his analysis. So we've been working on this for a week now.

Turns out his analysis points to Macrium Reflect and its CBT technology as very much involved with the freeze and the likely culprit, as opposed to MBAM being at fault. He had seen this clue before, but now with my new dumps he was really convinced.

So I opened a ticket on the Macrium Reflect site, and was very fortunate to have a lead programmer from their CBT development team get assigned to handle the ticket. I provided him with the same three dumps I'd given to Malwarebytes, for his analysis. Although he was initially somewhat confused about exactly what the Malwarebytes people had found that pointed to Macrium Refllect as the culprit, he dove right in to see what the dump revealed.

Lo and behold, he is sure he's discovered what was going on:

"After performing analysis on the crash reports that you sent, it appears that your system has processed a rather complex series of events that has lead to a race-condition between the Malwarebytes product and our MRCBT.SYS driver during a file-system TRIM operation.
We are still performing analysis, but in the mean time, we have implemented a workaround for this situation and I am pleased to provide links (below) to an updated driver that should stop your computer(s) from freezing."

There are still many questions that need answering, but for now there does appear to be a genuine temporary software fix for Macrium Reflect, for something it is doing that appears "in conflict in some way" with something that MBAM is doing, which ultimately is responsible for the freeze. By sidestepping in some way the perceived incompatibility, the expectation is that the freeze symptom should disappear completely.

I've installed their temporarily patched MRCBT.SYS on ASUS, and it's now about 7 hours in and no freeze. I won't have any real confidence until at least 2-3 days have gone by, or even 7 days. But it does appear that rather than "failing hardware" causing the freeze, it seems to have been "conflicting software product recent engineering changes" (from both products) which is why I first saw the freeze starting about 8 months ago when significant changes were made to both products. This makes a great deal more sense (since I used both products on all three of my Win7 desktop HTPC/WMC machines) that coincidental failing hardware on three separate machines.

I will still likely go back to Bitdefender on ASUS when this is all over, rather than MBAM + MSE, since I've already bought a 5-pack licens for my machines and I'm completely satisfied with its fault-free performance on M910t. But at least it looks like whatever it was in Macrium Reflect that was incompatible with MBAM will be fixed.

Freeze gone. Happy days are here again.

 

[dsperber]

Final postscript on this issue. For me, it has now been 100% resolved based on either (a) using Bitdefender instead of MBAM + MSE, or (b) installing the test fix to MRCBT.SYS provided by Macrium Reflect support. This test fix has now been confirmed to solve the problem through almost two weeks of freeze-free experience with Bitdefender getting uninstalled and MBAM + MSE reinstalled.

So there was a genuine software conflict on SOME Win7 systems (all three of my HTPC machines were super-vulnerable for some reason, probably not just a coincidence) between how MBAM works and how Macrium Reflect's CBT technology works. And it turns out Macrium was able to make a simple but obviously significant change to their CBT driver which eliminated this conflict completely.

So, case closed. I've now once again uninstalled MBAM + MSE and reinstalled Bitdefender, which I have decided to go forward with on all of my own personal Win7 and Win10 machines having purchased a 5-seat license.

For technical closure, here is the detailed explanation from Macrium Reflect about what they discovered from the freeze-dumps I sent them, and what they did to overcome the potential conflict with how MBAM works.

=======================================================

Firstly, taking everything into account, I can see no flaw in what you have been advised by Malwarebytes, however; we have never seen this issue arise in any of our testing, nor has it been reported to us by any other customer. As such, we can only go off the information in the dump files you sent.

Basically, the state of your system at the point the dump file was generated, show that the Malwarebytes product had asked Windows to Unload a Registry hive (database of Registry key/value pairs). This in turn had caused Windows to delete (or move) a section of the Registry file, which in turn had generated a TRIM operation on a volume that CBT was tracking.

At this point, CBT needed to access some settings that are normally stored in memory (cached), however; for some reason (I can only guess that it needed the resources), Windows had elected to discard this memory. At this point, CBT tried to re-read the settings back from the Registry, but it can't because Windows is holding a global lock on the Registry in response to the request from the Malwarebytes product.
​
Malwarebytes and our CBT driver are now waiting for each other to complete before either of them can move forward.
​
Normally, this would be detrimental to both products, but would not cause the system to freeze, however; a further 45 requests to access the Registry (from various processes) come in and all of these now block, waiting for the global lock on the Registry to be released. I presume that one or more of these is a critical Windows component and this is what results in the freeze.

Our solution to this, was to read these particular settings at driver start-up, then store them in memory that Windows cannot discard. This removes all possibility of CBT needing to access the Registry during a TRIM operation.
​
Without access to the Malwarebytes product source code, I am not entirely sure what their product is doing, but I do not believe that they are doing anything wrong per se, and while it is a rare occurrence - I believe that our CBT driver should be able to cope with these circumstances.

I have attached the output of the analysis that we performed on the dump file. It is intended for software developers, but it is quite easy to see which other processes were also waiting to access the Registry and why.

I hope that this goes some way to explaining our findings.
​
=================================================

NOTE: Macrium Reflect is scheduling the official release of this fix to MRCBT.SYS sometime in the next few weeks. Since the latest version is 7.2.4156 (which still contains the "defective MRCBT.SYS") I assume whatever the next higher released version is will from that point going forward now contain the corrected MRCBT.SYS.