JamesRM

Man, you can't catch, can you? Not to my knowledge, scans in Recuva are all or nothing. In any case, if you are not interested in the files it presented you with after that scan, why consider recovering them? I thought you would try to prioritize the things that are important for you. Hard to say what is going on remotely to be honest, there are just too many possibilities for any sort of educated guess. The previous scan might have read more of the disk, with those files being in the part it didn't read this time, SATA ↔ USB translation might have failed to report the right content on some weak sectors, the disk could have deteriorated more since that previous scan (data previously recoverable, not being so anymore), ... If you still have Recuva opened, look through what it shows, there is nothing to lose and perhaps you overlooked something you deem important; and while it is unlikely as hell, the disk being idle might be relocating new sectors, when controllers mark one as damaged the relocation event doesn't happen immediately. Not necessarily! NTFS internals are well understood these days, and there's journaling, redundant metadata structures, transaction logs, ... it would be way worse if it had been a FAT32 or exFAT volume. The big problem here is the reliability of that drive, it seems to be in pretty bad shape .

Do you mean you can contact them through the support form at https://support.ccleaner.com/s/contact-form?language=en_US&form=general ? There is an email address for support as well, support@ccleaner.com, but because your email address wouldn't match the one in the Pro order I'd expect it to take a while until they get back to you. Unless someone from CCleaner acknowledged this post and expedited things, there is nothing else I can think of.

It could have been an older deal they had and it's not available anymore, or something only available through another channel, I have read about there being a 7 day one as well. Although they are pushing a "summer sale" via in-app offers, yet nothing of the sort is shown on the website (at least at the time of writing this) and at times not even that sale is presented to the user. Reminds me of those fake timers on websites trying to push people to buy whatever they are selling . To be fair, the material states even if one forgets to cancel before the trial runs out, they'd issue a refund if requested within the first 30 days, I don't think they'd renegue on it, but I do agree it is cumbersome.

Not with Recuva, but given we are in CCleaner's forum I won't name competing software, even if they play in different leagues. Imaging software isn't hard to find though, some companies offer both imaging and recovery solutions, and even though their recovery products are usually paid offerings, several allow scans for free so people can assess things before comitting. If you do attempt to create an image of that drive, make sure it is a "sector by sector" or "bit by bit" copy (or whatever other synonym for that the program uses), because you're interested in access / recovery, not back up. If the volume wasn't encrypted, the copy could still benefit from some lossless compression, making it smaller overall, but it is less effective on encrypted volumes. Yes, it is. If you leave HDS opened it'll take snapshots of the drive's S.M.A.R.T. every day, giving you relevant statistical insights. For example, you've been running a scan on the disk for a while and will continue to read that disk one way or another, if the number of relocated sectors increases, things are getting worse (but there is nothing you can do about it). Your drive being a 2.5'' 5400 RPM one is bound to be slow, but that wouldn't worry me, I'd just have to wait longer; it being old, having been used a lot and having so many damaged sectors would however, there's no telling how long it'll keep working, nor whether the data it holds is uncorrupted. If you ever completed a full scan, it'd have forced every sector to be read, relocating data if at all possible (there is some error correcting logic in the drives) and remapping those sectors if there were spares. I don't know about that particular model, no idea if you can trust those 12k relocations took place. Yeah... it doesn't surprise me , even on perfectly healthy disks, if the way it estimates the remaining time is just by dividing the amount left to read between the read speed at a given moment, it would increase if only because there are disks inside, tracks closer to the edge of the disk have higher speeds compared to those near the middle (short stroking drives was a thing years ago, for some reason...). In your case, things just compound, plenty of damaged sectors and remaps.

It doesn't seem like it, given the amount of HTML the app uses, the UI is governed by it (although still using IE's engine if I'm not mistaken...) In any case: https://ideas.ccleaner.com/c/356-allow-for-dark-theme-switching

I'm afraid so, I was just able to get it to happen in a portable 6.24. I did the first run while connected to the Internet, so I don't know for sure if it would also happen if it was ran first without Internet access, and later on with at another point. I have no reason to think it would be treated any different than the installed version though ☹

No way of going back, getting things to a working state probably. Use a different browser (or an incognito / private session, so that no 3rd party cookies are present) and see what happens. If you get a different outcome, delete all cookies from the one where you get that error. Kind of a bummer if you have several services you'd like to save cookies for, you'd need to login again in them, but without knowing the way they interact with each other, hard to address otherwise. reCAPTCHA, for example, has several stages of authentication, a token is generated and embedded in forms (hidden); and reCAPTCHA has been of Google for quite some time. Assuming you aren't doing anything nefarious... Perhaps someone with more knowledge than me about this can help though, check back after a while if you haven't solved it by then.

I can barely see the data in the screenshots , but it doesn't really matter, what's that, more than 10k sectors? Consumer grade drives are lucky to have half that, they typically have less. Because of the state that drive is in. Every sector read, if failed, leads to repeated reads of the same sector and after several repeated failures the controller of the drive marks it as bad and a remap event will follow soon (some disks expose the number of pending relocations via S.M.A.R.T. too). Successfully remapped sectors are slower to read too, think of it as leaving a sticky note where your keys usually are, saying that they are somewhere else in the house without you ever remembering that they won't ever be there anymore (so every time you need them, you find the sticky note first before actually getting the keys). Sectors that can't be remapped are lost. Perhaps in some forensic labs... and even then, with the close tracks are these days and SMR, there's little chance. I figured as much, that volume doesn't have BitLocker activated. The key is saved in the clear, that's why you can read its contents without being asked to unlock the volume first. In other words, there's nothing protecting the volume nor the encryption key. The other command would tell you more about it if you are curious, but it bears no difference. Reading S.M.A.R.T. data doesn't overload anything, it's instantaneous, I asked questions because if it were me, I'd like to make informed decisions, diagnose first, act later. Without knowing in which state a drive is, scans, especially those that read through it all, are not only premature but can also be detrimental as they'd keep straining the drive. Those reads would be better spent on creating an image (you can think of it as a virtual copy of the whole disk) or at least using a recovery program that allows one to save the data gathered during a scan, so that recovery can be done in batches (different days, different moments) without needing to read it all over again. They also allow for proper navigation through the volume structure, regardless of whether the files you want were deleted or not, as if it were Windows' Explorer. And not every program does the same, nor in the same way; some may not need deep scans because they are able to work with the mirror of the table I mentioned yesterday, others need both, others even have crazy in-place fixes which I could hardly recommend (they wouldn't apply to your case anyway). It doesn't make much of a difference. Even on drives that are working properly, if they are configured to use write caching you lose just whatever changes weren't committed yet. Removable drives don't cache writes by default on Windows. Talking of removable drives, USB enclosures have bridge controllers that translate commands a drive understands (SATA in your case) to USB and vice-versa, but they not always map them all (for example, some NVMe to USB don't send TRIM/UNMAP to the connected SSDs) and aren't as reliable as having the drives connected directly, it is possible for some of those freezes to be cause by the translation being subpar. There is a lot of nuances if we were to really get into things. Anyway, I don't mean to contradict the advice you are given, my opinion is just different, do what you feel is best, it's going to take time either way.

My bad! Sorry about that .

Hard drives come with spare sectors, when one of the sectors is damaged it is transparently (for the user) remapped to one in the spare region, speed consistency would take a hit in that situation, but there is a limited number of spares. We'll see it when we see the S.M.A.R.T. data for that drive. Not necessarily, depending on its age it may just be worn out, they are mechanical machines after all. Yes, that volume most likely is in the state I mentioned earlier, having the encryption key saved in plaintext, new data written to that drive would still be encrypted, but there are no protectors; the "unknown" just part implies the filesystem signature is corrupted. If you run this on an elevated CMD or PowerShell, what does it report back? manage-bde -protectors d: -get Because if there are no protectors BitLocker wouldn't be active per se. I believe you could disable encryption without going through BitLocker's activation (that's where you'd see the recovery key), but it would take a long time (given its size) and it would be unadvisable since you're trying to recover things. Honestly, access to that volume should be restricted, right clicking the one shown as (D:) in the Disk Management console, choosing to change the drive letter and then removing it; any (proper) data recovery software shouldn't need to access it that way to analyze or recover data from it. This is what I'd do, considering how things are looking like. 1. Stop that Recuva deep scan, it serves no purpose at this stage. 2. Look into the state BitLocker is in, things are quite different if it is in a suspended state (what I described above) vs. if it is fully activated and backed by TPM or TPM+PIN. 3. Limit access to that volume, no drive letter to it, no mount point either. 4. Assess drive health, there are various tools capable of it, HDS I mentioned earlier is just one of them, but I'd like to know what I'm dealing with. Only afterwards I'd evaluate my options, there is no rush, it needn't be done today and can wait for another day, it is better to do things properly. Either way, Recuva is not the proper tool for the job, it may be okay to recover something you just deleted from the Desktop so to speak, but that's about it; it's just too limited. EDIT: For completeness, also report back with what the following outputs (also from an elevated prompt): manage-bde -status d: PS. You don't have any other working drive with at least 1 TB of free space, do you? PPS. I am afraid I don't share your opinion on Windows updates though, even if they aren't properly tested these days, perhaps instead of Patch Tuesday one could do "Patch Saturday" so to speak , but they are indeed useful.

For now, even on 6.25, it still is a randomized trial so the machines enrolled in it won't be able to , every time CCleaner acquires remote configuration the trials a machine is enrolled in can change and the timer for it is about a day. It makes no difference if you use the "slim" installer, the regular one, or the "portable" version; CCleaner binaries are the same.

I have just seen this thread; I'll try to help where I can, but those things are complex and there are many things to unpack here... Windows does not (out of the blue) activate it on its own, there is a recovery key (which is different from the BitLocker password) during activation for safeguarding... If it were actually activated, and you have a Microsoft account linked to your user in that machine perhaps they key is saved there? See here if that were the case: https://account.microsoft.com/devices/recoverykey Some Windows machines do have BitLocker activated for the system drive after completing the initial set-up, but I don't know what prompts it and the same deal with the recovery key being presented (or saved online) applies. However, I do remember (several years back) some Linux and Android distributions for regular PCs enabling BitLocker on drives upon booting but not activating it (some bug must have been). If it sounds confusing, it is , but in essence, data would still be encrypted in that state, it's just the encryption key would have been saved in plaintext, BitLocker protection wouldn't be enforced. First things first, that is not the system drive, is it? Have you used the drive since you realized your data wasn't there anymore? Access to that drive should be minimized, taking it offline and removing access to it via normal means to try to prevent the data from being overwritten. Can you post a screenshot of Disk Management when it is connected to a machine? You can open it via they Win+X menu or searching for it in Start. I'd like to know if it is recognized by Windows, how, and whether it has a drive letter assigned to it for starters. Next, I don't know about "HDtune", but we'd need to know some details about that drive. Install (in a different drive) and run Hard Disk Sentinel ( https://www.hdsentinel.com/hard_disk_sentinel.php ), for example, you don't need the Pro version, what we're after should be displayed in the trial. Post a screenshot of the Overview and S.M.A.R.T. tabs for the drive we're interested in. I suggest you right click the somewhere in the S.M.A.R.T. tab and choose to view data in decimal, it's clearer that way, it should look something like this: If HDSentinel can't show any data and you have the drive connected through a USB interface, that could be the problem, communication is different and not everything is exposed through USB, especially on consumer hardware. I don't know if I'll be able to explain it in simple terms, but I'll give it a shot. When you (or something) delete a file, its data is generally still present in the drive exactly where it was, what actually happens is there is a table of sorts that lists every file in the volume and the entry for that file is removed from the list. The naive idea behind data recovery is to look at that table (or a mirror copy of it that also exists), to find out where the deleted files were stored in that volume, so that those sectors can be accessed directly to copy their contents somewhere else, "reconstructing" the file. There are many problems that can make it useless, for example, when the file was deleted, the place where its contents were in the disk is marked as available, that's why isolation is needed, any new write to that disk can be to a sector that once held that file's data, leading to a partial recovery at best. Another example, if that structure I described which holds metadata is overwritten (formatting a drive doesn't overwrite it all, but because it creates an empty one some parts of it are lost), there goes the "easy" approach to data recovery and so-called deep scans are needed. Recovering data is hard enough when the drive isn't failing, so let's hope yours is not, but there are more variables to take into account, like BitLocker or the model of drive it is. Generally, one shouldn't be working or applying fixes directly on the drive itself except for very specific cases, it would be imaged first (bit-by-bit copy of it into a file) and analysis and all would be done to that image instead, but that requires more space.

It is certainly not ideal, if one wants to uninstall, the uninstaller should take care of terminating the program if it's still running. EDIT: Nevermind... I though you were talking about Windows, Mac is different.

Custom Clean would be the least of our problems if that were the case

I can't reproduce the issue on my end, I (probably) get the same upgrade page you see: But selecting either of them leads to appropriately discounted prices (with VAT taken into consideration because of where I am though, and in Euro instead): The checkout process is done through the app (all steps), but if you try to go through CCleaner's website to make the purchase, the picture is different (no discount for starters, but one of the purchase icons seems deceptive):