Repair MSI Windows installer. Cleanup Obsolete. MSI and. MSP files in the Windows…

Windows Installer EOP (CVE-2023-21800)

TL;DR: This blog post describes the details and methodology of our research targeting the Windows Installer (MSI) installation technology. If you’re only interested in the vulnerability itself, then jump right there

Introduction

Recently, I decided to research a single common aspect of many popular Windows applications. their MSI installer packages.

Not every application is distributed this way. Some applications implement custom bootstrapping mechanisms, some are just meant to be dropped on the disk. However, in a typical enterprise environment, some form of control over the installed packages is often desired. Using the MSI packages simplifies the installation process for any number of systems and also provides additional benefits such as automatic repair, easy patching, and compatibility with GPO. A good example is Google Chrome, which is typically distributed as a standalone executable, but an enterprise package is offered on a dedicated domain.

Another interesting aspect of enterprise environments is a need for strict control over employee accounts. In particular, in a well-secured Windows environment, the rule of least privileges ensures no administrative rights are given unless there’s a really good reason. This is bad news for malware or malicious attackers who would benefit from having additional privileges at hand.

During my research, I wanted to take a look at the security of popular MSI packages and understand whether they could be used by an attacker for any malicious purposes and, in particular, to elevate local privileges.

Typical installation

It’s very common for the MSI package to require administrative rights. As a result, running a malicious installer is a straightforward game-over. I wanted to look at legitimate, properly signed MSI packages. Asking someone to type an admin password, then somehow opening elevated cmd is also an option that I chose not to address in this blog post.

Let’s quickly look at how the installer files are generated. Turns out, there are several options to generate an MSI package. Some of the most popular ones are WiX Toolset, InstallShield, and Advanced Installer. The first one is free and open-source, but requires you to write dedicated XML files. The other two offer various sets of features, rich GUI interfaces, and customer support, but require an additional license. One could look for generic vulnerabilities in those products, however, it’s really hard to address all possible variations of offered features. On the other hand, it’s exactly where the actual bugs in the installation process might be introduced.

During the installation process, new files will be created. Some existing files might also be renamed or deleted. The access rights to various securable objects may be changed. The interesting question is what would happen if unexpected access rights are present. Would the installer fail or would it attempt to edit the permission lists? Most installers will also modify Windows registry keys, drop some shortcuts here and there, and finally log certain actions in the event log, database, or plain files.

The list of actions isn’t really sealed. The MSI packages may implement the so-called custom actions which are implemented in a dedicated DLL. If this is the case, it’s very reasonable to look for interesting bugs over there.

Once we have an installer package ready and installed, we can often observe a new copy being cached in the C:\Windows\Installers directory. This is a hidden system directory where unprivileged users cannot write. The copies of the MSI packages are renamed to random names matching the following regular expression: ^[0-9a-z]\.MSI. The name will be unique for every machine and even every new installation. To identify a specific package, we can look at file properties (but it’s up to the MSI creator to decide which properties are configured), search the Windows registry, or ask the WMI:

Get-WmiObject.class Win32_Product | ? _.Name.like Chrome | select IdentifyingNumber,Name IdentifyingNumber Name- B460110D-ACBF-34F1-883C-CC985072AF9E Google Chrome

Referring to the package via its GUID is our safest bet. However, different versions of the same product may still have different identifiers.

Assuming we’re using an unprivileged user account, is there anything interesting we can do with that knowledge?

Repair process

The builtin Windows tool, called msiexec.exe. is located in the System32 and SysWOW64 directories. It is used to manage the MSI packages. The tool is a core component of Windows with a long history of vulnerabilities. As a side note, I also happen to have found one such issue in the past (CVE-2021-26415). The documented list of its options can be found on the MSDN page although some additional undocumented switches are also implemented.

The flags worth highlighting are:

• /lvx to log any additional details and search for interesting events
• /qn to hide any UI interactions. This is extremely useful when attempting to develop an automated exploit. On the other hand, potential errors will result in new message boxes. Until the message is accepted, the process does not continue and can be frozen in an unexpected state. We might be able to modify some existing files before the original access rights are reintroduced.

The repair options section lists flags we could use to trigger the repair actions. These actions would ensure the bad files are removed, and good files are reinstalled instead. The definition of bad is something we control, i.e., we can force the reinstallation of all files, all registry entries, or, say, only those with an invalid checksum.

Most of the msiexec actions will require elevation. We cannot install or uninstall arbitrary packages (unless of course the system is badly misconfigured). However, the repair option might be an interesting exception! It might be, because not every package will work like this, but it’s not hard to find one that will. For these, the msiexec will auto-elevate to perform necessary actions as a SYSTEM user. Interestingly enough, some actions will be still performed using our unprivileged account making the case even more noteworthy.

The impersonation of our account will happen for various security reasons. Only some actions can be impersonated, though. If you’re seeing a file renamed by the SYSTEM user, it’s always going to be a fully privileged action. On the other hand, when analyzing who exactly writes to a given file, we need to look at how the file handle was opened in the first place.

We can use tools such as Process Monitor to observe all these events. To filter out the noise, I would recommend using the settings shown below. It’s possible to miss something interesting, e.g., a child processes’ actions, but it’s unrealistic to dig into every single event at once. Also, I’m intentionally disabling registry activity tracking, but occasionally it’s worth reenabling this to see if certain actions aren’t controlled by editable registry keys.

Another trick I’d recommend is to highlight the distinction between impersonated and non-impersonated operations. I prefer to highlight anything that isn’t explicitly impersonated, but you may prefer to reverse the logic.

Then, to start analyzing the events of the aforementioned Google Chrome installer, one could run the following command:

The stream of events should be captured by ProcMon but to look for issues, we need to understand what can be considered an issue. In short, any action on a securable object that we can somehow modify is interesting. SYSTEM writes a file we control? That’s our target.

Typically, we cannot directly control the affected path. However, we can replace the original file with a symlink. Regular symlinks are likely not available for unprivileged users, but we may use some tricks and tools to reinvent the functionality on Windows.

Windows EoP primitives

Although we’re not trying to pop a shell out of every located vulnerability, it’s interesting to educate the readers on what would be possible given some of the Elevation of Privilege primitives.

With an arbitrary file creation vulnerability we could attack the system by creating a DLL that one of the system processes would load. It’s slightly harder, but not impossible, to locate a Windows process that loads our planted DLL without rebooting the entire system.

Having an arbitrary file creation vulnerability but with no control over the content, our chances to pop a shell are drastically reduced. We can still make Windows inoperable, though.

With an arbitrary file delete vulnerability we can at least break the operating system. Often though, we can also turn this into an arbitrary folder delete and use the sophisticated method discovered by Abdelhamid Naceri to actually pop a shell.

The list of possible primitives is long and fascinating. A single EoP primitive should be treated as a serious security issue, nevertheless.

One vulnerability to rule them all (CVE-2023-21800)

I’ve observed the same interesting behavior in numerous tested MSI packages. The packages were created by different MSI creators using different types of resources and basically had nothing in common. Yet, they were all following the same pattern. Namely, the environment variables set by the unprivileged user were also used in the context of the SYSTEM user invoked by the repair operation.

Although I initially thought that the applications were incorrectly trusting some environment variables, it turned out that the Windows Installer’s rollback mechanism was responsible for the insecure actions.

7-zip

7-Zip provides dedicated Windows Installers which are published on the project page. The following file was tested:

To better understand the problem, we can study the source code of the application. The installer, defined in the DOC/7zip.wxs file, refers to the ProgramMenuFolder identifier.

ID=ProgramMenuFolder Name=PMenu LongName=Programs ID=PMenu Name=7zip LongName=7-Zip / ID=Help Guid=(var.compHelp) ID=_7zip.chm Name=7-zip.chm DiskId=1 ID=startmenuHelpShortcut Directory=PMenu Name=7zipHelp LongName=7-Zip Help /

The ProgramMenuFolder is later used to store some components, such as a shortcut to the 7-zip.chm file.

The installer sets the ProgramMenuFolder property to the full path of the Program Menu folder for the current user. If an “All Users” profile exists and the ALLUSERS property is set, then this property is set to the folder in the “All Users” profile.

In other words, the property will either point to the directory controlled by the current user (in %APPDATA% as in the previous example), or to the directory associated with the “All Users” profile.

While the first configuration does not require additional explanation, the second configuration is tricky. The C:\ProgramData\Microsoft\Windows\Start Menu\Programs path is typically used while C:\ProgramData is writable even by unprivileged users. The C:\ProgramData\Microsoft path is properly locked down. This leaves us with a secure default.

However, the user invoking the repair process may intentionally modify (i.e., poison) the PROGRAMDATA environment variable and thus redirect the “All Users” profile to the arbitrary location which is writable by the user. The setx command can be used for that. It modifies variables associated with the current user but it’s important to emphasize that only the future sessions are affected. A completely new cmd.exe instance should be started to inherit the new settings.

Instead of placing legitimate files, a symlink to an arbitrary file can be placed in the %PROGRAMDATA%\Microsoft\Windows\Start Menu\Programs\7-zip\ directory as one of the expected files. As a result, the repair operation will:

• Remove the arbitrary file (using the SYSTEM privileges)
• Attempt to restore the original file (using an unprivileged user account)

The second action will fail, resulting in an Arbitrary File Delete primitive. This can be observed on the following capture, assuming we’re targeting the previously created C:\Windows\System32\doyensec.txt file. We intentionally created a symlink to the targeted file under the C:\FakeProgramData\Microsoft\Windows\Start Menu\Programs\7-zip\7-Zip Help.lnk path.

Firstly, we can see the actions resulting in the REPARSE status. The file is briefly processed (or rather its attributes are), and the SetRenameInformationFile is called on it. The rename part is slightly misleading. What is actually happening is that file is moved to a different location. This is how the Windows installer creates rollback instructions in case something goes wrong. As stated before, the SetRenameInformationFile doesn’t work on the file handle level and cannot be impersonated. This action runs with the full SYSTEM privileges.

Later on, we can spot attempts to restore the original file, but using an impersonated token. These actions result in ACCESS DENIED errors, therefore the targeted file remains deleted.

The same sequence was observed in numerous other installers. For instance, I worked with PuTTY’s maintainer on a possible workaround which was introduced in the 0.78 version. In that version, the elevated repair is allowed only if administrator credentials are provided. However, this isn’t functionally equal and has introduced some other issues. The 0.79 release should restore the old WiX configuration.

Redirection Guard

The issue was reported directly to Microsoft with all the above information and a dedicated exploit. Microsoft assigned CVE-2023-21800 identifier to it.

It was reproducible on the latest versions of Windows 10 and Windows 11. However, it was not bounty-eligible as the attack was already mitigated on the Windows 11 Developer Preview. The same mitigation has been enabled with the 2022-02-14 update.

In October 2022 Microsoft shipped a new feature called Redirection Guard on Windows 10 and Windows 11. The update introduced a new type of mitigation called ProcessRedirectionTrustPolicy and the corresponding PROCESS_MITIGATION_REDIRECTION_TRUST_POLICY structure. If the mitigation is enabled for a given process, all processed junctions are additionally verified. The verification first checks if the filesystem junction was created by non-admin users and, if so, if the policy prevents following them. If the operation is prevented, the error 0xC00004BC is returned. The junctions created by admin users are explicitly allowed as having a higher trust-level label.

In the initial round, Redirection Guard was enabled for the print service. The 2022-02-14 update enabled the same mitigation on the msiexec process.

This can be observed in the following ProcMon capture:

The msiexec is one of a few applications that have this mitigation enforced by default. To check for yourself, use the following not-so-great code:

#include #include #include #include #include #include using AutoHandle = std::unique_ptrstd::remove_pointer_tHANDLE, decltype(CloseHandle); using Proc = std::pairstd::wstring, AutoHandle; std::vectorProc getRunningProcesses std::vectorProc processes; std::unique_ptrstd::remove_pointer_tHANDLE, decltype(CloseHandle) snapshot(CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0), CloseHandle); PROCESSENTRY32 pe32; pe32.dwSize = sizeof(pe32); Process32First(snapshot.get, pe32); do auto h = OpenProcess(PROCESS_QUERY_INFORMATION, FALSE, pe32.th32ProcessID); if (h) processes.emplace_back(std::wstring(pe32.szExeFile), AutoHandle(h, CloseHandle)); while (Process32Next(snapshot.get, pe32)); return processes; int main auto runningProcesses = getRunningProcesses; PROCESS_MITIGATION_REDIRECTION_TRUST_POLICY policy; for (auto process : runningProcesses) auto result = GetProcessMitigationPolicy(process.second.get, ProcessRedirectionTrustPolicy, policy, sizeof(policy)); if (result (policy.AuditRedirectionTrust | policy.EnforceRedirectionTrust | policy.Flags)) printf(%ws:\n, process.first.c_str); printf(\tAuditRedirectionTrust: % d\n\tEnforceRedirectionTrust : % d\n\tFlags : % d\n, policy.AuditRedirectionTrust, policy.EnforceRedirectionTrust, policy.Flags);

The Redirection Guard should prevent an entire class of junction attacks and might significantly complicate local privilege escalation attacks. While it addresses the previously mentioned issue, it also addresses other types of installer bugs, such as when a privileged installer moves files from user-controlled directories.

Cleanup Obsolete.MSI and.MSP files in the Windows Installer Folder to Free Disk Space

When you install a program in Windows, the program’s.MSI setup package gets copied to the Installer folder. The Installer folder is a protected folder, with System Hidden attributes, and is found under your Windows folder.

What is Windows Installer folder?

The Installer directory is meant to be a cache location for installer data files for various applications installed on the computer.

Sometime later, you may decide you want to repair, uninstall or reinstall the program via Apps Features or Programs Features in the Control Panel. At that time, the system needs the.MSI package from the Installer folder to repair, reinstall or cleanly uninstall the software.

If the corresponding setup package (.MSI or.msp) file isn’t found, Windows throws the error “The installation source for this product is not available. Verify that the source exists and that you can access it.” when trying to repair or uninstall the problem.

Windows Installer registry entries

When a software setup (i.e., Windows Installer package) is run, registry entries are created for that program under the following branches:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall HKEY_CLASSES_ROOT\Installer\Products HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\\Products

The SID can be something like S-1-5-18. S-1-5-18 is the Security Identifier for “Local System” account. If the software you’ve installed used your account’s credentials or token, then it’s written under your key in the registry. See Microsoft article Well-known security identifiers in Windows operating systems.

Note: For 32-bit programs installed on a 64-bit Windows computer, the entries get recorded under the equivalent SOFTWARE\WOW6432Node registry node.

How to Safely Cleanup the Windows Installer Folder to Free Disk Space

Over time, the Installer directory may grow and consume a massive amount of hard disk space. You may be wondering if you can delete files in the Windows\Installer directory or not.

Can you arbitrarily delete the Windows\Installer folder or some of its files?

In short, NO! You should never randomly delete the contents of the C:\Windows\Installer folder manually. The system automatically manages it.

Sometimes during software uninstall routine, Windows installer patches may get orphaned. i.e., when a program is uninstalled, the corresponding.MSI package is somehow left behind in the Windows Installer folder. Only the orphaned packages can be deleted.

So how do you find the orphaned.MSI files in the Windows Installer folder?

There is a useful program called PatchCleaner that will identify orphaned files in the Installer folder. PatchCleaner then offers you to delete orphaned files or move them to a different location to test.

Download PatchCleaner from homedev software, and run it.

PatchCleaner enumerates the list of installers, the component codes and the corresponding.MSI file names programmatically, using Windows Scripting.

Then it compares the list of package files located in the Installer folder with the Products list found in the registry. The.MSI files which have no reference in the registry are the orphan files.

Here is the details of “in use” or valid program entries.

And the detailed information of the orphaned entries are shown as well:

You can either delete the orphaned setup package or move it to another folder and then safely delete it after a few days.

Hope this article helped you recover valuable disk space by safely cleanup up the Windows Installer folder on your computer.

Solved: Windows Installer not working properly in Windows 10

Windows Installer is a core service on Microsoft Windows that manages the installation or uninstallation of everything in the Windows system including apps, features, and many other things. If for some unexpected reason, it breaks or the Windows installer stops working you will be stuck with new installations and even upgrades of apps. And while trying to install or uninstall a program you might see an error notification “Windows Installer Service could not be accessed”, “There’s a problem with this Windows Installer Package”, “Installation Package could not be opened”, and more.

Pro Tip: If you are not able to install software that is downloaded from the internet, throwing the error “Installation package could not be opened” then it’s probably a security issue. Windows system blocked the application as it does not trust them. To fix this problem You need to unblock it or disable your antivirus

Windows installer not working Windows 10

There is no exact reason responsible for the Windows installer not working. If you are unable to install certain applications due to Windows Installer Service could not be accessed error message, apply the solutions listed below.

Remove the Earlier Version of the Software

If you are getting error 1719 Windows installer could not be accessed while installing a new application then check If you already have the older version of the program you want to install on your computer. Because Most of the time the old version of software always gives rise to some unexpected issues.

• Press Windows key R, type appwiz.cpl and click OK to open Programs and Features
• locate the program you want to remove, right-click it then select uninstall from the context menu,
• Follow on-screen instructions to complete the uninstall process, and reboot your PC.
• Now try to reinstall the program to check whether the error 1719 Windows Installer service could not be accessed is solved.

Start Microsoft Installer Service

If the Windows installer service stopped or not started due to unknown reasons, you might experience, Windows Installer Service could not be accessed while install or uninstall programs on the Windows system. You need to manually start the Windows Installer Service to fix the problem.

Start Windows Installer Service using Command Prompt

• Type cmd in the Windows Search box and right-click on Command Prompt, select “Run as administrator”.
• Type command netstart MSIServer and hit Enter.

Start Windows Installer using the Windows Service console

• Press Windows key R, type services.msc and click ok,
• Scroll down and locate Windows Installer and check its state.
• If it’s not running, right-click on Windows Installer and select “Start”.
• If it’s already running then right-click on Windows Installer select restart.

Re-register Microsoft Installer Service

If still getting the “Windows Installer Service could not be accessed” error while installing programs on the Windows system? try to re-register the Microsoft Installer Service.

Open the command prompt as administrator, and perform the following commands and hit Enter after each command. Once done exit the command prompt and restart your PC.

%windir%\system32\msiexec.exe /unregister %windir%\system32\msiexec.exe /regserver %windir%\syswow64\msiexec.exe /unregister %windir%\syswow64\msiexec.exe /regserver

Reinstall Windows Installer

Still, need help? try to reinstall Windows Installer following the steps below to fix the Windows Installer service could not be accessed error on Windows 10.

• Search for cmd on start menu, right-click on command prompt select run as administrator,
• Next, type the following command and hit Enter after each command

cd %windir%\system32 ren MSI.dll MSI.old ren msiexec.exe msiexec.old ren msihnd.dll msihnd.old

• Once done close the command prompt using the exit command, and reboot your computer.
• Next, visit Microsoft’s official website and download the latest Windows Installer.
• Double-click the file to start the installation, and follow on screen instructions once done reboot your computer.
• Now try to install the program you need and check whether the issue of Windows Installer not working has been solved.

In addition, run the DISM (Deployment Image Servicing and Management) command and system file checker utility that checks Windows health and restores missing system files with the correct one.

Did these solutions help fix the Windows installer not working properly on Windows 10? Let us know on the Комментарии и мнения владельцев below,

Top 4 Ways to Windows Installer Service Could Not Be Accessed

When you are trying to install a new program on Windows 10 you may receive an error message Windows Installer service could not be accessed. But, don’t worry. This post will show you the top 4 ways to solve the Windows Installer not working Windows 10 issue. After fixing this problem, use MiniTool software to create a system image.

Windows Installer Service Could Not Be Accessed

It is annoying that you can’t successfully install a new program on Windows 10/8/7. For example, you may receive an error message that says that Windows Installer service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your personnel for assistance, as shown in following picture:

As a matter of fact, many computer users complain that they have met this error message and they don’t know how to fix this Windows Installer error. This error may occur when Windows Installer files are damaged or missing.

However, don’t worry. You have come to the right place. This article will introduce 4 ways to solve the Windows Installer service cannot be accessed issue. You can try to use them one by one.

Ways to Fix Windows Installer Service Could Not Be Accessed

Here, in this part, we will show you the 4 ways to solve error 1719 Windows Installer service could not be accessed in detail. Actually, each method is easy to operate.

Solution 1. Remove the Earlier Version of the Software

In order to solve the Windows Installer service could not be accessed issue, it is recommended to remove the previous version of software since the old version of software always gives rise to some unexpected issues. Plus uninstalling the previous program is always an effective way to solve Windows Installer service could not be accessed issue.

Furthermore, this method is pretty easy to operate. If you don’t know how to uninstall a piece of software, you can read the following instructions:

Step 1: Type Control Panel in the search box of Windows 10 and click it to enter its main interface.

Step 2: Click Programs and Features to continue. Then, choose the program you want to remove and right-click it to choose Uninstall from the context menu.

After you have successfully uninstalled the previous version of the software you can reinstall the program to check whether the error 1719 Windows Installer service could not be accessed is solved.

Solution 2. Manually Start Microsoft Installer Service

If the first method is not working, you can go on to the second solution. Try to manually start the Microsoft Installer Service to fix the Windows Installer not working Windows 10 issue. Microsoft Installer is a utility application in the Windows operating system which is used to install, maintain or remove software.

So, when you meet Windows Installer service could not be accessed you can try to check whether the Window Installer has stopped. Here, we will show you how to start the Microsoft Installer Service step by step.

Step 1: Press the Windows key and R key together to launch the Run dialog. Then input services.msc in the Run box and click OK or hit Enter to continue.

Step 2: Then the Service window will pop up. You need to choose Windows Installer to continue.

Step 3: Double-click the Windows Installer service to go to the Windows Installer Properties window. You need to change the Service status from Stopped to Running by clicking the Start button. Then click OK to continue.

After that, you can reboot your computer to check whether the issue Windows Installer service could not be accessed is solved.

Solution 3. Re-register Microsoft Installer Service

Now, you can go to the third method to fix the Windows Installer error if the above two methods have failed. Then, you can try to re-register the Microsoft Installer Service. Then the detailed operations to re-register Microsoft Installer service are as follows:

Step 1: Type cmd in the search box of Windows 10 and choose Command Prompt to continue.

Step 2: In the Command Prompt window you need to input the following commands and hit Enter after each command to continue:

%windir%\system32\msiexec.exe /unregister%windir%\system32\msiexec.exe /regserver%windir%\syswow64\msiexec.exe /unregister%windir%\syswow64\msiexec.exe /regserver

Step 3: You can type exit command to close the command prompt window.

After you have finished the above steps you can restart your computer and reinstall the program to check whether the issue Windows Installer service cannot be accessed is solved.

Solution 4. Reinstall Windows Installer

Now, we will go to the fourth method. In order to solve the Windows Installer service could not be accessed you can try to reinstall Windows Installer. We will tell you how to reinstall Windows Installer in detail.

Step 1: Press the Windows key and R key together to launch the Run dialog. Then type cmd in the box and click OK or hit Enter to continue.

Step 2: Then you need to type the following command and hit Enter after each command to continue:

cd %windir%\system32ren MSI.dll MSI.oldren msiexec.exe msiexec.oldren msihnd.dll msihnd.old

Step 3: Then, you can exit the command prompt Windows by typing exit command. After that, you can reboot your computer and update the Windows Installer to the latest version. In order to update to latest one you need to go to the Microsoft official website to download and install the latest Windows Installer.

Step 4: After the latest Windows Installer in installed you can restart your computer and install the program you need and check whether the issue Windows Installer not working Windows 10 has been solved.

Top Recommendation

After you have solved the Windows Installer service could not be accessed issue you had better create a system image to avoid a similar error in the coming days. With a system image, you can take advantage of it to restore it to the previous state instead of spending so much time to solve the problem when you come across a similar issue again.

MiniTool ShadowMaker

There are two ways to create a system image. On the one hand, Windows snap-in program can help you to create a system image, but on the other hand, you can use a piece of third-party software to create a system image. Here, we recommend MiniTool ShadowMaker.

MiniTool ShadowMaker, the best backup software for Windows 10, is a good assistant to create a system image. With its various powerful features, it can back up the operating system, files and folders, disks, partitions and so on.

In addition, it also has a Restore feature which plays an essential role in performing recovery solutions. For instance, it can be used to restore computer to an earlier date when some accidents occur. Also, MiniTool ShadowMaker is an automatic tool which can safeguard your computer and data well.

So as to create a system image to protect computer and data, you can download MiniTool ShadowMaker Trial which can be used for 30 days by clicking on the following button or choose to purchase an advanced edition.

Now, we will show you how to back up Windows 10 with MiniTool ShadowMaker.

Step 1: Install the backup tool and launch it. Then click Keep Trial. Then click Connect in the Local tab to enter its main interface.

Step 2: MiniTool ShadowMaker will remind you to back up immediately if you haven’t used this software to perform any backup action. Thus, you just need to click SET UP BACKUP to continue. MiniTool ShadowMaker is designed to back up the operating system by default.

In addition, you can also click the Backup tab to enter the backup interface. Then, you can click the Source and Destination tabs to choose what you want to back up and decide where you want to save the backup image.

Step 3: After that, you can click Back up Now to perform the action immediately. You can also choose Back up Later from the drop-down menu to delay the process.

Note: The Schedule setting can help to set backup matters on a regular basis such as daily/weekly/monthly/on event so as to protect the data and computer well. Scheme can help to manage disk free space by deleting previous backup versions. Options offers some advanced backup parameters. For example, you can set the image compression level.

Step 4: After you have created a system image you had better create a bootable mediathat is used to boot your computer into MiniTool Recovery Environment when your computer can’t normally boot from the operating system. Thus, you can go to the Tools tab to choose the Media Builder feature to continue.

As you can see, the operation methods of creating a system image by MiniTool ShadowMaker are pretty easy. Thus, you can download it to create a system image for the sake of protecting your PC and data well.

Windows Snap-in Program

In the above part, we have introduced how to create a system image with MiniTool ShadowMaker. Now, we will show you another way that is using Windows snap-in tool to create a system image so that you can restore your PC to its previous state. You can see the detailed operations in the following part.

Step 1: Type Control Panel in the search box of Windows 10. Then, choose it to enter its main interface.

Step 2: Choose Backup and Restore(Windows 7) to continue.

Step 3: Then click Create a system image in the left window to continue.

Step 4: Next, you need to choose a destination to save the system image. Here, you can choose a hard disk, a DVD disk and a network location. Then click Next to continue.

Note: But, please note that you can’t choose a USB drive as a destination. Otherwise, you will receive an error message that says the drive is not a valid backup location.

Step 5: Then you need to choose the source to back up. The System Reserved partition and C drive are checked by default. If you want to back up other partitions, you can check them together. Then, click Next to continue.

Step 6: Then, you are required to confirm the location and backup source. After that, click Start backup to perform this process immediately.

After that, you need to wait patiently for the process to be completed.

Bottom Line

In this article, we have introduced 4 solutions for the issue the Windows Installer service could not be accessed. You can choose any one of the solutions to solve the Window Installer not working problem. If you have any better solutions you can share them in the comment zone.

In addition, it is recommended to create a system image so as to perform some recovery solutions when encountering some accidents. There are two ways to create a system image, so you can choose either one.

From comparison, we think MiniTool ShadowMaker is more convenient to create a system image. In addition, if you have any problem with MiniTool ShadowMaker, please don’t hesitate to contact us via the email support@minitool.com.

About The Author

Tina is a technology enthusiast and joined MiniTool in 2018. As an editor of MiniTool, she is keeping on sharing computer tips and providing reliable solutions, especially specializing in Windows and files backup and restore. Besides, she is expanding her knowledge and skills in data recovery, disk space optimizations, etc. On her spare time, Tina likes to watch movies, go shopping or chat with friends and enjoy her life.

Copyright © 2023 MiniTool® Software Limited, All Rights Reserved.