Jump to content

x64

Members
  • Content Count

    20
  • Joined

  • Last visited

About x64

  • Rank
    New Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Comment: I've also been affected by this (for quite a while). I'm not posting this for direct support - more to add information to aid localisation of the issue. For me, my win 10 PC is now my secondary PC as I moved to a Mac a couple of years ago. As such the issue was annoying to me but is not critical enough to spend time raising my own support incident (although at the time indicated below, I did start gathering evidence to raise a call). The issue was Firefox locking up in the "Save As" dialogue when downloading a file. For me a clean install of MWB did not help (I did this at the same time as doing a Kaspersky upgrade - I fully removed/cleaned both from the system before reinstalling MWB first (recreating the issue) then reinstalling Kaspersky. This was about six months ago. I've not done any controlled testing recently (and I don't have time to do so now). For me disabling the Anti-exploit protection worked around the issue. I tried disabling individual AE protection elements to mitigate the issue, but none provided relief. Only the master AE switch was a 100% fix (obviously not ideal).Otherwise failure probability varied - maybe 30%-50% of downloads. My system - Win10x64 (1803) Would gave been updated to current, MWB was premium with latest component version for the time. Kaspersky version not relevant as I have seen the issue with it uninstalled and cleaned from my system. Firefox would have been latest version for the time. I do recall that the problem was present over s couple of major MWB version numbers and component versions, leading up to the indicated time. Apologies for the vagueness of the timing and version numbers reported here. This was several months ago. If there is a cause for this identified, I would be interested in the fix. x64
  2. Since updating my Windows 10 PC to 3.4.4 (Premium-Lifetime licence), I've noticed a couple of instances of files being locked open without reason. I'm not looking to any troubleshooting of the issue or investigate more deeply at the moment as I now mainly use a mac, the Windows PC only being turned on occasionally for certain tasks. This is more of a heads up as i don't see other posts about the issue yet. Incident 1: After attaching a USB drive to the PC and copying a 20GB incremental backup file to it using Windows explorer, the USB drive would not eject (usually not a problem under the previous MWB release). Stopping Malwarebytes by using "Quit Malwarebytes" from the system tray icon freed the lock and the drive then ejected normally. I did use Nirsoft's 'ofview' application to few open files on the drive - there were some but I do not recall the details. Incident 2: I was tidying up files in an area where I archive download files. I attempted to move some old versions of Zyxel router firmware (both zip archives and folders containing the extractions of those zips) into an 'old versions' folder. I experienced a few files that would not move 'Try Again' would not help (even after a minutes or so to allow the issue to clear). I had to skip the affected files. "ofview' confirmed the files were held locked. Again, stopping Malwarebytes by using "Quit Malwarebytes" from the system tray icon freed the lock, and I could them move the files. I'd not handled the files that were locked in the Windows session in any way prior to moving them - they'd been untouched for several months prior to the move attempt. Windows 10 pro 64 bit (v1709), Malwarebytes premium 3.4.4. Kaspersky Total security 18.0.0.405(g) with Malwarebytes exclusions added. Macrium Reflect 17.1. i7-6700CPU, 32GB ram. Recent changes - Upgrade MWB from previous version to 3.4.4, March Windows 10 updates, Office 2016 March updates. x64
  3. I had to post the whole lot for it to make technical sense and credibility, and yes some of it is very technical. Unfortunately, I could present no fix or permanent work around. Yes, I could probably recover a system that had progressed to what I called the 'permanent’ incarnation of the issue I described, but it would be impossible to talk anybody but a third line (or good second line) technician through the procedure (it is the equivalent of open heart surgery on the user profile). Even I would have problems if the issue had been festering too long (and the files in the user profile had got too far out of step with the user’s registry hives). The best I couild offer is awareness, and advice on simple recovery if the issue has not progressed too far (or in the wrong direction). In terms of non-technicians, the take-aways that I was hoping to impart were: An awareness of the issue and recognition of it - Know how you have the system tray icons arranged (and which ones are unhidden). If you log on and you find that are back to the default arrangement (with most system tray icons hidden), then log out and back in immediately. (If that restores the icons, then you were hit by the issue that I describe and it was non-permanent registry corruption). A prompt to think more widely - Are the assumptions that you've come to as to possible causes really valid?. In the case of the issue that I describe, it goes against the normal diagnostic procedures (in that very often when something breaks, the technician's first question will be "What's just been changed?") If you are technically adept enough - the script in my BleepingComputer post would be an ‘in-yer-face’ alert, if properly implemented. If you are able - take a backup of your user profile regularly (I use Macrium Reflect and have a file/folder backup of my home folder and profile, in addition to a full pc image backup). One other thing that is handy to have in your back pocket is a separate administrative user account that you only use in an emergency (such as your start menu being trashed by the permanent onset of the issue I describe). Enough information to help decide if the issue I wrote about is a possible (Or even probable) cause of the issue you posted about, or totally unrelated. In terms of technicians (MWB support for example). There is enough information there to point to a significant stage of preparing the user profile intermittently failing. As I said, whilst I had considered the possibility of my security products causing the issue (and they are certainly hooked into windows in ways that could interfere), I'd partially discounted the probability due to the various combinations of versions of those products that I'd seen the issue in conjunction with, but the possibility remains. Indeed a scrurity products vendor would be ideally placed to debug the situartion further if they thought their product might be involved. In addition to the information posted – I should say that I’ve observed the consequences of the failure by both examining the registry and having Procmon running during logon (which is how I found the cleanup routine). I’ve yet to capture the actual onset of such an event with procmon (due to the random and infrequent occurrences). All of this is in the BC posts.
  4. Hi all, I performed some detailed research into a similar issue a couple of years ago and this might well be related. The issue that I'm thinking about is intermittent, and is easy to make incorrect assumptions as to guilty/affected products (bear with me on this). The issue also goes back a long way, before the first version of Windows 10 was officially launched. When I talk about "the issue" below, I'm referring to the issue that I investigated - which might or might not be related to the OP's issue. I probably need to state that I have 40 years of experience with technology. over 30 of it supporting IT, and have particular skills in sorting out the wheat from the chaff in these situations. My feeling is that many unexplained Windows 10 'glitches' might root back to this issue. I was never able to get to the root cause (and hence a correct solution) due to the random nature of the issue, but after experiencing the issue a few times, switching my brain to diagnostic mode and swallowing the 'Red Pill', I did take a fairly deep trip into the rabbit hole that is this issue. My feeling was that it was a fault with way that Windows assembles the user registry during logon. Although (after analysis) thinking it unlikely, I was never completely able to exonerate the security products that I used (Kaspersky Internet/total security, and Malwarebytes premium). I'm now mainly using a mac so experience the issue only when I need to run programs that are only on my Windows system. I published my research as part of my contributions to this thread on BleepingComputer ( https://www.bleepingcomputer.com/forums/t/608833/automatic-update-caused-your-start-menu-isnt-working/ ). I'm x64 on there as well. For brevity (not that you can call the information below brief!!), I'll continue here with some bullet points of salient facts/suspicions- read the thread linked to above for detail. Symptoms vary but common ones are: Start menu fails to open Windows modern apps fail to launch System tray icons fail to populate as you had them arranged (this might well be the first sign of the issue after logon) Often 'fixed' by logging off/on (see later) Commonly advised fixes by Microsoft and other forum helpers (note these are imperfect!!! - they may work in some ways but do not properly address the issue - they are however things that 'ordinary users' can follow) Use powershell to reinstall Apps Create a new user (as this creates a new user profile) Partial root cause - Windows intermittently fails to correctly assemble the view of the HKCU registry hive during user logon. (I was never able to find out why). In particular the User Classes registry hive is not correctly linked under HKCU\Classes If the User Classes registry hive is not correctly linked under HKCU\Classes, then software that tried to access keys under HKCU\Classes will find their keys missing and might malfunction or write default information in that place (the latter is very common), but those keys get crated in the base user registry hive rather than the separate User Classes hive which would normally be mounted on that registry path. The missing and/or defaulted keys cause the symptoms listed above. Windows has a routine during logon where HKCU\classes (in the base user registry hive) is cleared before mounting the User Classes hive as HKCU/Classes. This clearance runs as the "System" identity. For the most, that clearance works (during the following logon) and (if need be) makes space for the User Classes hive to load. If the cleanup routine fails, Keys continue to exist in the base user hive under HKCU\Classes\..... and the real User Classes hive cannot mount as its path is occupied. If this happens, a logoff/on will no longer rectify the situation. Some apps create keys under HKCU\Classes, but without access for the 'System' user identity. In that case, should the issue strike, keys so created in the base user registry hive cannot be removed by the cleanup routine and the issue progresses from the log off/on fix to permanent. At the time of my investigation "Dropbox" was such an app. I'm not saying that Dropbox was doing anything wrong, but it just got caught up and inadvertently made the issue worse. If the issue progresses to 'permanent', then it is most likely beyond the average man in the street to properly recover from. Although restoring a Backup of the user's profile should work (if such a backup exists). Otherwise we are back to creating a new user (with a fresh profile), along with all of the inconvenience that brings. If the issue has not progressed to permanent, then the sooner after logon that the issue is identified the better - log off/on immediately - see note above about the loss of arrangement of the system tray icons being a good warning. I also wrote a script to put an 'in my face warning' on screen when the issue occurs. Delaying logoff/logon allows the User classes hive to become out of sync with other files in the user profile - if that happens the issue becomes at least partially permanent. Scope - I've seen the issue on all Windows 10 releases - I've seen references to it in the preview builds before release. During all om my testing I've had a version of Kaspersky and Malwarebytes running - However these have been multiple versions of both products (KIS/KTS 16/17/18 and MWB premium 2.2 -> 3.2.2) That diversity of versions lessens the association of the issue with those products, without as I said exonerating them. Frequency - When I was logging onto my Windows 10 PC twice a day, Maybe I'd see the issue once a month. Occasionally I'd get a few occurrences a day or two apart. Other times a couple of months issue free. I suspect there is some kind of timing issue at play here, and hence back to incorrect assumptions of guilty related products - a Hypothesis of mine is that sometimes installing certain combinations of products might take the timing of the logon process closer or further from failure. I hope that helps unravel some confusion (rather than causing more!) - it might even provide the base for someone to find the real root cause. Having mainly moved to mac, my need to dig deeper is diminished.
  5. From Magdala's topic "Malwarebytes" That's interesting. In another thread a couple of weeks ago treed seemed to say that lifetime keys would not work with, or be issued for with the Mac version (the unstated underlying message being that they were different products) The quote above seems to set equivalence between the versions for the different platforms, which changes the game entirely - it's now admitted to be the same product - just expanded in scope. My situation is that I have two lifetime keys, both initially used on Windows systems. One of those systems has been retired and replaced by the MacBook that I'm typing this on now. The other windows PC is still in use for things that I can only do on that platform (it gets turned on briefly a couple of times a week). With the retirement of my Windows Development laptop, I have a lifetime licence spare that I'd really like to use on what is now my main system. Even if you don't engineer the Mac version to accept lifetime keys (and I can think of good reasons other than backdoor expiry of lifetime keys not to do so - anti piracy being the main one), there are still ways that you could honour lifetime licences where the keyholder chooses to change platform. For example allow lifetime keys to be redeemed to prime an online account to issue annual new style keys FOC to the lifetime keyholder. To be honest that scheme might work well for Windows lifetime users as well, honouring the licence whilst keeping those powerful lifetime keys under greater control. x64
  6. No problem, pleased to advise. There was a patch for the previous Win 10 version ( https://support.microsoft.com/en-gb/help/4032693 ) but that seems to have a problem of it's own. In any case, any non-enterprise user hanging out from Creators edition and not taking extreme (and unwise) measures to avoid it would lose the ability to defer it soon. x64
  7. Yes - see this page... https://support.microsoft.com/en-gb/help/4018124/windows-10-update-history (updated with each new update) So 4022716 for the relevant new patch for Win10. I love the way the Outlook search issue (causing major problems for my business customers) is relegated to the second to last bullet point in the relevant article ("Addressed a reliability issue in Windows Search")... Move along now, nothing to see here!!! June was a very poor month for MS update reliability. x64
  8. Performed 'over the top' install to bump beta version to 3.1.1.1722 (1.0.117) from 3.1.0.1716. Noted: The installation went smoothly I was not asked to (and did not bother to voluntarily) reboot. Display language again reverted to the generic "English" from my preferred "English (UK)". Report "sort order" bug reported in my post above still present. Again immediately after the Installation wizard completed and I fired up the UI, updates were reported as 'Current' but immediately found more to update when prodded. Comments: I had not experienced any obvious extra issues with the v3.1.0.1716 (1.0.115) beta other than those noted in my post above (my primary web browser is Firefox). I'm unable to comment on any issues with difficulty starting protection components with this or the previous 3.1 beta. Whilst in the 3.0 builds I was experiencing occasional issues with all real-time modules (see post above) it was infrequent enough that statistically, I'd not be likely to see it in the so far short public lifteime of the 3.1 betas (the suggested exclusions were set in Kaspersky over most of those issues). I think all of the other things I wrote in my OP above are still relevant. x64
  9. I've just successfully upgraded to the new beta release from 3.0.6 CU4.1. As suggested, I ran an over the top installation. As others have done, I voluntarily rebooted after the installation although this was not requested by the installer. The installation went smoothly. I have noted that during the upgrade, my premium (lifetime) licence and activation were correctly retained, along with scheduled tasks and exclusions. As reported by others, the UI language was reset. After the upgrade, updates were reported as "Updates: Current" on the dashboard, but clicking on that found more to install. A bug that I've not seen reported yet. In the reports list, clicking the head of the "Date and Time" column to sort by date seems to sort the opposite direction to that which the sort arrow suggests (arrow pointing down returns an ascending date order and vice-versa). I noted reduced memory footprint (now 230MB, previously 260MB), and the Office 2016 save crash was fixed. My system is Windows 10 pro x64 v1703, running Malwarebytes 3 Premium alongside Kaspersky Total Security 2017 (MR0 patch e), and Macrium v7 Home paid. Prior to this upgrade my issues were: The office 2016 "save as" crash (apparently fixed in 3.1 beta) Occasional infrequent protection start failures (any of the four real time modules), recent (pre 3.1 beta) updates much improved a previously much worse occurrence rate. Out of ten or so random failures over the past couple of months only one was not fixable by Quitting Malwarebytes from the system tray icon and immediately restarting it from the desktop icon. The one occurrence for which that cure failed was fixed by a reboot. (3.1 beta status – unknown as of yet – time will tell) Suggestions: Rename the default "English" language setting "English (US)". UK users cannot see it's sub-optimal for us. As I suggested in another topic, add tooltips to data the "Location" and "Threat" fields of reports (and the quarantine list) to allow quick perusal of reports without fiddling with column widths. As another forum user suggested, add "Stopping..." as a status for the real-time modules. You can click to disable them and not realise the click was accepted and the service is pending stopping. Then click again (which is also accepted) and eventually you see the protection turn off then flick back on again as both clicks take effect. Resurect the "Known issues" list on the forum. As others have said, having forewarning of significant issues, or a place to check for known issues during troubleshooting can be a massive time saver. [please nobody other than forum or Malwarebytes staff respond to this point - enough unnecessary unpleasantness was spread in the other topic about this] "Protection History" on the dashboard does not say much useful. it needs to put the figues into context (a limited time period that the counts cover?) and maybe even click through on the "Scan detections" and "Real time Detections" figures to lists of those detections. x64
  10. A simple improvement would be to add "tooltip" balloons on mouseover of the Location and Threat values, on both the scan report and quarantine list dialogues. x64
  11. Be aware that there is a problem with Kaspersky Internet Security ans Total Security that sounds very much like this. The problem was introduced with "patch D" a few weeks ago. They expect to fix it with "patch E", which is under testing at the moment and *might* be released next week. Workaroud is currently to use KIS 2016 or KTS 2016. if you are running KIS 2017 or KTS 2017, consider whether it could be the issue. x64
×
×
  • 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.