anachromat

FYI, a week or so ago I detailed problems w/ various Win10 freezes, which appeared to be resolved after installing the then-beta version of Malwarebytes (see below for link to original message thread). But that only lasted long enough for the thread to be marked RESOLVED 😅 The problems actually continued, but less frequently. Sometimes a day goes by with none, sometimes there are half a dozen freezes in a day. In every case, opening MB and disabling Ransomware Protection restores all frozen programs to regular behavior. Since there's a (so far) 100% reliable workaround, I don't much care. Just FYI here for others with similar problems.

Still no freezes today, so the surest way in the universe to provoke one is to send a message saying "no freezes!" before the day ends 😄 For the record, this is using the current beta version of MB 4.1.1.71, component package version 1.0.955. All protection layers have been enabled since last night. This even survived two 1-hour sleeps (which always provoked freezes before).

So far so good! Haven't seen a freeze since installing the beta MB (with all protection layers enabled). But there's a long day to go before I'll declare victory. @Porthos, no, I don't expect scans to go fast 🙂 Whether it's running a scan or defragmenting a drive or ... any resource-intensive task goes faster and better if it's allowed (as much as possible) exclusive access to the resource(s) it's taxing.

OK - I disabled registering MB with Windows Security Center, and am running the MB beta version. Too soon to guess whether that's better/worse/neutral in respect of the widespread program freezes. The advice to reduce manual scan priority just doesn't make sense to me, though. I only run manual scans, and only when I know I won't be using the machine again before one finishes. Getting the scan done ASAP is my #1 priority then.

The clean reinstall worked without problem. Things seemed fine then for a couple hours, and then various programs starting freezing again. Even a `cmd.exe` window running a robocopy to an external USB drive. One new thing I learned: I didn't need to reboot to get unstuck. I just needed to open MB and turn Ransomware Protection off again. Bingo! Everything (primarily the cmd.exe window, Chrome, Firefox, an editor, and a calendar/task program) resumed running fine at once then. I didn't try the other tweaks you suggested because they appear to be random thrashing 🤪 I haven't had any problems with MB scans, and don't do any scheduled scans anyway (I delete the one MB comes with) - I run a scan "by hand" pretty much every day, but at a time when I know the computer will be free for a while. That can't be put on a schedule.

mbst-grab-results.zip

Thanks for posting this! Sounds like the same here: after the Windows 2004 update, on s capable desktop machine, frequent instances of various programs freezing, utterly unresponsive, to the extent that even trying to kill them in Task Manager had no visible effect. A reboot always fixed it, but it could take several minutes for Windows to wholly exit before it started to reboot again. When things freeze, it's like little else I've seen before: the CPUs, and disk, stay mostly idle. It's "like" they're stuck waiting to acquire a lock that's never released. Anyway, with no expectation it would actually help, I tried turning off MB's Ransomware Protection. Voila! That was about 6 hours ago, and everything has been running perfectly since. Telling: there was only one thing I found that could deliberately provoke problems: put the computer in Sleep mode, and wake it up a few minutes later. Freeze City then, every time. But that appears harmless now too. Then again, _could_ all be just coincidence.

If your computer crashed due to RAM exhaustion (like mine did), just a reminder to check the file system for errors: in Windows Explorer, right click on your drive (like "OS (C:)"), select Properties, then the Tools tab, then the Check button ("This option will check the drive for file system errors."). This rarely finds anything wrong under Win10, but it did on mine just now. If it finds errors, it will ask you to reboot to get them repaired.

Just went through this myself. Summarizing what worked: Use the Chrome Sync dashboard to disconnect Chrome and clear the settings on the server: https://www.google.com/settings/chrome/sync And click the "Stop and Clear" button. Close Chrome. Run a Malwarebytes scan. Under Premium, a HyperScan (the fastest) is good enough. When the scan ends. let it quarantine PUP.OPTIONAL.ASK.A. Start Chrome, and sign in to Chrome Sync again.

Just FYI, the problem went away for me. See my earlier msg in this thread. the next time I opened the program after the manual scan completed, the database was at v2014.07.10,09, and the program believes it's (finally) up to date.

Same here, starting today: says v2014.07.09.13 is out of date, but no number of attempts to update remove the message. So I closed the program and restarted it, and started a manual scan. Soon after that started, it said the database was corrupt, and would I like to download a fresh copy? I said sure, and after a while it completed the manual scan. But the database is still at v2014.07.09.13, and the "out of date" messages are back. I suspect there may be a problem

When scheduled tasks run significantly slower than manually-initiated tasks (for jobs of any kind), that's usually because scheduled tasks have been set to run at a lower priority. That's usually appropriate for scheduled tasks because they're usually "background tasks": things that need to be done, but where the user doesn't want them to compete effectively for resources (like CPU and disk access) against things the user may be doing "by hand" while they're running. The native Windows task scheduler, for example, runs tasks at "below normal" priority by default. But I don't know which mechanism(s) Malwarebytes uses to schedule tasks, so maybe that's way off base. Sounds plausible to me, though .

There's a pinned topic at the very top of this forum about that very problem. Here: https://forums.malwarebytes.org/index.php?showtopic=149909 Try doing what that post suggests

@ncs, you should really open a new issue about that! There's no way to guess whether your problems may or may not have the same cause unless you run a few tools and post a few log files. If you open a new report, someone will reply with detailed instructions about how to do that. It would help. I strongly doubt my problem, or the other reports of BAD_POOL_HEADER BSODs currently active on this forum, are due to malware, but nobody can be certain until the true causes are determined. I have decades of experience tracking down memory corruption errors reported by dynamic memory allocators and garbage collection systems, and this "smells like a typical one of those". Although my experience is in the context of various programming language support libraries, and not in the context of Windows driver development, so my intuition may be wrong . If you post your log files (see above), someone can look at them and make a pretty good guess as to whether your computer shows signs of infection. The other reports here have already done that, and are still open because they don't show clear signs of infection. In any case, good luck

Was worth a try . Alas, when the next BSOD occurred, procdump did not create a dump file - only the Windows dump files were left behind. Perhaps a kernel bugcheck doesn't count as "an (ordinary) exception" in this context? Or perhaps it does, but the procdump dump file wasn't written to disk before Windows shut itself down? Don't know. In any case, I'll attach the Windows mini-dump. Same old, same old. Before the crash, procdump recorded several first-chance exceptions in the command window, but they don't appear to be relevant (and occurred at times "far" removed from the BSOD): [16:09:26] Exception: E06D7363.?AVException@util@mb@@[16:09:26] Exception: E06D7363.?AVException@util@mb@@[16:09:26] Exception: E06D7363.?AVException@util@mb@@[16:09:26] Exception: E06D7363.?AVException@util@mb@@[17:09:26] Exception: E06D7363.?AVException@util@mb@@[17:09:27] Exception: E06D7363.?AVException@util@mb@@[17:09:27] Exception: E06D7363.?AVException@util@mb@@[17:09:27] Exception: E06D7363.?AVException@util@mb@@[18:09:26] Exception: E06D7363.?AVException@util@mb@@[18:09:26] Exception: E06D7363.?AVException@util@mb@@[18:09:26] Exception: E06D7363.?AVException@util@mb@@[18:09:26] Exception: E06D7363.?AVException@util@mb@@[18:12:51] Exception: 000006BB[18:13:18] Exception: 000006BB[18:13:18] Exception: 000006BB[18:13:18] Exception: 000006BBSo every hour something wakes up and throws 4 C++ exceptions (E06D7363) in quick succession, and 000006BB seems harder to track down But MBAM handled all those exceptions itself, and the last one occurred more than 40 minutes before the BSOD. It's possible there was more output in that window I never saw, though. Mini061414-01.zip