Profile corruption

[TONYBEE]

Thank you for the information Galileo. Luckily I  didn't need it, when I created a shortcut without administrative privileges Malwarebytes opened and worked fine. Just an update, no problems with Malwarebytes, and no need to reset my privileges. Keeping my fingers crossed.

[galileo]

@ x64

I fully agree with your use of the word "insidious"!  While - thankfully - I have not seen the particular issues you describe, I have had similar "insidious" (love that description) issues that are deeply embedded in the "plumbing" arise with various systems through the years.  Your description of the profile corruption makes sense in that it builds upon the initial error thus propagating further and further errors (i.e. corruption) until the system finally collapses.  Ponder this:

• Install a new system (bare metal) with only Windows; perform all Windows updates including going through every item in Device Manager one-by-one checking for driver updates (which, surprisingly btw, Windows does not necessarily fully complete even on a bare metal install); check Event Log for errors and correct all the issues that you can (mostly DCOM permissions); verify that you have no profile corruption(s) - if necessary burn in the system for a few days to accomplish this verification.
• Image this installation.
• Install only MBAM (v2 or v3); verify that MBAM is functioning correctly; give the system some time to run and update on its own to accomplish this.
• Check the Event Log and monitor the system for the types of misbehavior that seem to indicate some type(s) of corruption.  
• Restore the image, install MBAM on the fresh image and cycle through another MBAM startup setting variation and verify that the system is stable.
• Finally, restore the image, install MBAM and now cycle through each of the MBAM startup settings without changing the image (i.e. exercise the full range of MBAM program settings without changing installations) and verify that the system is stable.

If MBAM is "the" or "a" culprit, one can find either:

• The specific MBAM setting that generates an error instability, or
• That running through the range of MBAM settings is generating some type of error or instability.

...yes, this is actually a developer responsibility...but, this may help get to the root of what is initiating the profile corruption that you are seeing.  It is also worth noting that as other software is installed on the system (even OEM drivers), those items could also start creating their own issues and potentially colliding with MBAM during the startup phase...the permutations are essentially endless and maddening...

...just some thoughts...

[galileo]

28 minutes ago, TONYBEE said:

Thank you for the information Galileo. Luckily I  didn't need it, when I created a shortcut without administrative privileges Malwarebytes opened and worked fine. Just an update, no problems with Malwarebytes, and no need to reset my privileges. Keeping my fingers crossed.

@TONYBEE

Good for you.  I can say that I have not had any ongoing issues with MBAM 3 on either of my systems...at least not so far after several weeks.  I did have an initial "Updates" issue on one system which resolved itself upon setting the program to check for updates before a scan and then starting a manual scan...the program updated and has been flawless thereafter. I should note that my two systems were bare metal installs with no prior installations of MBAM...although I had installed other software before I performed the MBAM installations.

edit:  I am not quite fully correct regarding the "flawlessness" of MBAM 3.  There is the System Volume (shadow copy) issue that is still ongoing.  The workaround being to disable "Ransomware Protection" prior to deleting shadow copies (i.e. System Restore points) and re-enable it afterwards.

Edited February 21, 2017 by galileo

[galileo]

10 hours ago, John A said:

@galileo

The profile corruption is apparently rare, although there may be users out there experiencing it who don't realise that MB is causing it.  It happens on Windows 10 x 64, x32 and Windows 7.  I understand each computer is different, but MB should not interfere with basic Windows functions like user profiles.

@ John A

Fully agree with all said.  I would suspect that it would certainly be likely that one may not even realize that profile corruption is occurring, much less that MBAM could be involved.

[Telos]

1 hour ago, galileo said:

edit:  I am not quite fully correct regarding the "flawlessness" of MBAM 3.  There is the System Volume (shadow copy) issue that is still ongoing.  The workaround being to disable "Ransomware Protection" prior to deleting shadow copies (i.e. System Restore points) and re-enable it afterwards.

The preview release (see sticky) has reportedly solved the VSS snapshot issue.

[shaun279]

1 hour ago, galileo said:

@TONYBEE

I am not quite fully correct regarding the "flawlessness" of MBAM 3.  There is the System Volume (shadow copy) issue that is still ongoing.  The workaround being to disable "Ransomware Protection" prior to deleting shadow copies (i.e. System Restore points) and re-enable it afterwards.

May I know more about the shadow copy issue? I'm currently running full windows 7 backup every morning, I'm worried this may affect my ability to restore someday if anything goes wrong.

EDIT: nevermind, see Telos post 

Edited February 21, 2017 by shaun279

[galileo]

5 minutes ago, Telos said:

The preview release (see sticky) has reportedly solved the VSS snapshot issue.

I had seen that as well - but thanks for the comment regardless.  At the moment I do not have a suitable non-production test environment and have thus decided to wait on the production release that, I believe, is scheduled for this week.

[x64]

@galileo

The testing that you suggested would not be appropriate to the issue that I wrote about. Did you mean to direct the suggestion to one of the other contributors to this thread?

Regarding my issue - I piped up as I saw another W10 user reporting profile corruption with a resolution (logoff/back in) which is a signature of the issue I'm chasing.

I get the issue frequently enough for it to be noticable, but infrequently enough that I cannot 'test' expecting to catch an instance of the initial 'user classes hive' mount failure. Even less could I deduce that the issue is fixed/mittigated because it has not occurred for a period of time (to be statistically significant that would need to be two logons a day over the period of a number of months. (for example the dates of my previous issues were 27/1, 26/1, then 16/1, 22/12, 11/12, 7/12, 2/12.). As you see the issue can be frequent or sparse. Difficult to tell if it will never happen again or still lurking ready for my next logon. 

As I said I maintain an open mind as to whether the issue is due to one of my security products (KTS/MWB), but have thrid party evidence that it is neither.

I do not believe that device drivers are likely to contribute to this issue - it's too specific and device drivers are iin the wrong part of the OS to have that effect (I do have the experience to assert that - 30 years in the trade). Filter drivers are a different kettle of fish and could easily interfere and cause such issues - hence contining to entertain the possibility that the security apps are implicated.

x64

This has got me thinking about the (my) profile corruption issue again . I might try Procmon boot logging again on the off-chance of catching the issue. The last time I tried this - murphy hit big time.... Not only did I get the Procmon Win10 BSOD issue, but also (total coincidence, but classic case of Murphy's law, and in the words of Douglas Adams, "timed for maximum contempt"), at the same time as I got the the BSOD my motherboard blew up requiring not only System board but CPU and RAM as well (as nothing is back compatible any more - £600GBP... ouch...). You could not make that up!... A new version of Procmon has just been released -  no mention of fixing the BSOD though... Am I brave enough??

[galileo]

@x64

...mea culpa...I was referring not so much to your specific corruption issues as to the general issue of teasing out MBAM's potential role in "any" erroring scenarios.  For some reason unbeknownst to me, I was generally associating your post regarding profile corruptions with related/ongoing "potential" MBAM issues.  While your topic is related to what I was thinking of, you are certainly correct in that the test approach would not capture your hive mounting failure.

Take a shot at Procmon again.  Once you've been around the block, you have some knowledge of what potholes to avoid on the next trip....so to speak.

I too have met that Murphy chap....and I wish him every success at completing what many consider to be an anatomically impossible feat...  

Edited February 21, 2017 by galileo

[x64]

In terms of a testing approach - for a 'hard fault;' or 'very frequent fault' it woud work but having a separate build without your usual software/comfig would be hard work for many.

If doing that kind of thing a cooks tour (along with scrupulous* recording of each test) might narrow it. Provoke issue, disable suspected culprit program + prove fix; Reenable culprit program disable half of possible contributory settings, test that one group of sttings provokes issue and other does not, then split the troublesome settings in two and repeat...Each test would need to be statistically significant - seeing the fault is obvious, but how many repeats do you need to do to prove that the issue is not pressent in this configuration?????...

I know what to do if procmon BSODs of me (use the recovery advanced options to launch regedit and manually disable the procmon23.sys driver)... Its just a pain in the (err yes!), and the thought of the  psychatric help after dealing with the similtaneous procmon bsod and mobio failure.

x64

* that's your 'word for today'......, yesterday's being 'incidious'   

 

[Porthos]

To those reading this topic and are having profile issues all you need to do is thurn off self protection in settings and reboot.

One if the fixes in the CU4 release is.

Fixed issue that could cause user to have to login with a temporary profile instead of their standard user profile

You can download the new version below and CLEAN install using the MB clean tool.

 

 

[RyanLink]

Confirming this happened to me with a terminal Server 2008 R2 as well.  Locked/corrupted almost every user profile so it was generating temp profiles at login.  LockHunter showed that System was locking each profile's NTUSER.DAT and other registry hive files even after reboot, and couldn't unlock them.  Errors 1530, 1508, 1533 etc. in event log.

Shouldn't have been installed on a server in the first place, especially with active protection, but that was it.  Uninstalling MBAM reverted the profiles to normal.

There were also VSS errors in the event log.

—

Ryan Link

Solutions Engineer | Concept Technology Inc.

Office: 615.xxx.xxxx

Technical Support: 615.xxx.xxxx

www.concepttechnologyinc.com

Nashville Business Journal's "Small Business of the Year" 2016

Edited May 17, 2017 by gonzo
clean up spam catcher stuff

[gonzo]

Ryan,

 

You are correct.  As it stands now, there are known issues with Terminal Server.  Had you continued, your server would have crashed, as each session leaves residue in RAM.  Our specs do not mention Terminal Server/RDP for that reason.