Jump to content

anachromat

Members
  • Content Count

    44
  • Joined

  • Last visited

Community Reputation

0 Neutral

About anachromat

  • Rank
    New Member

Recent Profile Visitors

837 profile views
  1. 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. J
  2. 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).
  3. 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.
  4. 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.
  5. 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 pr
  6. 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
  7. 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.
  8. 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.
  9. 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.
  10. 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
  11. 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 mec
  12. 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
  13. @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 a
  14. 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
Back to top
×
×
  • Create New...

Important Information

This site uses cookies - We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.