c# - Uninstall Custom Action Not Deleting Registry Key

Question

In my program, I create a registry key under current user. This program is run by the Task Scheduler with the highest permissions (S-1-5-32-545).

In my uninstall custom action, I have code to delete this key.

The code to delete the key works when I run as administrator.

The code does not work when run from the uninstall custom action.

I'm guessing that the reason it doesn't work in the latter case is because current user is different when the uninstaller executes than when local admin executes the code.

How can I delete this registry key when run from the uninstall custom action? How do I point the uninstall custom action to the correct current user?

Answer 1

I am largely unfamiliar with the use of task scheduler in Windows 10. I used it a lot back in the day in Windows 2000, and then it was very primitive - severely lacking in features I needed.

I'll just try to add some observations for you, bear with me if it isn't quite an answer. Please update your question with more details if this is the case - so we can understand exactly what you need.

---

Adding / Deleting Scheduled Tasks

I am wondering how you are creating the scheduled task? Are you hacking the registry directly? You should probably use schtasks.exe to create and delete it by command line with your WiX package. Here is one question / answer where they are dealing with the same issue: WIX Create Scheduled Task.

You already know this, but this is for others too:

1. Create your scheduled task manually using the scheduled task console.
   • Hold down Windows Key, tap R
   • Type in: taskschd.msc and press Enter
2. Now create your task manually in the scheduled task GUI and test it.
3. Create / Delete the scheduled task with schtasks.exe via a Quiet Execution Custom Action in your WiX package.
   • You can export an XML with the task settings and use it with schtasks.exe. I haven't tested this, but there is a sample here: Use an XML task file with Schtasks.exe in your WiX package.
   • You can also push command lines with MSI properties as shown here: WIX Create Scheduled Task.

---

Storage of Scheduled Tasks

It seems the scheduled tasks are not stored in the user section of the registry (HKCU), but on disk and in the per-machine section of the registry (HKLM): Where does Windows store the settings for Scheduled Tasks console? This should mean that they are deletable for all users on the machine by simply deleting them on uninstall. How does your HKCU registry key enter the picture? Here is the MSDN page on Schtasks.exe.

---

Alternatives to Scheduled Tasks

Just for the record, there are some alternatives to running your application as a scheduled task which may be better or easier than a scheduled task:

1. You can run your application as a Windows service.
   • This is a developer heavy "solution" requiring code changes, but is probably the most reliable - especially for business critical stuff.
   • See this summary: When should I use a scheduled task instead of a Windows Service?
     • Windows Services are more reliable for 24/7 tasks.
     • Scheduled tasks for stuff that happens "every now and then" (even once at logon).
     • "In summary, a scheduled task is often better for periodic, maintenance-type chores that don't demand sophisticated control".
   • Services should normally be run as LocalService, LocalSystem, Network Service - without a GUI - but it can also be run with user credentials.
   • Windows Services Frequently Asked Questions (FAQ). Just for reference and "safekeeping" of the link.
   • See some information on different service accounts you can use here: The difference between the 'Local System' account and the 'Network Service' account?
   • Does your application present an actual GUI to the user? It seems this is no longer possible (since Vista): interactive services. I have asked whether this is accurate or not or if "history has changed again". Phil Wilson (MSI expert) can probably tell us - I read an article of his on services back in the day.
2. You can use the startup folder for allusers as suggested here.
   • There are several options here. Please check link. There are further links in the linked article that should be worth a quick read.

3. Register in the registry to launch on boot / login.

   • Nice Tool: autoruns64.exe. If you really want to figure out a plethora of ways to run something on boot (by registering it in the registry), you could use the Sysinternals tool autoruns64.exe (that is a direct download link from the live sysinternals tool share, here is the Microsoft page).
   • This tool really shows you just how many ways things can be scheduled to run when the system starts up by being registered "somewhere in the registry". Drivers, services, scheduled tasks, IE, WinLogon, and much more. Perhaps uncheck the "Hide" entries in the Options menu to be truly perplexed by the number of relevant keys (heaps of malware vectors).

   • Warning: this tool is not for normal users. It has all the rope you need to shoot yourself in the foot if you don't know what you are disabling. Developer / sys-admin only please. Strangely enough it doesn't look like the startup folders in the user-profile are listed in the tool - I guess it is a tool concerned with registry-based launchers only. A screenshot I found:

   •