Jump to content

DSperber

Honorary Members
  • Posts

    85
  • Joined

  • Last visited

Reputation

0 Neutral

Recent Profile Visitors

1,574 profile views
  1. I appreciate the info. Since the product version was released publicly, and is no longer beta, is this now officially a defect which must be fixed? Presumably. Probably should have been corrected before being released as-is, or perhaps deferring the official release until the bug was corrected. Regardless, can there please be confirmation from Malwarebytes staff here on the forum that this bug has been officially acknowledged and accepted and is currently being worked on, and will be fixed?
  2. I've tried individual report deletes, as well as DELETE ALL. Nothing works.
  3. Attached. When I added an exclusion for SetupHost.exe sure enough the Win10 upgrade then got past that point and completed normally. So my friend's machine is now operating under Win10. MBAMSERVICE.LOG
  4. I'm performing an in-place Windows 7 -> Windows 10 upgrade for a friend. A ways into the preliminary "getting ready" steps there is a popup from Malwarebytes claiming that a ransomware thread has been blocked. Unfortunately, this is a SetupHost.exe file from the Win10 upgrade, so the upgrade simply stops. The file is quarantined. I have restored the file, and added an exclusion for it. I hope this time the upgrade gets past this obstacle. -Ransomware Details- File: 1 Malware.Ransom.Agent.Generic, C:\$WINDOWS.~BT\Sources\SetupHost.exe, Quarantined, [0], [392685],0.0.0 False-Ransomware.txt
  5. Silverfast is a German scanner software company whose software I have been using for more than a decade. Laserfast Ai is their product, which is a top-of-the-line scanner which I use for my Epson Perfection 4990 scanner. For some reason, when the program Silverfast.exe access the Silverfast web site (217.6.73.195) to check for software updates, it is suddenly being falsely considered to be a Trojan.
  6. Just for closure on this one... Today Macrium Reflect brought out their latest version update, to 7.2.4228 (that's for the non-free Macrium Reflect Home edition), which contains the official public release of the "fix" to their CBT driver to truly eliminate the conflict with MBAM that was responsible for this long-exisitng "freeze" symptom some number of Win7 systems. I assume a similar fix would be available in the Macrium Reflect Free version. So even thoug a particular "freeze" issue was reported for MBAM users back last December, and then fixed by Malwarebytes in January, that apparently wasn't the only such "freeze" issue involving MBAM in one way or another. As I've described in this thread, I had early on backed out the problematic December version of MBAM and yet still was having freezes, as I'd been having for the previous few months... long before December. And furthermore, even after applying the January "corrected fixed version of MBAM" that supposedly fixed the freeze, I still continued to have my own freeze symptoms. Obviously MBAM may have had its one particular freeze, but this second one involving a collision with the CBT driver of Macrium Reflect was obviously a distinct and unique issue on its own, that also resulted in a "freeze" symptom. Anyway, this second problem is now apparently 100% resolved (based on my own freeze-free experience beta testing their update for two weeks). so it's now out. If you are a Macrium Reflect user be sure to apply this latest version 7.2.4228 (or newer, in the future) update in order to get the fix to MRCBT.SYS. From their Release Notes: Bug Fixes Change Block Tracker Fixed an issue where a TRIM operation on a Registry hive would cause a dead-lock if some third-party software was holding a lock on the Registry.
  7. Well, I can't say for absolute sure yet, but it does not seem to be occurring on my ASUS machine where the beta MRCBT.SYS is installed and running for several days now (still freeze-free). But then the 36887 error never occurred on that machine anyway. It had only occurred on my M910t machine which has been running freeze-free with Bitdefender (instead of MBAM + MSE) for more than 21 days now. So until and unless I revert M910t off of Bitdefender and back to MBAM + MSE (along with the fixed MRCBT.SYS from Macrium Reflect which presumably finally solves the freeze) I don't know that I will be able to explore this separate 36887 issue any further. I really would like to do that, of course, and maybe still will now that I have good confidence that the updated MRCBT.SYS is just as effective as using Bitdefender as a prevention for any future freeze. I will decide whether to do that or not the next time I have a need to re-boot M910t. It's now "Windows Update Tuesday", but there isn't much to apply. So I don't know a re-boot will be called for which would therefore be a good occasion to give MBAM another [temporary?] try again, just to gather 36887 event data again. I also had wanted to reinstall the latest versions of nVidia graphics driver and Aida64, both of which I'd backed out to late 2017 versions as part of my 8-month attempt to try and find the software/driver product "culprit" (either separately or in combination) responsible for the freeze... for which we now finally have what sure seems to be the genuine solution. I may wait until Monday for this experiment, as there's an awful lot of TV which needs recording by M910t all this week through Sunday night ("Masters" golf Thurs-Sun, and "Game of Thrones" Seasons 1-7 marathon all week and final Season 8 debut on Sunday night). Gotta have M910t continue to remain flawless 24/7 through then.
  8. I asked one more question of Macrium: ----------------------------------------------------------------------------------------------------- Final question... Even though you've devised a workaround that allows CBT itself to operate freely despite the Registry lock resulting from the MBAM action, what about all the other 45 queued requests that build up from other tasks, all due to the same Registry lock? Is not this whole never-freed backlog what results in the eventual total freeze? Would they not still queue up, eventually again exhausting the size of the queue and resulting in the freeze even though CBT itself isn't any longer caught in this queue because of your code change to CBT? Or, is everything finally released when the TRIM operation completes? Or, if not the end of the TRIM operation, what is it that would eventually unlock things allowing all of the queued up requests on Registry finally proceed and the queue empty out... so that no fatal freeze occurs? ----------------------------------------------------------------------------------------------------------------- To which they replied: With the workaround in place, Windows will complete the TRIM operation and allow Malwarebytes to release the lock. Once this happens, the other processes will no longer need to wait for Malwarebytes and everything should run smoothly. My only concern is that CBT and/or Malwarebytes could have been the first point of failure in a sequence of events that was destined to end badly anyway. For example, if another process is leaking resources and this is what prompted Windows to discard the memory containing the CBT settings, then a different failure could arise further down the line. This will only become apparent through testing, but should you run into problems, please let us know and we will do our best to help. Kind regards, Macrium Support ------------------------------------------------------------------------------------------------------------ But the good news is that I've now reached the 24-hour still freeze-free point on my ASUS machine on which the revised test version of MRCBT.SYS was installed. Fingers crossed we're finally out of the woods on this one.
  9. I've now received a more detailed explanation of the analysis performed by the Macrium Reflect CBT team, on the freeze dumps I provided. -------------------------------------------------------------------------------------------------------------------------------- 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. --------------------------------------------------------------------------------------------------------------------------------------------- This and at least 2 of the other dumps that I looked at, including the 16GB file that you uploaded to our FTP site, indicate the same sequence of events - they all show that CBT is stuck waiting on a global Registry lock that the Malwarebytes product holds. Please note that this locking/waiting mechanism is not something that either MBAM or CBT have directly asked the system to do, it is a side-effect of the implementation of the Windows Registry and as such, they can change from one Windows version to the next. To be honest, I haven’t really done much investigation into how your computer got into this state. After confirming that CBT was indeed dead-locked, waiting on the global Registry lock resulting from the Malwarebytes action, my sole focus was on implementing a solution that would allow CBT to run freely under the same set of circumstances. As I stated previously, I didn’t discover anything that contradicts the information that Malwarebytes have given you, but I am afraid that I do not have an answer to what is unique about the combination of our software and your computer(s) that triggered this. I hope that this goes some way to explaining our findings. Kind regards, Macrium Support -----------------------------------------------------------------------------------------------------------------
  10. One more comment... The subject title for this thread describes TWO issues I have been fighting with. One is the freeze, and the second is the error 36887 errors occurring on the System Event Log whenever a SCAN is performed by MBAM... but only on this particular machine of mine. I don't see that error on my other machines, despite the fact that I run MBAM on ALL machines. "I have been studying the Event Log closely, and have observed that Malwarebytes Premium daily scan at 6:30AM seems to ALWAYS produce two "error" entries in the log for event ID 36887, with "the following fatal alert was received 70" typically reported first followed by "the following fatal alert was received 40" reported second. I can reproduce this pair of errors "on demand" simply by running the scan manually specifically when the "scan file system" item is reached, so I'm 100% certain these two errors are coming from MBAM." So it still is appropriate to try and understand what the story is that is responsible for these Event Log error messages produced when the "scan file system" item is reached during the nightly SCAN. That's why I found it interesting that the MR technician referenced those same words "file system" in his summary statement: "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." So in passing, I wonder if there's any connection here, in possibly explaining not only the freeze story but also why this particular machine also produces 36887 errors regularly? Of course the contradicting information is that my other M910t machine, also running nightly SCAN from MBAM, does NOT generate 36887 errors, and yet it was susceptible to freeze as well when running MBAM? Also, one must not lose sight of the fact that I had "solved" the freeze problem on M910t about three weeks ago, by uninstalling MBAM + MSE, and installing Bitdefender. So if the underlying problem was a defect solely in MRCBT.SYS completely unrelated to MBAM, and I hadn't touched Macrium Reflect three weeks ago, how is it that the freeze disappeared on M910t... even with the so-called "defective MRCBT.SYS"? Obviously using Bitdefender instead of MBAM injected some kind of "fix", as I've now run freeze-free for almost 3 weeks. I will also pass this info on to the Macrium Reflect tech staff, as another relevant clue.
  11. I've now heard back from Macrium Reflect support, who've have a chance to look closely into the three dumps I provided to them over the past few days. From their response it sounds like we may have made FANTASTIC PROGRESS on discovering the actual cause of the freeze, and fixing it. Perhaps the instant-fix is just a temporary workaround until the permanent more elegant complete fix is available, but it does sound like real insight into what is happening is now available. Here is what they said to me on my MR ticket (and, by the way, THIS IS WHY I GENERALLY LICENSE THE NON-FREE VERSION OF A PRODUCT... to support the vendor and its product and its development team, and to guarantee product support like this in case of a real issue). -------------------------------------------------------------------------------------------------------------------------------- Hi Darryl, 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. Please can you download the relevant driver and replace the existing driver in your C:\Windows\system32\drivers folder, then restart Windows for the changes to take effect. I understand that this will take some time for you to report any findings, but please let us know the outcome at your convenience. 32bit - ... 64bit - ... Kind regards, Macrium Support ------------------------------------------------------------------------------------------------------------ I am about to install the temporary freeze-avoiding workaround-version of MRCBT.SYS that they have provided to me, and re-boot. Then it's a matter of just waiting for time to pass, to see if a freeze returns. If history means anything the particular "fluke" combination of circumstances can occur very quickly, or within a few hours of re-booting, or a few times a day, or maybe not until a day or two has gone by. But typically no more than two days at best is needed to set up the enivornment so that a freeze by that time is almost certain. We shall see. In the meantime, based on @LiquidTension's comment that at least one report exists of a freeze (dump to go with it?) that occurred WITHOUT MBAM PRESENT AT ALL (does that mean it was temporarily uninstalled in order to completely remove it from possibly contributing to the freeze "soup" mix of circumstances?), but only Macrium Reflect. I will pass that information on to MR, so that they are fully aware whatever is the story with MRCBT.SYS and its ultimate fix, that it is also apparently possible to expose their freeze-causing defect having nothing to do at all with MBAM! In otherwords, while MBAM being present might exacerbate things, it's not required. The underlying problem with MRCBT.SYS may truly be in the design of MRCBT.SYS by itself, where the true fix must therefore also be. I will pass along this notion on my reply to my ongoing MR open ticket conversation, just to be sure they are aware of the fact that MBAM has seen this MR-only freeze. Hopefully that particular MR-only freeze dump (in the hands of MBAM support) is still available, and I can get that URL in order to pass on that dump to the MR people for them to examine as well. Anyway, looks like we're really making terrific progress here.
  12. Ok. Both ZIP dumps have now been uploaded successfully. I've sent a PM with URL instructions for download of the two ZIP files.
  13. Update again... freeze again, this time not during "idle" but during an actual "busy" period during which I was composing an email and typing away madly. This second freeze occurred at 11:58AM, which is just about 2 1/2 hours after this morning's re-boot at around 9:15AM (following the 4:58AM first freeze). While the upload of the 16GB compressed memory dump to the hosting site was proceeding in the background at 10 Mb/s (using WinSCP as the file transfer program), I was just doing normal work. I had Firefox open with two tabs in the background, and I was working in my email client typing an email in the foreground. Not overly busy, but definitely not "idle". I got to a point where I needed to backspace in the email I was composing, and suddenly it didn't respond. I was able to use the mouse click just once to be able to see the Aida64 window where sure enough less than two minutes earlier the "time" value had frozen. In other words I was still able to work within my email composition window for those two minutes, but eventually the effects of the freeze caught up with what I was doing with keyboard and mouse, and that was it. So now I will attempt to upload BOTH of these freezes from today. I will provide URL information when I get hopefully them uploaded. The second one compresses to 10GB, so I'll try doing that one first. I'll then address the first one which was 16GB compressed.
  14. Update: after re-booting on Friday 4/5 at 9:15AM I have been waiting almost two days for another freeze to occur, with MBAM and MR installed as well as Team Viewer and Dyn Updater fully active. The Tuesday 4/2 dump I originally sent you included MR 7.2.4063 which was the installed version at the time. On Wednesday 4/3 I updated MR to the new 7.2.4156 which had just been released, but put off the requested re-boot awaiting the next freeze which I hoped wouldn't be too long in arriving. Well, it took one day and 19 hours of waiting, but the freeze.finally occurred early this morning 4/7 at 04:18AM (while I was sleeping and the machine was completely "idle" except for the normally operating background programs, HTPC/WMC components, etc. I discovered the freeze this morning at around 9AM and forced a BSOD and complete MEMORY.DMP which once again is about 34GB as it was back on Tuesday. I have zipped MEMORY.DMP for upload to you, but for some reason the compressed size of today's dump is about 16GB, rather than the much smaller 2GB compressed size of Tuesday's dump. I can only assume that there was much more of my 32GB physical memory used at one time or another over the past 1 day 19 hours, which all together simply didn't compress as well as Tuesday's dump which probably had a lot more unused "zero'd" memory and thus compressed much better. Again, the underlying raw MEMORY.DMP itself was 34GB in both cases. So, unfortunately, at my personal broadband ISP service upload speed it's going to take 2-3 hours for me to upload this second 16GB ZIP'd file. I'm sending it the Macrium Reflect FTP site they provided to me for upload, and I will PM you with the URL for that dump when when the upload completes so that you can download it directly from their FTP site. But it's going to be a few more hours before it's completed and available Shouldn't be a problem for you, because today is Sunday. It'll be ready for you by Monday morning. I'm also attaching here a small photo of what my screen looked like when I found it. This is to give some context to what my own freeze symptom looks like. Note that the "time" and "up time" values presented in Aida64 have "frozen" as of 4:18:27AM and 1d 19:04:41, respectively. Aida64 updates its values every 4 seconds, so screen updating to this window stopped back at 4:18:27AM. In the meantime, the Clockwise window (just off lower-left corner of the Aida64 window) has continued to update its own system clock value, which shows 9:02:02AM when I discovered the freeze. Also note that the Windows system clock in the lower-right corner of the screen also shows 9:02AM. So both of these on-screen clock values are still "running and active" and obviously not frozen. Also I can move the mouse around and the onscreen cursor moves around, but right-click and left-cick on anything doesn't work to produce the expected result. Also, note that the PERFMON window in the lower-right is also continuing to progress left-to-right updated every second, and with properly updated clock values on the X-axis. However the blue "graph" output is extremely "ragged" and irregular, and shows many white spaces between the blue output. This suggests to me that the system was unable to write to the screen during these interspersed blank periods, while then starting again displaying blue, until the next white area. So this output is not completely frozen, but does certainly appear impacted from its normal behavior. I didn't photo the upper-right portion of the screen, but that's where the DUMeter window appears, and it is completely frozen onscreen as well (just like Aida64) and is no longer progressing at all, which is normally right-to-left updated every second. I also can't communicate to the ASUS machine (from operating M910t) using either RealVNC or Team Viewer. The above comments are simply meant to provide some context to what I mean when I say "freeze". Note that this is somewhat different on Z170 than it was on M910t (before I uninstalled MBAM + MSE and installed Bitdefender to replace them, and the freezes finally stopped entirely). On M910t I see a "total freeze" of PERFMON, whereas it seems to half-operate on Z170. Also, on M910t the mouse cursor is frozen and can't be moved around the screen as it still can on Z170 (even if mouse-clicks have no effect). Anyway, still hours to go on the dump upload. Sorry for this (and for how long it's going to take you to download it for study), but it turned out to be 16GB compressed. Same 34GB uncompressed.
  15. Still no re-freeze symptom occurring again on ASUS, not since Tuesday night (when Macrium Reflect 7.2.4063 was installed), and not since Wednesday afternoon after applying the Macrium Reflect update to 7.2.4156, and also not since re-booting Friday morning (I had deferred doing that as requested by the Macrium Reflect update, but decided to go ahead with it yesterday). So I'm once again running as I was on Tuesday night, including also with Team Viewer and Dyn Updater active. Perhaps I just haven't lucked-in to set up whatever is the particular set of circumstances conducive to triggering a freeze... but maybe it will still come. Really just unpredictable and random. If it could be reproduced on -demand we would already know what was causing it. Clearly there are some "surrounding circumstances" or other conditions or things that have run or are running, etc., all of which work together to make the 'soup" that is required only then for the freeze to maybe possibly appear. Anyway, no new freeze or MEMORY.DMP yet to report. However, I have now gotten a personal response back from Jamie (from Macrium) who is taking over the ticket. He is one of the key developers on the CBT driver component team and is the one who will be looking into the Tuesday 4/2 MEMORY.DMP I sent to them, and which you looked at as well. He has asked me to ask you a few questions. I will act as the relay, and communicate your response back to him. Whereas my own personal questions are from the perspective of a "user", his questions are more technical. And I'm sure he's looking for truly technical answers. So please do answer them in terms as technical as you'd like, using whatever terminlogy or specifics or attachments or screenshots or whatever that you'd like, and I will communicate all of it to Jamie at Macrium. Thanks. Here is what he asks: --------------------------------------------------------------------------------------------------------------------- Thank you for taking the time to document your issue in such detail and for providing the associated files that will help us investigate. I am one of the developers who work on the Change Block Tracker (CBT) component and I will be taking over your case and performing analysis on the crash dump report in the coming days. My initial reaction to your post is one of confusion as while our CBT driver does read some values from the current “SYSTEM” Registry hive, it makes no attempt to acquire a lock on them. Furthermore, it is not possible to unload the current SYSTEM hive as it is used by Windows itself. Working on the assumption that something has been lost in translation between their developers and their customer support, would it be possible for you to ask the nice people at Malwarebytes to provide the exact path of the Registry key that they believe our CBT driver is referencing and also to provide some further details on what they have acquired from the minidump that leads them to believe that MRCBT is holding a lock on the Registry? Kind regards, Macrium Support
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.