Hi Arvy, First, welcome back from me too. I looked at my Macrium 6.3.1821 (paid, home edition) on Win 7 64-bit. Note that I updated using the inbuild updater of Macrium. I haven't yet updated to the latest version 6.3.1835. 1. C:\Program Files (x86)\Macrium\Common\MacriumService.exe version 6.3.1745 digital signed 25 Feb 2017 MD5 - 1062B6E10167650B5C5150E05A05F40D SHA-160 - A132C72ABA1CB7509D930941F1621AF3F36E7DA3 SHA-256 - 0FD0D65291FEC35D526C505D1459792C6E991926BED922522762DE97F3E2248E There are no other Macrium files in C:\Program Files (x86)\Macrium\ 2. C:\Program Files\Macrium\Common\MacriumService.exe version 6.3.1821 digital signed 7 June 2017 MD5 - 554DC3D07A85DE8D9A146554D1DED11F SHA-160 - 270338E2B67060C19BF4B20F1C4091208AC4692C SHA-256 - 6C4DE50A2509FDA7A71FE964B6A6DAE012F5FD13669CE6AB32AAA8D7F49602A4 3. HKLM\SYSTEM\CurrentControlSet\Services\MacriumService ImagePath MacriumService.exe C:\Program Files\Macrium\Common\MacriumService.exe
Is Reflect v6.3.1835 Patch going to cause a problem? It installed on my pc today - you guys are making me real uneasy! Should I move the Macrium Common file in the Programs Files (x86) over to the Macrium Common file in the Programs File?
@JohnBurns -- Check the results before doing anything. The MacriumService.exe update is probably inconsequential again in this case. It didn't crash anything and you'd probably see a lot of "screaming" about it in Macrium's own forums if it did anything really bad. It just updated that file in the wrong location when I installed the patch using the internal "check for updates" option. I can't be more positive about it as I applied my own ad hoc fix before letting it reboot and reload. You'll know it's not updating the service executable properly if it doesn't stop the service before updating the executable file. In that case, you can do it yourself after checking the two file versions if you wish. Windows will load whatever version's under Program Files, not Program Files (x86). __ @FanJ - Thanks for the welcome. The problem that I identified in the previous patch was acknowledged and confirmed by the company founder himself. I suppose it's possible that they might have corrected it for that patch before you applied it and then it snuck back into the most recent one. Frankly, nothing about their package assembly or its oversight would surprise me much. There seems to be even less versioning coordination between the main app and the WinPE package, but that doesn't really matter as much.
Sorry, I don't know what you mean with "in this case". In which case exactly? Looking at my reply # 5026 I see no inconsequential things. The ImagePath in HKLM\SYSTEM\CurrentControlSet\Services\MacriumService is pointing to C:\Program Files\Macrium\Common\MacriumService.exe, and that is where my file MacriumService.exe version 6.3.1821 is located. About the only thing I see is the leftover of MacriumService.exe version 6.3.1745 in C:\Program Files (x86)\Macrium\Common\ PS: I still have not updated to version 6.3.1835
My fault, FanJ. I replied out of order. I guess JohnBurns' concerns grabbed my attention first. Anyhow, I can think of no other explanation for your results. It certainly wouldn't be the first time that a problem recurred after a "slipstream quick fix" to an earlier product release.
No problem, it can happen to all of us. I saw that you've edited some more For the record again: I see no problems with my current installed 6.3.1821 with respect to the location of MacriumService.exe and the ImagePath in the registry key. That ImagePath is pointing to the right location. And (again for the record) I have not yet updated to 6.3.1835.
I understood what you said and I've offered you the only explanation I can think of. The problem with the v6.3.1821 patch when I identified it to Macrium immediately upon release certainly wasn't imaginary. It was confirmed by them as I said and by others as well. Maybe they then fixed that patch before you installed it, but if so, the same problem found its way back into the v6.3.1835 patch. Maybe they'll see this and "quick fix" that one too. We'll know whenever you, or JohnBurns, or others do try it and tell us about the actual results. __ P.S.: I didn't edit my reply to you which you quoted. I only edited my reply to JohnBurns to emphasize the need for checking file versions before doing anything else. Is that kind of editing considered as objectionable here. Is it not assumed that a reply beginning without any specified addressee is in response to the post that immediately precedes it.
I have a client on Macrium V5 which fell victim to the screwy change Microsoft did to the Task Scheduling. He hasn't had backups since March 3. I just want to confirm if this was resolved in V6 without the need to do anything manually with the Windows Task Scheduler? I managed to get mine (V5) running automatically properly, but I don't want some silly workaround out at my client's site. Thanks.
@ssbtech -- Reflect v6 uses the Windows Task Scheduler v1 API and it had worked well with all supported Windows versions until Microsoft made some unanticipated changes in their Win10 "Anniversary" update. At that point, Macrium had to make some hasty modifications to accommodate what they had been regarding as Windows development "bugs" that would be fixed by Microsoft prior to the W10.1607 final release. See this KB article. The bottom line is that Reflect v6 has continued using the WTS v1 API in essentially the same way as before using only its own user interface to add, modify or delete. No need for any direct WTS edits. No one can know, of course, when it might be caught again by some other unanticipated OS changes. Seems to be okay with the Creators Update. What's your client running? The major change came with Reflect v7's adoption of the Task Scheduler v2 API and, at the same time, the scheduling of tasks to run as SYSTEM by default, but I'll assume from your question that v7 particulars don't interest you unless you say otherwise.
I hate bringing this up again especially in Macrium thread. But I promise this is the last swerve off from it. @Brian k- Since the disk is still running but obviously going to need pulled eventually I have a question better suited for you and the Frogman. What are the chances that since $BadClus $BadFile is also showing up in my defragger on this drive, of shrinking the volume so that the bad sector is past the end of the volume as a small workaround to get it to an unallocated space at the end of the drive and I suppose test the procedure worked by afterwards running ChkDsk /B like on the older windows versions? I just want to try to get the NTFS file system to clear the BadFile List through this method even though it will still be there only not on the active volume. Am I drawing straws here?
EASTER, From an Admin command prompt run... chkdsk x: /b Then run... chkdsk x: /scan Any bad sectors? (x: is the drive letter)
There IS a bad sector for sure but i'll run that now and see what it returns to post. Thanks for the response. As usual it stops cold at 12% and the last few times I ran chkdsk /f or /r , it consumed a lot of time so results might not be until tomorrow if it continues that same pattern. I do intend to replace it but was looking to see if somehow that bad one might get pushed to the rear and off the list if I shrink the volume. I know it's a cheap way to squeeze out a little extra time but maybe something to learn in this process too.
You can't move the bad sector but if it is at the 12% mark you could create a partition in the final 80 to 85% of the drive. It might help for a while. (leave the first 15 to 20% of the drive as unallocated free space) You can do this without losing data. In the past, how did chkdsk /scan report bad sectors? What was the number of KB?
I missed the details if any on the chkdsk /B but not run the chkdsk /scan yet and it's late. It did run for approx. the time I posted my last reply to this one. Not terribly long but I suspect once these happen it's Kaputt before long anyway. If that percentage number is an accurate point on the drive as you suggest then your figures are spot on where to shrink FROM to leaving the $BadClus to an unallocated section. This is the last WD Drive left. All previous ones met the same fate. Thanks You for hanging in there with some guidance on this.
I updated to 1835 yesterday via internal updater on my primary machine (Win 10 CU). I can confirm that macriumservice.exe was updated in Program Files (x86). In Program Files, where registry points to, version is still 6.3.1665.0 dated 2016/12/12. I haven't noticed ill-effects, but they really should fix this!
Sorry for the noob question guys/gals, but I am still new to Macrium Reflect. Does the Free version not allow making images of USB or SD drives? I assume that is the case, but the free/paid breakdown chart does not seem to indicate that.
Win 7 Pro 64-bit. Macrium Reflect (paid) home-edition. I use PE 5 for bootable rescue DVD and I make the recovery environment. I had version 6.3.1821 installed. As far as I could tell there was nothing wrong with it with respect to location of the file MacriumService.exe and the ImagePath in the reg-key HKLM\SYSTEM\CurrentControlSet\Services\MacriumService About the only thing I could see was the leftover C:\Program Files (x86)\Macrium\Common\MacriumService.exe with version number 6.3.1745 See reply 5026. I just updated to 6.3.1835 using the internal updater, made a new bootable rescue DVD (so PE 5 was also updated), and made a new recovery environment. Now look at MacriumService.exe and compare it to the info I gave in above mentioned reply 5026 : 1. C:\Program Files (x86)\Macrium\Common\MacriumService.exe version 6.3.1835 digital signed 26 June 2017 MD5 - 3176B64DAF37A70CD1F6BD57EB3825DE SHA-160 - 844050F5CAF2CC9C6DD4AEB3EEF2EADA4915A614 SHA-256 - 9CEDF8987C18FEAB66BC627EE3BCDA4F2F572667DA9F7EBB28ACA4003BFC6340 There are no other Macrium files in C:\Program Files (x86)\Macrium\ 2. C:\Program Files\Macrium\Common\MacriumService.exe version 6.3.1821 digital signed 7 June 2017 MD5 - 554DC3D07A85DE8D9A146554D1DED11F SHA-160 - 270338E2B67060C19BF4B20F1C4091208AC4692C SHA-256 - 6C4DE50A2509FDA7A71FE964B6A6DAE012F5FD13669CE6AB32AAA8D7F49602A4 3. HKLM\SYSTEM\CurrentControlSet\Services\MacriumService ImagePath MacriumService.exe C:\Program Files\Macrium\Common\MacriumService.exe ===== Are my conclusions right (see below)? 4. The ImagePath in the reg-key is correct. 5. The wrong file MacriumService.exe was updated. C:\Program Files (x86)\Macrium\Common\MacriumService.exe was updated to 6.3.1835 C:\Program Files\Macrium\Common\MacriumService.exe was not updated to 6.3.1835
@WildByDesign -- There are lots of utilities available for backing up USB drives, but unfortunately Macrium Reflect isn't one of them despite numerous feature requests from users. They're too busy adding kernel mode device class filters and trying to figure out how the Task Scheduler v2 API works. @FanJ -- Yes, it's exactly as I said in my initial post #5019 on this subject entitled Reflect v6.3.1835 Patch Error as was also quoted and confirmed by paulderdash and JohnBurns above. __ If people want the patching error fixed, someone should probably remind Nick Sills about my warning in Macrium's own forum and his promises to correct the potentially harmful sloppiness. It won't be me.
I think your conclusions are right. The reg-key is now pointing at the 'old' service. In my case that is 6.3.1665.0 dated 2016/12/12 - see #5041.
@paulderdash -- No recent "noise" about it that I've seen. Someone should bump my previous warning but I'm not going back there to do it myself. Even if I did, I'm not sure that Mr. Sills would be any more receptive and follow up his promises any more effectively than he did before. Yes, it's damned sloppy and potentially quite harmful, but it's not new and their overall attitude about any long-time user inputs tends increasingly toward arrogance IMO. @FanJ -- You're welcome.
Thank you! In my case: the reg-key is pointing to the right location. But the file there C:\Program Files\Macrium\Common\MacriumService.exe was not updated.
